ANALISIS Y DISEO ORIENTADO A OBJETOS

ANALISIS Y DISEO ORIENTADO A OBJETOSRicardo Giraldo Gmez

ADOOIntroduccinEl 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 conocimientoTodo es basado en clases y objetosADOOJustificacin

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)ADOOUna 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 programacinIntegracin de tecnologas y aplicacionesSurgimiento de nuevos estndaresADOO

ADOO

La Orientacin a ObjetosADOOModelos de ciclo de vidaQu 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.

La eleccin de uno u otro depende de las caractersticas del proyecto.

Con tecnologas orientadas a objetos se tiende a ciclos de vida iterativos e incrementales.ADOOMCV en CascadaDesventajasNo permite iteraciones

Los Requisitos se congelan al principio del Proyecto.

No existe un proyecto enseable hasta el final del proyecto

Estudio de Viabilidad, Planificacin y EstimacinRetiroADOOMCV Iterativo e Incremental (RUP)

[mas iteraciones]PlanificacinAnlisisDiseoExtraer Clases ReutilizablesPrototipoPruebasEval. Cliente[mas iteraciones]IncrementoPlanificacinAnlisisDiseoIteracin de A & DADOOProblema vs SolucinControl TrficoAvinControlador TrficoAeropuertoPlan VueloModelo del Dominio del Problema

Dominio del Problema

Dominio de la SolucinVentana ResumenVentana MapasBD Plan de VuelosControl TrficoModelo Dominio de la SolucinADOOParadigma de Orientacin a Objetos

Diseos modulares.Efectos laterales mnimos(encapsulamiento)Extensibilidad.Fcil de modificar.Orientado a datos.Explota la herencia (jerrquico).Reutilizacin de clases.ADOOVentajas

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 realPrototipos rpidosHerramientas y bibliotecas muy ampliasAplicaciones construidas enganchando objetosMejor comprensin y mantenimientoApropiado para aplicaciones dirigidas por eventos.ADOOInconvenientes

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).ADOOAnlisis Orientado a ObjetosEl 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 datosPermanece estable ante el cambio de requisitosNo nfasis Entrada-Salidanfasis en el contenido de las entidadesNo agrupa funciones, agrupa mtodosPaso de mensajes determina la secuencia de funcionamientoADOOAnlisis Orientado a ObjetosCentrarse 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.ADOOAnlisis Orientado ObjetosLa especificacin de requisitos describe el sistema, en lenguaje natural.

Sirve de comunicacin entre desarrolladores y clientes, contrato.

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

Sirve de comunicacin entre desarrolladores.Obtencin de RequisitosAnlisisDiseo del SistemaEspecificacin de requisitos: DocumentoModelo de Anlisis: ModeloModelo del SistemaADOOAnlisis Orientado a ObjetosModelos de AnlisisModelo 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 DatosDiagramas de Flujo de ControlDiagrama de Transicin de Estados

Modelo basado en Clases

Diagrama de Clases.Diagrama de Paquetes.Modelo CRCDiagramas de Interaccin

Modelo basado en Comportamiento

Diagramas de EstadoDiagramas de Secuencia

MODELOS DE ANALISISADOOAnlisis Orientado a ObjetosModelos de Anlisis: Basado en Escenarios.Modelo funcional: casos de uso y escenarios.

Modelo de Objetos: diagramas de clases y objetos.

Modelo dinmico: diagramas de secuenciasModelo de Anlisis: ModeloModelo Funcional : ModeloModelo de Objetos : ModeloModelo Dinmico : ModeloADOOAnlisis Orientado a ObjetosModelos 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.

ADOOCasos 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)ADOOCasos de usoPasos:Identificar los lmites (alcance) del sistema.

Identificar los actores principales.

Para cada uno, identificar sus objetivos.

Definir casos de uso que satisfagan sus objetivos.ADOOCasos 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.ADOOCasos 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.ADOOCasos 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.ADOOCasos 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)ADOOModelos de Anlisis Basados en ClasesIdentificar las clasesAnalizar 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 ConceptualesADOODiagramas 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 relacionesLos 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 sistemaPara modelar colaboraciones simples.Para modelar el esquema lgico de una base de datosADOOClasificacin 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 anlisisCaso de uso Procesar VentaADOOMtodo de Clase-Responsabilidad-Colaborador (CRC)

Clases/Responsabilidades/ColaboradoresFacilitan 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)ADOOMtodo 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.