Your SlideShare is downloading. ×
0
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Taller presentacion
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Taller presentacion

503

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
503
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
36
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Herramientas Informaticas UML y patrones de diseñoUniv. Marco Aurelio Avalos Nina
  • 2. Qué es UML? El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos. UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.
  • 3. Qué es UML? UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los objetos de un sistema programado.
  • 4. UML UML es un lenguaje de modelado que sirve para visualizar, especificar , construir y documentar un sistema software.
  • 5. UML para construir Es posible Ingeniería Directa hacer corresponder Modelo CÓDIGO con los UML lenguajes de Ingeniería Inversa programación
  • 6. Modelos y Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos
  • 7. Modelos y Diagramas Modelo: captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Diagrama: representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.
  • 8. Organización de Modelos Vista de Vista de Diseño Implementación Vista de los Casos de Uso Vista de Vista de Procesos Despliegue
  • 9. Relación Vistas - DiagramasVista de casos de uso Diagramas de casos de uso Diagramas de actividadesVista de diseño Diagramas de clases Diagramas de interacción Diagramas de estadosVista de procesos Diagramas de clase Diagramas de interacciónVista de implementación Diagramas de componentesVista de despliegue Diagrama de despliegue
  • 10. Diagramas de UML State State Use Case Diagrams de Diagramas Use Case Diagrams State Use Case Diagrams de Diagramas Clases State Use Case Diagrams Diagrams de Diagramas Diagrams de Diagramas Casos de Uso Diagrams Diagrams Objetos Secuencia Scenario State Scenario State Diagrams de Diagramas Diagrams de Diagramas Diagrams Diagrams Colaboración Modelo Componentes Scenario Component Scenario Component Diagramas de Diagrams Diagrams de Diagramas Diagrams Diagrams Distribución Estados Diagramas de Actividad
  • 11. Mecanismos comunes en UML Especificaciones. Es más que un lenguaje gráfico (semántica detrás de la notación). Adornos. Detalles sobre un clase, nivel de acceso de sus métodos, notas. Divisiones Comunes: Clase/Objecto o Interfaz/Implementación.
  • 12. Mecanismos comunes en UML {orderById} «utility» Producto -Paginas : int +Insert() IDataManaged +Update() +Delete() #GetNumPaginas() : int «utility» «utility» p1 : Producto p2 : Producto Paginas : int Paginas : int Definición de un producto gestionado desde base de datos
  • 13. Casos de Uso
  • 14. Casos de Usos Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.
  • 15. Casos de Usos Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema. Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.
  • 16. Casos de Usos
  • 17. Casos de Usos Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.
  • 18. Casos de Usos También se puede encontrar tres tipos de relaciones, como son: – Comunica (comunicates) Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.
  • 19. Casos de Usos Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. Frecuentemente no hay actor asociado con el caso de uso común.
  • 20. Casos de Usos Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento.
  • 21. Casos de Usos Técnicas comunes de modelado: – Modelado del contexto del sistema (utilidad similar a los DFD). – Modelado de los requisitos de un sistema. – Modelado del proceso de test y estrés del sistema.
  • 22. Diagrama de Clases
  • 23. Conceptos básicos orientación a objetos Clase Objeto Herencia Interfaz Polimorfismo de clases Clases y atributos estáticos Clases y atributos finales Clases y métodos abstractos
  • 24. Diagrama de clases Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.
  • 25. Diagrama de clases Usos comunes del diagrama: – Modelado del vocabulario del sistema. – Modelado de colaboraciones simples. – Modelado de un esquema lógico de base de datos. – Modelado de un conjunto de clases de test.
  • 26. Diagrama de clases Clase: representa un conjunto de entidades que tienen en común propiedades, operaciones, relaciones y semántica. Una clase es un constructor que define la estructura y comportamiento de una colección de objeto denominados instancia de la clase. En UML la clase está representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.
  • 27. Diagrama de clases Atributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado. Las sintaxis de una atributo es: – Visibilidad <nombre>: tipo = valor { propiedades} Donde visibilidad es uno de los siguientes: – + público. – # protegido. – - privado.
  • 28. Diagrama de clases Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es: Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades}
  • 29. Diagrama de clases Nombre de la clase Atributos Métodos
  • 30. Diagrama de clases Responsabilidades: Contrato u obligación de una clase, asignada en el momento del diseño. Clase Producto: – Registrar el código de la publicación. – Mantener estructura del producto plantilla.
  • 31. Diagrama de clases Técnicas de modelado: – Modelado del vocabulario de un sistema a partir de las descripciones funcionales. – Modelado de la distribución de responsabilidades en un sistema. – Modelado de cosas que no son software (hardware, personas, etc). – Modelado de tipos primitivos.
  • 32. Diagrama de clases Objeto: es una instancia de una clase. Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos. Asociación (rol, multiplicidad, calificador): representan las relaciones entre instancias de clase. Una asociación es una línea que une dos o más clases.
  • 33. Diagrama de clases Nombre: Identifica la asociación entre los objetos, caracterizándola. Rol: Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.
  • 34. Diagrama de clases Multiplicidad: Describe la cardinalidad de la relación, es decir, cuanto objetos de esa clase pueden participar en la relación dada. Tipos:
  • 35. Diagrama de clases Dependencia: Es una relación donde existen entidades independientes y otras dependientes, lo que implica que cambiar el elemento independiente puede requerir cambios en los dependientes. Se representa con una línea punteada direccional, indicando el sentido de la dependencia.
  • 36. Diagrama de clases
  • 37. Diagrama de clases Los tipos de asociaciones entre clases presentes en un diagrama estático son: – Asociación binaria. – Asociación n-aria. – Composición. – Generalización. – Refinamiento.
  • 38. Diagrama de clases Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es decir, no se exige dependencia existencial ni encapsulamiento). Se indica como una línea sólida que une dos clases. Asociación n-aria: Es una asociación entre tres o más clases. Se representa como un diamante del cual salen líneas de asociación a las clases.
  • 39. Diagrama de clases Composición: Es una asociación fuerte que implica: – Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. – Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.
  • 40. Diagrama de clases – Los objetivos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto. Se denota dibujando un rombo del lado de la clase que contiene a la otra en la relación.
  • 41. Diagrama de clases Agregación: Relaciona una clase ya ensamblada con una clase componente. Es también una relación de composición menos fuerte (no se exige dependencia existencial) y se denota por un rombo sin rellenar en un o de los extremos.
  • 42. Diagrama de clases Generalización: es un proceso de abstracción en el cual un conjunto de clases existentes, que tienen atributos y métodos comunes, es referido por una clase genérica a un nivel mayor de abstracción. La relación de generalización denota una relación de herencia entre clases. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase.
  • 43. Diagrama de interacción Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación.
  • 44. Diagrama de interacción Elementos básicos del diagrama de interacción: – Objetos o actores para cada entidad. – Enlaces entre los objetos. – Procedimientos a invocar entre los objetos. – Mensajes entre los objetos.
  • 45. Diagrama de interacción
  • 46. Diagrama de interacción Diagramas de Colaboración: – Es una forma de representar interacción entre los objetos, es decir, las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que están indicadas por un número A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, etc) y ciclos en la ejecución. Muestra como varios objetos colaboran en un solo caso de uso.
  • 47. Diagrama de interacción
  • 48. Diagrama de interacción Técnicas de modelado: – Modelado dinámico del sistema. – Implementación de un caso de uso en concreto para cada diagrama. – Modelado del flujo de control por ordenación temporal (secuencia). – Modelado del flujo de control por organización (colaboración).
  • 49. Diagrama de Estados
  • 50. Diagrama de estados Diagrama de Estados: – Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Esta representado principalmente por los siguientes elementos:  Estado.  Elemento.  Transición.
  • 51. Diagrama de estados Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos.
  • 52. Diagrama de estados Partes que componen un estado: – Nombre – Acciones de entrada y de salida. – Transiciones internas. – Subestados. – Eventos diferidos.
  • 53. Diagrama de estados Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta, puede ser una: - Condición que toma el de verdadero o falso. – Recepción de una señal de otro objeto en el modelo. – Recepción de un mensaje. – Paso de cierto período de tiempo, después de entrar al estado o de cierta
  • 54. Diagrama de estados Transición: Es una relación entre estados de un fuente a un destino. Partes que componen una transición: – Estado de origen. – Evento de disparo. – Condición de guarda. – Acción. – Estado de destino.
  • 55. Diagrama de estados
  • 56. Diagrama de Actividades
  • 57. Diagrama de Actividades Un diagrama de actividades es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al esta en él ) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior. Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.
  • 58. Diagrama de Actividades Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Los elementos que conforman el diagrama son: – Acción – Transición. – Objetos
  • 59. Diagrama de Actividades Estado de Acción: representa un estado con acción interna, con lo menos una transición que indica la culminación de la acción (por medio de un evento implícito). – Permite modular un paso dentro del algoritmo. Se representan por un rectángulo con bordes redondeados.
  • 60. Diagrama de Actividades Estado de Actividad: Estado más general que permite su descomposición en otro diagrama de actividades interno, de nivel más bajo. – Su representación, en cuanto a la notación, es la misma que el de Acción.
  • 61. Diagrama de Actividades Casos especiales: – Estado inicial. Representa el punto de entrada del diagrama de actividades. – Estado final. Su existencia depende de si el diagrama es cíclico. – Ítem de decisión. Representado con un rombo, permite tomar bifurcaciones condicionales.
  • 62. Diagrama de Actividades Transición: Es la relación entre dos estados y se encuentran unidos por flechas; indicando que un objeto que está en el primer estado realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas.
  • 63. Diagrama de Actividades
  • 64. Diagrama de Componentes
  • 65. Diagrama de componentes Los diagramas de componentes describen los elementos físicos reemplazables del sistema y sus relaciones Muestran las opciones de realización incluyendo código fuente, binario y ejecutable
  • 66. Diagrama de componentes  Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, librerías, bibliotecas cargadas dinámicamente, etc.  Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente
  • 67. Diagrama de componentes
  • 68. Diagrama de Despliegue
  • 69. Diagrama de despliegue Los diagramas de despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos
  • 70. Diagrama de despliegue La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como – Dispositivos – Procesadores – Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.
  • 71. Diagrama de despliegue Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.
  • 72. Diagrama de despliegue
  • 73. Diagrama de despliegue
  • 74. RUP: El Proceso Unificado de Rational
  • 75. Casos de uso Dirigido por casos de uso – Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactua con él – Casos de uso como el hilo conductor que orienta las actividades de desarrollo Casos de Uso <<defineNecesidades>> <<realiza>> <<verifica>> Análisis Diseño Pruebas Recopilar, Clarificar y Realizar los Verificar que se Validar los casos de uso satisfacen los requerimientos casos de uso
  • 76. Estructura Dinámica  Ciclo: cada ciclo una nueva versión del producto  Fase: Etapas de un ciclo que finalizan en un HITO  Iteración: Proceso de ingeniería sobre una funcionalidad limitada del sistema
  • 77. Estructura Roles QUIÉN? Actividades CÓMO? Artefactos QUÈ? Flujo de Trabajo CUÁNDO? realiza responsable de diseño de caso diseñador de uso diagrama de secuencia
  • 78. Roles Definición del comportamiento y responsabilidades de los participantes Propietario de una serie de artefactos Recurso Rol Actividad Artefacto Patricia Diseñador Diseño de Objetos DC Juan Analista Definición de CU DCU Dominio Mónica Diseñador Diseño de CU DS Pedro Funcional
  • 79. 1 GRACIAS!!!!!!!!!!!!!!!

×