Clase03 m sw

422 views

Published on

separatas uml

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
422
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Clase03 m sw

  1. 1. UML Ing. Amador De La Cruz Bautistaemail:amadeba2020@hotmail.com IESPT-HUANTA 1
  2. 2.  Desarrollo de soft OO usando UML ◦ Introducción ◦ Modelado del soft  UML (Conceptos básicos) ◦ Paradigma OO  Fundamentos  Diagramas de CU  Diagramas de Interacciones  Diagramas de clase  Diagramas de estado/actividad  Diagrama de componentes  Diagrama de despliegue 2
  3. 3.  Ejemplos  Modelado ◦ Construcción de una  Proceso bien definido cucha para un perro  Herramientas más sofisticadas  Puede hacerlo una sola persona ◦ Construcción de un Requiere: rascacielos  Modelado mínimo  Contexto de  Proceso simple desarrollo  Herramientas simples  Determinar ◦ Construcción de una configuración del casa proceso  Construida  Recursos necesarios eficientemente y en  Herramientas más un tiempo sofisticadas aún. razonable de un equipo 3
  4. 4. NotaciónHerramientas Proceso 4
  5. 5. “El modelado captura las partes esenciales del sistema” Orden ItemenvíoProceso de Negocios Sistema Computacional 5
  6. 6.  UML = Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos Documento “OMG Unified Modeling Language Specification” UML combina notaciones provenientes desde: ◦ Modelado Orientado a Objetos ◦ Modelado de Datos ◦ Modelado de Componentes ◦ Modelado de Flujos de Trabajo (Workflows) 6
  7. 7.  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) Establecer una notación estándar 7
  8. 8.  Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. 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 8
  9. 9. 2001 UML 2.0 2000 UML 1.4 1999 UML 1.3 Revisiones menores 1998 UML 1.2Nov ‘97 UML aprobado por el OMG Ingeniería de Software - Clase 6 UNPSJB - 2005 9
  10. 10. Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditionsShlaer-Mellor UMLObject life cycles Harel State ChartsGamma et. al.Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Responsabilities Fusion Operation descriptions, message numbering 10
  11. 11.  Definición semi-formal del Metamodelo de UML Mecanismos de Extensión en UML: ◦ Stereotypes ◦ Constraints ◦ Tagged Values Permiten adaptar los elementos de modelado, asignándoles una semántica particular 11
  12. 12.  Definición del proceso de desarrollo usando UML. UML no es una metodología Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc. “Monopolio de conceptos, técnicas y métodos en torno a UML” 12
  13. 13.  UML será el lenguaje de modelado orientado a objetos estándar predominante los próximos años Razones: ◦ Participación de metodólogos influyentes ◦ Participación de importantes empresas ◦ Aceptación del OMG como notación estándar Evidencias: ◦ Herramientas que proveen la notación UML ◦ “Edición” de libros ◦ Congresos, cursos, etc. 13
  14. 14.  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 por arcosOMG UML 1.4 Specification 14
  15. 15.  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 15
  16. 16.  Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento  Diagrama de Estados  Diagrama de ActividadDiagramas de Interacción  Diagrama de Secuencia  Diagrama de ColaboraciónDiagramas de implementación  Diagrama de Componentes  Diagrama de Despliegue 16
  17. 17. Los diagramas expresan gráficamente partes de un modelo 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 17
  18. 18.  4+1 vistas de Kruchten (1995) Vista de Vista Lógica Realización Vista de los Casos de Uso Vista de Vista de Procesos Distribución Este enfoque sigue el browser de Rational Rose UNPSJB - 2005 18
  19. 19. Propuesta de Rational Unified Process (RUP)  M. de Casos de Uso del Negocio (Business Use-Case Model)  M. de Objetos del Negocio (Business Object Model)  M. de Casos de Uso (Use-Case Model)  M. de Análisis (Analysis Model)  M. de Diseño (Design Model)  M. de Despliegue (Deployment Model)  M. de Datos (Data Model)  M. de Implementación (Implementation Model)  M. de Pruebas (Test Model) UNPSJB - 2005 19
  20. 20.  Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado Se representan gráficamente como: Nombre de paquete UNPSJB - 2005 20
  21. 21.  Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema) Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes UNPSJB - 2005 21
  22. 22.  Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa El operador “::” permite designar una clase definida en un contexto distinto del actual UNPSJB - 2005 22
  23. 23. UNPSJB - 2005 23
  24. 24.  Casos de Uso es una técnica para capturar información de cómo un sistema o negocio Verificar Situación del Cliente trabaja, o de cómo se Supervisor desea que trabaje No pertenece estrictamente al enfoque orientado a Administrativo Preparar Catálogo Sistema objeto, es una técnica Inventario para captura de requisitos Tipos de Venta UNPSJB - 2005 24
  25. 25. En el paquete tipos de venta: Otro Ejemplo Venta Normal Solicitar Préstamo Cliente [Tarjeta Caducada] <<extend>> Venta en Rebajas Vendedor Solicitar Nueva Tarjeta Venta en Ofertas UNPSJB - 2005 25
  26. 26. <<include>> Reintegro Cuenta CorrienteCliente Verificar Operación <<include>> Reintegro Cuenta de Crédito UNPSJB - 2005 26
  27. 27. :WInPréstamos :Socio :Video :Préstamo: Encargado prestar(video, socio) verificar situación socio verificar situación video registrar préstamo entregar recibo UNPSJB - 2005 27
  28. 28. :Socio :Video 2: verificar situación socio 1: prestar(video, socio) 3: verificar situación video :WInPréstamos 5: entregar recibo: Encargado 4: registrar préstamo :Préstamo Ingeniería de Software - Clase 6 UNPSJB - 2005 28
  29. 29.  El Diagrama de Clases es el diagrama principal para el análisis y diseño 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 Ingeniería de Software - Clase 6 UNPSJB - 2005 29
  30. 30. (Clase y Visibilidad) Asociación dirige director Departamento Profesor 0..1 1 UNPSJB - 2005 30
  31. 31. empleador trabajadoresEmpresa Empleado * 1..* Cargo superior nombre sueldo 0..1 subordinado 1..* UNPSJB - 2005 31
  32. 32. Trabajador{ disjunta, completa }Directivo Administrativo Obrero UNPSJB - 2005 32
  33. 33. Motor Piloto Vendedor de billetes 1..4 1..2 1 1 n n 1 n 1 n Avión Vuelo Reserva n { disjunta, completa } 1Avión militar Avión comercial Línea aérea { disjunta, completa } Avión de carga Avión de pasajeros Ingeniería de Software - Clase 6 UNPSJB - 2005 33
  34. 34. alta baja número_préstamos = 0 sin préstamos Socionúmero : intnombre : char[50]número_prestamos : int = 0 prestar devolver[ número_préstamos = 1 ]alta()baja()prestar(código_libro : int, fecha : date)devolver(código_libro : int, fecha : date) número_préstamos > 0 con préstamos prestar devolver[ número_préstamos > 1 ] UNPSJB - 2005 34
  35. 35. [no hay café] [no zumo] Buscar Bebida [hay café [hay zumo] Poner café en filtro Añadir agua al depósito Agarrar tazaPoner filtro en máquina Agarrar zumo Encender máquina / cafetera.On Café en preparación indicador de fin Servir café Beber UNPSJB - 2005 35
  36. 36. Pasajero Vendedor AirlineSolicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y preciosSeleccionar vuelo Solicitar pago Reservar plazas Confirmar Pagar pasaje plaza reservada Emitir billete UNPSJB - 2005 36
  37. 37. Control y Análisis Interf az de Terminal Comment CommentGestión de Cuentas Acceso a BD Rutinas de Coneccion Comment Comment Comment UNPSJB - 2005 37
  38. 38. Servidor Central Control y Análisis Acceso a BD Comment Comment Rutinas de Coneccion Comment Terminal de Consulta Interfaz de Terminal Rutinas de Coneccion Comment CommentPunto de Venta Rutinas de Coneccion Comment Gestión de Cuentas Interfaz de Terminal Comment Comment UNPSJB - 2005 38
  39. 39.  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 UNPSJB - 2005 39

×