Aspectos Avanzados de la Tecnología de Objetos

1. Aspectos Avanzados de laTecnología de Objetos 2. Fundamentos del modelo de objetos (1ra parte) Dr. Juan José Aranda Aboy

2. Objetivos específicos • Definir los conceptos de objeto, clase y componente. • Caracterizar el proceso de desarrollo. • Conocer y emplear adecuadamente el lenguaje unificado de modelado (UML). Dr. Juan José Aranda Aboy

3. Contenidos • Ingeniería del software con componentes. • Conceptos de objetos. • El proceso de desarrollo. • El lenguaje unificado de modelado (Unified Modeling Language – UML): • Fundamentos de los modelos de casos de uso. • Fundamentos de los modelos de clases. • Fundamentos de los diagramas de interacción y colaboración. • Fundamentos de los diagramas de estado y de actividad. • Diagramas de implementación. • Paquetes, subsistemas, modelos. Dr. Juan José Aranda Aboy

4. Introducción • Según la definición del IEEE: • “Software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo“. • "un Producto de Software es un producto diseñado para un usuario". Dr. Juan José Aranda Aboy

5. Concepto de Ingeniería de Software • En este contexto, la Ingeniería de Software (Software Engineering - SE) es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software“. • En palabras simples, se considera que "la Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas, eficaces en costo ó económicas, a los problemas de desarrollo de software“. • Es decir: "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos“, o sea, buenos sistemas. Dr. Juan José Aranda Aboy

6. Características del SW • Es un elemento lógico del sistema, no físico. Posee características muy distintas a las del hardware: • El software se desarrolla, no se fabrica en un sentido clásico. • Para HW ó SW, la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del HW puede introducir problemas de calidad que no existen ó que son fácilmente corregibles en el SW. • Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente. • Ambas actividades requieren de la construcción de un producto, pero los métodos son diferentes. • Los costes del software se encuentran en la ingeniería. Esto significa que los proyectos no pueden gestionarse como si fueran proyectos de fabricación. Dr. Juan José Aranda Aboy

7. Características del SW (2) • El software NO se estropea. • No es susceptible a los males del entorno que hacen que el hardware se estropee: • Cuando un componente HW se estropea, se sustituye por un repuesto. • No hay pieza de repuesto para el software. • Cada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradujo el diseño a código de maquina ejecutable. • El mantenimiento del SW tiene una complejidad mucho mayor que la del mantenimiento del HW. • La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. • Hasta hace muy poco, no existían catálogos de componentes de SW. • Se puede comprar software ya desarrollado, pero posiblemente sólo como una unidad completa, no como componentes que pueden reensamblarse en nuevos programas. Dr. Juan José Aranda Aboy

8. Perspectiva industrial • En los primeros días de la informática, los sistemas basados en computadora se desarrollaban usando técnicas de gestión orientadas al hardware. • Los gestores del proyecto se centraban en el hardware, debido a que era el factor principal del presupuesto en el desarrollo del sistema. • Para controlar los costes del hardware, los gestores instituyeron controles formales y estándares técnicos. Exigían un análisis y diseño completo antes de que algo se construyera. Median el proceso para determinar donde podían hacerse mejoras. Aplicaban los controles, los métodos y las herramientas conocidas como Ingeniería del Hardware. • Desgraciadamente, el software era normalmente un añadido. La programación se veía como un arte. Existían pocos métodos formales y pocas personas los usaban. Dr. Juan José Aranda Aboy

9. Perspectiva industrial actual • Hoy, la distribución de costes en el desarrollo de sistemas informáticos ha cambiado drásticamente: El software, en lugar del hardware, es el elemento principal. • En las décadas pasadas, los ejecutivos y muchos aprendices técnicos se habían hecho las siguientes preguntas: • ¿Por qué lleva tanto tiempo terminar los programas? • ¿Por qué es tan elevado el coste? • ¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes? • ¿Por qué nos resulta difícil constatar el progreso conforme se desarrolla el software? • Estas y otras muchas cuestiones son una manifestación del carácter del software y de la forma en que se desarrolla, un problema que ha llevado a la adopción de la Ingeniería del Software como practica. Dr. Juan José Aranda Aboy

