Ricardo Giraldo Gmez

ADOO
Introduccin
El ADOO es un proceso evolucionario, sigue la huella de las anteriores abstracciones.

Por qu es tan popular?.

Por que se espera que nos conduzca de manera fcil y

rpida a un incremento de la productividad. Porque usa tcnicas de razonamiento similar a la usadas para resolver problemas de otros dominios. Uno de sus aspectos la POO se convierte en nuevo paradigma Conjunto de teoras, estndares y mtodos que juntos representan una forma organizar el conocimiento Todo es basado en clases y objetos

ADOO
Justificacin
Un proyecto software no consiste slo en programar. Necesitamos saber cules son las necesidades del cliente.
Identificar los requisitos, anotarlos, analizarlos, validarlos.

Necesitamos disear una solucin, y hacer los planos del

software: Diseo de la arquitectura, detallado, de datos, Hay que asegurarse de que el software funciona: Pruebas de unidad (a nivel de mtodo y clase), de integracin, del sistema, de aceptacin, etc. Hay que mantener el software. Documentacin (de cada una de las fases), coherencia entre los productos de las distintas fases (ej. cdigo vs. diseos)

ADOO
Una visin al futuro
Las tcnicas orientadas a objetos han sido empleadas por la

comunidad investigadora durante ms de 20 aos. Su uso tom fuerza cuando empezaron a aparecer lenguajes muy populares que soportaban algunas de las ideas de las tcnicas orientadas a objetos (Cobol, Pascal, C). Las nuevas tendencias muestran:
Una fuerte tendencia hacia el uso de herramientas visuales de

apoyo al diseo y programacin Integracin de tecnologas y aplicaciones Surgimiento de nuevos estndares

ADOO

ADOO
La Orientacin a Objetos

ADOO
Modelos de ciclo de vida
Qu estrategia seguimos para organizar las fases de un

proyecto?.

Un modelo de ciclo de vida nos gua en las fases que hay

que realizar, sus entradas y salidas, y los criterios de transicin. del proyecto.

La eleccin de uno u otro depende de las caractersticas Con tecnologas orientadas a objetos se tiende a ciclos

de vida iterativos e incrementales.

ADOO
MCV en Cascada
Estudio de Viabilidad, Planificacin y Estimacin

Desventajas
No permite iteraciones Los Requisitos se congelan al

Anlisis Diseo Desarrollo Prueba e Integracin

principio del Proyecto.

No existe un proyecto

Operacin y Mantenimiento

enseable hasta el final del proyecto

Retiro

ADOO
MCV Iterativo e Incremental (RUP)
[mas iteraciones]

Iteracin de A & D Planificacin

Anlisis

Diseo

Incremento Planificaci n

Anlisis

Diseo

Extraer Clases Reutilizables

Prototipo

Pruebas

Eval. Cliente

[mas iteraciones]

ADOO
Problema vs Solucin

Dominio del Problema

Dominio de la Solucin

Modelo del Dominio del Problema

Control Trfico Avin Controlador Trfico Aeropuert o

Modelo Dominio de la Solucin

Ventana Resumen Ventana Mapas BD Plan de Vuelos Control Trfico

Plan Vuelo

ADOO
Paradigma de Orientacin a Objetos
Diseos modulares. Efectos laterales mnimos(encapsulamiento)

Extensibilidad.
Fcil de modificar. Orientado a datos. Explota la herencia (jerrquico). Reutilizacin de clases.

ADOO
Ventajas
Mdulos con fuerte cohesin interna y escaso

acoplamiento externo (sin variables globales, ) Facilita el funcionamiento en entorno multiprocesador (objetos distribuidos) Correspondencia directa con el mundo real Prototipos rpidos Herramientas y bibliotecas muy amplias Aplicaciones construidas enganchando objetos Mejor comprensin y mantenimiento Apropiado para aplicaciones dirigidas por eventos.

ADOO
Inconvenientes
Impactos desfavorables sobre espacio y tiempo de

ejecucin. Forma de pensar diferente: curva de aprendizaje lenta. Herencia y ligadura dinmica dificultan las pruebas. Difcil seguir el flujo de ejecucin (e.j. llamadas implcitas a constructores, conversiones implcitas, etc.) Frameworks grandes y complicados (e.j. MFCs).

ADOO
Anlisis Orientado a Objetos
El anlisis de sistemas orientado a objetos es un nuevo

mtodo que realza la definicin de las caractersticas y comportamiento dentro de un sistema de objetos. Caractersticas:
Reduce el cdigo derivado de los datos

Permanece estable ante el cambio de requisitos

