2. ¿Que es ?
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está
respaldado por el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un
estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como
procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
3. HISTORIA.
Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric, en 1994, la
compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época:
Object-Modeling Technique (OMT) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch (de
Grady Booch) que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del
método de ingeniería de software orientado a objetos. Jacobson se unió a Rational, en 1995, después de que su compañía
Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se
sabía de sus constantes discusiones sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de
objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un "lenguaje
unificado de modelado" abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de
objetos durante la OOPSLA '96; eligieron "cajas" para representar clases en lugar de la notación de Booch que utilizaba
símbolos de "nubes".
Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue organizado un consorcio internacional
llamado UML Partners en 1996 para completar las especificaciones del UML, y para proponerlo como una respuesta al
OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante
el mismo mes, la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed
4. UML 1.x
Como notación de modelado, la influencia de la OMT domina UML (por ejemplo, el uso de rectángulos para clases y objetos).
Aunque se quitó la notación de "nubes" de Booch, sí se adoptó la capacidad de Booch para especificar detalles de diseño en
los niveles inferiores. La notación de "Casos de Uso" del Objectory y la notación de componentes de Booch fueron integrados
al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la
revisión mayor de UML 2.0.
Conceptos de muchos otros métodos orientados a objetos (MOO) fueron integrados superficialmente en UML con el
propósito de hacerlo compatible con todos los MOO. Además, el grupo tomó en cuenta muchos otros métodos de la época,
con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en
una gran variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de solamente un usuario a sistemas
concurrentes y distribuidos.
UML 2.x
UML ha madurado considerablemente desde UML 1.1, varias revisiones menores (UML 1.3, 1.4 y 1.5) han corregido
defectos y errores de la primera versión de UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el
OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2, aparecieron en 2007,
seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado
oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" que fue
formalmente liberada en junio de 2015.
5. DIAGRAMA DE CLASES:
Un diagrama de clases en Lenguaje Unificado de Modelado es un tipo de diagrama de estructura estática que describe la
estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones, y las relaciones entre los objetos.
La generación de códigos es automáticamente cuando acabe su diagrama.
VENTAJAS:
Genera un código automáticamente
Representa las relaciones entre las clases de sistema
Se diseña los componentes de la sistemas
Se posibilita una reducción de acoplamiento
DESVENTAJAS:
El método tiende hacer muy lento
La instalación es muy costosa
6. DIAGRAMA DE COLABORACIÓN:
Es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los
diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran
explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una
dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como
los hilos concurrentes.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
Permite elegir el orden en que pueden hacerse las cosas.
Puede describir procesos o causas de uso.
Muestra los aspectos dinámicos de un sistema.
DESVENTAJAS:
No indican de forma explícita que los objetos que ejecutan qué actividades ni tampoco la
7. DIAGRAMA DE SECUENCIA:
Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML .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. A menudo es útil para complementar a un diagrama de clases, pues el diagrama de secuencia se podría
describir de manera informal como "el diagrama de clases en movimiento", por lo que ambos deben estar relacionados
entre sí.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código en java
VENTAJAS:.
Da la posibilidad de representar los mensajes en función del tiempo.
La separación de los mensajes no indica intervalos o cantidades de tiempo, solo ordenación temporal.
Es posible añadir restricciones temporales
DESVENTAJA:
Una representación de un diagrama de secuencia demasiado largo, puede ser difícilmente entendido por alguien ajeno al
sistema.
8. DIAGRAMA DE CASOS DE USO:
Un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado
Unificado, 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.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
Su ventaja principal es la facilidad para interpretarlos, y hacen que sean especialmente útiles en la comunicación con el
cliente.
Identifica requerimientos estancados, dentro de un conjunto de requerimientos.
Permite representar más de un rol para cada afectado.
DESVENTAJAS:
En sistemas grandes toman mucho tiempo para definir todos los casos de uso.
9. DIAGRAMA DE COMPONENTES:
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las
dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas,
módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software
pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloS sin Título)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
Representan aspectos físicos del sistema.
Se pueden construir a partir del modelo de clases y escribir desde cero para el nuevo sistema.
Se puede importar de otros proyectos o de productos terceros.
Desventajas:
No representan aspectos irremplazables del sistema
10. DIAGRAMA DE ESTADO:
Este muestra la secuencia de estados por los que pasa bien un caso de uso, un objeto a lo largo de su vida, o bien todo el
sistema. Es una forma de representación gráfica más intuitiva de los autómatas finitos basadas en dígrafos con arcos
acotados llamados transiciones en los cuales se ponen los símbolos de tránsito entre un vértice (estado) y otro y se
identifican los estados de partida y los de aceptación del resto.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
El Diagrama de Estados tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al
hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, que espera
éste lograr al utilizar el sistema A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas
centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la
priorización del requerimiento.
Desventajas
11. DIAGRAMA DE DESPLIEGUE:
Los diagramas de despliegue son los complementos de los diagramas de componentes que, unidos, proveen la vista de
implementación del sistema. Describen la topología del sistema la estructura de los elementos de hardware y el software
que ejecuta cada uno de ellos.Los diagramas de despliegue representan a los nodos y sus relaciones. Los nodos son
conectados por asociaciones de comunicación tales como enlaces de red, conexiones TCP/IP.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
Muestra un conjunto de nodos y sus relaciones.
Se utilizan para describir la vista de despliegue estática de un sistema.
Se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o más componentes.
DESVENTAJAS:
La posible falla en la modelación de un hardware.
Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso
migrar de un nodo a otro.El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la
topología del sistema.
12. DIAGRAMA DE ACTIVIDADES:
Un diagrama de actividades ha sido diseñado para mostrar una visión simplificada de lo que ocurre durante una operación
o proceso. Básicamente es una extensión de un diagrama de estados con la diferencia que el diagrama de actividades
resalta las actividades; veremos que uno de los aspectos más importantes dentro del diagrama de actividades es su
facultad para expandirse dandonos a entrever o mejor mostrandonos quién tiene responsabilidades dentro de un proceso;
dándonos como resultado el modelamiento mucho más definido de dicho proceso.
La generación de códigos es :Realizar el diagrama-CLick derecho en (ModeloSinTitulo)-Seleccionar (Crear nueva Clase)-
Poner en propiedades la acción-Saldrá directamente el código a java
VENTAJAS:
Permite elegir el orden en que pueden hacerse las cosas.
Puede describir procesos o casos de uso.
Establece las reglas de secuencia a seguir.
Ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso.
DESVENTAJAS:
La gran desventaja de los diagramas de actividad es que no indican de forma explícita qué objetos ejecutan qué
actividades ni tampoco la forma en que el servicio de mensajería trabaja entre ellos. Para mostrar tales interacciones de