Ingeniería de Software Orientada a Objetos

Presentación del tema: "Ingeniería de Software Orientada a Objetos"— Transcripción de la presentación:

1 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 Breve Revisión para Jefes de Proyecto Ing. Fernando A. Cuenca

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
Estructuras de datos globales y pasivas Algoritmos que manipulan esa estructura de datos Serios problemas de acoplamiento

5 Arquitectura Orientada a Objetos
Conjunto cooperante de objetos encapsulados que interactúa por medio del envío de mensajes

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. Dominio del problema: aquella porción particular del mundo que puede distinguirse porque convenientemente se la considera como un todo, hasta cierto punto, separado del resto de la realidad. En el contexto de todo desarrollo de software, hay al menos dos dominios: el Dominio del Problema y la Dominio de la Máquina. Puede pensarse que en Dominio del Problema es aquello que esta dado, mientras que el de la Máquina es aquel a contruir.

10 Objetos: algunos ejemplos

11 ¿Qué es una Clase? Plantilla (o template) Conjunto de instancias
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 Clase Todo Objeto es instancia de una Clase
entidad individual Clase Especificación o descripción genérica Todo Objeto es instancia de una Clase

13 Mensajes y Polimorfismo
La única forma de acceder a un objeto es enviándole un Mensaje. “Acceder” obtener información del objeto solicitar la realización de una acción El objeto está encapsulado Elementos: Emisor y Receptor (Cliente y Servidor) Selector y parámetros Método Polimorfismo: es la habilidad que tienen diferentes clases para comportarse de manera diferente ante el mismo mensaje. Desde el punto de vista del receptor: Es la capacidad de diferentes objetos de responder de diferente manera ante el mismo mensaje. Desde el punto de vista del emisor: Es la capacidad para manipular objetos de diferentes clases solo en base al conocimiento de sus propiedades comunes, sin tener en cuenta la clase exacta a la que pertenecen.

14 Herencia: “es-un” Permite definir nuevas clases en base a otras clases ya existentes. Expresa relaciones semánticas (es-un) Generalización/Especialización La subclase extiende la superclase, redefiniendo y/o agregando propiedades.

15 Composición: “parte-de”
Jerarquías de “todo-y-parte”

16 OOSE Construcción Testeo Requerimientos Análisis Sistema

17 Análisis Análisis de Robustez Requerimientos Análisis de
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 Rol del Modelo de Use Cases
Expresado Validado Modelo del Dominio Modelo de Testeo Estructurado Implementado Materialiado Modelo de Análisis Modelo de Diseño Modelo de Implementación

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. Las interacciones comienzan a partir del primer evento y continúan hasta que el objetivo primario del actor se satisface o se abandona.

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 Un Usuario en particular puede jugar múltiples roles en diferentes momentos del tiempo Los Actores pueden materializarse en personas, dispositivos, sistemas externos, etc. Actores primarios: un actor que tiene un cierto objetivo para cuyo cumplimiento requiere de la asistencia del sistema Actores secundarios: actores desde los cuales el sistema requiere asistencia para poder cumplir sus funciones.

23 ¿Modelamos el negocio o el software?
Un sistema informático da soporte al funcionamiento de un sistema de negocios Los use cases pueden utilizarse para modelar los casos de uso del negocio por parte de los clientes externos, o bien para modelar la utilización por parte de los recursos de la organización de los sistemas informáticos que les permiten llevar adelante dichos procesos de negocio para sus clientes.

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 Escenario: un camino en particular a través de un Use Case, que muestra una particular combinación de condiciones dentro de ese Use Case. Todo Use Case tiene al menos un escenario: aquel donde todo sale bien (el curso normal) Extensiones: alteraciones significativas en el curso de eventos Variaciones: alternativas poco significativas que pueden ocurrir en una cierta interacción. Relaciones de Uso: permiten extraer porciones comunes entre varios use cases.

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 ... De acuerdo a “UML Distilled” de Matrin Fowler.

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 Riesgos de requerimientos: evitar construir el sistema incorrecto Riesgos tecnológicos: como calzan juntas las distintas piezas tecnológicas a usar? Riesgos de capacitación: tenemos la experiencia y know-how suficiente para el proyecto? Riesgos políticos: que tipo de reacciones se espera que aparezcan en la organización si el proyecto se concreta o fracasa?

33 Elaboración: Actividades
Modelado de Use Cases Modelado del Dominio Modelo de Diseño Construcción del prototipo Modelado de Use Cases: capturar los requerimientos funcionales Modelado del Dominio: comprender los conceptos que hay detrás del vocabulario del problema Modelo de Diseño: establecer la arquitectura del sistema, con énfasis en la futura extensibilidad del sistema

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%) Los Use Case se priorizan en función de su importancia funcional, su riesgo arquitectural y la certeza en su estimación El largo de la iteración debe ser fijo, para darle un ritmo constante al proyecto y evitar la parálisis. La fecha finalización interna no debe considerar el período de contingencias, pero la externa si.

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 Durante la Transición no hay desarrollo nuevo para incrementar la funcionalidad, pero si para corregir errores, realizar ajuste fino, etc.

38 Preguntas y Respuestas