No nfasis Entrada-Salida nfasis en el contenido de las entidades No agrupa funciones, agrupa mtodos Paso de mensajes determina la secuencia de funcionamiento

ADOO
Anlisis Orientado a Objetos
Centrarse en el qu. Identificar los requisitos: documentos de anlisis. Entrevistas. Identificar requisitos funcionales y no funcionales (ej.: rendimiento, fiabilidad) Especificar los requisitos: documento de especificacin de

requisitos.

Documento tcnico. Organizacin y clasificacin de los

requisitos.

Analizar: Modelos de anlisis. Estudio de posibles escenarios: casos de uso. Otras tcnicas: fichas CRC, orientados al flujo, etc. Validar.

ADOO
Anlisis Orientado Objetos
La especificacin de requisitos

describe el sistema, en lenguaje natural.

Obtencin de Requisitos

Especificacin de requisitos: Documento Modelo de Anlisis: Modelo

Sirve de comunicacin entre

desarrolladores contrato.
El

clientes,

Anlisis

modelo de anlisis usa notacin formal (ej.: Z, Alloy) o semi-formal (ej.: UML).

Diseo del Sistema

Modelo del Sistema

Sirve de comunicacin entre

desarrolladores.

ADOO
Anlisis Orientado a Objetos
Modelos de Anlisis
Modelo basado en escenarios
Caso de uso, texto. Caso de usos, diagramas. Diagramas de Actividad. Diagramas de Secuencia Modelo Orientado a flujo

Diagrama de Flujo de Datos Diagramas de Flujo de Control Diagrama de Transicin de Estados

MODELOS DE ANALISIS
Modelo basado en Clases Diagrama de Clases. Diagrama de Paquetes. Modelo CRC Diagramas de Interaccin Modelo basado en Comportamiento

Diagramas de Estado Diagramas de Secuencia

ADOO
Anlisis Orientado a Objetos
Modelos de Anlisis: Basado en Escenarios.
Modelo de Anlisis: Modelo

Modelo Funcional : Modelo

Modelo de Objetos : Modelo

Modelo Dinmico : Modelo

Modelo funcional: casos de uso y escenarios. Modelo de Objetos: diagramas de clases y objetos. Modelo dinmico: diagramas de secuencias

ADOO
Anlisis Orientado a Objetos
Modelos de Anlisis: Basado en Escenarios.
Un escenario es una secuencia especfica de acciones que ilustra un

comportamiento. Los escenarios son a los casos de uso lo que las instancias a las clases, es decir, un escenario es bsicamente una instancia de un caso de uso.

ADOO
Casos de uso
Describen qu hace el sistema desde el punto de vista

de un observador externo. Actores: quin interacta con el sistema?. Tambin pueden ser otros sistemas. Un escenario es un ejemplo de lo que ocurre cuando uno o varios actores interactan con el sistema. Caso de uso: conjunto de escenarios (secuencias de interaccin de los actores y el sistema)

ADOO
Casos de uso
Pasos: Identificar los lmites (alcance) del sistema.
Identificar los actores principales. Para cada uno, identificar sus objetivos. Definir casos de uso que satisfagan sus objetivos.

ADOO
Casos de Uso: Ejemplo
CASO DE USO 1: Procesar venta Uso: Actor Primario:
Cajero.

Interesados y objetivos:
Cajero: Quiere anotaciones precisas y rpidas de precios, sin errores. Cliente: Quiere que el pago sea rpido con el mnimo esfuerzo. Quiere una prueba de

compra para justificar devoluciones. Compaa: Quieren almacenar las transacciones y satisfacer los intereses de los clientes. Comercial: Quiere que se le actualicen sus comisiones por venta. Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cada venta. Puede que haya varias agencias (nacionales, regionales, etc.) Servicios de Autorizacin de Pagos (por tarjetas de crdito): Quiere recibir peticiones digitales de autorizaciones en el formato y protocolo correcto.

Precondiciones:
El cajero se ha identificado y autentificado.

ADOO
Casos de Uso: Ejemplo
Garanta de xito (Postcondiciones): Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de inventario y contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las aprobaciones de pago por tarjeta. Escenario principal de Exito:

1. Llega un clienta al TPV con bienes o servicios que comprar. 2. El cajero comienza una nueva compra. 3. El cajero introduce un identificador de producto. 4. El sistema registra el elemento y presenta una descripcin del mismo, su precio y total actual. Se calcula el precio de una lista de reglas. El cajero repite los pasos 3-4 hasta que no hay ms elementos. 5. El sistema presenta el total con los impuestos calculados. 6. El cajero le dice el total al cliente, y le pide que pague. 7. El cliente paga y el sistema procesa el pago. 8. El sistema registra la venta completada y manda la informacin a los sistemas externos de inventario y contabilidad. 9. El sistema genera el recibo. 10. El cliente se va.

