Aspectos Avanzados de la Tecnología de Objetos

Aspectos Avanzados de la Tecnología de Objetos
1. Introducción Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy
Contenidos Calidad de Software: ¿Qué es un buen sistema? ¿Se tienen buenos sistemas? ¿Cómo son los buenos sistemas? ¿Cómo se construye un buen sistema? Modularidad. Tipos abstractos de datos. El proceso de desarrollo. Sistema, diseño, modelo, diagrama. Dr. Juan José Aranda Aboy

Objetivos específicos
Definir qué se entiende por un buen sistema. Caracterizar la problemática de los sistemas existentes. Conocer cómo el enfoque de análisis y diseño orientado a objetos contribuye a la construcción de buenos sistemas. Dr. Juan José Aranda Aboy

Introducción Programar es divertido, pero desarrollar software de calidad es difícil. Entre las ideas espléndidas, los requisitos o la “visión”, y un producto software funcionando hay un gran espacio y tiempo. El Análisis y el Diseño definen cómo solucionar el problema: qué programar. Su resultado debe ser fácil de comunicar, revisar, implementar y evolucionar. Nuestro objetivo estará focalizado en la Ingeniería de Software orientada a objetos como la manera en que se utiliza esta tecnología para realizar análisis efectivos que permitan diseños e implementaciones eficientes de buenos sistemas. Dr. Juan José Aranda Aboy

¿Qué es un buen sistema? Un buen sistema, de alta calidad, es aquel que cumple las necesidades de sus usuarios: Útil y aprovechable: Resuelve el problema planteado. Hace la vida de los usuarios mas fácil ó mejor. Confiable: Tiene pocos errores. Flexible: Se adapta a los cambios que van apareciendo en las necesidades de los usuarios, permitiendo su mantenimiento. Accesible: Tanto para compra como para mantenimiento. Disponible: Tiene que ejecutarse sobre el hardware y Sistema Operativo disponibles. Debe entregarse a tiempo. Dr. Juan José Aranda Aboy

¿Se tienen buenos sistemas?
Los avances del software han revolucionado nuestra vida: la manera en que nos comunicamos, aprendemos ó como nos entretenemos, la banca, los cuidados de salud, etc. Sin embargo, también encontramos fallos, algunos drásticos, como por ejemplo: Explosión de Ariane 5 debido a una serie de fallos de software. Pacientes con sobre dosis de radiaciones producto de un software complejo, mal documentado y poco revisado. (Therac-25) etc... Documentación sobre fallos: Forum On Risks To The Public In Computers And Related Systems Dr. Juan José Aranda Aboy

Realidades y Promesas Realidades: Como promedio, los grandes proyectos duran un 50% mas de lo planificado. Las tres cuartas partes de los fallos de un gran proyecto son operativos. La cuarta parte de los grandes proyectos se cancela. Promesas: Las nuevas tecnologías prometen reducir los tiempos de desarrollo y aumentar la tasa de éxito de los proyectos... Dr. Juan José Aranda Aboy

¿Cómo son los buenos sistemas?
Hay un límite de cuanto puede entender un ser humano de una sola vez. Debe poderse emprender una tarea de desarrollo ó de mantenimiento sin entender todo el sistema. Es importante controlar la complejidad del sistema: Pensar en el sistema como un conjunto de módulos. Identificar dependencias entre módulos. Dr. Juan José Aranda Aboy

Modularidad Un módulo, en sentido amplio, puede ser cualquier elemento identificable del sistema que tiene sentido por si mismo: Archivos Subrutinas Funciones de biblioteca Clases, en un lenguaje orientado a objetos Programas ó subsistemas con relativa independencia Otras estructuras Identificado un buen módulo, se puede contemplar su reutilización como un componente. Dr. Juan José Aranda Aboy

Conceptos asociados Dependencia y acoplamiento Cohesión Interfaz Encapsulamiento Abstracción Dr. Juan José Aranda Aboy

