Aspectos Avanzados de la Tecnología de Objetos

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

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

Dr. Juan José Aranda Aboy
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

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

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

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

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

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

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

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

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

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

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 , 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lenguajes orientados a objetos
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 Dr. Juan José Aranda Aboy

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

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

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

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

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

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

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

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

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

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

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

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

Aspectos a evitar con los artefactos
Prolongación del tiempo dedicado a la etapa inicial. Intento de definir la mayoría de los requisitos. Esperar (y asumir) que los planes y estimaciones sean confiables. Se define la arquitectura, en lugar de hacerlo de modo iterativo en la fase de elaboración. Se cree que la secuencia adecuada de trabajo debería ser: definición de requisitos; diseño de la arquitectura; implementación No hay artefacto de análisis del negocio ó visión. No se identificaron la mayoría de los nombres de casos de uso y de los actores. Se escribieron todos los casos de uso con mucho detalle. Ninguno de los casos de uso se describió en detalle. Al menos una parte de los casos de uso debería estar escrita detalladamente para obtener algún conocimiento realista del alcance del problema. Dr. Juan José Aranda Aboy

El Proceso Unificado (UP) visitado nuevamente
El Proceso Unificado es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational, donde confluyen 'los tres amigos' como se llaman a sí mismos los tres grandes de la OO: Grady Booch, James Rumbaugh e Ivar Jacobson. Dr. Juan José Aranda Aboy

El UP … (2) El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas. Dr. Juan José Aranda Aboy

Enfoque del UP El Proceso Unificado ha adoptado un enfoque que se caracteriza por: Interacción con el usuario continua desde un inicio. Mitigación de riesgos antes de que ocurran. Liberaciones frecuentes. Aseguramiento de la calidad. Involucrar a todo el equipo en todas las decisiones del proyecto. Anticiparse al cambio de requerimientos. Se enfoca en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reutilización. Dr. Juan José Aranda Aboy

Perspectivas de arquitectura
Se considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa: Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios. Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor. Dr. Juan José Aranda Aboy

Características Una vista arquitectónica es "una descripción simplificada (una abstracción) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch]. Según el mismo autor, las características primordiales del Proceso Unificado son: Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontación de riesgos El diseño del software se realiza a tres niveles: conceptual, lógico y físico. Dr. Juan José Aranda Aboy

Arquitectura lógica de tres capas de una aplicación cliente/servidor
Dr. Juan José Aranda Aboy

Conceptos clave del UP El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson]. Según [Booch], los conceptos clave del Proceso Unificado son: Fase e iteraciones: ¿Cuándo se hace? Flujos de trabajo de procesos (actividades y pasos): ¿Qué se está haciendo? Artefactos (modelos, reportes, documentos): ¿Qué se produjo? Trabajador: un arquitecto ¿Quién lo hace?) Dr. Juan José Aranda Aboy

Diseño conceptual Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario. Se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles. Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución. Este tema se ampliará en próximas clases. Dr. Juan José Aranda Aboy

Diseño lógico Traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. Refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. Un objeto de negocios es el encapsulado de un servicio que abstrae las cualidades esenciales de algo de interés. Un servicio es una unidad con capacidad de cómputo que debe satisfacer: Ser seguro, lo que equivale a un uso correcto y con autorización Ser válido, qué tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catálogo de servicios que constituye un repositorio de servicios. Dr. Juan José Aranda Aboy

Objetos de negocio Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. Las tareas de verificación incluyen: Una verificación independiente: Pre y post condiciones Lógica y funcionalidad individual Una verificación dependiente: Verificación de dependencias Que operan como una unidad específica de trabajo Dr. Juan José Aranda Aboy

Tareas del diseño lógico
Identificar y definir los objetos de negocio y sus servicios. Definir las interfaces. Identificar las dependencias entre objetos. Validar contra los escenarios de uso. Comparar con la arquitectura de la empresa. Revisar y refinar tanto como sea necesario. Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis nombre-verbo de los escenarios de uso. También se puede emplear la técnica sujeto-verbo-objeto directo. En estas técnicas, los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Dr. Juan José Aranda Aboy

Interfaces Una interfaz tiene las siguientes partes: Nombre. Precondiciones: Lo que debe estar presente antes de ejecutarse Postcondiciones: Estado final Capacidad ó funcionalidad (SQL, seudo código, función matemática) Dependencias La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios transaccional ó coordinadamente. Dr. Juan José Aranda Aboy

Consideraciones con las interfaces
Identificar los eventos disparadores (triggers). Determinar cualquier dependencia (existencial o funcional). Determinar cualquier problema de consistencia o secuencia. Identificar cualquier regulación de tiempo crítica. Considerar algún problema organizacional (transacciones). Identificar y auditar los requerimientos de control. Determinar lugares y dependencias a través de la ubicación. Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio. Dr. Juan José Aranda Aboy