ADOO
Casos de Uso: Ejemplo
Extensiones (Flujos alternativos): a*. En cualquier momento, el sistema falla. 3a. Identificador invlido. 1. El sistema seala un error y rechaza la entrada. 7a. Pago en efectivo. ... 7b. Pago con tarjeta. ... Requisitos especiales:

Pantalla tctil en panel grande y plano. El texto debe ser visible desde un metro. Respuesta de autorizacin de crdito en menos de 30 secs, el 90% de las veces. Recuperacin robusta cuando el acceso a sistemas externos (tales como el inventario, impuestos, etc.) falla. Posibilidades de internacionalizacin de texto. Reglas de negocio insertables en los pasos 3 y 7.

ADOO
Casos de Uso: Ejemplo
Lista de variaciones de tecnologa y datos:
3a. Se introduce el identificador del elemento mediante escner de cdigo de barras o mediante el teclado. 3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU. 7a. La informacin sobre el pago con tarjeta se puede introducir mediante el teclado o ector. 7b. Se pide firma en papel. En dos aos, creemos que muchos clientes van a querer captura de firma digital. Frecuencia de ocurrencia: Puede ser casi continua. Temas abiertos: Cules son las posibles variaciones en las leyes sobre impuestos? Explorar el tema de recuperacin en caso de fallo de sistemas externos. Qu modificaciones se necesitan para negocios distintos? Debe el cajero extraer el cajn con la recaudacin al terminar? Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?

ADOO
Diagrama de Casos de Uso (UML)

ADOO
Modelos de Anlisis Basados en Clases
Identificar las clases Analizar los documentos de anlisis, o casos de uso. Clases que pertenecen al espacio de la solucin vs. espacio del problema. Aislar los sustantivos:
Entidades externas: producen o consumen informacin que usa el

sistema. Cosas (informes, seales, etc.): informacin que necesita el sistema. Sucesos o eventos que ocurren durante la operacin del sistema. Papeles que desempean los usuarios. Unidades organizacionales. Sitios que establecen el contexto y la funcin global del sistema. Estructuras que definen una clase de objetos o clases relacionadas.

ADOO
Diagrama de clases Conceptuales

ADOO
Diagramas de Clases
Los diagramas de clases son los ms utilizados en el modelado de

sistemas orientados a objetos. Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones Los diagramas de clases se utilizan para modelar la vista de diseo esttica de un sistema. Esta vista soporta principalmente los requisitos funcionales de un sistema, los servicios que el sistema debe proporcionar a los usuarios finales. Cuando se modela la vista de diseo esttica de un sistema, normalmente se utilizarn los diagramas de clases de unas de estas tres formas: Para modelar el vocabulario de un sistema Para modelar colaboraciones simples. Para modelar el esquema lgico de una base de datos

ADOO
Clasificacin de clases
Tipos de clases: entidad (a.k.a. de modelo o de negocio). Son clases que persisten durante la aplicacin. Representan informacin relevante para la aplicacin. De frontera (a.k.a. de contorno). Clases que crean la interfaz que el usuario ve y con la que interacciona. De control. Realizan una unidad de trabajo: crean o actualizan objetos de entidad, validan datos, etc.

ADOO
Diagrama de clases de anlisis
Caso de uso Procesar Venta

ADOO
Mtodo de Clase-Responsabilidad-Colaborador (CRC)
Clases/Responsabilidades/Colaboradores

Facilitan la colaboracin entre desarrolladores.

Una ficha por cada clase relevante. Se identifican sus responsabilidades.

Divisin de responsabilidades, relaciones de

colaboracin. Jerarquas de generalizacin/especializacin.

ADOO
Mtodo de Clase-Responsabilidad- Colaborador (CRC)

ADOO
Mtodo de Clase-Responsabilidad- Colaborador (CRC)
Un caso de uso captura el comportamiento esperado del sistema

(o subsistema, clase o interfaz) que est desarrollando, sin tener que especificar cmo se implementa ese comportamiento. Esta separacin es importante porque el anlisis de un sistema (que especifica un comportamiento) no debera estar influenciado, mientras sea posible, por cuestiones de implementacin (que especifican cmo se lleva a cabo el comportamiento). No obstante, un caso de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarn para llevar a cabo el comportamiento del caso de uso. Esta sociedad de elementos, incluyendo tanto su estructura esttica como la dinmica, se modela en UML como una colaboracin.