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

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

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

Arquitectura tradicional Estructuras de datos globales y pasivas Algoritmos que manipulan esa estructura de datos Serios problemas de acoplamiento

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

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

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

¿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.

¿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.

Objetos: algunos ejemplos

¿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

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

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.

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.

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

OOSE Construcción Testeo Requerimientos Análisis Sistema

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

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

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

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

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.

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.

¿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.

Un ejemplo: Use Cases del negocio

Un ejemplo: Use Cases del sistema informático

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.

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

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

El proceso Objectory Construcción Concepción Elaboración Transición 1 2 3 ... De acuerdo a “UML Distilled” de Matrin Fowler.

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

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

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?

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

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

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.

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

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.

Preguntas y Respuestas