Modelado, Ingenieria de Software

2,851 views

Published on

Taller de Modelamiento y Diagramación de Sistemas Automatizados con la utilización de las herramientas CASE Rational Rose Actividad N.- 1

www.modelado.pnfi.org

Published in: Education
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
2,851
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
186
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Modelado, Ingenieria de Software

  1. 1. 1 Taller de Modelamiento y Diagramación de Sistemas Automatizados con la utilización de las herramientas CASE Rational Rose Actividad N.- 1 www.modelado.pnfi.org Ing. MSc. Douglas Galvis
  2. 2. 2 Contenidos: 1.- Objetivos del Taller. 2.- Conceptualizaciones sobre : 2.1 Ingeniería de Software. 2.2 Proceso Unificado de Desarrollo 2.3 Lenguaje Modificado de Modelación (UML) 2.4 El proceso Unificado de Desarrollo (RUP) 2.5 Modelado y Diagramación de Casos de Usos del Negocio. (ejemplo tipo) 3.- Modelamiento y Diagramación de un Sistema automatizado . 4.- Utilización de la Herramienta CASE Rational Rose
  3. 3. 3 1.- Objetivos del Taller  Unificación de los Conocimientos entre los Profesores que dictan la Cátedra de Ingeniería de Software, en las Unidades Curriculares de la malla del PNFI, en los trayectos 2 y 3.  Estandarizar el Modelamiento y la diagramación en los Proyectos Sociotecnológicos al final de los trayecto 2 y 4.  Institucionalizar la utilización de Herramientas CASE, para la elaboración del Modelamiento y diagramado de los Sistemas, como recursos tecnológicos en la formación de los profesionales que egresan de la UPTEM
  4. 4. 4 Ingeniería del Software Soporte automático o semiautomático para el proceso y los métodos. Es el fundamento de la IS. Es la unión que mantiene juntas las capas de la tecnología. Indican cómo construir técnicamente el Sw.
  5. 5. 5 Mejores prácticas para el trabajo efectivo de un equipo en el desarrollo del software. (Dirige y organiza el proceso) (Notación)
  6. 6. 6 Lecturas Recomendadas • JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James, “El Proceso Unificado de Desarrollo de Software”.2000. Addison Wesley. • BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar; “El Lenguaje Unificado de Modelación. Libro introductorio”.2000. Addison Wesley. •LARMAN, Craig “UML y patrones” 1999, Prentice Hall Iberoamericana. • RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady; “El Lenguaje Unificado de Modelación. Manual de referencia”.2000. Addison Wesley. Bibliografía
  7. 7. 7 Lecturas Recomendadas • CONALLEN, Jim, “Building Web Applications with UML”.2002. 2nd edition. Addison Wesley. • BOOCH, Grady, MAKSIMCHUCK, Robert, ENGLEm Michael, YOUNG, Bobbi, CONALLEN, Jim, Houston, Kelli; “Objetct-Oriented Analysis and Design with Applications”. Third Edition. Addison Wesley. 2007. • HAMILTON, Kim, MILES, Russell; “Learning UML 2”.2006. O´ Reilly Media Bibliografía
  8. 8. 8 Proceso de Desarrollo de Software
  9. 9. 9 Proceso Define “quién” está haciendo “qué”, “cuándo” y “cómo” para alcanzar un determinado objetivo. Proceso de desarrollo de software (PDS) Requisitos del usuario Sistema informático
  10. 10. 10 Proceso de desarrollo de software (PDS)
  11. 11. 11 • Un proceso software debe especificar: – la secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividades – productos que deben crearse: qué y cuándo – asignación de tareas a cada miembro del equipo y al equipo como un todo – proporcionar heurísticas – criterios para controlar el proceso Proceso de desarrollo de software (PDS)
  12. 12. 12 UML
  13. 13. 13 “ Puede ser un seudocódigo, código, imágenes, diagramas, o largos paquetes de descripción; es decir, cualquier cosa que ayude a describir un sistema ” Lenguaje de modelación = +
  14. 14. 14 (Forma de expresar el modelo) Lenguaje de modelación += (Descripción de lo que significa esa modelación)
  15. 15. 15 • Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones • Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc. • Pugna entre distintos enfoques (y correspondientes gurús) Situación de partidaSituación de partida
  16. 16. 16 • Descrito en "The Unified Modeling Language for Object-Oriented Development" de Grady Booch, James Rumbaugh e Ivar Jacobson. • Basado en las experiencias personales de los autores. • Incorpora contribuciones de otras metodologías. Lenguaje Unificado de Modelación ? ¿Qué es el UML- Unified Modeling Language? U M L
  17. 17. 17 • Ofrece un estándar para describir un “plano” del sistema. • Incluye aspectos conceptuales tales como procesos de negocio y funciones del sistema y aspectos concretos como espresiones de lenguajes de programación, esquemas de BD y componentes de software reutilizables. Lenguaje Unificado de Modelación ? ¿Qué es el UML- Unified Modeling Language? U M L
  18. 18. 18 UML DocumentarDocumentar VisualizarVisualizar EspecificarEspecificar ConstruirConstruir Σ
  19. 19. 19 UML no es un método El UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos Aprobado como estándar por OMG en noviembre de 1997 El Object Management Group u OMG (de sus siglas en inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA.
  20. 20. 20  El esfuerzo de UML partió oficialmente en octubre de 1994, cuando Rumbaugh se unió a Booch en Rational.  El “Método Unificado” en su Versión 0.8, se presentó en el OOPSLA’95  El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose Orígenes de UML
  21. 21. 21 Creación del UML Booch method OMT Unified Method 0.8OOPSLA ´95 OOSEOther methods UML 0.9Web - June ´96 public feedback UML 1.5 UML 1.0UML partners UML 2.0 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 Version 1.1
  22. 22. 22 • Las primeras versiones de UML estaban más orientadas hacia la modelación del software y ahora se requiere más la modelación del sistema. • Necesidad de compartir modelos entre diferentes herramientas. • Nuevas tecnologías: Arquitectura basada en componentes, MDA • Las primeras versiones estaban más diseñadas para las personas y no para las máquinas, por lo que hay construcciones que no estaban suficientemente formalizadas. ¿Por qué UML 2.0?
  23. 23. 23 GRADY BOOCH IVAR JACOBSON JAMES RUMBAUGH Object Modelling Technique 1991(OMT) Object Oriented Analysis and Design with Applications 1994 Object Oriented Software Engineering: A Use Case Driven Approach 1992 (OOSE) Las Bases de UML • Booch, • Rumbaugh • Jacobson Rational Software Corporation. (1995) Las Bases de UMLLas Bases de UML
  24. 24. 24 • Modelar sistemas, a partir de los conceptos hacia los artefactos ejecutables, utilizando técnicas orientadas a objeto. • Enfocarnos en las cuestiones de escala inherentes a sistemas complejos, críticos en su misión. • Crear un lenguaje de modelación utilizable tanto por los humanos, como por las máquinas. Premisas de UML según Booch, Jacobson y Rumbaugh
  25. 25. 25 Contribuciones a UML Diagrama de Casos de uso Diagrama de Clases Diagrama de Objetos Diagrama de Secuencia Diagrama de Estado Diagrama de Componentes Diagrama de Estructura Compuesta Diagrama de Paquetes Diagrama de Comunicación Diagrama de Actividad Diagrama de Tiempo Diagrama de Despliegue OOSE/Jacobson OOAD/Booch OMT/Rumbaugh Otras mejores prácticas
  26. 26. 26 • Es un lenguaje formal ya que cada elemento del lenguaje tiene un significado fuerte que ayuda a modelar un aspecto particular del sistema. • Es conciso con una notación simple. • Es comprensible porque describe todos los aspecto importante del sistema. • Es escalable por lo que permite describir proyectos de diferentes tamaños. Ventajas de UML
  27. 27. 27 • Contiene las mejores prácticas de la comunidad orientada a objetos de los últimos 15 años. • Es un estándar abierto. • Da soporte a todo el ciclo de vida de desarrollo del software. • Da soporte a diversas áreas de aplicación. • Está soportado por muchas herramientas. Ventajas de UML
  28. 28. 28 • Carece de un semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva en ocasiones. • No se presta con facilidad al diseño de sistemas distribuidos. En estos sistemas son importantes factores como transmisión, serialización, persistencia, etc. No se puede señalar si un objeto es persistente o remoto. Limitaciones de UML
  29. 29. 29 Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto de software desde cada una de las perspectivas de interés
  30. 30. 30 Un producto de software es el código máquina y los ejecutables de un sistema Un producto de software es el conjunto de artefactos que se necesitan para representarlo en forma comprensible para: • Las máquinas. • Los trabajadores. • Los usuarios. • Los interesados. ¿artefactos? ¿Qué es un producto de software?
  31. 31. 31 ¿Artefactos? Término general aplicable a cualquier tipo de información creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema • Diagramas UML y su texto. • Bocetos de interfaz. • Planes de prueba. EjemplosEjemplos::
  32. 32. 32 • Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. • Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados Modelos y DiagramasModelos y Diagramas
  33. 33. 33 Modelo de Casos de Uso Modelo de Diseño Modelo de Implementación Trazabilidad entre los modelos Secuencia cronológica ModelosModelos Modelo de Despliegue Modelo de Análisis Modelo de Prueba
  34. 34. 34 Modelo de Casos de Uso Modelos y Diagramas Diagrama de Casos de Uso del Negocio Diagrama de Secuencia Diagrama de Comunicación Diagrama de Casos de Uso del Sistema Diagrama de Actividades Diagrama de Estado Diagrama de Paquetes
  35. 35. 35 • Casos de Uso y Diagramas de Casos de Uso Diagramas de UML Casos de uso Diagrama de casos de uso
  36. 36. 36  Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje  No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos Diagrama de casos de uso Cliente Solicitar Préstamo
  37. 37. 37 • Diagramas de estructura estática • Diagrama de clases • Diagrama de Objetos Diagramas de UML
  38. 38. 38  Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia  La definición de clase incluye definiciones para atributos y operaciones  El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones Diagrama de clases ProfesorDepartamento 0..1 1..*0..1
  39. 39. 39 Diagramas UML • Diagramas del comportamiento •Diagramas de Estado •Diagramas de Actividad •Diagramas de Secuencia •Diagrama de Comunicación •Diagrama de tiempo Diagrama de Secuencia Diagrama de Comunicación
  40. 40. 40 con préstamos sin préstamos alta baja prestar devolver[ número_préstamos = 1 ] prestar devolver[ número_préstamos > 1 ] número_préstamos = 0 número_préstamos > 0 Socio número : int nombre : char[50] número_prestamos : int = 0 alta() baja() prestar(código_libro : int, fecha : date) devolver(código_libro : int, fecha : date) Diagrama de estado
  41. 41. 41 Diagrama de actividades Buscar bebida ¿hay café? Poner café en filtro Añadir agua al depósito Coger taza Poner filtro en máquina Encender máquina Hacer café Servir café Beber Servir jugo ¿hay jugo? SÍ NO NO SÍ
  42. 42. 42 Diagrama de secuencia : Encargado :WInPréstamos :Socio :Video :Préstamo prestar(video, socio) verificar situación socio verificar situación video registrar préstamo entregar recibo
  43. 43. 43 : Encargado :WInPréstamos :Socio :Video :Préstamo 1: prestar(video, socio) 2: verificar situación socio 3: verificar situación video 4: registrar préstamo 5: entregar recibo Diagrama de comunicación
  44. 44. 44 • Diagramas de implementación • Diagramas de componentes • Diagramas de instalación/Distribución (Despliegue) Diagramas de UML Diagrama de componentes
  45. 45. 45 Interfaz de Terminal Gestión de Cuentas Rutinas de conexión Acceso a BD Control y Análisis Diagrama de componentes
  46. 46. 46 Diagrama de despliegue Punto de Venta Servidor Central Terminal de Consulta Gestión de Cuentas Comment Interfaz de Terminal Comment Rutinas de Coneccion Comment Rutinas de Coneccion Comment Interfaz de Terminal Comment Rutinas de Coneccion Comment Acceso a BD Comment Control y Análisis Comment
  47. 47. 47 Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. ¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos
  48. 48. 48 ¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.
  49. 49. 49 Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. ¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos
  50. 50. 50 Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. ¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos ¿Cómo se relacionan los diagramas?
  51. 51. 51  UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos  El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch Resumen
  52. 52. 52 El Proceso Unificado de Desarrollo (Rational Unified Process- RUP)
  53. 53. 53 Rational Unified Process RUP es un proceso para el desarrollo de software orientado a objeto que utiliza UML para describir un sistema Rational Software Corporation, 1998
  54. 54. 54 Rational Unified Process 5.0 Rational Objectory Process 4.1 Rational Objectory Process 4.0 Rational Approach Objectory Process Pruebas de rendimiento y carga (Performance Awareness) Ingeniería de Negocios Diseño OO de IU Ingeniería de Datos (Vigortech) UML 1.2 Proceso SQA (SQA Inc.) UML 1.0 Administración de Configuración y Cambios (Pure-Atria) Escuela de Requerimientos (Requisite Inc.) OMT Booch UML 0.8 1998 1997 1996 1995 Ericsson method1967 1987 Evolución de RUP
  55. 55. 55 Estructura Estática de RUP Fases e Iteraciones Disciplinas del Proceso Actividades, flujo de trabajo Artefactos Modelos, reportes, documentos Trabajadores ¿Cómo ocurre el proceso y sus detalles? ¿Qué se produce u obtiene? ¿Quién lo hace o se responsabiliza? ¿Cuándo ocurre el proceso?
  56. 56. 56 Estructura Dinámica Tiempo Concepción Elaboración Construcción Transición • Concepción Define el alcance del proyecto y el desarrollo de los casos del negocio. • Elaboración Planifica el proyecto, especifica las características y define los cimientos de la arquitectura. • Construcción Construye el producto. • Transición Implementa el producto a sus usuarios.
  57. 57. 57 Fases-Flujos de trabajo de RUP
  58. 58. 58 Características del ciclo de vida de RUP • Dirigido por Casos de Uso. • Centrado en la arquitectura. • Iterativo e incremental.
  59. 59. 59 Dirigido por Casos de Uso Ciclo de vida de RUP (Reflejar lo que los futuros usuarios necesitan y desean) Representa los requerimientos funcionales Requisitos Análisis Diseño Implementación Prueba Caso de Uso Guían el proceso de desarrollo porque los modelos que se crean llevan a cabo los casos de uso.
  60. 60. 60 Caso de Uso Realización de Análisis Realización de Diseño Caso de Prueba X «trace» «trace» «trace» «trace» Pruebas Funcionales Pruebas Unitarias Dirigido por Casos de Uso Ciclo de vida de RUP
  61. 61. 61 Dirigido por Casos de Uso Ciclo de vida de RUP
  62. 62. 62 Centrado en la arquitectura Ciclo de vida de RUP En la construcción, vista de: A) Estructura. B) Calefacción. C) Plomería. D) Electricidad. Estáticos Dinámicos Aspectos
  63. 63. 63 Centrado en la arquitectura Ciclo de vida de RUP (Visión común del sistema completo en la que desarrolladores y usuarios deben estar de acuerdo ) • Describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. • Se desarrolla mediante iteraciones comenzando por los CU relevantes desde el punto de vista de la arquitectura.
  64. 64. 64 Centrado en la arquitectura Ciclo de vida de RUP Vista lógica Vista de componentes Vista de despliegue Vista física Vista de Casos de uso Vista de diseño Vista de actividades Vista de estado Vista estática Vista de Casos de uso Vista de despliegue Vista de componentes Vista de Gestión del modelo Perfil
  65. 65. 65 Iterativo e incremental Ciclo de vida de RUP Hito de losHito de los objetivosobjetivos Hito de laHito de la arquitecturaarquitectura Hito de laHito de la funcionalidadfuncionalidad operativaoperativa Hito de laHito de la versión delversión del productoproducto • Dentro de cada fase hay hitos (artefactos a construir) asociados a resultados de cada iteración. • La terminación de una iteración produce un nuevo incremento.
  66. 66. 66 Enfoque Cascada Enfoque Iterativo e Incremental Iterativo e incremental Ciclo de vida de RUP
  67. 67. 67 Grado de Finalización de Artefactos Iterativo e incremental Ciclo de vida de RUP
  68. 68. 68 Beneficios de la iteración •Reduce el coste del riesgo al coste de un solo incremento. •Menos riesgo de no sacar el producto al mercado en fecha. •Acelera el ritmo de desarrollo. •Las necesidades del usuario y correspondientes requisitos no pueden definirse completamente al principio. Se requieren iteraciones sucesivas.
  69. 69. 69 RUP • RUP es un proceso que garantiza la elaboración de todas las fases de un producto de software orientado a objetos. •RUP es dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. • RUP utiliza el UML. • UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos
  70. 70. 70 Desarrollo en equipos UML y RUP Lenguaje de Modelamiento Proceso Unificado

×