Estanislao contreras object-oriented_y_uml

874 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
874
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Estanislao contreras object-oriented_y_uml

  1. 1. Universidad INGENIERÍA DE SOFTWARE Object Oriented y UML ELABORADO POR: Contreras Chávez, Estanislao madti0112@esan.edu.pe Abril 2007 Lima - Perú
  2. 2. Object Oriented y UML Estanislao Contreras Chávez ÍndiceIntroducción ................................................................................................................................... 3 1. Object Oriented ............................................................................................................ 4 1.1. Paradigma Orientado a Objetos .............................................................................. 4 1.2. Clases y Objetos...................................................................................................... 4 1.3. Atributos y Métodos ................................................................................................. 5 1.4. Encapsulamiento ..................................................................................................... 5 1.5. Herencia................................................................................................................... 6 1.6. Polimorfismo ............................................................................................................ 7 1.7. Ventajas de la metodología orientada a objetos ..................................................... 8 1.8. Problemas derivados de la utilización de la orientación a objetos .......................... 9 1.9. El estado actual de la OO...................................................................................... 10 1.10. Predicciones del futuro cercano de la OO............................................................. 10 2. UML............................................................................................................................ 11 2.1. La importancia del Modelado................................................................................. 11 2.2. El Lenguaje Unificado de Modelado UML ............................................................. 11 2.2.1 Historia de UML................................................................................................. 11 2.2.2 Modelado Visual ................................................................................................ 12 2.2.3 ¿Qué es UML? .................................................................................................. 13 2.2.4 Las fases del desarrollo de sistemas que soporta UML ................................... 14 2.2.5 Objetivos de UML .............................................................................................. 15 2.2.6 Beneficios de UML ............................................................................................ 15 2.3. Diagramas de UML................................................................................................ 15 2.4. Proceso de Desarrollo ........................................................................................... 18 Referencias .............................................................................................................................. 20Universidad ESAN – Maestría en Dirección de Tecnologías de Información 2 / 20
  3. 3. Object Oriented y UML Estanislao Contreras Chávez IntroducciónDesde el nacimiento de los primeros lenguajes de programación orientados a objetos, en ladécada de los 60, la Tecnología de Objetos (TO) se ha presentado como la solución a muchosde los problemas del desarrollo de software, consolidándose, en la década de los 90, como elparadigma de desarrollo para sistemas de complejidad media o alta (aplicaciones CAD/CAM,multimedia, aplicaciones distribuidas, etc.). Además, proporciona otra serie de ventajas comofacilitar la reutilización de código o permitir obtener aplicaciones más fácilmente escalables. Enla actualidad, y especialmente desde la aparición de Java y .NET, la TO parece ser también laque mejor se adapta a los nuevos tipos de desarrollos hipermedia y Web.Hablar de TO lleva consigo la necesidad de hablar de objetos, de componentes, de patrones,de lenguajes, de frameworks, de arquitecturas, de persistencia, etc. Por otra parte, la TO hoypasa por la integración de cada una de las técnicas y herramientas de desarrollo, tanto deanálisis y diseño, como de programación, persistencia o distribución. Cada una de estaspalabras clave, así como la problemática de la integración de las mismas, constituye un áreade interés que podría, sin duda alguna, dar lugar a un trabajo como éste. Por ello, nopretendemos profundizar en ninguna de estas áreas sino, más bien, ofrecer una visión generalde la TO en la actualidad así como de lo que, en nuestra opinión y haciendo una arriesgadaprevisión de futuro, constituyen las principales tendencias de la misma.Tras la aceptación del paradigma orientado a objetos (OO) como el más adecuado paraproducir software de calidad, a principios de los noventa emergieron un buen número demétodos de desarrollo de software OO. En 1993, Jacobson criticó en lo que el denominabaguerra de métodos y planteo la necesidad de llegar a una notación estándar de modelado,para evitar la confusión reinante y favorecer el uso de los métodos de software OO. A finales de1994 se inicio un esfuerzo unificación y es así como nace el Lenguaje Unificado deModelamiento (UML Unified Modeling Language). UML ha ejercido un gran impacto en lacomunidad software, tanto a nivel de desarrollo como de investigación y esas son las razonespor la cual presentamos un estudio preciso acerca de UML para exponer sus principalescaracterísticas.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 3 / 20
  4. 4. Object Oriented y UML Estanislao Contreras Chávez Revisión: 03 de abril de 2007ESTANISLAO CONTRERAS Object Oriented y UML1 .1. Object Oriented1.1. Paradigma Orientado a ObjetosEl paradigma orientado a objetos ha derivado de los paradigmas anteriores a éste. Así comolos métodos de diseño estructurado realizados guían a los desarrolladores que tratan deconstruir sistemas complejos utilizando algoritmos como sus bloques fundamentales deconstrucción, similarmente los métodos de diseño orientado a objetos han evolucionado paraayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados enobjetos y orientados a objetos, utilizando las clases y objetos como bloques de construcciónbásicos.El modelo de objetos ha sido influenciado por un número de factores no sólo de laProgramación Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglasen inglés). Además, el modelo de objetos ha probado ser un concepto uniforme en las cienciasde la computación, aplicable no sólo a los lenguajes de programación sino también al diseño deinterfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razónde ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la inherentecomplejidad de muchos tipos de sistemas.Actualmente, el Análisis y Diseño Orientado a Objetos (ADOO) va progresando como métodode análisis de requisitos por derecho propio y como complemento de otros métodos de análisis.En lugar de examinar un problema mediante el modelo clásico de entrada-proceso-salida (flujode información) o mediante un modelo derivado exclusivamente de estructuras jerárquicas deinformación, el ADOO introduce varios conceptos nuevos. Estos conceptos le pareceninusuales a mucha gente, pero son bastante naturales.1.2. Clases y ObjetosSe define a un objeto como "una entidad tangible que muestra alguna conducta bien definida".Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y losmétodos que controlan dichos datos".Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objetopuede solamente cambiar estado, conducta, ser manipulado o estar en relación con otrosobjetos de manera apropiada a este objeto.Una clase es una plantilla para objetos múltiples con características similares. Las clasescomprenden todas esas características de un conjunto particular de objetos. Cuando se escribeun programa en lenguaje orientado a objetos, no se definen objetos verdaderos sino se definenclases de objetos.1 Este trabajo fue elaborado por el alumno Estanislao Contreras con la finalidad de mostrar los fundamentos de ObjectOriented y UML.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 4 / 20
  5. 5. Object Oriented y UML Estanislao Contreras ChávezUna instancia de una clase es otro término para un objeto real. Si la clase es la representacióngeneral de un objeto, una instancia es su representación concreta. A menudo se utilizaindistintamente la palabra objeto o instancia para referirse, precisamente, a un objeto.1.3. Atributos y MétodosEn los lenguajes orientados a objetos, cada clase está compuesta de dos cualidades: atributos(estado) y métodos (comportamiento o conducta). Los atributos son las característicasindividuales que diferencian a un objeto de otro (ambos de la misma clase) y determinan laapariencia, estado u otras cualidades de ese objeto. Los atributos de un objeto incluyeninformación sobre su estado.Los métodos de una clase determinan el comportamiento o conducta que requiere esa clasepara que sus instancias puedan cambiar su estado interno o cuando dichas instancias sonllamadas para realizar algo por otra clase o instancia. El comportamiento es la única manera enque las instancias pueden hacerse algo a sí mismas o tener que hacerles algo. Los atributos seencuentran en la parte interna mientras que los métodos se encuentran en la parte externa delobjeto (figura 1). Atributos y Detalles Métodos e de la Implementación Interface Interna Pública Figura 1: Representación de un objetoPara definir el comportamiento de un objeto, se crean métodos, los cuales tienen unaapariencia y un comportamiento igual al de las funciones en otros lenguajes de programación,los lenguajes estructurados, pero se definen dentro de una clase. Los métodos no siempreafectan a un solo objeto; los objetos también se comunican entre sí mediante el uso demétodos. Una clase u objeto puede llamar métodos en otra clase u objeto para avisar sobre loscambios en el ambiente o para solicitarle a ese objeto que cambie su estado.1.4. EncapsulamientoCualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Además, comose puede observar en la figura 1, las variables del objeto se localizan en el centro o núcleo delobjeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Alempaquetamiento de las variables de un objeto con la protección de sus métodos se le llamaencapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de lapuesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta enpráctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en unamembrana protectora de métodos— es una representación ideal de un objeto y es el ideal porel que los diseñadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: amenudo, por razones de eficiencia o la puesta en práctica, un objeto puede querer exponeralgunas de sus variables o esconder algunos de sus métodos.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 5 / 20
  6. 6. Object Oriented y UML Estanislao Contreras ChávezEl encapsulamiento de variables y métodos en un componente de software ordenado es,todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladoresde software: • Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. • Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello.Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Lasclases proveen el beneficio de la reutilización. Los programadores de software utilizan la mismaclase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos.En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos yprocedimientos que se pueden llevar a cabo con estos datos. Esto encapsula los datos y losprocedimientos. La realidad es diferente: los atributos se relacionan al objeto o instancia y losmétodos a la clase. ¿Por qué se hace así? Los atributos son variables comunes en cada objetode una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente alque tienen para esa misma variable los demás objetos. Los métodos, por su parte, pertenecena la clase y no se almacenan en cada objeto, puesto que sería un desperdicio almacenar elmismo procedimiento varias veces y ello va contra el principio de reutilización de código.1.5. HerenciaOtro concepto muy importante en la metodología orientada a objetos es el de herencia. Laherencia es un mecanismo poderoso con el cual se puede definir una clase en términos de otraclase; lo que significa que cuando se escribe una clase, sólo se tiene que especificar ladiferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a lainformación contenida en esa otra clase.Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clasetiene una superclase (la clase superior en la jerarquía) y puede tener una o más subclases (lasclases que se encuentran debajo de esa clase en la jerarquía). Se dice que las clases inferioresen la jerarquía, las clases hijas, heredan de las clases más altas, las clases padres.Las subclases heredan todos los métodos y variables de las superclases. Es decir, en algunaclase, si la superclase define un comportamiento que la clase hija necesita, no se tendrá queredefinir o copiar ese código de la clase padre (figura 2). Superclase AtributoComun1 AtributoComun2 MetodoGeneral1() MetodoGeneral2() Subclase 1 Subclase 2 Subclase 3 AtributoParticularA AtributoParticularB AtributoParticularC MetodoEspecialA() MetodoEspecialB() MetodoEspecialC() Figura 2: Jerarquía de ClasesUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 6 / 20
  7. 7. Object Oriented y UML Estanislao Contreras ChávezDe esta manera, se puede pensar en una jerarquía de clase como la definición de conceptosdemasiado abstractos en lo alto de la jerarquía y esas ideas se convierten en algo másconcreto conforme se desciende por la cadena de la superclase.Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sussuperclases; pueden agregar variables y métodos además de los que ya heredan de sus clasespadres. Las clases hijas pueden, también, sobrescribir los métodos que heredan porimplementaciones especializadas para esos métodos (figura 3). De igual manera, no haylimitación a un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que sepuede heredar varios niveles hacia abajo y mientras más niveles descienda una clase, másespecializada será su conducta. Superclase AtributoComun1 AtributoComun2 MetodoGeneral1() MetodoGeneral2() <<virtual>> MetodoRedefinible() Subclase 1 Subclase 2 Subclase 3 AtributoParticularA AtributoParticularB AtributoParticularC MetodoEspecialA() MetodoEspecialB() MetodoEspecialC() <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() Subclase 2A Subclase 2B <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() Figura 3: Sobrescritura de métodos en una jerarquía de clasesLa herencia presenta los siguientes beneficios: • Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A través del uso de herencia, los programadores pueden reutilizar el código de la superclase muchas veces. • Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genéricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no está definida ni implementada. Otros programadores concluirán esos detalles con subclases especializadas.1.6. PolimorfismoEn programación orientada a objetos se denomina polimorfismo a la capacidad que tienenobjetos de diferentes clases de responder al mismo mensaje.Esto significa que puede haber muchos mensajes con el mismo nombre, en diferentes clases.Cada Clase responde al mensaje con su código propio (o método). Justamente de ahí elnombre de polimorfismo, muchas formas de responder al mismo mensaje.También se puede aplicar a la propiedad que poseen algunas operaciones de tener uncomportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican. Elpolimorfismo sólo es aplicable si cualquiera de los posibles tipos de objetos que se invoquenUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 7 / 20
  8. 8. Object Oriented y UML Estanislao Contreras Cháveztienen definida la operación empleada, y los tipos de datos de entrada requeridos y los valoresdevueltos, más allá de cómo se empleen o calculen, son compatibles entre sí.El concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Asínacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellasfunciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta;los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos unelemento cuyo tipo no está especificado.1.7. Ventajas de la metodología orientada a objetosEn síntesis, algunas ventajas que presenta son: • Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el software. • Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. • El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar. De la misma manera hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software. • Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construcción de software más complejo. • Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces. • Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se pueden adaptar para un diseño particular. • Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema. • Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás. • Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estándar. Esto les permite ser utilizadas en múltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que éste se especifique. • Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente en lugaresUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 8 / 20
  9. 9. Object Oriented y UML Estanislao Contreras Chávez ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario. • Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos clientes sólo pueden tener acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto los datos están protegidos contra su corrupción. • Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de objetos accesibles. El diseño orientado a objetos es la clave para la computación de distribución masiva. Las clases de una máquina interactúan con las de algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados a objetos en formato estándar. • Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de métodos, en tanto que una base de datos relacional básica carece de ello. • Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se ajustan a un contenedor orientado a objetos, de modo que la comunicación con ella sea a través de mensajes estándar orientados a objetos. • Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) utilizarán las técnicas gráficas para el diseño de las clases y de la interacción entre ellas, para el uso de los objetos existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado en términos de eventos, formas de activación, estados de objetos, etc. Las herramientas OO del CASE deben generar un código tan pronto se definan las clases y permitir al diseñador utilizar y probar los métodos recién creados. Las herramientas se deben diseñar de manera que apoyen el máximo de creatividad y una continua afinación del diseño durante la construcción.1.8. Problemas derivados de la utilización de la orientación a objetosUn sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sinembargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de losbeneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luegocomienzan a darse cuenta que han impuesto una nueva cultura que es ajena a losprogramadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente: • Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo. • Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, se da cuenta que las clases que se establecieron no son posibles; en ese caso seráUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 9 / 20
  10. 10. Object Oriented y UML Estanislao Contreras Chávez necesario reestructurar la jerarquía de clases devastando totalmente la planificación original. • Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.1.9. El estado actual de la OOEn cuanto a tendencias, hay que separar claramente dos aspectos: tendencias en cuanto amétodos para el desarrollo y gestión, que ayudan en la concepción, diseño, codificacióny pruebas así como la gestión de un sistema OO (Orientación a Objetos); y tendencias encuanto a la tecnología o infraestructura de desarrollo y explotación propiamente dicha.Procesos de desarrollo y gestiónComo consecuencia del nacimiento de los primeros lenguajes de programación OO así comode la complejidad creciente de las aplicaciones, comienzan a surgir, en la década de los 80, losprimeros métodos de análisis y diseño OO. Surgen así diversas metodologías, entre las quepodemos destacar el método de Booch (centrado en las etapas de diseño y construcción),OOSE de Jacobson (que proporcionaba un buen soporte para los casos de uso) y OMT deRumbaugh (más enfocada al análisis de sistemas de información con grandes volúmenes dedatos). Estos tres autores se unieron para definir UML, Lenguaje de Modelado Unificado, unconjunto de técnicas y un lenguaje de definición para el modelado de sistemas OO.Sin embargo, y pese a toda la funcionalidad que parece poseer UML y de la clara aceptaciónque ha tenido en el mercado, existen otras propuestas relevantes como OPEN (Henderson-Sellers), Catalysis (D’Souza y Cameron) para el desarrollo basado en componentes yframeworks con UML, o OHDM (Schawe y Rossi), para el desarrollo OO en Web.TecnologíaLlamamos tecnología a la infraestructura que nos permite desarrollar sistemas OO: middleware,Sistemas de Gestión de Bases de Datos (SGBD), Lenguajes de Programación (LP), etc. • En cuanto a middleware, CORBA, DCOM y .NET Remoting son la solución para arquitecturas distribuidas. Además, se seguirá evolucionando y mejorando los rendimientos y dando soporte a aspectos tales como mejoras en la seguridad, tolerancia a fallos, manejo de transacciones, etc. • Actualmente, los Sistemas de Gestión de Bases de Objetos (SGBO), no tienen la madurez suficiente para soportar aplicaciones con grandes volúmenes de datos que requieren rápidos tiempos de respuesta. Para este tipo de aplicaciones se utilizarán las nuevas versiones de los productos objeto-relacionales (p.e. Oracle, Informix). • En cuanto a los lenguajes de programación, se puede pronosticar, una mayor utilización de Java y los lenguajes de la plataforma .NET para sistemas de todo propósito, así como a un retroceso del C++ que quedaría más para software de sistemas y menos para sistemas de gestión.1.10. Predicciones del futuro cercano de la OO • Ampliación del estándar de UML para el modelado de nuevas aplicaciones (web, wap, etc.) así como para el desarrollo basado en componentes y servicios. • Desaparición casi total de C++ para sistemas de gestión a favor de una mayor utilización de Java y los lenguajes .NET.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 10 / 20
  11. 11. Object Oriented y UML Estanislao Contreras Chávez • Las BD reducirán sus funcionalidades, ocupándose casi exclusivamente de la persistencia de objetos y de un modo totalmente transparente. • Serán más habituales los entornos de desarrollo basados en componentes que permitirán construir sistemas «prefabricados». • Cibertiendas de aplicaciones “hágalo usted mismo”, donde el usuario, por menor costo, se lleva a casa un sistema desmontado que el mismo tendrá que componer. • Conexión de objetos físicos a la red, que permitirán, por ejemplo, poner a calentar la comida antes de salir del trabajo, o leer el contador de la luz desde un teléfono móvil. La evolución de los dispositivos electrónicos tiende a que cada uno de ellos lleve un pequeño ordenador que se pueda conectar a una red de datos, publicando sus servicios. En esta situación será posible que cada dispositivo electrónico (doméstico o industrial) se presente como un objeto distribuido, en una aplicación central que permitiría que interactuaran entre sí.2. UML2.1. La importancia del ModeladoEn todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya quedescriben el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado dedesarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando losdiseñadores del modelo deben investigar los requerimientos del producto terminado y dichosrequerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad.Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cualesdescribe un aspecto específico del producto o sistema en construcción.El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeñotamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande ymás complejo es el sistema, más importante es el papel de que juega el modelado por unasimple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlosen su totalidad".Un modelo proporciona “los planos” de un sistema y puede ser más o menos detallado, enfunción de los elementos que sean relevantes en cada momento.Todo sistema puede describirse desde distintos punto de vista: • Modelos estructurales (organización del sistema) • Modelos de comportamiento (dinámica del sistema)El modelo es esencial en la construcción de software para: • Comunica la estructura de un sistema complejo • Especificar el comportamiento deseado del sistema • Comprender mejor lo que estamos construyendo • Descubrir oportunidades de simplificación y reutilización2.2. El Lenguaje Unificado de Modelado UML2.2.1 Historia de UMLDesde los inicios de la informática se han estado utilizando distintas formas de representar losmodelos de una forma más bien personal o con algún diseño gráfico. La falta deestandarización en la manera de representar gráficamente un modelo impedía que los diseñosgráficos realizados se pudieran compartir fácilmente entre distintos diseñadores.Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladoressino también para servir de apoyo en los procesos de análisis de un problema. Con esteobjetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UMLUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 11 / 20
  12. 12. Object Oriented y UML Estanislao Contreras Chávezse ha convertido en ese estándar tan ansiado para representar y modelar la información con laque se trabaja en las fases de análisis y, especialmente, de diseño.UML es una técnica para la especificación sistemas en todas sus fases. El lenguaje UMLcomenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rationalfundada por Booch (dos reputados investiga-dores en el área de metodología del software). Elob-jetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y elOMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa mismaépoca otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas.Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a lacolaboración de otras empresas para que aportaran sus ideas. Todas estas colaboracionescondujeron a la definición de la primera versión de UML. Figura 4: Evolución del UMLLa versión actual de UML (principios de 2007) es la versión 2.1.1. UML 2.1.1 consiste en dosporciones, infraestructuras y superestructuras; se asocian a éstos las especificaciones dellenguaje de restricciones de objetos (Object Constraint Language OCL) y del diagrama deintercambios.2.2.2 Modelado VisualTal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificaciónde la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales delsistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notacióngráfica. Esto se conoce como modelado visual.El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De lamisma forma que para construir una choza no hace falta un modelo, cuando se intenta construirun sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelosque el ser humano pueda entender.UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de lossistemas software como para la arquitectura hardware donde se ejecuten.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 12 / 20
  13. 13. Object Oriented y UML Estanislao Contreras ChávezOtro objetivo de este modelado visual es que sea independiente del lenguaje deimplementación, de tal forma que los diseños realizados usando UML se pueda implementar encualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados aobjetos).UML es además un método formal de modelado. Esto aporta las siguientes ventajas: • Mayor rigor en la especificación. • Permite realizar una verificación y validación del modelo realizado. • Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto.El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor omenor medida todas las fases de un proyecto informático: desde el análisis con los casos deuso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación yconfiguración con los diagramas de despliegue.2.2.3 ¿Qué es UML?UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis ydiseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Unmétodo es una manera explícita de estructurar el pensamiento y las acciones de cadaindividuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y porqué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodoscontienen modelos y esos modelos son utilizados para describir algo y comunicar los resultadosdel uso del método.Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste devistas, diagramas, elementos de modelo  los símbolos utilizados en los modelos  y unconjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglasson sintácticas, semánticas y pragmáticas (figura 5). Figura 5: Lenguaje de modelo UMLVistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es unagráfica, pero sí una abstracción que consiste en un número de diagramas y todos esosdiagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan ellenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentesvistas que UML tiene son: • Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. • Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 13 / 20
  14. 14. Object Oriented y UML Estanislao Contreras Chávez • Vista de Componentes: Muestra la organización de los componentes de código. • Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente. • Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tienenueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas deun sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, decolaboración, de actividad, de componentes y de distribución.Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son loselementos de modelo que representan conceptos comunes orientados a objetos, tales comoclases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación,dependencia y generalización. Un elemento de modelo es utilizado en varios diagramasdiferentes, pero siempre tiene el mismo significado y simbología.Reglas o Mecanismos generales: Proveen comentarios extras, información o semánticaacerca del elemento de modelo; además proveen mecanismos de extensión para adaptar oextender UML a un método o proceso específico, organización o usuario.2.2.4 Las fases del desarrollo de sistemas que soporta UMLLas fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis,Diseño, Programación y Pruebas.Análisis de RequerimientosUML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través delmodelado de casos de uso, los actores externos que tienen interés en el sistema sonmodelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actoresy los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas sondivididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case.Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella)espera del sistema sin considerar la funcionalidad que se implementará. Un análisis derequerimientos puede ser realizado también para procesos de negocios, no solamente parasistemas de software.AnálisisLa fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos queestán presentes en el dominio del problema. Las clases que se modelan son identificadas, consus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases paraejecutar los casos de uso también se consideran en esta fase a través de los modelosdinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominiodel problema (conceptos del mundo real) y todavía no se consideran clases que definendetalles y soluciones en el sistema de software, tales como clases para interfaces de usuario,bases de datos, comunicaciones, concurrencia, etc.DiseñoEn la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregannuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo debases de datos para almacenar objetos en una base de datos, comunicaciones con otrossistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. Eldiseño resulta en especificaciones detalladas para la fase de programación.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 14 / 20
  15. 15. Object Oriented y UML Estanislao Contreras ChávezProgramaciónEn esta fase las clases del diseño son convertidas a código en un lenguaje de programaciónorientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo másaconsejable es trasladar mentalmente esos modelos a código.PruebasNormalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebasde sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clasesindividuales o a un grupo de clases y son típicamente ejecutadas por el programador. Laspruebas de integración integran componentes y clases en orden para verificar que se ejecutancomo se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validanque el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas deaceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y sonsimilares a las pruebas de sistema.2.2.5 Objetivos de UMLLos objetivos de UML son muchos, pero se pueden sintetizar sus funciones: • Visualizar: UML permite expresar de una for-ma gráfica un sistema de forma que otro lo puede entender. • Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. • Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados. • Documentar: Los propios elementos gráficos sirven como documentación del sistema des-arrollado que pueden servir para su futura re-visión.2.2.6 Beneficios de UML • Mejores tiempos totales de desarrollo (de 50 % o más). • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos. • Establecer conceptos y artefactos ejecutables. • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica. • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. • Mejor soporte a la planeación y al control de proyectos. • Alta reutilización y minimización de costos.2.3. Diagramas de UMLUn diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. Enconcreto, un diagrama ofrece una vista del sistema a modelar. Para poder representarcorrectamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar elsistema desde varias perspectivas. UML incluye los siguientes diagramas: • Diagrama de casos de uso. • Diagrama de clases. • Diagrama de objetos. • Diagrama de secuencia. • Diagrama de colaboración. • Diagrama de estados. • Diagrama de actividades. • Diagrama de componentes. • Diagrama de despliegue.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 15 / 20
  16. 16. Object Oriented y UML Estanislao Contreras ChávezLos diagramas más interesantes (y los más usados) son los de casos de uso, clases ysecuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejemplos de un sistemade venta de entradas de cine por Internet.El diagrama de casos de usos representa gráficamente los casos de uso que tiene unsistema. Se define un caso de uso como cada interacción supuesta con el sistema adesarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo quetiene que hacer un sistema y cómo. En la figura 6 se muestra un ejemplo de casos de uso,donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y lasoperaciones que pueden realizar (sus roles). Figura 6: Diagrama de Casos de UsoEl diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es eldiagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. Enla figura 7 se muestran las clases globales, sus atributos y las relaciones de una posiblesolución al problema de la venta de entradas.Universidad ESAN – Maestría en Dirección de Tecnologías de Información 16 / 20
  17. 17. Object Oriented y UML Estanislao Contreras Chávez Figura 7: Diagrama de ClasesEn el diagrama de secuencia se muestra la interacción de los objetos que componen unsistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 8 muestra lainteracción de crear una nueva sala para un espectáculo. Figura 8: Diagrama de SecuenciaUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 17 / 20
  18. 18. Object Oriented y UML Estanislao Contreras ChávezEl resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar elcomportamiento dinámico del sistema están los de interacción, colaboración, estados yactividades. Los diagramas de componentes y despliegue están enfocados a laimplementación del sistema.2.4. Proceso de DesarrolloAunque UML es bastante independiente del pro-ceso de desarrollo que se siga, los mismoscreadores de UML han propuesto su propia metodología de desarrollo, denominada el ProcesoUnificado de Desarrollo.El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema softwareen construcción está formado por componentes software interconectados a través de interfacesbien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todoslos esquemas de un sistema software. Pero, realmente, los aspectos que definen este ProcesoUnificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado en laarquitectura.Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores crean unaserie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos sevali-dan para que sean conformes a los casos de uso. Finalmente, los casos de uso tambiénsir-ven para realizar las pruebas sobre los componentes desarrollados.Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir unedificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas,fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notacióncorrespondiente. Siguiendo este ejemplo, el concepto de arquitectura software incluye losaspectos estáticos y dinámicos más significativos del sistema.Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo quepuede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyectoen varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan variosrecorridos por todas las fases. Cada recorrido por las fases se denomina iteración en elproyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cadaiteración parte de la anterior incrementado o revisando la funcionalidad implementada. Se sueledenominar proceso. (Ver figura 9).Universidad ESAN – Maestría en Dirección de Tecnologías de Información 18 / 20
  19. 19. Object Oriented y UML Estanislao Contreras Chávez Figura 9: Proceso Iterativo e IncrementalUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 19 / 20
  20. 20. Object Oriented y UML Estanislao Contreras ChávezReferencias • G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado", Addison Wesley, 1999 • Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo", Addision Wesley, 2000 • Martin Fowler: “UML Distilled”, Addison Wesley, 2004. • Pagina oficial de UML. www.uml.org • Wikipedia. www.wikipedia.orgUniversidad ESAN – Maestría en Dirección de Tecnologías de Información 20 / 20

×