Ingeniería del Software

Enviado por Laura Marthé Hinojosa Castillo

INTRODUCCIÓN

En este proyecto, se encontrará todo lo esencial para la investigación de los alumnos, docentes e incluso gente ajena a nuestra institución; que tengan el interés de aprender o ampliar sus conocimientos referente al UML, Microsoft Visio, y algunos conceptos de palabras determinadas para el entendimiento y facilidad de comprensión de esta lectura.

Esperando de ante mano que les sea de gran utilidad, les deseo un buen día y que disfruten de esta investigación que con tanto esmero y dedicación llegué a realizarlo, tanto para mi beneficio como para usted, amable lector.

Gracias por su atención y, nuevamente, le deso lo mejor y un excelente día.

OBJETIVO GENERAL

Aprender o ampliar sus conocimientos referentes al UML, Microsoft Visio, y algunos conceptos; con el fin de brindar mejores profesionistas y actualizar los avances del Software.

LENGUAJE UNIFICADO DE MODELADO.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modelling Language) es el lenguaje de modelado de sistemas de software más conocido en la actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran manera por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. El UML ofrece un estándar para escribir un "plano" del sistema, incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

El punto importante para notar aquí es que el UML es un "lenguaje" para especificar y no un método o un proceso. El UML se usa para definir un sistema de software; para detallar los artefactos en el sistema, para documentar y construir -es el lenguaje en el que está escrito el plano-. El UML se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo qué metodología o proceso usar.

El UML cuenta con varios tipos de modelos, los cuales muestran diferentes aspectos de las entidades representadas.

¿Qué es UML?

Es un lenguaje estándar para la especificación, visualización, construcción y documentación de artefactos de sistemas de Software, muy bueno para la modelación de negocios y otros sistemas que no son Software. El UML representa una colección de las mejores prácticas de ingeniería que tienen una probación exitosa en la modelación de sistemas largos y complejos

El UML es una parte muy importante para el desarrollo de Software Orientados a Objetos y en el Proceso de Desarrollo de Software. Utiliza, en su mayor parte, notaciones gráficas para expresar para expresar los proyectos de diseño del Software. Utilizando el ayudante del UML puede comunicar el equipo de proyecto, explorar el potencial de diseños, y validar el diseño de la arquitectura del Software.

Las principales metas del UML fueron:

Proveer usuarios con un "ready-to-use" (facilidad de uso), lenguaje de modelación visual expresivo donde ellos puedan desarrollar e intercambiar modelos significativos.
Proveer extensamente y específicamente mecanismos para extender el núcleo de conceptos.
Ser independientes en los lenguajes de programación particulares y procesos de desarrollo.
Proveer una base formal para el entendimiento del lenguaje de modelación.
Fomentar el crecimiento de las herramientas del mercado Orientado a Objetos.
Soportar el concepto de desarrollo en alto nivel tal como colaboraciones, sistemas, modelos y componentes.
Integrar mejores prácticas.

¿Por qué Utilizar el UML?

Como la estrategia de evaluación incrementa en muchas compañías, las industrias la observa como técnicas de automatización la producción del Software y para mejorar la calidad y reducir los costos y el tiempo del mercado. Éstas técnicas incluyen el componente tecnológico, la programación visual, modelos y sistemas. Los negocios también observan técnicas para manejar la complexión de sistemas, así ellos aumentan en ámbito y en escala.

En particular, ellos reconocen la necesidad de resolver problemas que ocurran en la arquitectura, tales como la distribución física, concurrencia, réplicas, seguridad, carga balanceada y tolerancia de culpa. Adicionalmente, el desarrollo de la World Wide Web (Mundo de la Ancha Telaraña), mientras se hacen algunas cosas simples, tiene exacerbada ese problema de arquitectura.

La UML fue desarrollada para responder todas esas necesidades.

¿Qué es un Modelo?

La modelización (bien matemática o física) es un mecanismo efectivo para el análisis técnico de sistemas basados en computadora. La figura ilustra el flujo global de información del proceso de modelización. El modelo se crea a partir de la observación del mundo real o de una aproximación basada en los objetivos del sistema. El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo la información de viabilidad técnica para el sistema propuesto.

Blanchard y Fabrycky [BLA81] definen un conjunto de criterios para el uso de modelos durante el análisis técnico de sistemas:

El modelo debe representar la dinámica de la configuración del sistema que está siendo evaluado.
El modelo debe realzar aquellos factores que sean más relevantes para el problema en cuestión y suprimir (con discreción) aquellos que no sean importantes.
El modelo debe ser amplio, incluyendo "todos" los factores relevantes, y fiable en cuanto a repetición de resultados.
El diseño del modelo debe ser lo suficientemente simple como para permitir una rápida implementación de la resolución del problema.
El diseño del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores adicionales si se requieren.

Los resultados del análisis técnico son la base de otra decisión del tipo "seguir/no seguir" con el sistema. Si el riesgo técnico es alto, si los modelos indican que la funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no encajan bien- ¡Hay qué volver a la mesa de trabajo!

Tipos de Modelo.

Funcional: Muestra la funcionalidad del sistema desde el punto de vista del usuario, incluye:
- Diagramas de caso de uso
Objetos: Muestra la estructura y la subestructura del sistema usando objetos, atributos, operaciones y asociaciones, incluye:
- Diagramas de clase
Dinámico: Muestra el comportamiento interno del sistema, incluye:
- Diagramas de secuencia
- Diagramas de actividad
- Diagramas de estados

