LENGUAJE MODIFICADO DE MODELADO(UML)

DEFINICIÓN
Este es un lenguaje de programación que se utiliza para el desarrollo de software
orientado a objetos. Para organizar el código del programa de manera más eficiente,
los programadores a menudo crean "objetos" que son conjuntos de datos
estructurados dentro de los programas. UML, que ha sido estandarizado por el
Object Management Group (OMG), fue diseñado para este propósito. El lenguaje
ha obtenido suficiente soporte como para convertirse en un lenguaje estándar para
visualizar y construir programas de software.

CARACTERÍSTICAS
• Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software
las herramientas para el análisis, el diseño y la implementación de sistemas
basados en software, así como para el modelado de procesos de negocios y
similares.
• Hacer progresar el estado de la industria permitiendo la interoperabilidad de
herramientas de modelado visual de objetos. No obstante, para habilitar un
intercambio significativo de información de modelos entre herramientas, se
requiere de un acuerdo con respecto a la semántica y notación.
UML cumple con los siguientes requerimientos:
• Establecer una definición formal de un metamodelo común basado en el
estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del
UML. La sintaxis abstracta define el conjunto de conceptos de modelado
UML, sus atributos y sus relaciones, así como las reglas de combinación de
estos conceptos para construir modelos UML parciales o completos.
• Brindar una explicación detallada de la semántica de cada concepto de
modelado UML. La semántica define, de manera independiente a la
tecnología, cómo los conceptos UML se habrán de desarrollar por las
computadoras.
• Especificar los elementos de notación de lectura humana para representar
los conceptos individuales de modelado UML, así como las reglas para
combinarlos en una variedad de diferentes tipos de diagramas que
corresponden a diferentes aspectos de los sistemas modelados.
• Definir formas que permitan hacer que las herramientas UML cumplan con
esta especificación. Esto se apoya (en una especificación independiente) con
una especificación basada en XML de formatos de intercambio de modelos
correspondientes (XMI) que deben ser concretados por herramientas
compatibles.
 VENTAJAS

Legibilidad y Reutilización
Un diagrama UML es beneficioso, ya que es muy fácil de leer. El diagrama está
destinado a ser comprendido por cualquier tipo de programador y ayuda a explicar
las relaciones en un programa de una manera directa. Tradicionalmente, para
entender un programa, un programador podría leer el código directamente. Esto
podría ser de miles o millones de líneas de código en programas muy grandes.
Tener un diagrama UML ayuda a ilustrar rápidamente esas relaciones. Además,
mediante el uso de un diagrama para mostrar el código que se ejecuta en un
programa, un programador es capaz de ver el código redundante y porciones de
reutilización de código que ya existe en lugar de volver a escribir esas funciones.
Estándar
UML es el estándar actual para la programación en lenguajes de programación
orientados a objetos. Al crear clases y otros objetos con relaciones entre sí, UML es
lo que se utiliza para describir visualmente estas relaciones. Debido a que se utiliza
como un estándar, es ampliamente conocido y bien conocido. Esto hace que sea
fácil para un nuevo programador al paso en un proyecto y ser productivo desde el
primer día.
Planning Tool
UML ayuda a planear un programa antes de la programación se lugar. En algunas
de las herramientas utilizadas para modelar UML, la herramienta va a generar
código basado en las clases establecidas en el modelo. Esto puede ayudar a reducir
los gastos en la etapa de ejecución de cualquier programa. Además, un diagrama
de modelo UML es fácil de cambiar, mientras que la reprogramación de una sección
de código puede ser tedioso y consume mucho tiempo.

