SlideShare una empresa de Scribd logo
1 de 12
UML.
¿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.
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
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.
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
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
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.
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.
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
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
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.
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

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

¿Que es uml ? ACTVIDAD No 4 Jennifer Garcia Montiel 2 "D"
¿Que es uml ? ACTVIDAD No 4  Jennifer Garcia Montiel 2 "D"¿Que es uml ? ACTVIDAD No 4  Jennifer Garcia Montiel 2 "D"
¿Que es uml ? ACTVIDAD No 4 Jennifer Garcia Montiel 2 "D"
 
Curso Uml 1 Introduccion
Curso Uml   1 IntroduccionCurso Uml   1 Introduccion
Curso Uml 1 Introduccion
 
Equipo2
Equipo2Equipo2
Equipo2
 
UML
UMLUML
UML
 
HA2NV50 EQ8-StarUML
HA2NV50 EQ8-StarUMLHA2NV50 EQ8-StarUML
HA2NV50 EQ8-StarUML
 
Modelo dinamico
Modelo dinamicoModelo dinamico
Modelo dinamico
 
IntroduccióN Uml
IntroduccióN UmlIntroduccióN Uml
IntroduccióN Uml
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
 
Uml
UmlUml
Uml
 
UML para sistemas tiempo real - Carlos Restrepo
UML para sistemas tiempo real - Carlos RestrepoUML para sistemas tiempo real - Carlos Restrepo
UML para sistemas tiempo real - Carlos Restrepo
 
Presentación power point relational rose
Presentación power point relational rosePresentación power point relational rose
Presentación power point relational rose
 
IngenieríA De Software Uml
IngenieríA De Software UmlIngenieríA De Software Uml
IngenieríA De Software Uml
 
Diagramas de uml generacion de codigos
Diagramas de uml generacion de codigosDiagramas de uml generacion de codigos
Diagramas de uml generacion de codigos
 
Uml java
Uml javaUml java
Uml java
 
Tm02 introduccion a rational rose
Tm02 introduccion a rational roseTm02 introduccion a rational rose
Tm02 introduccion a rational rose
 
MODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UMLMODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UML
 
Historia del uml
Historia del umlHistoria del uml
Historia del uml
 
Lenguaje unificado de modelado
Lenguaje unificado de modeladoLenguaje unificado de modelado
Lenguaje unificado de modelado
 
Lese 2 - introduccion a rational rose
Lese 2 - introduccion a rational roseLese 2 - introduccion a rational rose
Lese 2 - introduccion a rational rose
 

Similar a UML Diagramas

Similar a UML Diagramas (20)

Uml
UmlUml
Uml
 
Umbrello UML Modeller
Umbrello UML ModellerUmbrello UML Modeller
Umbrello UML Modeller
 
Desarrollo de uml
Desarrollo de umlDesarrollo de uml
Desarrollo de uml
 
UML(Lenguaje Unificado de Modelado)
UML(Lenguaje Unificado de Modelado)UML(Lenguaje Unificado de Modelado)
UML(Lenguaje Unificado de Modelado)
 
uml
umluml
uml
 
Introduccion a UML
Introduccion a UMLIntroduccion a UML
Introduccion a UML
 
Uml juan pablo cueto galindo
Uml juan pablo cueto galindoUml juan pablo cueto galindo
Uml juan pablo cueto galindo
 
Sesion1.1 uml
Sesion1.1 umlSesion1.1 uml
Sesion1.1 uml
 
Objeto de Aprendizaje : Introducción a UML
Objeto de Aprendizaje : Introducción a UMLObjeto de Aprendizaje : Introducción a UML
Objeto de Aprendizaje : Introducción a UML
 
Presentacion uml
Presentacion umlPresentacion uml
Presentacion uml
 
Introducción a UML
Introducción a UMLIntroducción a UML
Introducción a UML
 
Trabajo uml romero
Trabajo uml romeroTrabajo uml romero
Trabajo uml romero
 
Trabajo uml romero
Trabajo uml romeroTrabajo uml romero
Trabajo uml romero
 
Trabajo uml romero
Trabajo uml romeroTrabajo uml romero
Trabajo uml romero
 
Trabajo uml romero
Trabajo uml romeroTrabajo uml romero
Trabajo uml romero
 
10753034(1).ppt
10753034(1).ppt10753034(1).ppt
10753034(1).ppt
 
Uml
UmlUml
Uml
 
Uml
UmlUml
Uml
 
Uml
UmlUml
Uml
 
Presentacion uml dian1_2003
Presentacion uml dian1_2003Presentacion uml dian1_2003
Presentacion uml dian1_2003
 

UML Diagramas

  • 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