Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 2. Fundamentos del modelo...

Dr. Juan José Aranda Aboy

Aspectos Avanzados de la

Tecnología de Objetos

2. Fundamentos del modelo de objetos(1ra parte)


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).


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.


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".


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.


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.


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.


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.


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.


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.


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].


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: 1.Concepción: Define el alcance del proyecto y

desarrolla un caso de negocio.2.Elaboración: Define un plan del proyecto.

Especifica las características. Fundamenta la arquitectura.

3.Construcción: Crea el producto.4.Transición: transfiere el producto a los usuarios.


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.


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.


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.


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.


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.


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).


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.


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.

http://es.wikipedia.org/wiki/Simula

http://es.wikipedia.org/wiki/Smalltalk


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.

http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario

http://es.wikipedia.org/wiki/Programaci%C3%B3n_dirigida_por_eventos

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Ada

http://es.wikipedia.org/wiki/BASIC

http://es.wikipedia.org/wiki/Lisp

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Pascal


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.

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Eiffel

http://es.wikipedia.org/wiki/Java_%28lenguaje_de_programaci%C3%B3n%29


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).

http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o

http://es.wikipedia.org/w/index.php?title=Dise%C3%B1o_por_contrato&action=edit

http://es.wikipedia.org/wiki/Lenguaje_de_modelado_de_objetos

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado


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.


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.


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.


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.


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.


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.


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.


Características de la POOHay 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:

1.Abstracción

2.Encapsulamiento

3.Principio de ocultación

4.Polimorfismo

5.Herencia


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.


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.


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.


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++.

http://es.wikipedia.org/wiki/Sobrecarga


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).


Otras características deseadasAlgunos 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.


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

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Ada

http://es.wikipedia.org/wiki/C%2B%2B

http://es.wikipedia.org/wiki/C_Sharp

http://es.wikipedia.org/wiki/VB.NET

http://es.wikipedia.org/wiki/Visual_FoxPro

http://es.wikipedia.org/wiki/Delphi

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Eiffel

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Java

http://es.wikipedia.org/wiki/Objective-C

http://es.wikipedia.org/wiki/Objective-C

http://es.wikipedia.org/wiki/Perl

http://es.wikipedia.org/wiki/PHP

http://es.wikipedia.org/wiki/Python

http://es.wikipedia.org/wiki/Ruby

http://es.wikipedia.org/wiki/Smalltalk


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.

http://es.wikipedia.org/w/index.php?title=OOCOBOL&action=edit

http://es.wikipedia.org/w/index.php?title=OOLISP&action=edit

http://es.wikipedia.org/w/index.php?title=OOPROLOG&action=edit

http://es.wikipedia.org/wiki/Object_REXX

http://es.wikipedia.org/wiki/Object_REXX


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.


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".


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.


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).


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.


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.


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


Objetivos y ventajas de la POA

• Entre los objetivos que se ha propuesto están: 1. Separar conceptos: Se persigue que cada decisión se tome en un

lugar concreto y no diseminada por la aplicación. 2. 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.


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:


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.


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.


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.


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.


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.


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.


Perspectivas de arquitectura• Se considera que hay cuatro perspectivas de arquitectura que

cumplen los requerimientos de una empresa:1. 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.

2. 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.

3. 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.

4. 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.


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.


Arquitectura lógica de tres capas de una aplicación cliente/servidor


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?)


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


Características de diseño físico

El diseño físico debe involucrar: 1. 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.

2. 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.

3. El diseño para uso concurrente: El desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.


Características … (2)

4. 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.


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.


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.


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.


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.

http://www.rational.com/

http://www.sourceforge.net/


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!"


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?


¿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.

http://www.acm.org/serving/ethics.html

http://www.acm.org/serving/ethics.html

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/


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

http://homepages.inf.ed.ac.uk/perdita/Book/












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

http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html

http://html.rincondelvago.com/conceptos-y-evolucion-de-la-ingenieria-del-software.html

http://www.um.es/giisw/isbc/

http://www.lcc.uma.es/~av/Docencia/Doctorado/DoctoradoAlmeria.html

http://www.lcc.uma.es/~av/Docencia/Doctorado/DoctoradoAlmeria.html

http://es.wikipedia.org/wiki/Tipo_de_dato_abstracto

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://es.wikipedia.org/wiki/Tipo_de_dato_abstracto

http://es.wikipedia.org/wiki/Proceso_Unificado

http://es.wikipedia.org/wiki/Programaci%C3%B3n_Orientada_a_Aspectos


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


Referencias de Microsoft

• MSDN Domain-Specific Language Tools

• MSDN Software Factories

• Microsoft patterns & practices Developer Center

• patterns & practices: Web Applications

• MSDN Solution Architecture Center


Literatura presente ya en Internet• Booch G. 1998. Software Architecture and the UML. Presentación disponible

en: http://www.rational.com/uml como arch.zip.• Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999

Disponible en: http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm

• Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc. 22-Mar-1999 Disponible en: http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm

• Jacobson, I. 1998. "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en http://www.rational.com/uml como UMLconf.zip

• Microsoft y Rational 1998. 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 http://www.rational.com/uml/papers.

• Object Management Group. 1999. OMG Unified Modeling Language Specification (Draft). Versión 1.3. alfa R5, marzo de 1999. Disponible en: http://www.rational.com/uml

http://www.rational.com/uml%20como%20arch.zip

http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm

http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm

http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm

http://www.rational.com/uml%20como%20UMLconf.zip

http://www.rational.com/uml





Literatura aún ausente de Internet• Booch, G. 1988. Object Oriented Development. Trans. of

Soft. Eng. Vol. SE-12. Num. 2. Feb. 1986. pp. 211-221.• Cota A. 1994 "Ingeniería de Software". Soluciones

Avanzadas. Julio de 1994. pp. 5-13.• Greiff W. R. Paradigma vs Metodología; El Caso de la

POO (Parte II). Soluciones Avanzadas. Ene-Feb 1994. pp. 31-39.

• Jacobson, I. et. al. 1992. Object-Oriented Software Engineering; A Use Case Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp. 465-493.

• Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10.[Microsoft 1997] Microsoft 1997. Microsoft Solutions Framework 1.0. Microsoft Corporation. USA.

Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 2. Fundamentos del modelo...

Documents

Transcript of Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 2. Fundamentos del modelo...