Software Libre para Modelado en UML.

Poseidon for UML, Herramienta de modelado UML escrita en java que cuenta con una completa versión gratuita denominada Community Edition.
ArgoUml, Herramienta de modelado UML escrito en java.
Dia, Puede ser usado para modelar varios tipos de diagramas UML.
Umbrello, Herramienta para modelado UML para el entorno KDE.
MonoUML, Herramienta CASE para la plataforma mono.
UMLet, Herramienta para modelado rápido de UML también escrita en Java.
gModeler, Herramienta para modelado de UML basada en Flash (utilizable desde el navegador), que permite generar codigo Action Script 2.0 Compatible.

Estandarización de UML.

Además de haberse convertido en un estándar de facto, UML es un estándar industrial promovido por el grupo OMG al mismo nivel que el estándar CORBA para intercambio de objetos distribuidos. Para la revisión de UML se formaron dos "corrientes" que promovían la aparición de la nueva versión desde distintos puntos de vista. Finalmente se impuso la visión más industrial frente a la académica. Recientemente se ha publicado la versión 2.0 en la que aparecen muchas novedades y cambios que, fundamentalmente, se centran en resolver carencias prácticas. Además, esta versión recibe diversas mejoras que provienen del lenguaje SDL.

Críticas a UML.

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva.

Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente, o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado.

Su Utilización.

El estándar UML 2.0 está con nosotros. En Julio de 2003la superestructura UML2.0 fue publicado y desde entonces éste tuvo abundante especulación sobre los cambios y su impacto sobre la comunidad UML.

Los cambios más obvios del UML 1.x al 2.0 fueron la introducción de nuevos diagramas. Los nuevos diagramas incluyen:

* Diagrama de Estructura.

* Diagrama Compuesta.

* Diagrama de Comunicación.

* Diagrama de Oportunidad.

* Diagrama de Interacción por Repaso.

El siguiente Diagrama de Estructura aplica:

El Surgimiento.

Los lenguajes de modelado orientado a objetos comenzaron a surgir entre la mitad de 1970 y finales de 1980 como varias metodologías experimentadas con diferentes aproximaciones entre el análisis y diseño orientados a objetos. El número de los lenguajes de modelado identificados incrementaron un poco más del 10 o más del 50 por ciento durante el periodo 1989-1994. Muchos usuarios de los métodos orientados a objetos tuvieron problemas buscando la satisfacción completa en cualquiera de los lenguajes de modelado, llamándolo "La Guerra Metodista". A mediados de 1990, las nuevas iteraciones de aquellos métodos comenzaron a incorporarse en cada técnica del anterior, y un poco más claro provinentes de los métodos emergieron.

El desarrollo del UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de la Corporación Racional del Software comenzaron su trabajo unificando el método Booch y los métodos TMO (Técnica de Modelado Objeto) En Otoño de 1995, Ivar Jacobson y su compañía Objetory se unió con Racional y éstos unieron fuerzas, fusionándose en el método ISOO (Ingeniería de Software Orientado a Objetos)

Como el primer autor de los métodos Booch, TMO e ISOO; Grady Booch, Jim Rumbaugh e Ivar Jacobson fueron motivados para crear un lenguaje de modelado unificado por tres razones. Primero, estos métodos fueron evolucionando realmente, cada una, independientemente. Esto hizo tener sentido para continuar aquella evolución junto, mejor dicho, tan aparte, eliminando cualquier potencial innecesario y diferencias gratuitas que podrían confundir a los usuarios. Segundo, por la unificación de la semántica y la notación, ellos podrían dar alguna estabilidad al mercado orientado a objetos, dejando proyectos para arreglar sobre un lenguaje de modelado maduro y permitir un enfoque de herramientas constructivas y liberar características más aceptables. Tercero, ellos espectaron que de su colaboración podrían producir todos los tres métodos tempranos, ayudándolos a capturar lecciones aprendidas y a direccional problemas que ninguno de sus métodos anteriormente tocaron bien.

Los esfuerzos de Booch, Rumbaugh y Jacobson dieron resultado al llamado UML 0.9 y documentos 0.91 en Junio y Octubre de 1996. Los autores de UML fueron invitados y recibieron retroalimentación por la comunidad en general. Ellos incorporaron la retroalimentación, pero fue clara aquella atención enfocada adicionalmente que fue silenciosamente requerida.

Mientras que Racional fue tomando junto a UML, los esfuerzos se fueron haciendo, llevando a cabo la gran meta del lenguaje de modelado de una industria estándar. A principios de 1995, Ivar Jacobson (entonces Jefe de la Objetaría Oficial de la Tecnología) y Richard Soley (entonces Jefe de la OMG Oficial en la Tecnología) decidieron impulsar duramente para llevar a cabo una estandarización en los métodos del mercado. En Junio de 1995, un anfitrión de la OMG conoció a todos los grandes metodologiítas (o sus representantes), resultado del primer World Wide (Mundo Ancho) conformada para ser buscar metodologías estándar, bajo patrocinio de el proceso OMG.