Dependencia y acoplamiento
El módulo A depende del módulo B si cualquier cambio en el módulo B implica que también haya que modificar al módulo A. Se dice que A es un cliente de B, ó que B actúa como servidor de A. Es común que un mismo módulo sea tanto cliente como servidor, o sea, que dependa de otros módulos y que existan módulos que dependan de él. Incluso es posible una dependencia circular, lo que debe evitarse, ya que impide la reutilización. La dependencia se conoce a veces como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen débil acoplamiento, porque los cambios en una parte del sistema tienen menor probabilidad de propagación a través del mismo. Dr. Juan José Aranda Aboy

Encapsulamiento Para aprovechar el débil acoplamiento de un sistema es muy importante poder identificar qué módulos están acoplados. También se deben comprobar los cambios en un módulo, lo que pudiera ser caro. Idealmente, debe conocerse con certeza cuáles módulos de un sistema podrían verse afectados por un cambio en un módulo dado. Una vez establecidos los límites entre módulos: ¿Qué suposiciones pueden hacer los clientes de un determinado módulo? ¿Qué servicios se supone que va a proporcionar? ¿Qué módulos son clientes de un módulo dado? Dr. Juan José Aranda Aboy

Interfaces La Interfaz de un módulo define algunas de sus características, de las que sus clientes pueden depender. El resto del sistema puede utilizar al módulo solamente de las maneras permitidas pos sus interfaces. Por tanto: la interfaz encapsula conocimiento sobre el módulo. Si un módulo cambia internamente sin modificar su interfaz, dicho cambio no conllevará que haya que realizar ningún otro cambio en ninguna otra parte del sistema. Dr. Juan José Aranda Aboy

Sintaxis y semántica En muchos lenguajes de programación el módulos cliente analiza la dependencia sintáctica: qué tipos de datos tiene declarada la interfaz del módulo servidor. Lo ideal es poder comprobar igualmente la dependencia semántica: si la interfaz documenta fielmente las suposiciones que pueden conjeturarse sobre el módulo, realizaría una especificación del módulo, que explica qué pueden asumir los clientes sobre su comportamiento, no solamente la sintaxis acerca de cómo interactuar con él. Dr. Juan José Aranda Aboy

Dependencias de contexto
Es útil saber todas las dependencias que existen, además de las dependencias que están documentadas en los módulos del sistema. Este conocimiento clarifica: Cuáles servicios proporciona cada módulo. Cuáles servicios necesitará un módulo para funcionar. Los servicios necesitados por un módulo se denominan dependencias de su contexto, y pueden expresarse en función de interfaces. Las dependencias de contexto de un módulo y la interfaz propia del módulo constituyen un contrato que describe las responsabilidades de dicho módulo: Si el contexto proporciona lo que el módulo necesita, entonces él garantiza proporcionar los servicios descritos en su interfaz. Dr. Juan José Aranda Aboy

Beneficios La modularidad con interfaces definidas facilita la comprensión del sistema, así como su posible modificación, ya que reduce lo que se necesita saber del mismo: En un desarrollo en equipo, los desarrolladores de código que utilizan un módulo sólo deben comprender su interfaz, no cómo funciona, de manera que sean mas productivos. Se introducen menos errores, ya que los desarrolladores tienden a conocer lo que realmente necesitan saber y pueden ignorar de forma segura otros aspectos del sistema. Los errores son mas fáciles de encontrar tanto en desarrollo como en mantenimiento, debido a que no se examinan módulos irrelevantes. Una vez que exista un módulo con documentación de lo que proporciona y de lo que requiere, es posible pensar en su reutilización. Dr. Juan José Aranda Aboy

Módulos e interfaces Un módulo puede tener varias interfaces, lo que facilita identificar de la manera mas sencilla posible cuales serían los cambios requeridos si ocurriesen cambios en otros módulos. El empleo de varias interfaces para documentar un módulo permite precisar cuales servicios necesita un determinado cliente. Esta idea es útil tanto para mantenimiento como para reutilización. Conclusión parcial: Un buen sistema está formado por módulos encapsulados. Dr. Juan José Aranda Aboy

