1 / 38

Ingeniería de Software Orientada a Objetos

Universidad Tecnologica Nacional Facultad Cordoba. Laboratorio de Sistemas Area de Investigacion & Desarrollo. Ingeniería de Software Orientada a Objetos. Ing. Fernando A. Cuenca. Breve Revisión para Jefes de Proyecto. Agenda. Métodos y procesos Revisión de Conceptos de O-O OOSE

katina
Download Presentation

Ingeniería de Software Orientada a Objetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Universidad Tecnologica Nacional Facultad Cordoba Laboratorio de Sistemas Area de Investigacion & Desarrollo Ingeniería de Software Orientada a Objetos Ing. Fernando A. Cuenca Breve Revisión para Jefes de Proyecto

  2. Agenda • Métodos y procesos • Revisión de Conceptos de O-O • OOSE • Modelo de Use Cases • El Proceso Objectory

  3. El marco conceptual Herramientas Proceso Método Arquitectura Filosofía

  4. Arquitectura tradicional

  5. Arquitectura Orientada a Objetos

  6. Ventajas de la OO • Modelado mas natural de los problemas • Mejor manejo de la complejidad • Fomenta el reuso, con gran impacto en productividad y confiabilidad • Facilita el mantenimiento y extensión

  7. Efectos de Encapsulamiento • Componentes autocontenidos • Separación entre Interfaz e Implementación • Acceso controlado a la parte privada • Libertad para modificar la implementación • Menor nivel de acoplamiento

  8. ¿Qué significa “Orientado a Objetos”? Un modelo es orientado a objetos cuando está compuesto por un conjunto de objetos que cooperan entre si enviándose mensajes. Dichos objetos pertenecen a clases, las cuales pueden relacionarse entre si por medio de la herencia.

  9. ¿Qué es un Objeto? Un Objeto representa un ítem o entidad individual (ya sea conceptual o real) con un rol bien definido en el dominio del problema.

  10. Objetos: algunos ejemplos

  11. ¿Qué es una Clase? • Plantilla (o template) • Una Clase es la especificación o descripción genérica de un conjunto de objetos • Conjunto de instancias • Una Clase es un conjunto de objetos que comparten características y comportamientos comunes

  12. Objetos vs. Clases • Objeto • entidad individual • Clase • Especificación o descripción genérica • Todo Objeto es instancia de una Clase

  13. Mensajes y Polimorfismo

  14. Herencia: “es-un”

  15. Composición: “parte-de”

  16. OOSE Construcción Testeo Requerimientos Análisis Sistema

  17. Análisis Análisis de Robustez Requerimientos Análisis de Requerimientos Modelo de Use Cases Modelo de Análisis

  18. Construcción Modelo de Use Cases Diseño Implementación Modelo de Análisis Modelo de Diseño Modelo de Implementación

  19. Testeo Modelo de Use Cases Testeo de unidad Modelo de Diseño Producto Final Testeo de Integración Testeo de Sistema Modelo de Implementación Modelo de Testeo

  20. Modelo de Use Cases Modelo de Testeo Modelo de Implementación Modelo de Diseño Modelo de Análisis Modelo del Dominio Rol del Modelo de Use Cases Expresado Validado Estructurado Implementado Materialiado

  21. Use Cases Un Use Case es una secuencia típica de interacciones entre el sistema y sus actores, que apunta a obtener un resultado de valor para los mismos.

  22. Actores • Un Actor es un rol que entes del entorno asumen en relación al sistema • Entes: personas, dispositivos, sistemas, etc. • 1 Usuario = 1 o más roles • Actores primarios y secundarios

  23. ¿Modelamos el negocio o el software?

  24. Un ejemplo: Use Cases del negocio

  25. Un ejemplo: Use Cases del sistema informático

  26. Use Cases y Escenarios • Curso normal y cursos alternativos • Extensiones y variaciones • Relaciones de uso

  27. Más modelos... • Modelo de Objetos del Dominio • Modelo de Objetos/Diagramas de Clases • Diagramas de Interacción • Diagramas de Transición de Estados

  28. El Proceso de Desarrollo • Procesos en Cascada vs. Iterativos e Incrementales • Macroproceso y Microproceso

  29. El proceso Objectory Construcción Concepción Elaboración Transición 1 2 3 ...

  30. Concepción • “Tengo una idea! ... podríamos hacer un sistema que nos permita....” • Análisis de Factibilidad • Alcances preliminares del proyecto

  31. Elaboración • Definición de los requerimientos • Análisis y diseño de alto nivel • Establecer la arquitectura de base • Planificar la construcción • Análisis de Riesgo como fuerzas guia

  32. Elaboración • Riesgos asociados a requerimientos • Riesgos tecnológicos • Riesgos asociados a la capacitación • Riesgos políticos

  33. Elaboración: Actividades • Modelado de Use Cases • Modelado del Dominio • Modelo de Diseño • Construcción del prototipo

  34. Elaboración: la arquitectura de base • Modelo de Use Cases • Modelo del Dominio • Plataforma tecnológica

  35. Elaboración: planificación de la construcción • Priorizar los Use Cases • Estimar el tiempo requerido para cada Use Case • Definir el largo de la iteración (en semanas) • Calcular la cantidad de iteraciones • Asignar Use Cases a iteraciones • Agregar tiempo extra por contingencias (10% - 20%)

  36. Construcción • Cada iteración es un “mini-proyecto” • Cada iteración se centra en ciertos Use Cases • Cada iteración es incremental • No se permite desplazar fechas

  37. Transición • Optimización • Ajuste fino de los detalles • Definición de los detalles de la puesta en marcha

  38. Preguntas y Respuestas

More Related