Durante 1996, cambiaron limpiamente aquellas organizaciones visto UML como estrategia para los negocios. Una Solicitud de Propuesta (SDP), emitida por el Grupo de Gerencia de Objeto (GGO), provinieron el catalizador de esas organizaciones para unir fuerzas alrededor, produciendo una unión SDP responsable. Racional estableció UML consorcio socio con organizaciones severas esperando dedicar recursos para trabajar en una poderosa definición de UML 1.0. Ellos contribuyendo a mejorar la definición del UML 1.0, incluyendo: Corporación de Equipo Digital, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI SystemHouse, Microsoft, Oracle, Racional Software, TI, y Unisys. Esta modelación produjo a UML 1.0, un lenguaje modelado que fue muy bien definida, expresiva, poderosa, y generalmente aplicable. Ésta fue sometida por la OMG en Enero de 1997 como una respuesta inicial de la SDP.

En Enero de 1997, IBM, ObjecTime, Platinum Technology, Petch, Taskon, Reich Technologies y Soft Team también sometida separada la respuesta de SDP por la OMG. Estas compañías unieron sociedad de la UML para contribuir sus ideas, y juntos la sociedad la respuesta revisada de UML 1.1. El enfoque de la UML 1.1 tomada fue para mejorar la claridad de las semánticas del UML 1.0 y para incorporar contribuciones hacia los nuevos socios. Ésta fue sometida por la OMG con sus consideraciones y adaptadas en el Otoño de 1997.

Trabajar sobre el estándar UML 2.0 incluyeron propuestas para un consorcio, llamada "Socios U2". Ericsson es uno de los socios y buscadores para NorARC que tiene activamente propuesta nuevas improvisaciones para UML que están basadas en la facilidad de trabajo para la estandarización del SDP. Una cercana versión final de la propuesta por el consorcio "Socios U2" fue tomada en Enero de 2003 y una toma final de la OMG SDP En Junio de 2003.

Diagramas de Modelado UML.

UML está compuesto por los siguientes diagramas:

J Diagramas de Clases.

Diagrama de clases mostrando la disposición del patrón Strategy.

Este diagrama describe la estructura (simplificada) de un sistema de restaurante. El sistema tiene cualquier cantidad de platillos, una cocina, comedor y cualquier número de empleados, todos estos objetos asociados a un restaurante.]] El UML muestra las relaciones es_un con un triángulo y las relaciones contiene con un rombo.

A continuación presentaremos su simbología:

J Diagrama de Caso de Uso.

Los casos de uso son los óvalos y las figuras con forma "humana" son los actores.

La OMG define una notación gráfica para los casos de uso, pero se abstiene de definir algún formato escrito para describir la funcionalidad de los casos de uso en detalle; debido a esto algunas personas tienen el concepto erróneo acerca de que un caso de uso es su notación gráfica, cuando es la descripción escrita de escenarios la que da el verdadero valor al caso de uso.

En este diagrama se lleva la notación siguiente:

J Diagrama de Interacción por Repaso.

El Diagrama de Interacción por Repaso es un diagrama variante de la actividad. En este diagrama las diferentes secuencias son incluidas en una actividad que fluyen en orden para mostrar el flujo de trabajo por las secuencias. Ejemplo:

Detrás de los procesos detallados, los fragmentos están representados por los siguientes:

1. Captura de Cliente:

2. Captura de Factura:

J Diagrama de Estados.

El Diagrama de Estado de la Máquina captura los ciclos de vida de los objetos, subsistemas y sistemas. Ellos indican qué estado de un objeto puede tener y qué eventos diferentes afectan aquellos estados fuera de tiempo.

Éste diagrama podría ser adherido a clases que tienen claramente estados identificables y es gobernado por un comportamiento complejo.

Un estado es mostrado como un rectángulo redondeado con comportamientos opcionales de los atributos, eventos y actividades internas. El flujo de estado o transiciones son dibujados entre los Estados, usualmente guardan condiciones y reglas gobernando cómo y donde un objeto puede transicionar de un estado a otro.

Los estados son usualmente nombrados según a sus condiciones, por ejemplo: "Chocando", "Esperando" y "Despachando" son totalmente condiciones activas, un objeto lo puede hacer mientras espera una transición a otro estado o terminar el ciclo completamente.

Los nodos iniciales y terminales son representados como círculos sombreados o vacíos que son usados para representar el inicio y término de todas ls transiciones. El Diagrama de Estado de la Máquina puede tener un punto de inicio y severos puntos de término.

La transición de estados puede ser disparado por eventos. Estos eventos pueden tener palabras claves (guardar) asociándolo para clarificar el evento. Esto no es siempre necesario para mostrar esos eventos.

Los estados pueden ser anidados. Estos implican aquellos estados (sub estados) que puedan existir dentro de un estado total. Los estados Paralelos pueden ser también definidos donde un objeto pueda tener estados serios al mismo tiempo. Por ejemplo: Una persona puede tener en cualquier momento muchos estados paralelos. Estos pueden ser: "Caminando", "Pensando", "Joven", etc.

Considere los siguientes trazos de estados de una clase de factura:

A continuación se marcarán la simbología en este tipo de diagramas:

J Diagramas de Actividad.

Los Diagramas de Actividad son primordialmente usados para describir el comportamiento. Éstos son representados como un conjunto de flujo secuencial de las actividades, éstas describen conceptos como flujo de trabajo.

Una actividad describe una unidad lógica de trabajo. Las actividades pueden ser rotas bajo acciones. Una acción es la más pequeña unidad de trabajo que no es descompuesta ninguna lejana. Un diagrama de actividad tiene un inicio y puede tener múltiples puntos de terminación. El UML 2.0 también proviene de un flujo final (un círculo con una cruz), estos indican aquellos procesos de detención.