Abstracción: fuerte cohesión
Los módulos correctos tienen la propiedad de que sus interfaces proporcionan una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de implementar. Se dice que este tipo de módulos tiene una fuerte cohesión. La interfaz se abstrae de las cosas que el desarrollador no tiene que conocer para utilizar el módulo. El módulo realiza un conjunto coherente de acciones, pero -dentro de lo posible- el desarrollador del cliente está protegido de la información irrelevante relativa a cómo el módulo cumple sus funciones. Dr. Juan José Aranda Aboy

Información oculta La información oculta no tiene interés para los programadores del cliente. Precisando: Abstracción: Cuando un cliente de un módulo no necesita saber mas de lo que muestra su interfaz. Encapsulamiento: Cuando un cliente de un módulo no es capaz de saber mas de lo que hay en la interfaz. La situación en que la interfaz proporciona medios de interacción con algunos datos sin revelar su formato interno es normal tanto en el desarrollo orientado a objetos como en el estilo de tipo de datos abstractos. Dr. Juan José Aranda Aboy

Tipos de datos abstractos
Un tipo de dato abstracto (TDA) o Tipo abstracto de datos (TAD) es un modelo matemático compuesto por una colección de operaciones definidas sobre un conjunto de datos para el modelo. La abstracción de datos consiste en ocultar las características de un objeto y obviarlas, de manera que solamente utilizamos el nombre del objeto en nuestro programa. A esto se le llama ‘Abstracción’ y es un concepto muy útil en la programación, ya que un usuario no necesita mencionar todas las características y funciones de un objeto cada vez que éste se utiliza, sino que son declaradas por separado en el programa y simplemente se utiliza el término abstracto para mencionarlo. Se llama Abstracción de Datos a todo el proceso de definir, implementar y mencionar tipo abstracto de datos. Dr. Juan José Aranda Aboy

Caracterización de los TDA
Un TDA representa una abstracción: Se destacan los detalles (normalmente pocos) de la especificación (el qué). Se ocultan los detalles (casi siempre numerosos) de la implementación (el cómo). Está caracterizado por un conjunto de operaciones (funciones) denominado usualmente como su interfaz pública que representan el comportamiento del TDA; y una implementación, la parte privada del TDA, que está oculta al programa cliente que lo usa. Todos los lenguajes de alto nivel tienen predefinidos TDA; que son los tipos denominados simples y las estructuras predefinidas, y estos tienen sus interfaces públicas que incluyen las operaciones como la +, -, *, etc. Dr. Juan José Aranda Aboy

Ejemplos de TDA Algunos ejemplos de utilización de TDAs en programación son: Conjuntos: Implementación de conjuntos con sus operaciones básicas (unión, intersección y diferencia), operaciones de inserción, borrado, búsqueda... Árboles: Implementación de árboles de elementos, utilizados para la representación interna de datos complejos. Pilas y Colas: Implementación de los algoritmos FIFO y LIFO. Vectores y Matrices: Implementación de algoritmos y métodos numéricos. Dr. Juan José Aranda Aboy

Reutilización Si un módulo de cualquier tamaño y complejidad es una buena abstracción: tiene fuerte cohesión y débil acoplamiento; puede ser factible reutilizarle en sistemas posteriores, ó sustituirle en el sistema existente. Se le considera un componente conectable, aunque también dependerá de la arquitectura en la que se desarrolla el componente y sobre cuál arquitectura será utilizado. Puede pensarse en el desarrollo basado en componentes (Component Based Development - CBD) centrado en la arquitectura: Dr. Juan José Aranda Aboy

Arquitectura y componentes
Un componente es una unidad de reutilización y sustitución. Entre sus características están: Fuerte cohesión. Débil acoplamiento con el resto del sistema. Interfaz bien definida. Abstracción encapsulada de un elemento bien comprendido. Contexto de desarrollo. Contexto de utilización. La arquitectura del sistema incluye decisiones de alto nivel acerca de la estructura general del sistema que se aplican a mas de un sistema y que se toman para beneficiarse con la reutilización de componentes. Puede incluir otras decisiones respecto a cómo construir el sistema. Dr. Juan José Aranda Aboy

