Ingeniería de Software Orientada a Objetos

Ing. Fernando A. Cuenca

Universidad Tecnologica NacionalFacultad Cordoba

Laboratorio de SistemasArea de Investigacion & Desarrollo

Breve Revisión para Jefes de Proyecto

Agenda

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

El marco conceptual

Filosofía

Arquitectura

Método

Proceso

Herramientas

Arquitectura tradicional

Subrutinas

Datos globales

Arquitectura Orientada a Objetos

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.

Objetos: algunos ejemplos

Dominio del Problema Objetos

Operaciones comercialesArtículos, Facturas,Ventas, Compras, Clientes,Contratos, Créditos, etc.

Procesos industrialesOrden de Fabricación,Productos y piezas,Métodos, Máquinas, etc.

Redes de ComputadorasNodos, Enlaces,Protocolos, Dispositivos,Usuarios, Permisos, etc.

¿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 instanciasUna Clase es un conjunto de objetos que

comparten características y comportamientos comunes

Objetos vs. Clases

Objetoentidad individual

ClaseEspecificación o descripción genérica

Todo Objeto es instancia de una Clase

Mensajes y Polimorfismo

Mensaje

Método

ObjetoReceptor

ObjetoEmisor

Herencia: “es-un”

Composición: “parte-de”

C o m p u t a d o r a

M o n i t o r

G a b i n e t e

M o u s e

T e c l a d o

C P U M e m o r i a R A M D i s k e t t e r a D i s c o D u r o

OOSE

Análisis TesteoConstrucciónRequerimientos Sistema

Análisis

Requerimientos Análisis de Robustez

Análisis de Requerimientos

Modelo de Use Cases

Modelo de Análisis

Construcción

ImplementaciónDiseño

Modelo de Use Cases

Modelo de Análisis

Modelo de Diseño

Modelo de Implementación

Testeo

Testeo de unidad

Modelo de Use Cases

Modelo de Diseño

Modelo de Implementación

Testeo de Integración

Testeo de Sistema

Producto Final

Modelo de Testeo

Rol del Modelo de Use Cases

Modelo de Use Cases

Modelo deTesteo

Modelo de Implementación

Modelo de Diseño

Modelo de Análisis

Modelo delDominio

Expresado

Estructurado

Materialiado

Implementado

Validado

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.

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

¿Modelamos el negocio o el software?

Un ejemplo: Use Cases del negocio

Consulta en Sala de Lectura

Prestamo a Domicilio

Lector

Comision Directiva

Revision para Actualizacion

Un ejemplo: Use Cases del sistema informático

Consultar disponibilidad libro

Consignar Préstamo

Consignar Devolución

Bibliotecario

Confeccionar reporte de disponibilidades

Use Cases y Escenarios

Curso normal y cursos alternativos Extensiones y variaciones Relaciones de uso

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

Concepción Elaboración Transición1 2 3 ...

Construcción

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

Elaboración: Actividades

Modelado de Use Cases Modelado del Dominio Modelo de Diseño Construcción del prototipo

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%)

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

Preguntas y Respuestas