Ingeniería del Software

Enviado por Laura Marthé Hinojosa Castillo

Lenguaje Unificado de
Modelado
¿Qué es
UML?
¿Qué es un
Modelo?
Tipos de
Modelo
Software Libre para Modelado
en UML
Estandarización de
UML
Su
Utilización
El
Surgimiento
Diagramas de Modelado
UML
Diagramas de Casos de
Uso
Diagramas de
Interacción
Diagramas de
Estados
Diagramas de
Actividad
Diagramas de
Paquetes
Diagramas de
Componentes
Diagramas de
Despliegue
Diagramas de
Secuencias
Diagramas de
Colaboración
Diagramas de
Implementación
Diagramas de
Objetos
Diagramas de Estructura
Compuesta
Diagramas de
Comunicación
Diagramas de
Coordinación
Algunas Palabras por
Conocer
Microsoft
Visio
¿Qué es un
Diagrama de Modelo de UML?
Conclusiones
Glosario
Bibliografía

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.