Las actividades son unidas por flujos de procesos o eventos. En adición, un nodo de decisión puede modelar diversos comportamientos basados sobre una condición. Típicamente un nodo Inicial y Final son definidos para completar totalmente la representación del diagrama de actividad.

Los puntos de sincronización pueden también ser definidos para ilustrar como procesamiento puede ser cargado fuera en paralelo, entonces sincronizó aquel punto antes lejano la actividad está emprendido. Los parámetros de Entrada y Salida pueden ser mostrados. Esto es hecho por vía rectángulos que sujetan a las actividades.

Las particiones permiten el modelaje para crear vistas en el diagrama de actividad. Estas pueden mostrar las áreas de responsabilidad, los departamentos organizacionales y el mismo.

El siguiente ejemplo muestra lo que sucede si un sistema cambia invaluablemente mientras un usuario lo está usando. Éste usuario recibirá un mensaje donde el sistema está invaluable. El sistema tratará de reconectarse tres veces. Si esto no sucede, mostrará un mensaje de error. La actividad del mensaje hace uso de un parámetro de entrada: estado de conexión. Éste parámetro indica la actividad que ocurrió el error. La actividad del mensaje de error mostrada se rompe bajo las acciones ejecutadas.

Nosotros tenemos hecho el uso de particiones para indicar las áreas del sistema de ejecución y la gerencia de error.

J Diagramas de Paquetes.

Los paquetes son usados para organizar y manipular la complejidad de los modelos largos. Un grupo de paquetes modelan elementos y los diagramas semejantes como el uso de casos, clases, actividades, procesos, estados, etc., y sus diagramas asociados; en tal camino que eso puede ser remitido como uno entero. Los paquetes pueden ser representados en un diagrama, remitido como Diagrama de Paquete.

Un paquete es representado por un rectángulo con una pequeña lengüeta donde el nombre del paquete es marcado.

Los paquetes pueden tener relación con otros paquetes para mostrar que las dependencias están entre los paquetes. Las Relaciones de Dependencia son usadas qué paquetes están dependiendo sobre cada otro.

J Diagramas de Componentes.

El diagrama de componentes ilustra los componentes del software que serán usados para construir el sistema. Estos pueden ser construidos para el modelo de clase y escritos para satisfacer los requisitos del nuevo sistema, o puede ser dada para otros proyectos o vendedores de tercera persona. Los componentes son de nivel de agregación altos de las piezas más pequeñas del software, y provee una "caja negra" construyendo un block para el aprovechamiento de la construcción del software. Un componente puede ser siempre considerado como una unidad autónoma dentro de un sistema o sub sistema. Este tiene una o más provisiones e interfaces requeridas (portales vías potencialmente expuestas) y estas internas son ocultas y otras inaccesibles que estas provinieron por estas interfaces. Todo esto puede ser dependiente sobre otros elementos en términos de interfaces que son requeridas, un componente está encapsulado y estas dependencias son asignadas lejos que pueden ser tratados como un posible independiente. Como resultado, los componentes y los sub sistemas pueden ser flexiblemente rehusados y reemplazados por conexiones ("instalación eléctrica") para unirlos en vía sus provisiones e interfaces requeridas.

El Diagrama de Componente muestra la relación entre los componentes del software, sus dependencias, comunicaciones, localización y otras condiciones. Los Diagramas de Componentes son usados para estructurar los componentes en los sistemas del software. Ellos examinan y controlan las dependencias entre componentes o interfaces de los componentes. Un componente representa una parte modular, desplegable y reutilizables de un sistema.

Una o más clasificaciones que residen sobre el componente típicamente especifican un componente. Sub puesto de esa clasificación, explícitamente define la interface externa del componente. Un componente se conforma de la interface que esta expone, donde la interface representa los servicios provistos por los elementos que residen sobre el componente. Ejemplo:

J Diagramas de Despliegue.

El modelo de despliegue describe cómo una aplicación se despliega a través de una infraestructura. La intención del modelo de despliegue no es para describir la infraestructura, pero mejor dicho el camino en cual los componentes específicos deben corresponder a una aplicación que despliega a través de él.

En el ejemplo, un despliegue físico de una aplicación financiera es mostrado. Las múltiples computadoras del cliente/usuario con el "runtime" de componentes Windows 2000 y el componente del cliente de la aplicación financiera puede conectarse por vía TCP/IP a cualquier aplicación del servidor, ya que estos son múltiples. La aplicación Server/s- corriendo SCO – Unix y la aplicación financiera –conectados por vía TCP/IP hacia el servidor de la base de datos central- corriendo HP-UX –Oracle y tiene la base de datos maestra de la financiera sobre este.

Mensaje ando y flujo de trabajo entre el cliente- PC’s y entre la aplicación del servidor son ejecutados usando MS-Outlook y MS-Exchange. MS-Exchange soporte de flujo de trabajo y mensaje ando. Ejemplo:

J Diagramas de Secuencias.

Diagrama de secuencia. Este diagrama describe la secuencia (simplificada) de mensajes de un sistema de restaurante. El diagrama representa a un cliente pidiendo comida y pagando.

Las líneas punteadas extendiéndose hacia abajo indican la línea de tiempo de cada objeto. Las flechas representan mensajes (estímulos) de un "actor" u objeto a otros objetos.

