Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

planeacion de software

695 views

Published on

  • Be the first to comment

  • Be the first to like this

planeacion de software

  1. 1. DESARROLLO DE PROYECTOS DE SOFTWARE
  2. 2. UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: – Conceptos de modelado de datos (diagramas entidad-relación) – Modelado de negocios (flujos de trabajo) – Modelado de objetos – Modelado de componentes
  3. 3. Notación UML UML define 9 tipos de diagramas que representan los distintos puntos de vista de modelado.
  4. 4. Diagramas 1) Diagramas de casos de uso. Representan las funciones de un sistema desde el punto de vista del usuario. 2) Diagramas de secuencia. Son una representación temporal de los objetos y sus relaciones. 3) Diagramas de colaboración. Son una representación espacial de objetos, uniones e interacciones.
  5. 5. Diagramas 4) Diagramas de objeto. Representan objetos y sus relaciones. 5) Diagramas de clase. Representan la estructura estática en términos de clases y relaciones. 6) Diagramas de estado. Representan el comportamiento de una clase en términos de estado.
  6. 6. Diagramas 7) Diagramas de actividad. Representan el comportamiento de una operación como un conjunto de acciones. 8) Diagramas de despliegue. Representan la colocación de componentes en piezas particulares de hardware. 9) Diagramas de componente Representan los componentes físicos de una aplicación.
  7. 7. Diagramas de Caso de Uso
  8. 8. Diagramas de Casos de Uso Es la descripción de un comportamiento, de acuerdo a la funcionalidad esperado, con el objetivo de completar una tarea del sistema. Modela la funcionalidad del sistema desde el punto de vista de usuarios externos llamados actores. El propósito es definir una pieza de comportamiento coherente, sin revelar la estructura interna del sistema.
  9. 9. Ejemplo Nombre del Sistema Comunicación entre Actor y Caso de Uso Catálogo telefónico revisar condiciones hacer pedido Cliente atender pedidos establecer créditos Actores Caso de Uso Vendedor Encargado de Envíos Supervisor
  10. 10. Diagrama de Caso de Uso Actor: representa cualquier persona o sistema que necesita interactuar con el sistema. Actores principales. Personas que usan funciones del sistema principal. En el caso de un cajero automático, son los clientes. Actores secundarios. Llevan a cabo actividades de administración o mantenimiento. En el caso de un cajero, es la persona que rellena el cajero de dinero.
  11. 11. Casos y Actores Servicio Cliente Repara Mecánico Vende Maneja Vendedor La misma persona física puede hacer el rol de varios actores . Además, varias personas pueden tener el mismo rol y por lo tanto ser el mismo actor (todos los clientes). El nombre del actor describe el rol hecho por el usuario.
  12. 12. Casos y Actores en “paquetes” Para identificar en forma más sencilla a los actores y sus casos de uso, se sugiere organizarlos en “paquetes”, de acuerdo a las principales funciones de sistema: – Ayudan a la modularidad del sistema – Facilitan la identificación de las casos de uso y los actores principales y secundarios – Mantienen un nivel de complejidad adecuados
  13. 13. Relaciones Relación “usa” (use) Una relación “usa” entre casos significa que una instancia del caso fuente también incluye el comportamiento descrito por el caso apuntado. Esta relación ocurre cuando tenemos un comportamiento que es similar entre varios casos y no queremos copiar la descripción de ese comportamiento.
  14. 14. Relaciones Relación “extiende” (extend) Relación “extiende” se usa cuando tenemos un caso que es similar a otro caso pero hace un poco más. También puede verse como un comportamiento opcional al sistema.
  15. 15. Relaciones Transferido por computadora <<extiende>> Transfiere Cliente Remoto <<usa>> Identificación Cliente Local
  16. 16. Ejemplo Máquina de Bebidas Calientes Suponga que se requiere desarrollar el control de una máquina automática para despachar bebidas calientes. La máquina recibe monedas de 0.50, 1, 2 y 5 pesos. Existen tres tipos de bebidas (café negro, café capucino, chocolate).
  17. 17. Ejemplo Máquina de Bebidas Calientes Es posible azucarar al gusto el producto seleccionado y la máquina es capaz de dar cambio. El dinero que los usuarios introducen se guarda en un recipiente aparte al disponible para el cambio, el cual se encuentra ordenado por denominación.
  18. 18. Ejemplo Máquina de Bebidas Calientes Diagrama de Casos de Uso introducirDinero pedirAzucar “uses” pedirProducto “uses” cancelar “uses” darCambio
  19. 19. Ejemplo Catálogo Telefónico Extensión Inclusión <<include>> datos del cliente Estas inserciones son explicitas de “hacer pedido!” hacer pedido <<extend>> solicitar catálogo <<include>> <<include>> pedir producto organizar pago
  20. 20. Documentación de un Caso de Uso Una vez identificados los casos de uso y sus actores es muy importante documentar cada caso de uso. – Ayuda a aclarar la lógica de interacción – Permite detectar los objetos involucrados – Es la base para construir los diagramas de secuencia y de actividad.
  21. 21. Documentación de un Caso de Uso Nombre del caso de uso Actor(es) Descripción Pre-condición Disparador Eventos normales Excepciones (Variaciones alternas) http://members.aol.com/acockburn/papers/uctempla.htm
  22. 22. Ejemplo Máquina de Bebidas Calientes Documentación de un Caso de Uso Nombre del caso de uso: Actor(es): Descripción: Pre-condición: Disparador: Eventos normales: Excepciones : (Variaciones alternas) IntroducirDinero Cliente Solicita el dinero La maquina está lista. Recepción de monedas 1. Recibe dinero 2. Cuenta dinero 1. Falla de la máquina
  23. 23. Diagrama de Secuencia
  24. 24. Diagrama de Secuencia Un objeto Muestra un conjunto de mensajes dispuestos en una secuencia de tiempo. Muestra el comportamiento secuencial de un caso de uso. Nuevo objeto
  25. 25. Diagrama de Secuencia Objetos Un objeto Tiempo Nuevo objeto Mensajes Fin de la vida Línea de Vida
  26. 26. Ejemplo Máquina de Bebidas Calientes Diagrama de Secuencias :Máquina :Producto 1:servir() darCambio() “destroy” :Ingrediente 2:*[1..n] servir()
  27. 27. Diagrama de secuencia Catálogo Telefónico p: Cliente p: Vendedor s: Inventario 1.Solicita Artículo 2.Verifica “stack” 4.Indica existencia 5.Hace pedido 8.Fecha de Envío “9.destroy” 3.Indica Cant. de Artículos 6.Solicita el Artículo 7.Fecha de Envío s: Almacen
  28. 28. Diagrama de Colaboración
  29. 29. Diagrama de Colaboración Destaca la organización de los objetos que participan en una interacción. Tienen dos características que los distinguen de los diagrama de secuencias: •El camino: Indica como se enlaza un objeto a otro •El número de secuencia: indica la ordenación temporal de un mensaje.
  30. 30. Diagrama de Colaboración Enlace 1: acción() Objeto 1 2: acción() Mensaje Objeto 3 Objeto 2 3: acción() Secuencia Objetos
  31. 31. Ejemplo Máquina de Bebidas Calientes Diagrama de Colaboración 3:dar_Cambio() :Máquina 1:servir() :Producto 2:*[1..n] servir() :Ingrediente
  32. 32. Diagrama de Colaboración Catálogo Telefónico p: Cliente 1: Solicita Artículo 3: Hace pedido 5: “destroy” p: Vendedor 4: Solicita Artículo s: Almacen 2: Verifica “stack” s: Inventario
  33. 33. Diagramas de Objetos
  34. 34. Diagramas de objetos Presentan un conjunto de objetos y sus relaciones identificados en los requerimientos funcionales y casos de uso de un escenario de negocios de un sistema. Cubren una vista de diseño estático desde la perspectiva de casos reales o prototípicos. Para representarlos se parte de un proceso de identificación de sustantivos en la descripción de eventos normales y diagramas de secuencia y colaboración de los casos de uso
  35. 35. Modelo de Objetos Encontrando OBJETOS. Para evaluar si un objeto candidato realmente es un objeto del sistema debe tomar en cuenta: – Un objeto debe tener datos que deben ser almacenados – Cada objeto debe tener más de un atributo – Todas las instancias del objeto comparten los mismos los métodos y atributos.
  36. 36. Ejemplo Máquina de Bebidas Calientes Diagrama de Objetos Ingrediente Cantidad: 1c Nombre:cafe Producto Costo: 10.00 DepositoMonedas Nombre: Cafe numMonedas: 1 Máquina valorRecolectado : 10.00 PanelControl DepositoMonedasIguales Denominacion: 1.00, 5.00, 10.00
  37. 37. Ejemplo Rol d1:Departamento director Nombre=Fco. López Id: 121415 Nombre=“Ventas” Reporta d2:Departamento Nombre=“Conta” p:Persona Valor al Atributo Paga Enlace
  38. 38. Conceptos Básicos Clases Comportamiento: se refiere a aquellas cosas que el objeto puede realizar. Clase Nombre Operaciones Cliente Nombre Dirección Teléfono Alta() Baja() Modificación() Consulta() Atributos
  39. 39. Conceptos Básicos Clases y Objetos Objeto: Es cualquier cosa, lugar, persona acerca de la cual el usuario puede guardar información y asociar un comportamiento. Representación en UML :Cliente Nombre=“Ventas”
  40. 40. Relaciones 00 Herencia: significa que el comportamiento y/o atributos definidos en una clase pueden ser reusados en otra clase distinta. Generalización: es una relación que describe la forma que que dos clases interactuan es decir la subclase hereda los atributos y métodos de la superclase. Clase 1 Clase 2 Clase 3
  41. 41. Relaciones OO Composición: es una relación que describe cuando un objeto esta compuesto de uno o más objetos. Clase 1 Clase 2 Clase 3
  42. 42. Relaciones de colaboración Cardinalidad: relación entre objetos que denota el número de instancias de A que pueden ser relacionadas a una instancias de B – Cada instancia de la clase1 es asociada con cero o una instancia de la clase2 Clase 1 0..1 Clase 2 – Cada instancia de la clase1 es asociada con exactamente una instancia de la clase2 Clase 1 1 Clase 2
  43. 43. Relaciones de colaboración Relaciones de colaboración y su cardinalidad – Cada instancia de la clase1 es asociada con cero o muchas instancias de la clase2 Clase 1 * Clase 2 – Cada instancia de la clase1 es asociada con una o muchas instancias de la clase2 Clase 1 1..* Clase 2
  44. 44. Especificación de Clases Para cada clase del modelo de objetos se debe realizar una especificación de clases que contenga: – Nombre de la clase – Definición de negocio para la clase (significado para el usuario) – Relaciones, especificar si es una colaboración, especialización o composición.
  45. 45. Especificación de Clases – Atributos, especificando como mínimo el tipo de dato. – Definición de los métodos, incluyendo como el método se lleva a cabo y que datos necesita. Recomendable utilizar texto estructurado.
  46. 46. Ejemplo Máquina de Bebidas Calientes Diagrama de Clases Ingrediente cantidad nombre servir() 1..* 1..* 1..* Producto costo nombre servir() DepositoMonedas numMonedas agregarMoneda() 1..4 1 Máquina valorRecolectado recibirPeticion() recibirDinero() darCambio() …. PanelControl 4 DepositoMonedasIguales denominacion darMoneda() …..
  47. 47. Ejemplo: Diagrama de Clases Rol Empleado Nombre Id Registro() Dependencia director miembro * 1 1..* Departamento Nombre Clave Consulta() Solicitud() 1..* Generalización 1 Cardinalidad Agregación Empresa Nombre RFC Paga Depto. Contabilidad
  48. 48. Diagrama de Estado
  49. 49. Diagrama de Estado Modela los posibles cambios de un objeto. Estado inicial Estado 1 También es útil para describir el comportamiento del sistema. Estado 3 Estado 2 Estado final
  50. 50. Ejemplo: Máquina de Bebidas Calientes Diagrama de Estados userInput(BotonOn)[todoOk=true] BuenFuncionamiento userInput(BotonOn) [todoOk=false] userInput(BotonOn)[todoOk=true]/ MostrarDineroActual Lista [todoOk=true]/ IniciarIndicadores userInput(Boton)[todoOk=true]/ MostrarNivelAzucar, MostrarProducto Desperfecto k oO d [to ] lse a =f Elección Producto y azucar Apagada Sirviendo Producto [todoOk=true]/ServirProducto userInput(BotonOff) Recibiendo Monedas userInput(BotonOff)
  51. 51. Diagrama de Actividades
  52. 52. Diagrama de actividades Combina el diagrama de eventos de Jim Odell, las técnicas de modelado de estados y las redes de Petri. Son útiles en conexión con el flujo de trabajo donde una actividad es un método sobre una clase. Permite documentar la lógica de cada caso de uso.
  53. 53. Diagrama de Actividad [Condición 1] Actividad Actividad [Condición 2] *[Para todo caso] Actividad Actividad Actividad [Condición de sincronización]
  54. 54. Ejemplo: Máquina de Bebidas Calientes Diagrama de Actividad Preparar vaso Servir productos Servir azucar Indicar que la bebida esta lista Lista Servir Agua Caliente
  55. 55. Ejemplo: Diagrama de Actividad Método: hacer pedido Recibe orden Inicio *[Para cada artículo] Cancela orden Autoriza pago [fallo] Verifica existencias [éxito] Asigna orden [en existencia] Despacha orden [falta mercancia] Reordena
  56. 56. Diagrama de Despliegue
  57. 57. Diagrama de Despliegue El diagrama de despliegue (deployment) muestra la configuración de los elementos de procesamiento en tiempo de ejecución (run-time) con sus respectivos procesos de software Visualiza la distribución de componentes
  58. 58. Diagrama de Despliegue Base de datos Dirección Edificio Principal Biblioteca Jardines
  59. 59. Ejemplo: Máquina de Bebidas Calientes Diagrama de Despliegue PC Máquina 1 1 Panel Control 1 4 Deposito Monedas Iguales 1 1 1 3 Despachador Productos Deposito Monedas
  60. 60. Diagramas de Componentes
  61. 61. Diagramas de Componentes El mundo físico Los diagramas de componentes ilustran la organización y dependencia entre los componentes de software Un componente puede ser: – Código fuente – Código ejecutable – Código interpretado
  62. 62. Diagrama de Componentes Factura.exe Inscribe.exe Sistema facturación Persona.dll Curso.dll Curso Alumno Curso Curso Ofertado Usuario Profesor
  63. 63. Ejemplo Máquina de Bebidas Calientes Diagrama de Componentes Despachador Panel de Control.dll Despachador.dll Forma icónica Control de dinero.dll
  64. 64. Metamodelo Para dar más rigor, sin perder la utilidad se crea el metamodelo. Un metamodelo es un diagrama, usualmente un diagrama de clase, que define la notación. Se dice que UML es un lenguaje Metamodelo.
  65. 65. Diagrama Componente Clase Secuencia Distribución Estado Colaboración Caso de Uso Objeto Actividad
  66. 66. Bibliografía Booch G. , Rumbaugh J., Jacobson I. “El Lenguaje Unificado de Modelado”, Addison Wesley Iberoamericana, Madrid 1999 Rational Software Co., “Analysis and Design with UML”, 1997 Figueroa P., “Elementos notacionales de UML”, Univ. Los Andes, Bogotá, Colombia1997 http://agamenon.uniandes.edu.co/~pfiguero/soo/uml/
  67. 67. Bibliografía Muller P. , “Instant UML”, Wrox. 1997 Fowler M. , Scott K., “UML gota a gota”, 1997 Pressman R. , “Software Engineering. A practitioner´s Approach Ed. Mc Graw Hill. Cuarta edición. 1997 Larman C. “UML y patrones”. Ed. Prentice Hall. 1999. Página de Rational Rose en México: – http://www.abits.com.mx/

×