COMPONENTES Y TIPOS
Diagrama de casos de uso
Los diagramas de casos de uso describen las relaciones y las dependencias entre
un grupo de casos de uso y los actores que participan en el proceso.
Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros
usuarios del sistema y con el cliente, y resultan de especial interés para determinar
las funciones que debe poseer el sistema. Los diagramas de casos de uso
revelan qué debe hacer el sistema, pero no (ni pueden especificar) cómo deben
hacerlo.
Caso de uso
Un caso de uso describe (desde el punto de vista de los actores) un grupo de
actividades en un sistema que produce un resultado concreto y tangible.
Los casos de uso son descripciones de las interacciones típicas entre los usuarios
de un sistema y el mismo sistema. Representan la interfaz externa del sistema y
especifican una forma de los requisitos que el sistema debe cumplir (recuerde, solo
lo que debe hacer, no cómo debe hacerlo).
Los casos de uso también pueden tener relaciones con otros casos de uso. Los tres
tipos más frecuentes de relaciones entre casos de uso son:
• <<inclusión>>, que indica que un caso de uso tiene lugar dentro de otro caso
de uso.
• <<extensión>>, que indica que en cierta situación o en algún punto
(denominado punto de extensión), un caso de uso será extendido por otro.
• Generalización, que indica que un caso de uso hereda las características de
otro «supercaso de uso» y puede redefinir algunas de ellas o añadir otras
nuevas de un modo similar a la herencia entre clases.
Actor
Un actor es una entidad externa (situada fuera del sistema) que interactúa con el
sistema participando en (y a menudo iniciando) un caso de uso. Los actores pueden
ser personas de la vida real (por ejemplo, los usuarios del sistema), sistemas de
computadoras o eventos externos.
Los actores no representan a personas físicas ni a sistemas, sino a su rol. Esto
significa que cuando una persona interactúa con el sistema de formas distintas
(asumiendo diferentes roles), estará representada por varios actores.
Descripción del caso de uso
Las descripciones de los casos de uso son narraciones textuales de los mismos.
Suelen adoptar la forma de una nota o de un documento enlazado de algún modo
con el caso de uso y explican los procesos o las actividades que tienen lugar en el
caso de uso.
Diagrama de clase
Los diagramas de clase muestran las distintas clases que componen un sistema y
cómo se relacionan entre sí. Se dice que los diagramas de clase son «estáticos»
porque muestran las clases, junto a sus métodos y atributos, así como las relaciones
estáticas entre ellos: qué clases «conocen» a otras clases, o qué clases «son parte»
de otra clase, aunque no muestran las llamadas a los métodos entre ellas.
Clase
Una clase define los atributos y los métodos de un conjunto de objetos. Todos los
objetos de una clase (instancias de la clase) comparten el mismo comportamiento
y poseen el mismo conjunto de atributos (cada objeto tiene su propio conjunto). A
veces se usa el término «tipo» en lugar de «clase», pero es importante tener
presente que no son lo mismo, ya que «tipo» es un término más general.
Atributos
En UML, los atributos se muestran como mínimo con su nombre, aunque también
pueden mostrar su tipo, su valor inicial y otras propiedades. Los atributos también
se pueden mostrar con su visibilidad:
• + representa atributos públicos
• # representa atributos protegidos
• - representa atributos privados
Operaciones
Las operaciones (métodos) también se muestran como mínimo con su nombre,
aunque pueden mostrar también sus parámetros y los tipos que devuelven. Las
operaciones pueden, al igual que los atributos, mostrar su visibilidad:
• + representa operaciones públicas
• # representa operaciones protegidas
• - representa operaciones privadas
Plantillas
Las clases pueden tener plantillas, un valor que se usa para una clase o un tipo sin
especificar. El tipo de la plantilla se especifica cuando se inicia la clase (es decir,
cuando se crea un objeto).
Asociaciones de clases
Las clases se pueden relacionar (estar asociadas) con otras de diferentes modos:
Generalización
La herencia es uno de los conceptos fundamentales de la programación orientada
a objetos, en la que una clase «gana» todos los atributos y las operaciones de la
clase de la que hereda, y puede redefinir o modificar algunos de ellos, así como
añadir más atributos y operaciones propios.
Asociaciones
Una asociación representa una relación entre clases, y proporciona la semántica y
estructura común para muchos tipos de «conexiones» entre objetos.
Las asociaciones son el mecanismo que permite que los objetos se comuniquen
entre sí. Describe la conexión entre diferentes clases (la conexión entre objetos
reales se denomina «conexión de objetos» o enlace).
Agregación
Una agregación es un tipo especial de asociación en la que las dos clases
participantes no poseen un estado de igualdad, aunque forman una relación
«completa». Una agregación describe cómo la clase que tiene el papel del todo se
compone de otras clases (las posee), que tienen el papel de las partes. Para las
agregaciones, las clases que actúan como el todo siempre tienen una multiplicidad
de uno.
Composición
Las composiciones son asociaciones que representan agregaciones muy fuertes.
Esto significa que las composiciones también forman relaciones todo-parte, aunque
la relación es tan fuerte que las partes no pueden existir por sí mismas: solo pueden
existir dentro del todo y, si el todo se destruye, las partes también se destruirían.
Otros elementos de los diagramas de clases
Los diagramas de clases pueden contener otros elementos distintos las clases.
Interfaces
Las interfaces son clases abstractas, lo que significa que no se pueden crear
directamente instancias de ellas. Pueden contener operaciones, pero no atributos.
Las clases pueden heredar de interfaces (mediante una asociación de realización),
en cuyo caso se pueden hacer instancias de estos diagramas.
Tipo de datos
Los tipos de datos son primitivos que se suelen integrar en los lenguajes de
programación. Ejemplos típicos son los enteros y los booleanos. No pueden tener
relaciones con las clases, aunque las clases sí pueden tener relaciones con ellos.
Enumeraciones
Una enumeración es una simple lista de valores. Un ejemplo típico es una
enumeración de los días de la semana. Las opciones de una enumeración se llaman
«literales de enumeración». Como los tipos de datos, no pueden tener relaciones
con las clases, aunque las clases sí pueden tener relación con ellas.
Paquetes
Los paquetes representan un espacio de nombres de un lenguaje de programación.
Se usan en los diagramas para representar partes de un sistema que contienen más
de una clase (posiblemente cientos de clases).
Diagramas de secuencia
En los diagramas de secuencia, los objetos se representan mediante líneas
discontinuas verticales con el nombre de los objetos en la parte superior. El eje del
tiempo también es vertical, incrementándose hacia abajo, de modo que los
mensajes se envían de un objeto a otro en forma de flechas, con el nombre de la
operación y los parámetros.
Diagramas de colaboración
Los diagramas de colaboración muestran las interacciones que ocurren entre los
objetos que participan en una determinada situación. Esta es más o menos la misma
información que muestran los diagramas de secuencia, aunque en ellos el énfasis
recae en cómo ocurren las interacciones con el paso del tiempo, mientras que los
diagramas de colaboración ponen de relieve las relaciones entre los objetos y su
topología.
Diagrama de estados
Los diagramas de estados muestran los diferentes estados de un objeto durante su
vida y los estímulos que hacen que el objeto cambie su estado.
Los diagramas de estados ven los objetos como máquinas de estados o autómatas
finitos que pueden estar en uno de un conjunto finito de estados y que pueden
cambiar su estado mediante uno de un conjunto finito de estímulos. Por ejemplo, un
objeto de tipo ServidorDeRed puede estar en uno de los siguientes estados durante
su vida:
• Preparado
• A la escucha
• Trabajando
• Detenido
y los eventos que pueden hacer que el objeto cambie de estado son
• El objeto se ha creado
• El objeto recibe un mensaje de escucha
• Un cliente solicita una conexión a través de la red
• Un cliente termina una petición
• La petición se ejecuta y termina
• El objeto recibe un mensaje de detención
Estado
Los estados son las piezas fundamentales de los diagramas de estado. Un estado
pertenece a exactamente una clase y representa un resumen de los valores que
pueden tener los atributos de una clase. Un estado de UML describe el estado
interno de un objeto de una determinada clase.
Diagrama de actividades
Los diagramas de actividades describen la secuencia de actividades de un sistema
con la ayuda de actividades. Los diagramas de actividades son una forma especial
de los diagramas de estados que solo (o principalmente) contienen actividades.
Actividad
Una actividad es un paso único de un proceso. Una actividad es un estado de un
sistema con actividad interna y, al menos, una transición de salida. Las actividades
también pueden tener más de una transición de salida si poseen distintas
condiciones.
Elementos auxiliares
Existen varios elementos en UML que no poseen un valor semántico real para el
modelo, sino que ayudan a clarificar partes del diagrama. Estos elementos son:
• Líneas de texto
• Notas de texto y anclajes
• Cuadros
Las líneas de texto son útiles para añadir cortas informaciones de texto a un
diagrama. Son textos libres y no poseen ningún significado para el modelo.
Las notas son útiles para añadir información más detallada sobre un objeto o sobre
una situación determinada. Tienen la gran ventaja de que se pueden asociar a
elementos de UML para mostrar que la nota «pertenece» a un determinado objeto
o situación.
Los cuadros son rectángulos libres que se pueden usar para agrupar elementos
para facilitar la legibilidad de los diagramas. No poseen ningún significado lógico en
el modelo.
Diagramas de componentes
Los diagramas de componentes muestran los componentes de software (ya sean
tecnologías de componentes, como KParts, CORBA o Java Beans, o solo secciones
de un sistema que se puedan distinguir claramente) y los artefactos de los que se
componen, como archivos de código fuente, bibliotecas de programación o tablas
de bases de datos relacionales.
Diagramas de despliegue
Los diagramas de despliegue muestran las instancias de los componentes en
tiempo de ejecución y sus asociaciones. Incluyen nodos, que son recursos físicos.
Diagramas entidad-relación
Los diagramas entidad-relación (diagramas ER) muestran el diseño conceptual de
aplicaciones de bases de datos. Describen las distintas entidades (conceptos) del
sistema de información y las relaciones y restricciones existentes entre ellos. Una
extensión de los diagramas entidad-relación, denominada «diagramas entidad-
relación extendidos» o «diagramas entidad-relación avanzados» (EER), se usa para
incorporar técnicas de diseño orientadas a objetos en los diagramas ER.
Entidad
Una entidad es cualquier concepto del mundo real con una existencia
independiente. Puede ser un objeto con una existencia física (por ejemplo, una
computadora o un robot) o un objeto con una existencia conceptual (por ejemplo,
un curso universitario). Cada entidad posee un conjunto de atributos que describen
sus propiedades.
Atributos de las entidades
En los diagramas ER, los atributos de las identidades se muestran con su nombre
en un compartimento distinto de la entidad a la que pertenecen.
Restricciones
Las restricciones de los diagramas ER indican las restricciones de los datos en el
esquema de información.
• Clave primaria: El conjunto de atributos declarado como clave primaria es
único para la entidad. Solo puede existir una clave primaria en una entidad y
ninguno de los atributos que la constituyen puede ser nulo.
• Clave única: El conjunto de atributos declarado como clave única es único
para la entidad. Pueden existir varias restricciones únicas en una entidad.
Los atributos que la constituyen pueden ser nulos. Las claves únicas y las
claves primarias identifican unívocamente una fila de una tabla (entidad).
• Clave externa: Una clave externa es una restricción referencial entre dos
tablas. La clave externa identifica a una columna o a un conjunto de columnas
de una tabla que hacen referencia a una columna o a un conjunto de
columnas de otra tabla. Las columnas de la tabla referenciada deben formar
una clave primaria o una clave única.
• Restricción de comprobación: Una restricción de comprobación (también
conocida como «restricción de comprobación de tabla») es una condición
que define datos válidos cuando se añade o se actualiza una entrada de un
a tabla de una base de datos relacional. Se aplica una restricción de
comprobación a cada rila de la tabla. La restricción debe ser un predicado.
Se puede referir a una o a varias columnas de la tabla.
Conceptos de diagramas entidad-relación extendidos (EER)
Especialización
La especialización es un modo de formar nuevas entidades usando entidades ya
definidas. Las nuevas entidades, conocidas como entidades derivadas, poseen (o
heredan) los atributos de las entidades preexistentes, a las que se refieren como
entidades base. Están pensadas para ayudar a reutilizar los datos existentes con
pocas o ningunas modificaciones.
Especialización de disyunción
La especialización de disyunción indica que las subclases de la especialización
deben ser disyuntivas. Esto significa que una entidad puede ser miembro de un
máximo de una de las entidades derivadas de la especialización.
Especialización de solapamiento
Cuando las entidades derivadas no están restringidas para ser disyuntivas, se dice
que su conjunto de entidades está en una especialización de solapamiento. Esto
significa que la misma entidad del mundo real puede ser miembro de más de una
entidad derivada de la especialización.
Categoría
Se dice que una entidad derivada es una categoría cuando representa a una
colección de objetos que es un subconjunto de la unión de los distintos tipos de
entidades. Una categoría se modela cuando existe la necesidad de una relación de
una superclase/subclase con más de una superclase, donde las superclases
representan distintos tipos de entidades (muy parecido a la herencia múltiple de la
programación orientada a objetos).