Desarrollo basado en componentes
La manera ideal de construir un nuevo sistema es tomar algunos componentes ya existentes y conectarlos unos con otros. Los componentes tienen que ser elementos que completen las necesidades del sistema en su totalidad, y deben ser compatibles entre si. Esto depende de la presencia de la arquitectura adecuada. Las decisiones de arquitectura: Se tienen que tomar pronto en el proyecto. Se ven afectadas por la naturaleza de los componentes en la arquitectura. Pueden estar influenciadas por el entorno del proyecto. Dr. Juan José Aranda Aboy

Procesos ó metodologías de desarrollo
Proceso de desarrollo: Conjunto de reglas que definen cómo debería llevarse a cabo el desarrollo de un proyecto. Puede incluir documentos, modelos de diseño, etc.; así como el orden en que deben producirse. Método [logía] especifica qué herramientas - lenguaje de modelado - deben utilizarse para la descripción del trabajo de análisis y de diseño. Dr. Juan José Aranda Aboy

Modelos Un modelo es una representación abstracta de una especificación, un diseño ó un sistema desde un punto de vista particular. A menudo se representa mediante un diagrama. Su objetivo es expresar la esencia de algunos aspectos de lo que se está haciendo sin especificar detalles innecesarios. Su propósito es permitir que las personas involucradas en el desarrollo del sistema puedan reflexionar y debatir sobre los problemas y las soluciones sin desviarse de los objetivos. Un modelado tiene que poseer significado preciso y bien entendido. ¡Abstracto NO significa Confuso! Dr. Juan José Aranda Aboy

Lenguaje de modelado Manera de expresar los distintos modelos que se producen durante el proceso de desarrollo. Normalmente se centra en los diagramas, aunque puede utilizar texto. Tiene Sintaxis: Reglas que definen cuáles diagramas son legales. Semántica: Normas que determinan que significa un diagrama concreto. Dr. Juan José Aranda Aboy

¿Por qué un lenguaje unificado de modelado?
Dada la necesidad de debatir problemas y soluciones implicados en la construcción del sistema. El lenguaje debe ser: Suficientemente expresivo, para que incorpore los aspectos de diseño que será necesario tratar reflejados de manera que tengan sentido. Durante el diseño, los cambios se realizarán en el modelo. Suficientemente fácil de utilizar, para que ayude a tener un conocimiento claro. Inequívoco, para que ayude a resolver malos entendidos. Soportado por herramientas adecuadas, de manera que el esfuerzo de los desarrolladores esté enfocado a los aspectos que requieren su habilidad y no en trabajos rutinarios como crear un diagrama con una herramienta de dibujo. Generalmente utilizado. Dr. Juan José Aranda Aboy

Ventajas de la generalidad
Cuando un lenguaje de modelado es generalmente utilizado: La incorporación de nuevas personas al proyecto se simplifica si ya conocen el lenguaje de modelado utilizado. Para hacer diseño basado en componentes hay que leer las descripciones de las mismas, y cuanto mas rápido y fácil se pueda hacer es mas barato tener en cuenta un componente. Cuanto mas general sea la utilización de un lenguaje de modelado, mayor es la probabilidad de que sea el mismo utilizado por el escritor de las componentes involucradas. Dr. Juan José Aranda Aboy

Proceso y calidad Tanto el proceso de desarrollo como el sistema de gestión de calidad tienen como objetivo asegurar que el proceso - y el producto resultante- tenga alta calidad. En general, el proceso de desarrollo especificará aspectos mas técnicos que el sistema de gestión de calidad. Dr. Juan José Aranda Aboy

El proceso de desarrollo
Proceso en cascada (waterfall): Tiene cinco partes identificables, conocidas como fases del ciclo de vida: Análisis Diseño Implementación Pruebas Mantenimiento Tomado de Stevens, p57 Dr. Juan José Aranda Aboy