J Diagramas de Colaboración.

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.

Diagrama de Colaboración para un grupo de Objetos

J Clases y Diagramas de Implementación

Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el diagrama de clase el que se convierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la estructura estática del sistema. El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacenamiento de datos respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.

Modelando la Distribución y la Implementación

Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment' (despliegue), empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.

Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma)

Modelando la Distribución del Sistema con el Diagrama de Implementación

J Diagramas de Objetos.

Un diagrama de objeto está hecho para las instancias de tiempo real de los diagramas de clase o partes de los diagramas de clase. Como tal, un diagrama de objeto puede ser visto para ser un ejemplo de un diagrama de clase. Los diagramas de objetos pueden ser dibujados para explicar los diagramas de clase o para capturar ciertos escenarios de la vida real como ejemplos para demostrar conceptos y/o ciertos estados de los diagramas de clase como un punto de tiempo. Ejemplo:

Para el diagrama de clase:

J Diagramas de Estructura Compuesta.

El diagrama de estructura compuesta toma el modelo para describir las relaciones entre los elementos para trabajar junto a una clasificación. Este es similar al diagrama de clase, pero muestra partes y conectores. Las partes no son necesariamente clases en el modelo y ellos no representan las instancias particulares, pero ellos pueden tener roles donde las clasificaciones pueden jugar.

Las partes son mostradas de una manera similar a los objetos. El diagrama de estructura compuesta es usado para mostrar el "runtime" de la arquitectura de cualquier tipo de clasificación.

Ejemplo:

J Diagramas de Comunicación.

Un diagrama de comunicación muestra la colaboración dinámica entre los elementos. Es similar al diagrama de secuencia y la intención es para enfocar cómo los objetos colaboran con cada otro.

Los diagramas de comunicación muestran los intercambios de mensajes (o interacciones) entre los objetos tan bueno como la relación (poco llamado como "contexto")

Para una elección debe ser hecha para usar el diagrama de secuencia o el diagrama de comunicación. Si mostraran el tiempo o la secuencia de los eventos más importantes, el diagrama de secuencia podría ser usada. Si mostraran conceptos más importantes, el diagrama de colaboración sería usada.

El diagrama de comunicación es dibujada como un diagrama de objeto, donde un número de objetos se muestran con la relación entre ellos. Las flechas de mensajes son dibujadas en medio entonces para mostrar el flujo de los mensajes entre los objetos. Las etiquetas son puestas sobre el mensaje para mostrar el orden dentro de los mensajes que son puestos. Ejemplo:

Un ejemplo usando estereotipos:

J Diagrama de Coordinación.

Los diagramas de coordinación son usados para mostrar cambios y sus relaciones en tiempo de reloj. Este provee de una representación visual de los objetos cambiando el estado y la interacción fuera de tiempo. Los diagramas de coordinación pueden ser usados para definir el funcionamiento del hardware o la implementación de los componentes del software.

El X-axis del diagrama de coordinación normalmente tiene las unidades del tiempo con el Y-axis mostrando los objetos y sus estados. Los estados son normalmente cambiados por algún tipo de evento que causa el cambio de estado.

Los diagramas de coordinación pueden ser dibujados para una evaluación o un punto de vista basado en el tiempo. Ejemplo:

Diagrama de Coordinación basada en el tiempo.

Diagrama de Coordinación basada en la evaluación.

Algunas Palabras por Conocer.

Agregación: La agregación no es un concepto exclusivo de los lenguajes de programación orientados a objetos. En realidad, cualquier lenguaje que soporte estructuras similares a los registros soporta la agregación. Sin embargo, la combinación de herencia con agregación es potente: La agregación permite el agrupamiento físico de estructuras relacionadas lógicamente, y la herencia permite que estos grupos de aparición frecuente se utilicen con facilidad en diferentes abstracciones. La agregación plantea el problema de la propiedad.

Multiplicidad: En el análisis de los autómatas celulares lineales reversibles, debemos empezar por conocer las propiedades que cumplen los autómatas sin Jardín del Edén, es decir, donde toda secuencia tenga al menos un ancestro. Relacionado a esta idea, en el trabajo de Hedlund encontramos un concepto fundamental al cual él denomina Multiplicidad Uniforme.

La multiplicidad uniforme en un autómata celular reversible nos dice que cada cadena de estados tiene el mismo número de ancestros que las demás cadenas; y este número es igual al número de nodos del diagrama de de Bruijn.

Composición: Puede ser clasificado en dos partes: Componentes del Software Reusables y Componentes del Programa.

Componentes del Software Reusables. Un componente de software puede ser una estructura de datos (o base de datos) o un componente arquitectónico del software (es decir, un programa) o un componente procedimental (es decir, un módulo). En cada caso, el componente del software ha de haber sido diseñado de forma que facilite su reutilización sin necesidad de conocer los detalles de su funcionamiento interno.

Componentes del Programa. Un aspecto importante de la calidad del diseño es la modularidad- esto es, la especificación de componentes de programa (módulos) que, combinados, forman el programa completo. El enfoque orientado a los objetos define el objeto como componente de programa que se encuentra enlazado con otros componentes (por ejemplo: datos privados, operaciones). Pero la definición de objetos y operaciones no es suficiente. Durante el diseño, también debemos identificar las interfaces que existen entre los objetos y la estructura general (en sentido arquitectónico) de objetos.

