OOSE

2.632 visualizaciones

Publicado el

OOSE object oriented software engineering

Publicado en: Software
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
2.632
En SlideShare
0
De insertados
0
Número de insertados
9
Acciones
Compartido
0
Descargas
77
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

OOSE

  1. 1. Barreto Valderrama Lizbeth Cam Urquizo Daniel Castañeda Gallardo Carlos Gutierrez Romero Fabio OOSE (Object-oriented Software Engineering) →
  2. 2. ← → Index. Introducción Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com → Planteamiento → Etapas de OOSE → Ejemplo → Conclusiones →
  3. 3. OOSE Breve Introduccion a OOSE
  4. 4. ← → INTRODUCCION Con la aparición de la orientación a objetos se vio la necesidad de crear metodologia eficaces ´para modelas estos nuevos sistemas.(OMT, Booch, OSEE). OOSE. Fue desarrollado por Ivar Jacobson (02-09-1939). Sueco. Ingeniero Electronico (Instituto de la Tecnologia de Chalmers en Gotemburgo - 1968). Clave en el desarrollo de UML, junto a James Rumbaung (Object- Modeling Technique) y Grady Booch (método de Boch). (RUP) Objectory AB primera herramienta de OOSE. Esta se Fusionó con Rational y las herramientas de OOSE fueron remplazadas por Rational. Con el desarrollo de UML y Met. RUP, OSEE se estaba convirtiendo en obsoleto. OSEE 1992 (Utilizar Use Case para describir el Sistema) OOSE es el primero en utilizar el concepto de casos de uso para definir los paradigmas de diseño de software. Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Analisis Diseño Implementacion Pruebas
  5. 5. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Soportan los aspectos de la empresa, como act. Arquitectura, métodos y procesos. Permite escalamiento de métodos. (aplicado forma interactiva y en partes). Estable Explicita los procedimientos etapa por etapa. Una buena estructura del sist. es facil de entender, cambiar, test y mantem. (importantes y forman base del método). Diseño y Construccionde SW comparado Industriade Const. Planteamiento Herramientas Procesos Metodos Arquitectura Analisis Diseño Implementacion Pruebas
  6. 6. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com 5 Tecnicaso Etapas Planteadas por Jacobson Planteamiento Analisis Analisis Modelo requerimientos Modelo de analisis Construccion Modelo de diseño Implementacion Prueba Prueba Analisis Diseño Implementacion Pruebas
  7. 7. ← → El análisis de requerimientos. Modelado de casos de uso Diseño de interfaz de usuario Un modelo de dominio Análisis de Robustez Modelado El sistema con tres tipos de objetos Analisis diseño Iimplementación Descripciones de entorno Los diagramas de interacción Gráficos de transición de estado Un modelo de objeto Implementación Código Fuente Cosntrucción Prueba de la unidad Las pruebas de integración Las pruebas del sistema Pruebas Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Etapas de OOSE Analisis Diseño Implementacion Pruebas
  8. 8. ← → Limita Sistema y esp el comportamiento. (Use Case, descrp. GUI, problem domian model). Modelado Requerimientos Plantemiento de las 5 Tecnicasde OOSE Producir una estructura ideal, robusta y modificable de un objeto. Modelado Análisis Refina los objetos. Mateniendo una ambiente de implementacion. (diagram interacction, diagram transition state). Modelado Diseño Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Planteamiento Codigo Fuente de los Objetos especificados en Modelo Diseño. Modelado Impl. Comprobar y verificar la funcionalidad del Sistema. Modelo Prueba Analisis Diseño Implementacion Pruebas
  9. 9. I Modelo de Requerimientos
  10. 10. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Primera Etapa Modelo de Requerimientos Un modelo de requerimientos es creado para especificar toda la funcionalidad del sistema. Consiste en tres partes. Modelo de Casode Uso Idealización de un persona externa (Rol) u otro sist. Que interactua con otro, subsistema, clase. Actor Es una unidad o tarea de funcionalidad. … Asociaciones, escenarios(mas general). Caso deUso Representan las funciones que un sistema puede ejecutar. Analisis Diseño Implementacion Pruebas
  11. 11. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Primera Etapa About Portfolio Data Contact Análisis de Requerimientos
  12. 12. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Primera Etapa About Portfolio Data Contact Análisis de Requerimientos Descripción de Interfaces Es importante que los usuarios estén envueltos en las descripciones de las interfaces detalladas. Modelo de Dominio de Objeto Se define los conceptos con los que el sistema debe trabajar, muestra las instancias de objetos, clases y relación de asociaciones.
  13. 13. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Primera Etapa About Portfolio Data Contact Análisis de Requerimientos Modelo de Dominio de Objeto inherits inherits Cliente Base 0...N Contiene Cliente individual Grupo Cliente Cliente
  14. 14. II MODELO DE ANALISIS Llamado tambien Analisis de Estructura
  15. 15. ← → Analisis OBJECT-ORIENTED SOFTWARE ENGINEERING Analisis Modelo de Analisis Aquí se define la estructura lógica del sistema independiente de la aplicación. El modelo de análisis es la estructura más estable y mantenible del sistema Es el modelo producto de un análisis robustez Especifica los objetos lógicos, su relación y agrupacion
  16. 16. ← → Objetivos OBJECT-ORIENTED SOFTWARE ENGINEERING • Reconocer los objetos que forman parte del Sistema • Proporciona una prueba de completitud a los casos de uso, antes de pasar al diseño • Reconocer asociaciones y estructuras de objetos • Asignar atributos a los objetos • Asociar un objeto a sus atributos • Dividir el sistema en subsistemas (para preparar más adelante los paquetes). Analisis
  17. 17. ← → Elementos OBJECT-ORIENTED SOFTWARE ENGINEERING Consiste en operar diferentes entidades, realiza proceso y retorna resultado a un objeto • Transporta la acción del actor a los eventos del sistema • Cada actor puede tener su conjunto de interfaces Analisis OBJETO DE CONTROL
  18. 18. ← → Elementos OBJECT-ORIENTED SOFTWARE ENGINEERING • Modelan información perdurable • Modelo que captura datos • Por lo general actúan como controladores o coordinadores del proceso que se realice en los casos de uso Analisis OBJETO DE ENTIDAD
  19. 19. ← → Elementos OBJECT-ORIENTED SOFTWARE ENGINEERING Representar a las entidades que gestionan las transacciones entre el sistema y los actores en el mundo exterior. • Describe la comunicación bidireccional entre el sistema y sus usuarios, estos pueden ser los sistemas humanos u otros Analisis OBJETO DE INTERFAZ
  20. 20. ← → Ejemplo diagrama OBJECT-ORIENTED SOFTWARE ENGINEERING Analisis Interface Control Cliente Cliente Cliente Base Agregar Cliente Operador
  21. 21. ← → Elementos OBJECT-ORIENTED SOFTWARE ENGINEERING • Agrupan objetos en niveles • Reducen complejidad de estructura • La división es por funcionalidad y acoplamiento Analisis Subsistema Receptor items Panel de cliente Impresora Dispositivo alarma Paquete cliente Paquete alarma e impresora
  22. 22. III MODELO DE DISEÑO O llamado Modelo de Plan
  23. 23. ← → Modelo Diseño OBJECT-ORIENTED SOFTWARE ENGINEERING Diseño Modelo de Diseño Adapta el sistema al ambiente de implementación que será utilizado Refinar el Modelo de Análisis tomando en cuenta las características de implementación Describe detalles de clases de diseño Encontramos diagramas de interacción y de estado de transición
  24. 24. ← → Subfases OBJECT-ORIENTED SOFTWARE ENGINEERING Diseño Determinación de características de entorno de ejecución • (DBMS, las características del lenguaje de programación, distribución consideraciones) Definición de bloques • Cada objeto en el modelo de análisis se asigna un bloque • Añaden bloques de implementación • Definición de interfaces y semánticas Especificación de de interacción entre objetos y comportamiento • Diagrama de interacción • Diagrama de estado de transición
  25. 25. ← → Diagrama de bloques OBJECT-ORIENTED SOFTWARE ENGINEERING • Cada objeto de análisis simplemente se transforma en un bloque • La división es por funcionalidad y acoplamiento • Son llamado diagramas de clases Diseño VentaCliente
  26. 26. ← → Diagrama de interacción: OBJECT-ORIENTED SOFTWARE ENGINEERING • Describe lo que el uso incluye por lo que se refiere a comunicar los objetos • Se dibujo para c/u de los casos de uso • Se visualiza la interacción de envio y recibimiento de estimulo entre bloques Diseño Crear Iniciar Item() activar nuevo Item Panel cliente Receptor de items Borde sistema
  27. 27. ← → Grafo de transición de estado OBJECT-ORIENTED SOFTWARE ENGINEERING • se utiliza para describir el comportamiento de cada bloque. • Se usan para describir conducta del objeto por lo que se refiere a que pueden recibirse los estímulos y qué estímulos pueden causar • Usa notación SDL Diseño Venta
  28. 28. IV Modelo de Implementación
  29. 29. ← → Modelo de Implementación En esta etapa es cuando se procede a la ejecución del código fuente que ha sido seleccionado. Es la codificación del sistema tanto en el desarrollo de las Bases de Datos como las distintas Aplicaciones con las que contará. Traceabilidad Comunicación entre clases Leng. de Prog. Clases Robustas
  30. 30. ← → Modelo de Implementación Elaboración de los: Diagrama de Clases, Diagrama de Secuencias, Modelo Físico , Matriz de Funciones, Tranzabilidad de Casos de Uso Programas Codificados y versionados en SVN, Pruebas de pares, manual de usuario, Línea Base en SVN Diseño de la Aplicación Construcción
  31. 31. V Modelo de Prueba
  32. 32. ← → Modelo de Prueba En esta etapa se procede a probar tantos las aplicaciones como el funcionamiento de las Clases y la robustez del sistema. Se empieza por los niveles mas bajos del sistema : - Modulos deObjetos y Bloques - El Desarrollo de la Aplicación.
  33. 33. ← → Modelo de Prueba La comprobación de esta etapa es el Modelo de Requisito, ya que si se cuemplen todos los Requisitos allí especificados, para la aprobación. Aquí nuevamente la robustez del sistema Ayuda a la localización de faltas y la traceabilidad ayuda al movimiento dentro del Modelo Del Plan ( a donde la falta será corregida). Rol de los Casos de Uso en el Testing
  34. 34. Aplicación del Método de Análisis Orientado a Objetos
  35. 35. ← → Caso de Estudio : Biblioteca BIBLIOTECA Circulación Dirección Usuario Procesos Técnicos
  36. 36. ← → Biblioteca –Modelo de Requirimientos Actor Casos de Uso Personal de Procesos Técnicos Registrar Usuario Registrar Documento Registrar Pago de Multas Registrar Días Festivos Dirección Registrar Reglamento Cancelación Automática Reser. Generar Reporte Mens. Multas Cierre de semestre Usuario Consulta por autor Consulta por título Consulta por reservas Consulta de préstamos Personal de Circulación Préstamo, reserva, liquidación
  37. 37. ← → Biblioteca –Modelo de Requirimientos Caso de Uso : Reservas 1. El empleado de circulación digita la opción para la realización de la reserva. 2. La pantalla anterior aparece ante el empleado 3. El empleado digita el código del empleado que va a realizar la reserva. 4. Los campos nombre,estado,nro. de préstamos vencidos y nro. de multas aparecen automáticamente en la pantalla y no son modificables. 5. El empleado digita el número de indización, el volumen y la fecha. 6. Aparecen automáticamente en la pantalla los campos título y categoría, estos no son modificables. 7. Si el usuario desea reservar otro libro, el empleado repite los pasos 5 y 6. 8. Cuando no haya más libros para reservar, entonces el empleado Acepta la transición.
  38. 38. ← → Biblioteca –Modelo de Requirimientos Caso de Uso : Reservas
  39. 39. ← → Biblioteca –Modelo de Análisis
  40. 40. ← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - hello@prezzo.com Biblioteca –Modelo de Diseño
  41. 41. ← → Biblioteca – Modelo de Aplicación -Pruebas
  42. 42. OOSE Comparativa con las metodologías contemporáneas a Jacobson
  43. 43. ← → Comparativaconlas metodologías contemporáneasa Jacobson Comparativa con las metodologías contemporáneas a Jacobson METODOLOGIAS Ingeniería de software orientado a objetos OOSE Técnica de modelado de objetos OMT Metodología Booch DESARROLLADOR Desarrollada por Ivar Jacobson. Desarrollada por James Rumbaugh. Desarrollada por Grady Booch. FUNCIONALIDAD El modelo de caso de uso sirve como modelo central. Describe el análisis y diseño orientado a objetos, que incorporan tanto comportamiento como estructuras de datos. La realización de modelos es muy importante para la construcción de sistemas complejos. ENFOQUE El modelo de caso de uso es la base en la etapa de análisis, construcción y prueba. La esencia del desarrollo es la identificación y organización de conceptos en el dominio del problema. La parte más importante en el análisis y diseño orientado a objetos es la identificación de clases y objetos.
  44. 44. ← → Comparativaconlas metodologías contemporáneasa Jacobson Comparativa con las metodologías contemporáneas a Jacobson MODELOS Presenta cinco técnicas para modelar un sistema: Modelo de requerimientos, análisis, diseño, implementación y prueba. El sistema es descrito a partir de tres modelos diferentes: un modelo de objetos, un modelo dinámico, y un modelo funcional. Propone cuatro modelos de desarrollo orientado a objetos: estructura física y lógica y su semántica estática y dinámica. FUNCIONALIDAD MODELOS Estos modelos capturan el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas Cada modelo describe un aspecto del sistema pero contiene referencias a los demás Modelos, por eso no son totalmente independientes. Los aspectos metodológicos fueron incorporados en varias metodologías y procesos, siendo la principal el Proceso Racional Unificado (RUP). FUERZA Método fuerte para producir requisitos orientados al usuario y orientada a objetos modelo de análisis. Método fuerte para la producción de modelo de objetos de estructura estática del sistema. Método fuerte para la producción orientada a objetos detallados modelos de diseño. DEBILIDAD No trate la programación orientada a objetos al mismo nivel que otros métodos. No se puede expresar plenamente los requisitos. Centrarse exclusivamente en el diseño y no en análisis.
  45. 45. ← → Conclusiones  Este es el método más completo.  Tiene características favorables para los sistemas que requieren la participación de los usuarios y los expertos.  Los casos de uso conducen a lo largo del desarrollo del sistema.  Tiende a asegurar un sistema es consistente y coherente.  El uso de este tipo de objetos facilita las actualizaciones y el mantenimiento futuro del sistema.  La notación que el método utiliza es bastante diferente.  Esta metodología favorece el desarrollo del equipo.
  46. 46. Gracias

×