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
Datos globales

Subrutinas
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

Artículos, Facturas,
Operaciones comerciales Ventas, Compras, Clientes,
Contratos, Créditos, etc.
Orden de Fabricación,
Procesos industriales Productos y piezas,
Métodos, Máquinas, etc.
Nodos, Enlaces,
Redes de Computadoras 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 instancias
 UnaClase es un conjunto de objetos que
comparten características y comportamientos
comunes
 Objetos vs. Clases
 Objeto
 entidad individual
 Clase
 Especificación o descripción genérica
 Todo Objeto es instancia de una Clase
Mensajes y Polimorfismo

Objeto Objeto
Emisor Mensaje Receptor

Método
Herencia: “es-un”
Composición: “parte-de”

C o m p u ta d o ra

M o u se

M o n ito r

G a b in e te T e c la d o

CPU M e m o ria R A M D isk e tte ra D isc o D u ro

 OOSE

Requerimientos Análisis Construcción Testeo Sistema

 Análisis

Requerimientos Análisis de Análisis de

Requerimientos Robustez

Modelo de Modelo de
Use Cases Análisis
 Construcción

Modelo de
Use Cases
Diseño Implementación

Modelo de
Análisis

Modelo de Modelo de
Diseño Implementación
 Testeo

Modelo de
Use Cases

Testeo de unidad
Modelo de Producto
Diseño Testeo de Integración
Final
Testeo de Sistema

Modelo de
Implementación

Modelo de
Testeo
 Rol del Modelo de Use Cases
Modelo de
Expresado Use Cases
Validado

Modelo del
Estructurado Implementado Modelo de
Dominio
Testeo
Materialiado

Modelo de Modelo de Modelo de

Análisis Diseño 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.
 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

Lector
Prestamo a Domicilio

Revision para Actualizacion

Comision
Directiva
Un ejemplo: Use Cases del sistema
informático

Consignar Préstamo
Bibliotecario

Consignar Devolución

Confeccionar reporte de
disponibilidades

Consultar disponibilidad libro

 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
 Procesosen Cascada vs. Iterativos e Incrementales
 Macroproceso y Microproceso
 El proceso Objectory

Construcción
Concepción Elaboración Transición
1 2 3 ...
 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