10. Competitividad del SW • Durante muchos años, los desarrolladores de software empleados por grandes y pequeñas compañías eran los únicos en este campo. • Como todos los programas se construían de manera personalizada, los desarrolladores de este software doméstico dictaban los costes, planificación y calidad. • Hoy, todo esto ha cambiado. • El software ahora es una empresa extremadamente competitiva. • El software que se construía internamente ahora se puede adquirir en tiendas. • Muchas empresas que en su momento pagaban legiones de programadores para crear aplicaciones especializadas, ahora ofrecen a un tercero mucho del trabajo del software. Dr. Juan José Aranda Aboy

11. Procesos asociados • Proceso de ingeniería de software: Se define como un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad [Jacobson]. • Proceso de desarrollo de software: Aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson]. Dr. Juan José Aranda Aboy

12. Ciclo de vida • El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. • A este proceso también se le llama el ciclo de vida del software que, como hemos visto, comprende cuatro grandes fases: • Concepción: Define el alcance del proyecto y desarrolla un caso de negocio. • Elaboración: Define un plan del proyecto. Especifica las características. Fundamenta la arquitectura. • Construcción: Crea el producto. • Transición: transfiere el producto a los usuarios. Dr. Juan José Aranda Aboy

13. Evolución de la Ingeniería de SW • Recordemos que inicialmente la programación de las computadoras era un arte que disponía de escasos métodos sistemáticos en los que basarse para realizar productos de software. Se desarrollaba con poca planificación. • La época 60 - 70, se caracterizó por el establecimiento del software como un producto que se desarrollaba para una distribución general. En esta época nació lo que se conoce como el mantenimiento del software que se necesita cuando cambian los requisitos de los usuarios y se hace imprescindible la modificación del software. El esfuerzo requerido para este mantenimiento era en la mayoría de los casos tan elevado que se hacía imposible el mantenimiento. • A continuación, surge una etapa que se caracteriza por la aparición de una serie de técnicas como la Programación Estructurada y las Metodologías de Diseño, que solucionan los problemas anteriores. A finales de esta etapa aparecen las herramientas CASE rudimentarias. Dr. Juan José Aranda Aboy

14. Programación tradicional (estructurada) • Considera que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. • La programación estructurada clásica anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. • En la programación estructurada se escriben funciones y después se les pasan los datos. • Los programadores que emplean lenguajes orientados a objetos con los esquemas mentales clásicos, definen objetos con datos y métodos, y después envían mensajes a los objetos diciendo que realicen dichos métodos en sí mismos. Dr. Juan José Aranda Aboy

15. Ingeniería del SW basada en Componentes • Algunos tópicos importantes para comprender el contexto actual de la ingeniería de software son: • Metodologías • Arquitecturas y Lenguajes de Análisis y Diseño (ADLs) • Frameworks • Agentes • Plataformas • Antes de analizar los pasos del proceso de desarrollo de software, se revisarán los conceptos fundamentales que guían la tecnología OO: • el paradigma, • los principios, • el análisis y • el diseño. Dr. Juan José Aranda Aboy

16. Programación orientada a objetos - OOP • Es un paradigma de programación que define los programas en términos de “clases de objetos”. • Los objetos que son entidades que combinan: • estado: es decir, datos; y • comportamiento: esto es, procedimientos o métodos; así como • identidad: propiedad del objeto que lo diferencia del resto. • La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. • Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. Dr. Juan José Aranda Aboy

17. Beneficios del enfoque OO Según [Booch], los beneficios del enfoque OO son: • Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, Ada y Java. • Segundo, el uso del modelo OO alienta la reutilización no solamente del software, sino de diseños completos. • Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y en tecnología. • El mismo autor considera que el principal beneficio del OOD es que proporciona un mecanismo para formalizar el modelo de la realidad. Dr. Juan José Aranda Aboy