Aunque un componente de programa es una abstracción de diseño, se puede representar dentro del contexto del lenguaje de programación que se va a utilizar para implementar el diseño.

Generalización: Es la amplitud de aplicación potencial de los componentes del programa. Denota una relación "es un" (is a)

Asociación: Existen tres actividades asociadas con este paso: La Especificación de Asociaciones, La Identificación de varias Colaboraciones y el Refinamiento de las Asociaciones.

Identificación de Asociaciones. Es principalmente una actividad de análisis y de diseño inicial.

Las asociaciones son semánticas débiles: sólo representan alguna suerte de dependencia semántica, el papel y cardinalidad de cada participante en la relación, y posiblemente una declaración de navegabilidad. Sin embargo, durante el análisis y el diseño inicial, esto es con frecuencia suficiente, por que captura suficientes detalles interesantes sobre la relación entre dos abstracciones, aunque nos previene de realizar declaraciones prematuras de diseño detallado.

Refinamiento de las Asociaciones. Es una actividad de análisis y de diseño. Durante el análisis, se pueden desplegar ciertas asociaciones en otras relaciones más precisas semánticamente para reflejar la comprensión creciente que se tiene del dominio del problema. Durante el diseño, se transforman análogamente asociaciones así como se añaden nuevas relaciones concretas con el fin de proporcionar un plano para la implementación.

Notas: Existen dos tipos de notaciones: Asociaciones Atribuidas y Notas, y Comparación de las Notaciones de Diseño.

Asociaciones Atribuidas y Notas. La solución rotacional a este problema específico se generaliza a un elemento de los diagramas que puede aplicarse a cualquier diagrama de la notación.

Asociaciones atribuidas y notas.

La propia idea de las asociaciones atribuidas tiene una generalización. Concretamente, durante el análisis y el diseño existe una cantidad muy grande de suposiciones y decisiones aparentemente aleatorias que puede recoger cada desarrollador; estas interioridades se pierden a menudo, por que no hay normalmente un lugar en el que recogerlas, excepto mantenerlas en la cabeza del desarrollador (práctica decididamente poco fiable). Así, es útil añadir notas arbitrarias a cualquier elemento del diagrama, cuyo texto capture estas asociaciones y decisiones.

Para tales notas, se usa un icono distintivo en forma de nota y se conecta al elemento al que afecta mediante una línea discontinua como la usada antes. Las notas, en gran medida una cuestión de herramientas, pueden contener cualquier información, incluyendo simple texto, fragmentos de código o referencias a otros documentos. Una nota puede estar sin conexión, lo que significa que se aplica al diagrama en su conjunto.

Comparación de las Notaciones de Diseño. Una notación de diseño debe conducir a una representación procedimental que sea fácil de comprender y revisar. Además, la notación debe facilitar la "codificación", de forma que el código se obtenga de hecho como un producto natural del diseño. Finalmente, la representación del diseño debe ser fácilmente mantenible, de forma que el diseño represente siempre correctamente el programa.

Las notaciones de diseño se componen de lo siguiente: Modularidad, Simplicidad Global, Facilidad de Edición, Legible por la máquina, Mantenimiento, Exigencia de Estructura, Procesamiento Automático, Representación de los Datos, Verificación Lógica y Disposición para la Codificación.

Estereotipos: Los ESTEREOTIPOS, son modelos (de comportamiento, de apariencia…) que se fijan para los miembros de una determinada colectividad. Los valores de una sociedad se traducen en estereotipos modélicos que sustentan las ideologías o intereses dominantes.

Microsoft Visio

¿Qué es Microsoft Visio?

Visio es un programa inteligente de creación de diagramas. Sí, le permite comunicar ideas de una forma visual. Pero Visio también proporciona varias características que hacen que sus diagramas tenga más sentido, sean más flexibles y estén más en consonancia con sus necesidades. Más que algo que fotocopiar, puede captar información de otras maneras que sean valiosas para usted y para su negocio.

Visio crea diagramas. Eso significa que le permite poner en conexión una serie de cuadros y flechas, ¿no? Incorrecto. Visio ofrece mucho más.

Su Utilización.

Uno de los usos más comunes de Visio es ilustrar procesos empresariales. Los diagramas de procesos empresariales se encuentran tanto en Visio Standard como en Visio Professional. Aquí se incluye un ejemplo. Se trata de un diagrama de flujo que explica el proceso de desarrollo farmacéutico usado en una organización.

Diagrama de flujo.

Crear un diagrama como éste es bastante fácil. Las formas (en este ejemplo, los rectángulos incluidos en el diagrama de flujo) ya están preparados para que los pueda usar. Lo único que debe hacer es arrastrarlos hasta su ubicación, escribir texto en su interior y cambiar ligeramente su tamaño.

Algo más que resaltar: las líneas que unen las formas se denominan conectores. Los conectores se pegan fácilmente a las formas. Cuando se mueve una forma, también lo hace su conector.

Diagrama de flujo con un hipervínculo a información más detallada.

Éste es un ejemplo de lo poderosos que pueden ser los diagramas de Visio: si una parte de su diagrama requiere incluir información adicional, puede crear esa parte detallada por separado y agregar un hipervínculo a ella.

En este ejemplo se incluye un hipervínculo en la forma Ensayos. Haciendo clic en ella, el lector puede tener acceso a más detalles sobre ese paso concreto del proceso.