Modelo de ciclo de vida (Buchanan)
Tomado de Alonso, p53 Dr. Juan José Aranda Aboy

Gestión de riesgos Tema amplio y extremadamente importante. Consideremos dos aspectos: Cada vez que se toma una decisión se corre el riesgo de que sea incorrecta. Mala comprensión de los requisitos por parte de los desarrolladores. Se puede tratar de controlar el riesgo descubriendo errores lo antes posible. Cualquier cosa que aumente la confianza en que los requisitos establecidos están correctos, reduce el riesgo. Dr. Juan José Aranda Aboy

Proceso en espiral Incorpora las dos ideas anteriores. (Boehm) Esencialmente está formado por cuatro etapas: Analizar riesgos y planificar. Analizar requisitos para esta iteración. Ingeniería, diseño, implementación y pruebas. Evaluación. Dr. Juan José Aranda Aboy

Un proceso en espiral sencillo
Tomado de Stevens, p58 Dr. Juan José Aranda Aboy

Métodos de desarrollo Algunos métodos de desarrollo orientado a objetos populares son: OOD de Booch – Rational Software OMT de Rumbaugh OOSE y Objectory de Jacobson Dr. Juan José Aranda Aboy

Procesos a utilizar con UML
Tomar la gestión de riesgos como un concepto central. Permitir que las iteraciones sean un medio para controlar el riesgo. Centrado en la arquitectura y basado en componentes: podría tener como actividades prioritarias el seguimiento y la toma de decisiones de arquitectura correctas y el uso y desarrollo de buenos componentes. Dr. Juan José Aranda Aboy

Proceso unificado (UP)
Sitúa su espiral principal en su fase de construcción: Inicio: Visión aproximada, análisis del negocio, alcance, estimaciones imprecisas. Finaliza con el compromiso del patrocinador del proyecto de seguir adelante, conocidos el caso de negocios del proyecto, su viabilidad y alcance básicos. Elaboración: Visión refinada, implementación iterativa del núcleo central de la arquitectura. Resolución de los riesgos altos. Identificación de otros requisitos y alcance. Estimaciones mas realistas. Finaliza con La arquitectura básica del sistema en cuestión. Un plan convenido para la construcción Todos los riesgos significativos identificados. Los principales riesgos comprendidos lo suficiente Construcción: Implementación iterativa de los restantes requisitos de menor riesgo y elementos mas fáciles. Preparación para el despliegue. Finaliza con una versión beta del sistema. Transición: Pruebas beta. Proceso de presentación del sistema a sus usuarios. Despliegue. Dr. Juan José Aranda Aboy

Disciplinas del UP Tomado de Larman, p21 Dr. Juan José Aranda Aboy

Disciplinas y fases del UP
Las disciplinas (flujos de trabajo) del UP son el conjunto de actividades y artefactos (productos del trabajo: códigos, gráficos Web, esquema de base de datos, documentos de texto, diagramas, modelos, etc.) relacionados en un área determinada. Modelado del negocio: Consiste en modelar los objetos del dominio. A gran escala, referencia el modelado de los procesos de negocio de toda la empresa. Requisitos: Análisis de los requerimientos para una aplicación: escritura de casos de uso e identificación de requisitos no funcionales. Diseño: Todos los aspectos, incluyendo arquitectura global, objetos, bases de datos, comunicación en red, etc. Tomado de Larman, p21 Dr. Juan José Aranda Aboy

Sistema, diseño, modelo, diagrama
Cualquier proceso de desarrollo pretende producir un sistema. El diseño, y especialmente la arquitectura del sistema, incorporan las decisiones importantes sobre cómo construirlo, abstrayéndose de muchos detalles. Se construirán diferentes modelos del diseño utilizando diagramas en un lenguaje de modelado: Modelo de casos de uso: describe el sistema requerido desde el punto de vista del usuario. Modelo estático: describe los elementos del sistema y sus relaciones. Modelo dinámico: describe el comportamiento del sistema a lo largo del tiempo. Dr. Juan José Aranda Aboy

