Lenguaje unificado de modelado
Lenguaje
Unificado de Modelado (UML,
por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de
sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management
Group).
Es un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema. UML
ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
Es importante
remarcar que UML es un "lenguaje de modelado" para especificar o para
describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras,
es el lenguaje en el que está descrito el modelo.
Se puede aplicar
en el desarrollo de software gran variedad de formas para dar soporte a una
metodología de desarrollo de software (tal como el Proceso Unificado Racional
o RUP),
pero no especifica en sí mismo qué metodología o proceso usar.
CARACTERISTICAS DEL UML
UML debe entenderse como:
- Un estándar para modelado de sistemas.
- No es un estándar para procesos de software.
- Debe aplicarse en el contexto de un proceso de software.
Es una notación, no es un proceso.
Establecido como estándar para documentar el proceso de ingeniería de software.
Combina lo mejor del modelado de procesos, objetos, datos y componentes.
- Un estándar para modelado de sistemas.
- No es un estándar para procesos de software.
- Debe aplicarse en el contexto de un proceso de software.
Es una notación, no es un proceso.
Establecido como estándar para documentar el proceso de ingeniería de software.
Combina lo mejor del modelado de procesos, objetos, datos y componentes.
LOS PRINCIPALES BENEFICIOS DE UML SON:
Mejores tiempos
totales de desarrollo (de 50 % o más).
Modelar sistemas (y
no sólo de software) utilizando conceptos orientados a objetos.
Establecer
conceptos y artefactos ejecutables.
Encaminar el
desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje
de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la
planeación y al control de proyectos.
Alta reutilización
y minimización de costos.
Casos de Uso (Use Case)
Introducción
El diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Elementos
Una definición
previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa
a una persona en particular, sino más bien la labor que realiza frente al
sistema.
Como ejemplo a la
definición anterior, tenemos el caso de un sistema de ventas en que el rol de
Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por
el Jefe de Local.
Es una
operación/tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde
otro caso de uso.
- Relaciones:
- Asociación
Es el tipo de
relación más básica que indica la invocación desde un actor o caso de uso a
otra operación (caso de uso). Dicha relación se denota con una flecha simple.
- Dependencia o Instanciación
Es una forma muy
particular de relación entre clases, en la cual una clase depende de otra, es
decir, se instancia (se crea). Dicha relación se denota con una flecha
punteada.
- Generalización
Este tipo de relación
es uno de los más utilizados, cumple una doble función dependiendo de su
estereotipo, que puede ser de Uso (<<uses>>) o
de Herencia (<<extends>>).
Este tipo de relación
esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características
que son similares en más de un caso de uso y no se desea mantener copiada la
descripción de la característica.
De lo anterior cabe
mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en
donde esta la duda clásica de usar o heredar.
Ejemplo:
Como ejemplo esta el caso de una
Máquina Recicladora:
Sistema que controla una máquina de
reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o
aceptar:
- Registrar el número de ítemes ingresados.
- Imprimir un recibo cuando el usuario lo
solicita:
a.
Describe lo depositado
b.
El valor de cada item
c.
Total
- El usuario/cliente presiona el botón de
comienzo
- Existe un operador que desea saber lo
siguiente:
a.
Cuantos ítemes han sido retornados en el día.
b.
Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
- El operador debe además poder cambiar:
a.
Información asociada a ítemes.
b.
Dar una alarma en el caso de que:
i.
Item se atora.
ii.
No hay más papel.
Como una primera aproximación
identificamos a los actores que interactuan con el sistema:
Luego, tenemos que un Cliente puede
Depositar Itemes y un Operador puede cambiar la información de un Item o bien
puede Imprimir un informe:
Además podemos notar que un item puede
ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de
comprobantes, que puede ser realizada después de depositar algún item por un
cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del
diagrama Use Case es:
Diagrama de casos de uso
En el Lenguaje de Modelado Unificado, un diagrama
de casos de uso es una
forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación
gráfica para
representar casos de uso llamada modelo de casos de uso. UML no define
estándares para que el formato escrito describa los casos de uso, y
así mucha gente no entiende que esta notación gráfica define la naturaleza de
un caso de uso; sin embargo una notación gráfica puede solo dar una vista
general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras
los dos conceptos están relacionados, los casos de uso son mucho más detallados
que los diagramas de casos de uso. En los conceptos se debe detallar más de un
caso de uso para poder identificar qué es lo que hace un caso de uso.
·
La
descripción escrita del comportamiento del sistema al afrontar una tarea
de negocio o un requisito
de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios humanos u
otros sistemas.
·
La
posición o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organización, un conjunto de casos de uso coherentes y
consistentes promueven una imagen fácil de comprender del comportamiento del
sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo
de desarrollo.
En esta
práctica es común crear especificaciones suplementarias para capturar detalles
de requisitos que caen fuera del ámbito de las descripciones de los casos de
uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento,
temas de escalabilidad/gestión, o cumplimiento de estándares.
El
diagrama describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por
elipses y los actores están, por
ejemplo, los casos de uso se muestran como parte del sistema que está siendo
modelado, los actores no.
La
interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción
coherente del comportamiento deseado, quizás los límites del sistema o del caso
de uso deban de ser re-examinados. Alternativamente, la interacción entre
actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo,
los actores son una especie de rol, un usuario humano u otra entidad externa
puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser
realmente la misma persona.
Relaciones de
Casos de Uso
Las tres relaciones principales
entre los casos de uso son soportadas por el estándar UML, el cual describe
notación gráfica para esas relaciones. Veamos una revisión de ellas a
continuación:
Inclusión
(include )
Es una forma de interacción o
creación, un caso de uso dado puede "incluir" otro caso de uso. El
primer caso de uso a menudo depende del resultado del caso de uso incluido.
Esto es útil para extraer comportamientos verdaderamente comunes desde
múltiples casos de uso a una descripción individual (si el actor realiza el
caso de uso base tendrá que realizar también el caso de uso incluido), desde el caso de uso. El
estándar de Lenguaje de Modelado
Unificado de OMG define
una notación gráfica para realizar diagramas de casos de uso, pero no el
formato para describir casos de
uso. Mucha gente sufre la equivocación pensando que un caso de uso
es una notación gráfica (o es su descripción). Mientras la notación gráfica y
las descripciones esto no sirve.
Extensión
(extend)
Es otra forma de interacción,
un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el
comportamiento del caso de la extensión se utiliza en casos de uso, un caso de
uso a otro caso siempre debe tener extensión o inclusión. El caso de uso
extensión puede ser insertado en el caso de uso extendido bajo ciertas
condiciones. La notación, es una flecha de punta abierta con línea discontinua,
desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser
útil para lidiar con casos especiales, o para acomodar nuevos requisitos
durante el mantenimiento del sistema y su extensión.
Generalización
"Entonces la Generalización es la
actividad de identificar elementos en común entre conceptos y definir las
relaciones de una superclase (concepto general) y subclase (concepto
especializado). Es una manera de construir clasificaciones taxonómicas entre
conceptos que entonces se representan en jerarquías de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en cuanto a la
intención y extensión."
Diagrama de clases
Ejemplo de diagrama de clases de una Universidad.
En ingeniería
de software, un diagrama de clases en Lenguaje
Unificado de Modelado (UML) es
un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o
métodos), y las relaciones entre los objetos.
Miembros
UML proporciona mecanismos para
representar los miembros de la clase, como atributos y métodos, así como
información adicional sobre ellos.
Visibilidad
Para especificar la visibilidad
de un miembro de la clase (es decir, cualquier atributo o método), se coloca
uno de los siguientes signos delante de ese miembro:
+ |
Público
|
- |
Privado
|
# |
Protegido
|
/ |
Derivado (se puede combinar con
otro)
|
~ |
Paquete
|
Ámbitos
UML especifica dos tipos de
ámbitos para los miembros: instancias y clasificadores y estos últimos se representan con nombres subrayados.
·
Los miembros clasificadores se denotan comúnmente como “estáticos”
en muchos lenguajes de programación. Su ámbito es la propia clase.
·
Los valores de los atributos son los mismos en todas las
instancias
·
La invocación de métodos no afecta al estado de las instancias
·
Los miembros instancias tienen como ámbito una instancia
específica.
·
Los valores de los atributos pueden variar entre instancias
·
La invocación de métodos puede afectar al estado de las
instancias(es decir, cambiar el valor de sus atributos)
Para indicar que un miembro
posee un ámbito de clasificador, hay que subrayar su nombre. De lo contrario,
se asume por defecto que tendrá ámbito de instancia.
Los diagramas de objetos representan las instancias de su proyecto de
desarrollo
Los diagramas de objetos de UModel 2016 representan un único
ejemplo de una clase y se utilizan para ilustrar un punto de datos en su
aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia,
UModel le permite asignar una clase ya existente representada por la instancia.
UModel ofrece automáticamente al objeto instancias de las propiedades
pertinentes desde la clase y el usuario puede insertar valores de muestras para
el objeto.
Los diagramas de objetos UML utilizan una notación similar a los diagramas de clases y se utilizan para
ilustrar una instancia de una clase en un momento dado. Imagine que desea
dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de
sus relaciones.
Los diagramas de objetos
pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante
el proceso de planificación de clases o para ayudar a partes interesadas para
quienes los diagramas de clases sean demasiado abstractos.
Puesto que los diagramas
de objetos utilizan notaciones muy similares a los diagramas de clases, la
barra de herramientas de diagramas de objetos usan algunos de los iconos de la
barra de herramientas de diagramas de clases. Para editar los atributos y
valores de un objeto puede utilizar la barra de herramientas, el diálogo de propiedades
o editarlos directamente en el diagrama.
Resumen
Lenguaje
Unificado de Modelado (UML,
por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de
sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG (Object
Management Group).
Se puede aplicar
en el desarrollo de software gran variedad de formas para dar soporte a una
metodología de desarrollo de software (tal como el Proceso Unificado Racional
o RUP),
pero no especifica en sí mismo qué metodología o proceso usa
METODOLOGÍA RUP.
Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y
se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML,
constituye
la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su
realización.
Se centra en la producción y mantenimiento de modelos del sistema.
Principales características
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado
en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del
proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que
desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles
a lo largo del proceso).
CICLO DE VIDA
elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la
arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.
2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten
definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación
de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la
solución preliminar.
3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello
se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el proyecto.
4. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar
a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con
las especificaciones entregadas por las personas involucradas en el proyecto.
Para obtener un máximo control de variables que conlleva un desarrollo de aplicaciones
http://es.slideshare.net/cristianbenites01/metodologia-rup-56188195