Ahora es buen momento de mencionar que otros programas de Microsoft Office como Microsoft PowerPoint® y Microsoft Word también le ayudan a crear diagramas. Sin embargo, esos programas no le ofrecen tantas posibilidades como Visio para trabajar con los diagramas. Tampoco incluyen tantas opciones sofisticadas crear y modificar los diagramas.

Cuando necesite un diagrama grande y detallado, Visio es el programa más adecuado. Pero si sólo necesita crear un diagrama modesto en un momento de prisa, puede utilizar su programa favorito de Office.

Un Organigrama.

Los organigramas, disponibles tanto en Visio Standard como en Visio Professional, son otro tipo de diagrama usado frecuentemente en las organizaciones. Aquí ofrecemos un ejemplo.

Por supuesto, las líneas y formas les permiten ver fácilmente la estructura de responsabilidades de una organización. Pero aquí es donde de verdad destaca Visio: también puede asociar datos con las formas que componen el diagrama. Los datos relacionados con una forma se denominan propiedades personalizadas.

En el caso de los organigramas, puede seleccionar una forma de empleado y asociar a ella información importante como su ubicación, número de teléfono y departamento, de manera que esta información también forme parte del organigrama.

Otro motivo importante para crear organigramas en Visio es que puede crearlos automáticamente usando información contenida en un origen de datos. Por ejemplo, puede basar un organigrama en una base de datos, en un libro de Microsoft Excel, o incluso en el sistema de correo electrónico de su organización (si utiliza Microsoft Exchange Server). Piénselo: con sólo hacer clic unas cuantas veces, el diagrama estará listo. No será necesario escribir manualmente los nombres y los puestos. Como ya se ha dicho, Visio es inteligente.

Diagrama de lluvia de ideas y su esquema correspondiente.

Los diagramas de lluvia de ideas, disponibles tanto en Visio Standard como en Visio Professional, pueden ayudarle a registrar y desarrollar cualquier conjunto de ideas relacionadas e información, como nuevas estrategias de negocios, esquemas de libros, actas de reunión o planes de viaje.

Hay dos formas de crear este tipo de diagramas:

Puede crear el diagrama visualmente arrastrando las formas hasta su lugar.

– o bien –

Puede crear el diagrama de forma automática, escribiendo un esquema en la ventana de esquema. De esta forma, Visio creará las formas automáticamente.

Nota: También puede importar un esquema de Word en Visio como diagrama de lluvia de ideas, o bien exportar un diagrama de lluvia de ideas de Visio como esquema de Word, lo que facilita enormemente replantear el trabajo.

Mapa de red.

Otro diagrama de organización que puede preparar con Visio Professional es un diagrama de red. Puede crear diagramas sencillos o muy detallados. Aquí ofrecemos una pequeña parte de un diagrama de red detallado.

Por supuesto, las formas de los equipos, los servidores, etc. ya están preparados en Visio. Piense el esfuerzo que supondría tener que dibujarlos usted mismo.

Además, si agrega propiedades personalizadas a cada forma (como el número de activo, la dirección de red o el nombre del equipo), puede preparar informes de inventario detallados, directamente en Visio.

Mapa de un sitio Web

Visio Professional también le ayuda a crear diagramas Web, como mapas de sitios Web. Cada una de las formas del mapa representa un vínculo de un sitio Web e incluye información sobre el tipo de vínculo y su ubicación. El mapa se puede utilizar para analizar la organización del sitio o para clasificar el contenido del mismo.

Y una demostración de lo poderoso e inteligente que es Visio: no es necesario que cree este diagrama manualmente. Puede utilizar una plantilla especial que le pregunta la dirección Web de su sitio. Visio abrirá su sitio Web, leerá el código, buscará todos los vínculos y generará el mapa automáticamente.

¿Qué es un Diagrama de Modelo UML?

Un Modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés. El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos.

Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete.

La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación. La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos, símbolos bidimensionales, rutas y cadenas.

Un icono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.

Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos. Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.

UML está compuesto por los siguientes diagramas:

Área	Vista	Diagramas	Conceptos Principales
Estructural	Vista Estática	Diagrama de Clases	Clase, asociación, generalización, dependencia, realización, interfaz.
	Vista de Casos de Uso	Diagramas de Casos de Uso	Caso de Uso, Actor, asociación, extensión, generalización.
	Vista de Implementación	Diagramas de Componentes	Componente, interfaz, dependencia, relaización.
	Vista de Despliegue	Diagramas de Despliegue	Nodo, componente, dependencia, localización.
Dinámica	Vista de Estados de máquina	Diagramas de Estados	Estado, evento, transición, acción.
	Vista de actividad	Diagramas de Actividad	Estado, actividad, transición, determinación, división, unión.
	Vista de interacción	Diagramas de Secuencia	Interacción, objeto, mensaje, activación.
	Vista de interacción	Diagramas de Colaboración	Colaboración, interacción, rol de colaboración, mensaje.
Administración o Gestión de modelo	Vista de Gestión de modelo	Diagramas de Clases	Paquete, subsistema, modelo.
Extensión de UML	Todas	Todos	Restricción, estereotipo, valores, etiquetados.

CONCLUSIONES

El Lenguaje de Modelado Unificado se podría decir que es una buena opción para el diseño y desarrollo de un software, ya que emplea muchos tipos de diagramas que son de gran utilidad, dependiendo de la situación y empleo del software. Es más utilizable para el Desarrollo de Software orientado a Objetos y en Proceso de Desarrollo de Software. Se usan notaciones gráficas e iconos para el empleo de los diagramas.