Validación del modelo lógico
Debe ser tal que garantice que éste sea: Completo: Debe representar todos los escenarios de uso, Correcto: El comportamiento lógico debe corresponder con el comportamiento conceptual, y Claro: Los objetos de negocio y servicios no deben ser ambiguos. En el diseño lógico conceptualmente se divide en tres niveles de servicios: de usuario, de negocio y de datos; con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Dr. Juan José Aranda Aboy

Servicios de usuario (user services)
Controlan la interacción. Un servicio de usuario son: personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una interfaz gráfica de usuario (GUI) u otra interfaz que puede ser no visual (mensajes o funciones); la cual maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Cuando es necesaria la comunicación, un servicio de usuario incluye un contenido: qué se necesita comunicar al usuario; y una forma: cómo se comunica el contenido. Dr. Juan José Aranda Aboy

Servicios de negocio (bussines services)
Convierten datos recibidos de los servicios de datos y de usuario en información: datos + regla de negocio. Las tareas de los servicios de negocio son: Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en información Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción. Pueden usar otros servicios de negocio para completar su tarea. Dr. Juan José Aranda Aboy

Servicios de datos (data services)
Son los servicios de bajo nivel que apoyan a los servicios de negocio e incluyen una amplia gama de categorías: Declaración del esquema y su evolución: Estructuras de datos, tipos, acceso indexado, SQL, APIs, etc. Respaldo y recuperación: Recuperación de datos si un evento falla. Búsqueda y Lectura: Búsquedas, compilación, optimización y ejecución de solicitudes. Formación de un conjunto de resultados. Inserción, actualización y borrado: Procesar modificaciones consistentemente transaccional. Una transacción es Atómica: Ocurre o no, Consistente: Preserva la integridad, Aislada: Otras transacciones ocurren antes o después; y Durable: Una vez completada, sobrevive. Dr. Juan José Aranda Aboy

Servicios de datos (2) Bloqueo: Permite al acceso concurrente a los datos. Validación de datos: Verifica la integridad del dominio, triggers y gateways, para comprobar el estado de los datos antes de aceptarlos: manejo de errores. Seguridad: Acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios. Administración de la conexión: Mecanismos básicos para establecer una sesión de los servicios de datos. Establecer una conexión involucra: una identificación, la colocación y provisión de datos, el tiempo de sesión y el tipo de interacción: conversacional, transaccional, multiusuario, monousuario. Distribución de datos: Distribuye información, a múltiples unidades de recuperación, a bases de datos heterogéneas, etc.; según la topologías de la red. Dr. Juan José Aranda Aboy

Diseño físico Traduce el diseño lógico en una solución implementable y costo-efectiva o económica. En el diseño físico se debe cuidar el nivel de granularidad: un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico; y la agregación y contención: un componente puede reutilizarse mediante técnicas de agregación y contención, sin duplicar el código. Dr. Juan José Aranda Aboy

Componente La unidad de construcción elemental del diseño físico es el componente. Las características de un componente son: Se define según cómo interactúa con otros. Encapsula sus funciones y sus datos. Es reutilizable a través de las aplicaciones. Puede verse como una caja negra. Puede contener otros componentes. Dr. Juan José Aranda Aboy

Características de diseño físico
El diseño físico debe involucrar: El diseño para distribución: Debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red. El diseño para multitarea: Debe diseñarse en términos de la administración concurrente de dos ó más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso. El diseño para uso concurrente: El desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud. Dr. Juan José Aranda Aboy

Características … (2) El diseño con el manejo de errores y prueba de eventos: Validando los parámetros a la entrada antes de continuar con cualquier proceso. Protegiendo recursos críticos: Manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria. Protegiendo datos importantes: Contar con una excepción a la mitad de la actuación en las bases de datos. Puesta a punto (Debugging): Crear una versión para limpiar errores. Protección integral de transacciones de negocios: Los errores deben regresarse al componente que llama. Dr. Juan José Aranda Aboy

Arquitectura física de tres capas de la aplicación cliente/servidor

Tareas de diseño físico
El diseño físico comprende las siguientes tareas: Definir los componentes Refinar el empaquetamiento y distribución de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios físicos de datos Examinar la tolerancia a fallas y la recuperación de errores Validar el diseño físico De las tareas anteriores, la más importante es la distribución de los datos, que pueden estar centralizados, como una partición, en un extracto ó ser una réplica. Dr. Juan José Aranda Aboy

Distribuciones de datos
Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay superposición entre particiones. En una partición horizontal, cada hilera existe en una sola base de datos. En una partición vertical, cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa una etiqueta de tiempo (timestamp) para indicar qué tan viejos son los datos. Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas. Dr. Juan José Aranda Aboy

Alternativas tecnológicas
El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias, ya que una mala decisión implicará un costo enorme -en dinero y en tiempo- al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado (ó liviano) que no acapare al servidor, comunicándose entre sí en una plataforma Internet con protocolos estándar en redes heterogéneas. Dr. Juan José Aranda Aboy