18. Características de los objetos • Un objeto contiene toda la información, atributos, que permiten definirlo e identificarlo frente a otros objetos pertenecientes a otras clases, e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. • A su vez, todo objeto dispone de mecanismos de interacción, llamados métodos, que favorecen la comunicación entre objetos de una misma clase o de distintas clases, y en consecuencia, el cambio de estado en los propios objetos. • Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan, ni deben separarse, información (datos) y procesamiento (métodos). Dr. Juan José Aranda Aboy

19. Consideración • Dada esta propiedad de conjunto de una clase de objetos, (que al contar con una serie de atributos definitorios, requiere de métodos para poder tratarlos, lo que hace que ambos conceptos están íntimamente entrelazados), el programador debe pensar indistintamente en ambos términos, ya que no debe nunca separar ó dar mayor importancia a los atributos en favor de los métodos, ni viceversa. • Hacerlo puede llevar al programador a seguir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen esa información por el otro, llegando a una programación estructurada “camuflada” en un lenguaje de programación orientado a objetos. • Algunas personas también distinguen la POO sin clases, la cual es llamada a veces programación basada en objetos. Dr. Juan José Aranda Aboy

20. Historia de la POO • Los conceptos de la programación orientada a objetos tienen su origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. • Ellos trabajaban en simulaciones de naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de diversas naves podían afectar unas a las otras. • La idea fue agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamiento. • Estos conceptos fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula por Xerox PARC. La primera versión fue escrita sobre Basic. • SmallTalk fue diseñado para ser un sistema completamente dinámico, en el cual los objetos se podrían crear y modificar "en marcha" en lugar de tener un sistema basado en programas estáticos. Dr. Juan José Aranda Aboy

21. Consolidación • La programación orientada a objetos tomó posición como el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++ , una extensión del lenguaje de programación C. • Su consolidación fue alcanzada gracias al auge de las Interfaces gráficas de usuario, para los cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos. • Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. • La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y a la capacidad de mantenimiento del código. Dr. Juan José Aranda Aboy

22. Lenguajes “puros” de objetos • Los lenguajes orientados a objetos "puros", por otra parte, carecían de las características de las cuales dependen muchos programadores. • Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de manera "segura". • Eiffel, de Bertrand Meyer, fue un temprano y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet y a la implementación de la máquina virtual de Java en la mayoría de navegadores. Dr. Juan José Aranda Aboy

23. Métodos modernos • Aunque la programación estructurada -también llamada procedural o procedimental-, condujo a mejoras con respecto a la técnica de programación secuencial (Floyd, Hoare), los métodos modernos de diseño de software orientado a objetos incluyen mejoras entre las que están: • el uso de los patrones de diseño, • el diseño por contrato, y • los lenguajes de modelado (Ejemplo: UML). Dr. Juan José Aranda Aboy

24. Diferencias con la programación estructurada • Las principales diferencias entre la programación estructurada y la orientada a objetos radican en que: • La programación orientada a objetos es resultado de una evolución de la programación estructurada que se plasma en el diseño de una familia de lenguajes y en conceptos que existían previamente, integrados con algunos nuevos conceptos. • La programación orientada a objetos se basa en lenguajes que soportan sintáctica y semánticamente la unión entre los tipos abstractos de datos y sus operaciones. A esta unión se la suele llamar clase. • La programación orientada a objetos incorpora en su entorno de ejecución mecanismos tales como el polimorfismo y el envío de mensajes entre objetos. Dr. Juan José Aranda Aboy

25. Problemas de la programación clásica • Erróneamente se le adjudican ciertos problemas a la programación estructurada clásica como si fueran inherentes a la misma. • Esos problemas fueron haciéndose cada vez más graves. • Antes de la programación orientada a objetos, diversos autores encontraron soluciones basadas en aplicar estrictas metodologías de trabajo. • De esa época son los conceptos de cohesión y acoplamiento que ya conocemos. Dr. Juan José Aranda Aboy