El Modelo se obtiene a partir de la observación de lo que está en el mundo real, a sus alrededores. El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo la información de viabilidad técnica para el sistema propuesto.

Hay varios tipos de modelos, como son: Funcionales, Objetos y Dinámicos; donde se involucran los diagramas del UML.

Existen varios softwares que se basan en el UML, que son herramientas desde Java hasta orientados a Objetos y Flash. Marcando opciones para todo tipo de programadores y/o usuarios.

Como todo producto de mercado, ha sido criticado por su falta de semántica precisa, por lo que muchos dicen que no puede ser objetiva. Sin embargo, a mi punto de vista, creo que lo más importante (y esencial) es que sea capaz de poder desarrollar, interpretar y diseñar un buen software, indicando los puntos buenos o malos del mismo.

Hasta ahora, sólo existen hasta la versión 2.0 del UML. Donde ha tenido una mejoría muy notable y con mayor facilidad de uso. Entre otras, la agregación de más tipos de diagramas.

Como tipos de diagramas del Lenguaje de Modelado Unificado, están: Diagramas de Clases, de Caso de Uso, de Interacción, de Estados, de Actividad, de Paquetes, de Componentes, de Despliegue, de Secuencia, de Colaboración, de Implementación, de Objetos, de Estructura Compuesta, de Comunicación, y de Coordinación. Todas éstas útiles, dependiendo del objetivo del software; muchos se parecen entre sí, pero cada quien tienen sus propias cualidades.

También se hablan de las palabras más usuales y utilizadas en el mundo de la informática, donde debemos tener el entendimiento y comprensión de su significado para poder emplear y desarrollar un sistema de software que cumplan con todas (por lo menos, la mayoría) de los requisitos y objetivos que el cliente espera del software.

Microsoft Visio es un paquete que emplea la creación y diseño de los diagramas, al cien por ciento de su capacidad. Es decir, que Microsoft Visio proporciona una amplia creatividad en el diseño de los diagramas, al igual que muchos tipos de diagramas que se pueden formular, desde un simple diagrama de flujo hasta un diagrama de lluvia de ideas con su esquema correspondiente, organigramas y mapas de sitios Web.

Una gran opción y oportunidad para el empleo de los diagramas, organigramas y mapas; todo esto permite diseñar de una forma excelente donde podrás notar los puntos buenos y las partes erróneas o complejas donde se necesite llevar mayor atención y mejorar la estructura.

La utilización de los diagramas de UML emplea, por lo general, grafos e iconos que contienen formas de conexión con sus rutas. La información importa más en su topología y no tanto por el tamaño o colocación de los símbolos, y que existen 3 tipos importantes de relaciones visuales: Conexión, Contención y Adhesión Visual. Los diagramas se emplean más que nada de forma bidimensional, podrán representarse las formas tridimensionales en bidimensionales, pero no pueden ser tridimensionales.

Existen cuatro tipos de construcciones gráficas: Iconos, Símbolos Bidimensionales, Rutas, y Cadenas.

Creo que tenemos a la mano muchas herramientas que podrán ser de gran utilidad para formar un buen software u otro diseño que se basen en los gráficos y diagramas, no tienen qué ser precisamente sobre la informática. Cada día la tecnología va incrementando muy velozmente, y cada vez habrá mejores y mayores opciones de herramientas para satisfacer las necesidades personales y empresariales que llegarán a ser inimaginables. Pero por ahora, hay muy buenas opciones y que debemos tomarlas para mejorar el futuro de nuestra profesión y de las empresas.

GLOSARIO

UML: Proviene de las siglas en inglés, "Unified Modelling Language" (Lenguaje de Modelo Unificado). El UML ofrece un estándar para escribir un "plano" del sistema, incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

Rational: Empresa basada en el Desarrollo del Software, en E. U. A.

World Wide Web: Conocido como WWW (Red del Mundo Entero), sistema de acceso y búsqueda en la Internet.

Facto: De hecho.

OMG: Proviene de las siglas en inglés Object Management Group. Define una notación gráfica para los casos de uso, pero se abstiene de definir algún formato escrito para describir la funcionalidad de los casos de uso en detalle; debido a esto algunas personas tienen el concepto erróneo acerca de que un caso de uso es su notación gráfica, cuando es la descripción escrita de escenarios la que da el verdadero valor al caso de uso.

Status: Estado actual de una situación.

Iteraciones: Cualquiera de las acciones realizadas por un bucle en el desarrollo de u programa.

Transición: Cambio de un estado a otro.

Particiones: División.

Blanking: Proviene de la palabra inglés que significa "Extinción". Éste término se refiere al hecho de no encenderse un carácter sobre el monitor de visualización, lo que puede suceder por muy diversos motivos.

Abstracción: Considerar aparte las cosas unidas entre sí.

Contexto: Conjunto de circunstancias en las que se sitúa un hecho.

Hipervínculo: Dícese de un programa secundario que asegura el enlace entre dos programas principales.

Web: Sistema de acceso y búsqueda en la Internet.

Semántico: Relativo a la significación de las palabras.

BIBLIOGRAFÍA

Libros:

Booch G.

1996.

2° Edición.

Editorial Adison Wesley Longman.

Análisis y Diseño Orientado a Objetos con Aplicaciones.