Vistas Lógica: ¿qué partes teóricamente están juntas? ¿cuáles son las clases? ¿cómo están relacionadas? Se modela para comprobar los requisitos funcionales. De proceso: ¿qué hilos de control existen? ¿qué cosas pueden darse concurrentemente? ¿Cuándo sincronizar? Ayuda a asegura que se cumplan los requisitos no funcionales tales como la disponibilidad y las prestaciones. De desarrollo: ¿qué partes puede desarrollar el mismo equipo de personas? ¿qué puede reutilizarse? Ayuda a gestionar el proyecto. Física: ¿qué partes se ejecutarán sobre el mismo computador? Ayuda a asegurar que se cumplan los requisitos no funcionales. Es una vista mas concreta que la vista de proceso. Dr. Juan José Aranda Aboy

¿Cómo se construye un buen sistema?
Realizando una aproximación técnica primaria, para construir un buen sistema: Se utiliza un proceso definido, con fases claras, cada una de las cuales tiene un producto final: documentos, algún código funcionando ... Se relaciona con encontrar tan pronto como sea posible un claro conjunto de requisitos cuidadosamente definidos. Se consideran los formularios de verificación y validación tales como pruebas elementos esenciales para la construcción del producto en si. Se utiliza un almacenamiento de conocimientos, arquitecturas y componentes relevantes. Se hace un uso coherente de las herramientas. Dr. Juan José Aranda Aboy

Preguntas ¿Cuáles son las mejores y las peores experiencias que ha tenido recientemente producto de sistemas basados en software? ¿Cómo se identifica el acoplamiento? ¿Cómo se mide? ¿Qué puede documentarse en las interfaces a los módulos? ¿Cuántas comprobaciones son automáticas? ¿Cuál es el resultado de seleccionar mal los módulos? Ejemplifique interfaces que conozca. Comente las ventajas y mencione las desventajas de tener un lenguaje unificado de modelado. ¿Bajo que circunstancias vale la pena utilizar un proceso de desarrollo en cascada? Dr. Juan José Aranda Aboy

Preguntas (2) Para gestionar el riesgo de una mala decisión, se acostumbra a posponerla cuanto se pueda. ¿Es una buena idea? ¿Depende del tipo de decisión? ¿Por qué? Busque información sobre los siguientes procesos y métodos de desarrollo: El Proceso Unificado de Rational (RUP) Catalysis Proceso Orientado a Objeto, Entorno y Notación: OPEN Programación Extrema (XP) de Beck Bazaar (método empleado para desarrollar Linux) SCRUM Modelo de Desarrollo de Sistemas Dinámico (DSDM) Dr. Juan José Aranda Aboy

Referencias Stevens, P. “Utilización de UML en Ingeniería del Software con Objetos y Componentes”, Addison Wesley, 2002 (en inglés: “Using UML: software engineering with objects and components”) Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004 Alonso,A. et al “Ingeniería del Conocimiento: Aspectos Metodológicos”, Pearson, 2004 Wikipedia: Diseño de Software Desarrollo en cascada Metodología OMT Lenguaje Unificado de Modelado Proceso Unificado de Desarrollo Software Tipo de dato abstracto Dr. Juan José Aranda Aboy

Tópicos de interés en Internet
Catalysis (Rational) Unified Process; Proceso Unificado de Rational Fusion Extreme Programming; Programación Extrema The Cathedral and the Bazaar SCRUM DSDM OPEN Enlaces de Cetus sobre métodos de A/D OO Descripción resumida de los ciclos de vida en el desarrollo de software, incluyendo el modelo de Forsberg Vee; así como información adicional sobre el modelo V. Dr. Juan José Aranda Aboy

Aspectos Avanzados de la Tecnología de Objetos

Presentaciones similares

Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Aspectos Avanzados de la Tecnología de Objetos

Presentaciones similares

Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback