Metodología Orientada a Objetos

Clave 43100007Maestría en Sistemas ComputacionalesConvenio SEP - UPAEP

Módulo 01Introducción al

Unified Modeling Language (UML)

Mayo 2009

Contenido del módulo 11. Introducción al Unified Modeling Language (UML)

1.1 Vista Rápida: ADOO1.1.1 ¿Que es el Análisis y Diseño?1.1.2 ¿Porqué analizar y diseñar? 1.1.3 ¿Qué son el Análisis y Diseño Orientado a Objetos?1.1.4 Orientación a Objetos1.1.5 Como se realiza la identificación de objetos.1.1.6 Uso de la Orientación a Objetos

1.2 Antecedentes de UML1.3 ¿Qué es UML?1.4 Objetivos del UML1.5 Evolución del UML1.6 Áreas conceptuales de UML

1

Vista Rápida Análisis y Diseño Orientado a Objetos

Antes de empezar con el estudio de UML como metodología orientada a objetos, es necesario aclarar algunos conceptos necesarios para su entendimiento, así, empezaremos teniendo claro algunos preceptos que la anteceden; en este sentido, sabemos que el análisis y diseño son dos actividades fundamentales para el desarrollo de software; esto es una introducción al A/DOO, nos centraremos en el dominio y comprensión de los fundamentos, de esta manera para empezar formúlese a manera de reflexión las siguientes preguntas:

¿Que son el análisis y el diseño? ¿Para qué analizar y diseñar? ¿Qué son el análisis y el diseño orientado a objetos? ¿Qué significa orientación a objetos? ¿Para qué se usa la orientación a objetos?

¿Qué son el análisis y el diseño?

El análisis pone énfasis en la investigación del problema y los requisitos, en lugar de ponerlo en la solución. Por ejemplo si se desea un nuevo sistema de información para una biblioteca; ¿Cómo se utilizará el análisis?

“Análisis” es un término amplio, es más adecuado calificarlo como -Análisis de requisitos (un estudio de los requisitos) o Análisis de Objetos (un estudio de los objetos del dominio)

El diseño pone énfasis en la solución conceptual que satisface los requisitos, en lugar de ponerlo en la implementación. Como en el “Análisis”, en el diseño es más apropiado calificar el término como diseño de objetos.

En resumidas cuentas, en el análisis se da respuesta al “Qué”, mientras que durante el diseño se responde al “Como”.

¿Para qué analizar y diseñar?En resumidas cuentas, a pesar de todas las indicaciones de los procesos de desarrollo de software, usted y yo sabemos que la cuestión fundamental e importante del desarrollo del software es la escritura de código. Después de todo, los diagramas son sólo imágenes bonitas. Ningún usuario va a agradecer la belleza de los dibujos, lo que el usuario quiere es software que funcione; entonces para que analizar y diseñar.

2

Por tanto, ahora que está considerando usar UML, es importante preguntarse porque lo hará y como le ayudará a usted en el momento de escribir el código. No existe una evidencia empírica adecuada que demuestre que estas técnicas son buenas o malas.

Son muchos los beneficios logrados con estas actividades cuando se trata de desarrollar software, en contrapunto con la curva de aprendizaje asociada a la OO; no es difícil aprender a programar en un lenguaje OO; el problema es que es necesario cierto tiempo para aprovecha sus ventajas. Como dice Tom Hadfield: los leguajes OO permiten ventajas pero no las proporcionan; para aprovechar estas ventajas hay que realizar el infame cambio de paradigma. ¿Qué son el análisis y el diseño orientado a objetos?Durante el análisis orientado a objetos se presta especial atención en encontrar y describir los objetos en el dominio del problema. Por ejemplo en el sistema de información de una biblioteca algunos de los conceptos –objetos- con libros, biblioteca, socio.

El proceso de análisis para identificar objetos y clases de éstos es una de las áreas más difíciles en el desarrollo OO; este proceso comprende el desarrollo de un modelo OO del dominio de la aplicación. Los objetos identificados reflejan las entidades y operaciones que se asocian con el problema a resolver.

Sin importar el ciclo de vida, un desarrollo OO requiere varios pasos para describir requerimientos, diseñar el sistema, codificar y probar. El análisis de requerimientos OO es usualmente hecho en lenguaje natural e incluye los conceptos y escenarios que tiene que ver con el dominio de la aplicación. Los conceptos incluyen información, servicios y responsabilidades. El conocimiento del dominio hace que los desarrolladores entiendan el contexto en el cual el sistema será usado y describe los requerimientos en la manera que el usuario los entenderá; en este sentido, esta expresión de los requerimientos será la misma, sin importar como los desarrolladores decidan implementar el sistema.

Durante el diseño orientado a objetos se presta especial atención a la definición de los objetos de software, y en como colaboran para satisfacer los requisitos. Por ejemplo en el sistema de la biblioteca, un objeto software libro podría tener un atributo titulo y un método obtenerCapitulo.

El proceso de diseño OO comprende la creación de clases de objetos y las relaciones entre estas clases; este proceso comprende el desarrollo de un modelo OO de un sistema de software para implementar los

3

requisitos identificados. Los objetos del diseño OO están relacionados con la solución del problema a resolver.

Hay dos líneas guía que aplicar para representar el diseño de un sistema OO. Primera, es importante identificar y representar clases y objetos. Debemos conocer no solo los objetos del mundo real del dominio de la aplicación, también los detalles de los atributos y comportamiento de los objetos. Segunda. Debemos identificar las interacciones y relaciones de los objetos y clases: Sus asociaciones, composiciones, agregaciones y relaciones inherentes.

Programación Orientada a Objetos – Se refiere a llevar a cabo el diseño de software utilizando un lenguaje de programación orientado a objetos. Un lenguaje de este tipo, permite la implementación directa de los objetos y suministra recursos para definir las clases de objetos.

¿Qué significa Orientación a Objetos?Es fundamental que comprenda todo lo relacionado a la orientación a objetos para el proceso que realizará, específicamente es importante que conozca algunos conceptos clave sobre la orientación a objetos. Estos conceptos son:

Abstracción Herencia Polimorfismo Encapsulamiento Envío de mensajes Asociaciones Agregación

La OO es un paradigma que depende de ciertos principios fundamentales, en las siguientes líneas veremos dichos principios que hacen funcionar a los objetos y como utilizarlos para hacer el análisis y diseño.

El mundo está lleno de objetos, mire a su alrededor y vera objetos por doquier, incluso usted y yo somos un objeto en este mundo. Los sistemas tratan de simular los objetos (o al menos parte de estos) mediante el software; así pues, definiremos un objeto como la instancia de una clase (o categoría); de esta manera usted y yo somos instancia de la clase persona.

Objeto: Es una entidad que tiene un estado y un conjunto de operaciones definidas que operan sobre este estado. Es estado representa un conjunto de atributos del objeto. Las operaciones

4

que son asociadas con el objeto proveen servicios a otros objetos que solicitan estos servicios cuando se requiere llevar a cabo algún cálculo.

En este sentido, un objeto cuenta con una estructura, es decir atributos (propiedades) y acciones; las acciones son todas las actividades que el objeto es capaz de realizar. Como objetos de la clase persona, usted y yo contamos con los siguientes atributos: altura, peso, edad y mucho otros; además de las siguientes acciones: comer, leer, escribir, hablar, trabajar, etcétera. En el mundo de la orientación a objetos, una clase tiene otro propósito además de la categorización, es en realidad una plantilla para crear objetos (algunos dicen que es lo mismo, pero evitaremos ese debate).

Es importante que recuerde que el propósito de la orientación a objetos es desarrollar software que refleje particularmente un esquema del mundo. Entre más atributos y acciones tome en cuenta, mayor será la similitud de sus software con la realidad.

¿Cómo realizar la identificación de Objetos?No hay una fórmula mágica para realizar la identificación de objetos, usualmente se basa en la experiencia y el conocimiento del dominio de los diseñadores; sin embargo, se presentan algunos puntos que le ayudarán sustancialmente a realizar esta tarea.

1. Utilizar un análisis gramatical de la descripción en lenguaje natural de un sistema. Los objetos y los atributos son sustantivos, las operaciones o servicios son verbos. (Enfoque del método HOOD, Robinson, 1992)

2. Utilizar entidades tangibles (cosas) en el domino de la aplicación como aviones; papeles como administrador; eventos como una petición; interacciones como reuniones; ubicaciones como oficinas; unidades organizacionales como compañías. Esto debe complementarse identificando estructuras de almacenamiento (estructuras de datos abstractos) en el dominio de la solución, las cuales podrían requerirse para apoyar a estos objetos. (Coad y Yourdon, 1990)

3. Utilizar un enfoque de comportamiento en el cual el diseñador, primero comprende el comportamiento total del sistema. Los diversos comportamientos se asignan a distintas partes del sistema para así comprender quien inicia y participa en esos comportamientos. Los participantes que juegan papeles importantes se identifican como objetos. (Rubin y Goldberg, 1992)

4. Utilizar un análisis basado en escenarios en el cual se identifican y analizan en su momento varios escenarios de la forma de utilizar el sistema. Puesto que cada escenario se analiza, el equipo

5

responsable del análisis debe de identificar los objetos, atributos y operaciones requeridas. (Beck y Cunningham, 1989).

La OO refiere además de atributos y acciones, otros aspectos importantes como son abstracción, herencia, polimorfismo y encapsulamiento; además de las asociaciones y la agregación.

Abstracción – Se refiere a quitar las propiedades y acciones de un objeto y dejar solo las necesarias; se puede definir como la extracción de las propiedades esenciales de un concepto.

Herencia – Como ya dijimos un objeto es la instancia de una clase, esta acción de inicio tiene una consecuencia importante, que el objeto tiene todas las características de la clase de la que proviene, ha esto se le conoce como herencia. Además un objeto no solo hereda de la clase de una clase, si no que una clase también puede heredar de otra clase. Polimorfismo – Como sabemos las clases tienen atributos y operaciones; en ocasiones las operaciones tiene el mismo nombre en diferentes clases; en la OO cada clase “Sabe” como realizar tal operación.En sentido literal, polimorfismo significa la capacidad de tener más de una forma, en esencia se refiere al hecho que una misma operación puede tener diferente comportamiento en diferentes objetos; en otras palabras, diferentes objetos reaccionan al mismo mensaje de modo diferente.

Encapsulamiento – la esencia del encapsulamiento es que cuando un objeto trae consigo su funcionalidad, esta última se oculta. ¿Cuál es la importancia de esto?, en el software este principio permite el reducir el potencial de errores que se pueden ocurrir. En un sistema que consta de objetos, éstos dependen unos de otros en diversas formas; si uno de ellos falla y los especialistas en software tienen que modificarlo de alguna forma, el ocultar sus operaciones de otros objetos, significará que tal vez no sea necesario modificar los demás objetos.

Envío de mensajes – En un sistema los objetos trabajan en conjunto, esto se logra mediante el envío de mensajes entre ellos, un objeto envía a otro un mensaje para realizar una operación y el objeto receptor ejecutará la operación.

Asociaciones – Otro principio del paradigma OO, es que los objetos se relacionan entre sí de alguna forma. La multiplicidad es un aspecto importante de las asociaciones entre objetos. Indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada.

6

Agregación – Un tipo de agregación trae consigo una estrecha relación entre un objeto agregado y sus objetos componentes, a esto se le conoce como composición, el punto central de la composición es que el componente se considera como tal sólo como parte del objeto compuesto.

La agregación y la composición son importantes dado que reflejan casos extremadamente comunes, y ello ayuda a que se creen modelos que se asemejen considerablemente a la realidad.

Uso de la Orientación a Objetos Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad de los sistemas. Para modelarlos necesitará comprender lo que son las asociaciones, si esta consiente de los posibles tipos de asociaciones, tendrá una amplia gama de posibilidades cuando hable con los clientes respecto a sus necesidades, estará en condiciones de obtener sus requerimientos y creará los modelos de los sistemas que le ayudarán a cumplir los retos del negocio.

Lo importante es utilizar los conceptos de la Orientación a Objetos para ayudarle a comprender el área de conocimiento de su cliente (su dominio), y establecer sus puntos de vista al cliente en términos que él o ella puedan comprender.

Es allí donde se aplica el UML.

UML

AntecedentesInicialmente surgieron los LOO (lenguajes Orientados a Objetos), el primero reconocido como tal es SIMULA 67, desarrollado en 1967; aunque no tuvo un seguimiento significativo influyo en desarrollos posteriores de LOO, como Smalltalk a principios de los 80’s, además de Objective C, C++, Eiffel y CLOS; el uso de dichos lenguajes fue limitado, pero lo que más atrajo la atención fue el Paradigma OO surgiendo así los primeros métodos de desarrollo OO.

Aparecieron muchos libros de MOO, cada uno con su propio conjunto de conceptos, definiciones, notación, terminología y procesos; pero en general hubo gran similitud ente los conceptos propuestos por los diferentes autores. Todos los métodos eran similares, sin embargo, tenían entre sí una gran cantidad de diferencias menores, con frecuencia muy incómodas. Los mismos conceptos básicos aprecian con denominaciones muy diferentes, lo cual confundía a los clientes y desarrolladores.

7

Metodologías OO

- Booch (OOAD)- CASEIode (CCM)- Coad-Yourdon- Nicola (OOA,OOD)- NE University (Demeter)- Object Engin. (Fresco)- HP – Coleman’94 (Fusion)- Graham (SOMA)- Texas Instruments (IE\O)- ICL (MTD)- ParcPlace (OBA)

- Jacobson (OOSE)- Olivetti (OGROUP)- Martin-Odell (OOIE)- TASKON (OORAM)- Winter (OSMOSYS)- Rumbaugh (OMT)- LBMS (SE/OT)- Shlaer/Mellor (OOSA)- CCTA (SSADM)- Wirfs-Brock (RDD)- Lloyds Register (Z++)

Evidentemente surgió la imperiosa necesidad de unificar la maremágnum de métodos existentes; el primer intento exitoso de combatir y reemplazar los métodos existentes llegó cuando Rumbaugh se unió a Booch en racional Software Corporation en 1994; ellos empezaron a combinar sus métodos (Booch, OMT-Object Modeling Technique), resultando una primera propuesta en 1995; en este momento, Ivar Jacovson también se unió a Rational dejando General Electric; trabajando conjuntamente con Rumbaugh y Booch con la intención de unificar sus métodos y crear el Lenguaje Unificado de Modelado. Este esfuerzo de los autores de tres prestigiados métodos, inclinó favorablemente la balanza en el campo de la MOO; desde entonces UML se considera como el sucesor de la oleada de métodos de A/DOO que surgió a finales de los 80´s y principios de los 90´s. Decimos pues que el UML es un lenguaje de modelado, y no un método. La mayor parte de los métodos consisten, al menos en principio, en un lenguaje y en proceso para modelar. El UML es una notación (principalmente gráfica), de que se valen los métodos para expresar los diseños. El proceso es la orientación que nos dan sobre los pasos a seguir para hacer el diseño. Si usted desea analizar un diseño con alguien, lo que ambos necesitan comprender es el lenguaje de modelado, no el proceso que usted siguió para lograr el diseño.

UML no es A/DOO o un método para entenderlo, es simplemente una notación. No es tan útil aprender a hacer diagramas UML sintácticamente correctos (una herramienta CASE podría ayudarle a eso), si no es capaz de crear un diseño excelente o evaluar y mejorar uno existente. Esta es la habilidad más difícil y valiosa. Como ya se mencionó, la unión de los creadores de las metodologías Booch’94, OMT y OOSE (Grady Boochy, James Rumbaugh e Ivar Jacobson), conocidos como los “tres amigos”, dio origen a UML; cuya

8

primera versión 1.1, se presentó para su estandarización en 1997 a la OMG (Object Management Group) y fue aceptada unánimemente. La creación de UML, se debió inicialmente a los “tres amigos”, ellos iniciaron el esfuerzo, pero muchos ayudaron a llevarlo a una conclusión exitosa; el resultado es una norma construida sobre las muchas ideas y contribuciones de muchos individuos y compañías de la comunidad OO. UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran número métodos de desarrollo orientado a objetos que habían surgido (y terminar así con la guerra de los métodos). La construcción de modelos, al igual que se emplea en otras áreas de la ingeniería, hace que los usuarios entienda la realidad de la tecnología y la posibilidad de que reflexione antes de invertir y gastar grandes cantidades en proyectos que no estén seguros en su desarrollo, reduciendo costos y el tiempo empelado en la construcción de las piezas que construirán dicho modelo.

¿Qué es UML? (Lenguaje Unificado de Modelado) UML es un lenguaje de modelado visual, que se usa para

especificar, visualizar, construir y documentar artefactos de un sistema de software.

Está pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominio de la aplicación y medios.

La especificación del UML no define un proceso estándar, pero está pensado para ser útil en un proceso de desarrollo iterativo; pretende dar apoyo a la mayoría de los procesos de desarrollo orientado a objetos.

UML capta la información sobre las estructuras estáticas y dinámicas de un sistema; las primeras definen los tipos de objetos importantes para un sistema y para su implementación, así como las relaciones entre los objetos; las segundas definen la historia de los objetos en el tiempo y la comunicación entre los objetos para cumplir con los objetivos.

Objetivos del UML

1. El primero y más importante, UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.

2. UML, no tiene propietario y está basado en el común acuerdo de gran parte de la comunidad informática.

3. Está pensado para reemplazar al menos los modelos OMT, Booch, Objectory y otro método importantes.

4. Pretende abordar los problemas actuales del desarrollo de software, tales como el tamaño, distribución, concurrencia, patrones y desarrollo en equipo.

9

5. UML no pretende ser un método de desarrollo completo. No incluye un proceso de desarrollo paso a paso. Es importante darse cuenta que UML y el proceso para usarlo son dos cosas independientes.

El objetivo final de UML era ser tan simple como fuera posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesitan construir.

UML es un lenguaje para modelar sistemas de información, y su objetivo fundamental es lograr modelos que, además de describir con cierto grado de formalismo tales sistemas, pueden ser entendidos por los clientes o usuarios de aquello que se modela.

Sin importar el proceso, no olvide que puede emplearse cualquier proceso con el UML. El UML es independiente del proceso, es libre de elegir el más adecuado para su proyecto; se cual fuere el proceso con el que trabaje; el UML pude servirle par registrar las decisiones de análisis y diseño que resulten.

Por otra parte, distintos factores relacionados con el desarrollo de software conducen necesariamente a diferentes tipos de procesos. Entre estos factores se incluyen el tipo de software que se está desarrollando (tiempo real, sistema de información, producto de computadora de escritorio), la escala (un solo desarrollador, un solo equipo, un equipo de más de 100 miembros), entre muchos otros factores.

Evolución del UML

10

Áreas conceptuales del UML

Estructura estática

Cualquier modelo define los conceptos clave de la aplicación, sus propiedades internas y las relaciones entre cada uno de estos; estos conceptos son modelados de clases, que categorizar un conjunto de objetos que almacenan información y se comunican para implementar un comportamiento. La información que almacenan se modela con atributos y el comportamiento con operaciones.

- Si las clases comparten información se puede modelar con la generalización.

- Las relaciones objeto a objeto se pueden modelar con asociaciones, dependencias.

La vista estática del modelo se expresa con diagramas de clases y pueden usarse para generar la mayoría de las declaraciones de estructuras de datos en un programa.

Comportamiento dinámicoHay dos formas de modelar el comportamiento. Una es mediante la historia de la vida de un objeto y otra son los patrones de comunicación

11

de un conjunto de objetos, que muestra cómo interactúan para implementar un comportamiento.

- La visión de un objeto aislado es una máquina de estados – como responde a los eventos en función de su estado actual- , esto se representa mediante un diagrama de estados.

- La visión de interacción de los objetos de un sistema es una colaboración, que se realiza mediante el flujo de mensajes entre éstos; esto se representa mediante los diagramas de secuencia y colaboración.

Construcciones de implementación

UML ofrece modelos que tiene significado para el análisis lógico y para la implementación física. Un nodo es un recurso computacional que define una localización durante la ejecución del sistema, pueden contener componentes y objetos. La vista de despliegue describe la configuración de los nodos de un sistema en ejecución y la organización de los componentes y objetos en él.

Organización del modeloCuando los modelos son muy grandes, la organización del modelo debe ser dividida en piezas coherentes, en UML se puede desarrollar un modelo de paquetes de tamaño modesto; donde los paquetes son unidades organizativas, jerárquicas y de propósito general, que pueden usarse para el almacenamiento, control de acceso, gestión de la configuración y construcción de bibliotecas. Incluso puede modelarse la dependencia entre paquetes.

Mecanismos de extensiónNo importa que tan vasto sea un lenguaje, siempre se querrán hacer extensiones; dichas extensiones en UML se realizan mediante los estereotipos, sin que haya un cambio en el leguaje básico. Un estereotipo es una nueva clase de elemento de modelado con la misma estructura de un elemento existente pero con restricciones adicionales.

Conceptos de UML

Área Vista Diagramas Conceptos PrincipalesEstructural Vista estática diagramas de clases Clase, asociación,

generalización,

12

realización, interfaz.Vista de casos de uso

diagramas de casos de uso

Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso.

Vista de implementación

diagramas de comportamiento

Componente, interfaz, dependencia, realización.

Vista de despliegue

diagrama de despliegue

Nodo, componente, dependencia, localización.

Dinámica Vista de máquina de estados

diagrama de estados Estado, evento, transición, acción.

Vista de actividad diagrama de actividad

Estado, actividad, transición de terminación, división, unión.

Vista de interacción

diagrama de secuencia

Interacción, objeto, mensajes, activación.

diagrama de colaboración

Colaboración, interacción, rol de colaboración, mensaje.

Gestión de modelo

Vista de gestión de modelos

diagrama de clases Paquete, subsistema, modelo

Extensión de UML

Todas Todos Restricción, estereotipo, valores etiquetados.

Una vista es simplemente un subconjunto de UML que modela construcciones que representan un aspecto de un sistema; uno o dos clases de diagramas proporcionan una notación visual para los conceptos de cada vista.

Vista estática

La vista estática modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación de la aplicación. Esta visión es estática porque no describe el comportamiento del sistema a través del tiempo, los componentes principales de esta vista son las clases y sus relaciones; la visión estática se exhibe en los diagramas de clases.

Vista de casos de uso

Esta vista modela la funcionalidad del sistema según lo perciben los usuarios externos, llamados actores. Un caso de uso es una unidad coherente de funcionalidad, expresada como transacción entre actores y el sistema. Su propósito es enumerar a los actores y los casos de uso, y demostrar qué actores participan en cada caso de uso.

Vista de interacción

13

Esta vista describe secuencias de intercambios de mensajes entre los roles que implementan en comportamiento del sistema. El rol es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción. Esta vista se exhibe en dos diagramas: Secuencias y Colaboración.

Vista de máquina de estados

Esta vista modela las posibles historias de vida de un objeto de una clase. Una maquina de estado contiene los estados conectados por transiciones. Cada estado modela un periodo de tiempo, durante la vida del objeto, en el que satisface ciertas condiciones. Cuando ocurre un evento se puede desencadenar una transición que lleve al objeto a un nuevo estado. Esta vista se exhibe con el diagrama de estados.

Vista de actividades

Es una variante de una maquina de estados, que muestra las actividades de computación implicadas en la ejecución de un cálculo. Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Esta vista se muestra con el diagrama de actividades.

Vista física

Esta vista modela la estructura de la implementación de la aplicación por sí misma, su organización en componentes, y su despliegue en nodos de ejecución. Hay dos visitas físicas: Vista de implementación y Vista de despliegue.

La primera modela los componentes de un sistema – a partir de los cuales se construye la aplicación – así como las dependencias de los componentes, para poder determinar el impacto de un cambio propuesto; esta vista de presenta con el diagrama de componentes.

La segunda representa la disposición de las instancias de los componentes de ejecución en instancias de nodos. Un nodo es un recurso de ejecución tal como una computadora, un dispositivo, una memoria. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos; esta vista se representa con el diagrama de despliegue.

Vista de gestión del modelo

14

Esta vista modela la organización del modelo en sí mismo, un modelo abarca un conjunto de paquetes que contienen los elementos del modelo, tales como clases, maquinas de estado y casos de uso. Los paquetes son unidades para manipular el contenido de un modelo.

Construcción de extensiones

UML tiene tres construcciones básicas de extensión: restricciones, estereotipos y valores etiquetados. Una restricción es una declaración textual de una relación semántica expresada en un cierto lenguaje formal o en lenguaje natural. Un estereotipo es una nueva clase de elemento del modelo, ideada por el modelador, y basada en un tipo existente de elemento modelo. Un valor etiquetado es una porción de información con nombre, unida a cualquier elemento del modelo.

Pueden ser utilizadas para crear versiones adaptadas en un área particular de aplicación.

Ahora que conoce la importancia que tiene el A/DOO en la construcción de software, lo que motivo y dio origen al UML, que sabe un poco de sus creadores, los conceptos principales que maneja y las vistas que considera para realizar el modelado de un sistema, comenzaremos a estudiar su notación; y a comprender la importancia que tiene el UML cuando se realizar la difícil tarea de A/DOO.

Diagramas de UML

La siguiente sección muestra una descripción general de los diversos diagramas de UML; incluyendo los 3 diagramas de la versión 2.0; en las sesiones siguientes abordaremos los diagramas más usados y conoceremos su notación; para que mediante diversos ejemplos prácticos veamos su uso.

Estructura

1. Diagrama de Paquetes: En un diagrama que muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.

2. Diagrama de Clases: Describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, donde se crea el diseño conceptual de la información que se manejará en el sistema, y la relación entre uno y otro.

15

3. Diagrama de Objetos: Son un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

4. Diagrama de estructura compuesta (2.0): Muestra la estructura interna de un clasificador, incluyendo sus puntos de la interacción a otras partes del sistema. Los elementos de la clase se han descrito en detalle en la sección en diagramas de la clase. Esta sección describe la manera en que las clases se pueden exhibir como elementos compuestos que exponen interfaces y contienen puertos y piezas.

5. Diagrama de componentes: Muestra las piezas de software, controladores embebidos, etc., que compondrán un sistema. Un diagrama de componentes muestra un nivel de abstracción más alto que un diagrama de la clase – usualmente un componente es implementado por unas o más clases (u objetos) en tiempo de ejecución-.

6. Diagrama de despliegue: Muestra la configuración de los elementos del hardware (nodos) y muestras como los elementos de software son mapeados en esos nodos.

Comportamiento

7. Diagrama de casos de uso: El modelo del caso del uso captura los requisitos de un sistema. Los casos del uso son un medio que comunica a los usuarios y otros stakehoolders lo que el sistema intenta hacer.

8. Diagrama de actividad: Muestra un flujo de trabajo (mediante una secuencia de actividades) desde un punto de inicio hasta un punto final, detallando las trayectorias de decisión que existen. Son útiles para el modelado del negocio, donde se detallan los procesos involucrados en las actividades del negocio.

9. Diagrama de máquina de estados: Modela el comportamiento de un solo objeto, especificando la secuencia de estados que un objeto tiene en su tiempo de vida, en respuesta a eventos.

Interacción

10. Diagrama de colaboración: Es un diagrama colaboración que muestra información similar al diagrama de secuencia, pero su enfoque primario es mostrar las relaciones de los objetos, si considerar el tiempo. También es conocido como diagrama de comunicación.

11. Diagrama de secuencias: El diagrama de secuencia es uno de los diagramas más efectivos para modelar interacción

16

entre objetos en un sistema. Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso.

12. Diagrama de tiempos (2.0): Muestran los cambios en el estado o valor de uno o más elementos en el tiempo. También, pueden mostrar la interacción para la sincronización de eventos. – su duración contra las restricciones de tiempo –.

13. Diagrama de interacción (2.0): Es un tipo de diagrama de actividad, en la cual los nodos representan diagramas de interacción. Los diagramas de interacción, pueden incluir diagramas secuencia, de colaboración, de interacción y de tiempo. Los diagramas de interacción introducen dos nuevos elementos: ocurrencias en la interacción y elementos de la interacción.

17

Bibliografía1. Shari Lawrence Pfleeger, Joanne M. Atlee “Software

Engineering ,Theory and Practice”, Thrid Edition, Pearson, Prentice Hall

2. Craig Larman, “UML y Patrones, Una introducción al análisis y diseño orientado a objetos y al proceso unificado”, Segunda Edición, Pearson, Prentice Hall.

3. Eric j. Fraude, “Ingeniería de Software, Una perspectiva orientada a objetos”, Alfaomega.

4. James Rumbaugh, Ivar Jacobson y Grady Booch, “El lenguaje Unificado de Modelado, Manual de Referencia“, Addison Wesley

5. Martin Flower con Kendall, “UML gota a gota”, Pearson Addison Wesley

6. Ian Sommerville, “Ingeniería de Software”, Sexta Edición, Addison Wesley, 2002, ISBN:970-26-0206-8.

7. Joseph Schmuller, “Apendiendo UML en 24 horas”, Prentice may

18