Herramientas de ingeniería de software
Un ingeniero de software necesita herramientas. Las herramientas de Rational son las más avanzadas, pero son muy costosas. La versión de prueba dura sólo 30 días. También pueden utilizarse las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de código abierto y aún están de desarrollo. Herramientas de Ingeniería de Software: Enlace a información sobre las herramientas líderes que implementan la ingeniería de software, desde el modelado de sistemas con UML hasta el proceso unificado que tiene que ver con la administración de proyectos. SourceForge.net: Es una base de datos de proyectos de software de código abierto u open source software, generalmente gratuitos (freeware), bajo licencia GNU ó equivalente. Dr. Juan José Aranda Aboy

Ejemplo de herramienta: Rational

Ejemplo de herramienta: ArgoUML

Ejemplo de herramienta: MS Visio

Reflexión final Todo lo visto muestra tal como la teoría aconseja que se deben hacer las cosas. En la práctica común de la ingeniería de software frecuentemente se menosprecia el valor de una metodología para crear el producto de software, lo que demerita la incipiente profesión de Ingeniero de Software en particular, la del especialista en Tecnologías de la Información, en general y a las empresas de Consultoría de software, ya que en múltiples ocasiones se cede ante el “chantaje” profesional del jefe o del cliente, quien ordena la construcción del software con argumentos como: “¡No hay tiempo para eso! ¡A programar!" Dr. Juan José Aranda Aboy

Reflexión final (2) Para reflexionar, preguntémonos: ¿Qué pasaría si el ingeniero civil o el arquitecto construye una casa o un edificio sin hacer sus planos, proyectos y maquetas? ¿Cree que la obra pueda concluirse cubriendo las necesidades, con la calidad necesaria y a tiempo? ¿Permitiría que un cirujano le interviniera sin hacer los estudios respectivos para obtener las evidencias del problema de salud que le aqueja? ¿Permitiría a un abogado que le defendiera sin conocer las pruebas y sin un plan para su defensa? Dr. Juan José Aranda Aboy

¿Entonces …? ¿Por qué los ingenieros en software ceden a veces ante el “chantaje de la falta de tiempo” y construyen software sin el análisis y diseño expresado en un proyecto, más allá de las ideas existentes “en su cabeza”? ¿Por qué se intenta hacer análisis y diseño sobre la marcha, pero nunca se concluyen, pues ya no hay tiempo? ¿Dónde queda la ética profesional? Consulte, como referencia, el Código de Ética del Ingeniero en Software y de la Práctica Profesional en el sitio de la Association for Computing Machinery. 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 Grady Booch, James Rumbaugh, Ivar Jacobson “The Unified Modeling Language User Guide”, Addison Wesley, 1998 OMG Unified Modeling Language Specification, Version 1.3, June 1999 Kruchten, P. “The Rational Unified Process”, Addison Wesley, 2000 Dr. Juan José Aranda Aboy

Referencias en Internet
Ingeniería de Software. Conceptos y evolución. Ingeniería del software basada en componentes. Curso sobre Ingeniería del Software Basada en Componentes. Wikipedia: Programación Orientada a Objetos Lenguaje Unificado de Modelado Proceso Unificado de Desarrollo Software Programación Orientada a Aspectos Patrón de diseño Dr. Juan José Aranda Aboy

Referencias en Internet (en inglés)
The Object Oriented Programming Web The Object Management Group (OMG) Introducing UML: Object-Oriented Analysis and Design Architecture & Design: Overview Computer programming/Object oriented programming Topic: Object-Oriented Programming Dr. Juan José Aranda Aboy

Referencias de Microsoft
MSDN Domain-Specific Language Tools MSDN Software Factories Microsoft patterns & practices Developer Center patterns & practices: Web Applications MSDN Solution Architecture Center Dr. Juan José Aranda Aboy

Literatura presente ya en Internet
Booch G Software Architecture and the UML. Presentación disponible en: como arch.zip. Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc. 22-Mar-1999 Disponible en: Jacobson, I "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en como UMLconf.zip Microsoft y Rational A White Paper on the Benefits of Integrating Microsoft Solutions Framework and The Rational Process. Rational Software Corporation y Microsoft Corporation. Documento msfratprocs.doc Disponible en Object Management Group OMG Unified Modeling Language Specification (Draft). Versión 1.3. alfa R5, marzo de Disponible en: Dr. Juan José Aranda Aboy

Literatura aún ausente de Internet
Booch, G Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb pp Cota A "Ingeniería de Software". Soluciones Avanzadas. Julio de pp Greiff W. R. Paradigma vs Metodología; El Caso de la POO (Parte II). Soluciones Avanzadas. Ene-Feb pp Jacobson, I. et. al Object-Oriented Software Engineering; A Use Case Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp Lewis G "What is Software Engineering?" DataPro (4015). Feb pp [Microsoft 1997] Microsoft Microsoft Solutions Framework 1.0. Microsoft Corporation. USA. 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