26. Problemas que destacan • Modelo mental anómalo: Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras que la programación clásica se basa en el comportamiento, representado usualmente por verbos. • Es difícil modificar y extender los programas: Suele haber datos compartidos por varios subprogramas, los que introducen interacciones ocultas entre ellos. • Es difícil mantener los programas: Casi todos los sistemas informáticos grandes tienen errores ocultos, que no surgen a la luz hasta después de muchas horas de funcionamiento. • Es difícil reutilizar los programas: Es prácticamente imposible aprovechar en una aplicación nueva las subrutinas que se diseñaron para otra. • Es compleja la coordinación y organización entre programadores para la creación de aplicaciones de media y gran envergadura. Dr. Juan José Aranda Aboy

27. Nota importante • En la programación orientada a objetos pura no deben utilizarse llamadas a subrutinas, únicamente mensajes. • Por esta razón, la POO recibe el nombre de programación sin CALL, al igual que la programación estructurada es conocida como programación sin GOTO. (Dijkstra: “The Humble Programmer”, “Go To Statement Considered Harmful”) • Sin embargo, no todos los lenguajes orientados a objetos prohíben la instrucción CALL, o su equivalente, por lo que permiten realizar una programación híbrida: imperativa y orientada a objetos a la vez. Dr. Juan José Aranda Aboy

28. La POO como solución • La programación orientada a objetos es una nueva forma de programar que trata de encontrar solución a estos problemas. • Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Particularmente destacan: • Objeto: Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad ("métodos"). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). • Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas. • Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema. Dr. Juan José Aranda Aboy

29. Conceptos asociados • Evento: • Un suceso en el sistema. Por ejemplo: interacción del usuario con la máquina, mensaje enviado por un objeto. • El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. • También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera. • Mensaje: • Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. • Propiedad ó atributo: • Contenedor de un tipo de datos asociados a un objeto o con una clase de objetos, que hace los datos visibles desde fuera del objeto, y cuyo valor puede ser alterado por la ejecución de algún método. Dr. Juan José Aranda Aboy

30. Conceptos asociados (2) • Estado interno: • Es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto o clase de objetos. • Componentes de un objeto: • atributos, • identidad, • relaciones y • métodos. • Representación de un objeto: • Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes. • En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto. Dr. Juan José Aranda Aboy

31. Características de la POO Hay desacuerdo sobre qué características de una metodología de programación ó lenguaje la definen como “orientado a objetos”. Sin embargo, hay consenso general en que las más importantes son: • Abstracción • Encapsulamiento • Principio de ocultación • Polimorfismo • Herencia Dr. Juan José Aranda Aboy

32. Abstracción • Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. • Los procesos, las funciones ó los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. Dr. Juan José Aranda Aboy

33. Encapsulamiento • Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. • Esto permite aumentar la cohesión de los componentes del sistemas. • Algunos autores confunden este concepto con el principio de ocultación, principalmente porque suelen emplearse conjuntamente. Dr. Juan José Aranda Aboy

34. Principio de ocultación • Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. • El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. • Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. • La aplicación entera se reduce a un agregado ó rompecabezas de objetos. • Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. Dr. Juan José Aranda Aboy

35. Polimorfismo • Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre. Al llamarlos por ese nombre, se utilizará el comportamiento correspondiente al objeto que se esté usando. Dicho de otro modo: • las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y • la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. • Cuando esto ocurre en “tiempo de ejecución”, esta última característica se llama asignación tardía o asignación dinámica. • Algunos lenguajes proporcionan medios de polimorfismo más estáticos, en “tiempo de compilación” tales como las plantillas (templates) y la sobrecarga de operadores de C++. Dr. Juan José Aranda Aboy

36. Herencia: Jerarquía de clases • Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. • Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. • La herencia organiza y facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. • Estos pueden compartir y extender su comportamiento sin tener que reimplementar su comportamiento. • Esto suele hacerse habitualmente agrupando los objetos en clases, y éstas en árboles o enrejados que reflejan un comportamiento común. • Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple; característica no soportada por algunos lenguajes. (Ejemplo: Java). Dr. Juan José Aranda Aboy

37. Otras características deseadas Algunos autores señalan que deben tomarse en cuenta también las siguientes características: • Tipificación: Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados ó, cuando mucho, puedan intercambiarse de manera muy restringida. • Concurrencia: Es la propiedad que distingue un objeto que está activo de uno que no lo está. • Persistencia: Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo, es decir: el objeto continua existiendo después de que su creador ha dejado de existir y/o el espacio, es decir, la localización del objeto, se mueve del espacio de dirección en que fue creado. Dr. Juan José Aranda Aboy

38. Ada C++ C# VB.NET Visual FoxPro Delphi Eiffel Java Objective-C Perl (soporta herencia múltiple) PHP (desde versión 5) Python Ruby Smalltalk Lenguajes orientados a objetos Dr. Juan José Aranda Aboy

39. Otros lenguajes • Varios lenguajes de programación no son puramente orientados a objetos, sino híbridos que combinan la OOP con otros paradigmas. • Al igual que C++, otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados añadiendo extensiones orientadas a objetos a un lenguaje de programación clásico. Dr. Juan José Aranda Aboy

40. Relaciones entre objetos • Definen el comportamiento del sistema. • Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. • El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. • Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. • Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada. Dr. Juan José Aranda Aboy

41. Análisis y Diseño orientado a objetos • Greiff comenta que el Análisis Orientado a Objetos (Object Oriented Analysis - OOA) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de dominio del problema". • Según Booch, el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos: lógico y físico, tal como los modelos estáticos y dinámicos del sistema bajo diseño". Dr. Juan José Aranda Aboy

42. Metodologías OO • En cuanto a metodologías OO: Actualmente hay un gran número de métodos orientado a objetos. Muchos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. • Algunas de las metodologías más conocidas y estudiadas hasta antes de la consolidación del UML, según Jacobson, eran: • Object-Oriented Design (OOD), Booch. • Object Modeling Technique (OMT), Rumbaugh. • Object Oriented Analysis (OOA), Coad /Yourdon. • Hierarchical Object Oriented Design (HOOD), ESA. • Object Oriented Structured Design (OOSD), Wasserman. • Object Oriented Systems Analysis (OOSA), Shaler y Mellor. • Responsibility Driven Design (RDD), Wirfs-Brock, entre otros. • Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en UML, bajo el respaldo del Object Management Group. Dr. Juan José Aranda Aboy

43. Problemas de los paradigmas • Muchas veces, a la hora de programar, se encuentran problemas que no pueden resolverse adecuadamente con las técnicas habituales usadas en la programación imperativa u orientada a objetos, por lo que fuerzan a tomar decisiones de diseño que repercuten de manera importante en el desarrollo de la aplicación y que nos alejan con frecuencia de otras posibilidades. • La implementación de dichas decisiones implica escribir líneas de código que están distribuidas por toda, o gran parte, de la aplicación para definir la lógica de cierta propiedad o comportamiento del sistema, con las consecuentes dificultades de mantenimiento y desarrollo que ello implica. Este problema se conoce como código disperso (scattered code). Dr. Juan José Aranda Aboy

44. Problemas de los paradigmas (2) • Otro problema que puede aparecer es que un mismo módulo se implemente de modo que maneje múltiples comportamientos o aspectos del sistema simultáneamente. Este problema se conoce como código enmarañado (tangled code). • El hecho cierto es que hay algunas decisiones de diseño que son difíciles de capturar con las técnicas antes citadas, debido a que ciertos problemas no se dejan encapsular de igual forma que los que habitualmente se han resuelto con funciones u objetos. • La resolución de estos problemas supone, o bien la utilización de repetidas líneas de código por diferentes componentes del sistema, o bien la superposición dentro de un componente de funcionalidades dispares. Dr. Juan José Aranda Aboy

45. Programación orientada a aspectos - POA • Representa un nuevo paso en la abstracción de paradigmas de programación. • Aunque todavía es una metodología en estado de maduración, cada vez atrae a más investigadores e incluso proyectos comerciales en todo el mundo. • Permite, de manera comprensible y clara, definir las aplicaciones considerando estos problemas de dispersión y enmarañamiento del código. • Por aspectos se entienden dichos problemas, que afectan a la aplicación de manera horizontal. • Este paradigma persigue el poder tenerlos de manera aislada de forma adecuada y comprensible, dando la posibilidad de construir el sistema al componerles junto con el resto de los componentes. Dr. Juan José Aranda Aboy

46. Intención de la POA • Su intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. • Gracias a la POA se pueden capturar los diferentes conceptos que componen una aplicación en entidades bien definidas, de manera apropiada en cada uno de los casos y eliminando las dependencias inherentes entre cada uno de los módulos, con lo que se consigue: • razonar mejor sobre los conceptos, • se elimina la dispersión del código y • las implementaciones resultan más comprensibles, adaptables y reutilizables. • Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas como • los métodos adaptivos, • los filtros de composición, • la programación orientada a sujetos o • la separación multidimensional de competencias Dr. Juan José Aranda Aboy

47. Objetivos y ventajas de la POA • Entre los objetivos que se ha propuesto están: • Separar conceptos: Se persigue que cada decisión se tome en un lugar concreto y no diseminada por la aplicación. • Minimizar las dependencias entre conceptos: Se pretende desacoplar los distintos elementos que intervienen en un programa. • Su consecución implicaría las siguientes ventajas: • Un código menos enmarañado, más natural y más reducido. • Mayor facilidad para razonar sobre los conceptos, ya que están separados y las dependencias entre ellos son mínimas. • Un código más fácil de depurar y más fácil de mantener. • Se consigue que un conjunto grande de modificaciones en la definición de una materia tenga un impacto mínimo en las otras. • Se tiene un código más reusable y que se puede acoplar y desacoplar cuando sea necesario. Dr. Juan José Aranda Aboy

48. Introducción al proceso de desarrollo • Los proyectos requieren una etapa inicial en la que se estudian: • ¿Cuál es la visión y el análisis del negocio? • ¿Es viable? (Factibilidad) • ¿Se compra ó se construye? • ¿Cuánto cuesta? • La idea es vislumbrar el alcance del producto deseado, así como obtener una visión y realizar un análisis del negocio. • El principal problema es determinar si el personal involucrado está de acuerdo con la visión del proyecto y si vale la pena invertir en un estudio serio del mismo. • El resultado fundamental de la etapa de inicio es establecer una visión común inicial de los objetivos del proyecto reflejada mediante un conjunto de artefactos (documentos, diagramas) comunes: Dr. Juan José Aranda Aboy

49. Artefactos en la fase de inicio • Visión y análisis del negocio: Describe los objetivos y las restricciones de alto nivel. El análisis del negocio proporciona un informe para la toma de decisiones. • Modelo de casos de uso: Describe los requisitos funcionales y los no funcionales relacionados. • Especificación complementaria: Describe otros requisitos. • Glosario: Terminología clave del dominio. • Lista de Riesgos y Plan de Gestión del Riesgo: Describe los riesgos del negocio: técnicos, recursos, planificación y las ideas para controlarlos ó darles respuesta. • Prototipos y pruebas de conceptos: Clarifican la visión y validan las ideas técnicas. • Plan de iteración: Describe que resultados se obtiene producto de la primera iteración de la elaboración. • Plan de desarrollo del software: Estimación, con baja precisión, de la duración y esfuerzo de la fase de elaboración: Herramientas, personas, formación y otros recursos. Dr. Juan José Aranda Aboy

50. Comentarios • Los artefactos a considerar son opcionales. • Deben elegirse sólo aquellos que añaden valor real al proyecto. • Lo importante de un artefacto es el pensamiento, análisis y disposición activa, mas que el documento ó el diagrama correspondiente. • Es aconsejable almacenar los datos digitalmente y online en el sitio Web del proyecto. Ejemplo: WebCollab • Algunos artefactos pueden analizarse nuevamente en etapas posteriores. También pueden agregarse nuevos artefactos. Dr. Juan José Aranda Aboy