Introducción

El fin de este manual es mostrar de forma clara la utilidad del lenguaje UML en escenarios
informáticos.

UML es un lenguaje visual y estándar que sirve para modelar procesos y sistemas de
información.

El desarrollo de software está basado en la construcción de aplicaciones que sirven para

automatizar procesos informáticos.

Existen diferentes entes que intervienen en el desarrollo de software, como los son los usuarios
finales de las aplicaciones, los dueños de procesos y por otro lado el equipo que desarrolla las
aplicaciones entre los que existen diferentes perfiles como los desarrolladores, analistas,
arquitectos y gerentes de proyecto. La lógica de negocio es conocida por los usuarios finales y
dueños de proceso pero no por el equipo de desarrollo y es aquí donde nos es muy útil el
lenguaje UML.

Como su definición lo indica el UML busca modelar estos procesos de forma tal que los
usuarios y los desarrolladores definan un proceso en un mismo lenguaje más universal
acordando distancias entre los deseables y el producido. Esta no es la única ventaja de modelar
los procesos en UML.

Los usuarios finales definen de forma clara el proceso que los involucra pudiendo encontrar
errores en los proceso por embotellamiento, sobrecargas de trabajo en recursos en otros.

Los arquitectos de software y los analistas pueden definir unas bases claras y robustas
previendo comportamientos y funcionalidades desde la etapa inicial.

Los gerentes de proyectos pueden tener definidas las actividades de forma clara minimizando el
desfase en sus cronogramas.

La documentación del proyecto se define de forma inmediata a partir de los diagramas UML.

Ahora empecemos con la explicación del lenguaje UML.

Por jose

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 y funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y componentes reutilizables.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

Diagrama de clases:

Es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y
las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño
de los sistemas, donde se crea el diseño conceptual de la información que se manejará.

- Atributos
- Métodos
- Relaciones:
1. Composición
2. Agregación
3. Asociación
4. Dependencia

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

ELEMENTOS DE CONSTRUCCIÓN

Para modelar procesos por medio de UML es necesario realizar diferentes diagramas los cuales
a su vez están compuestos de objetos y relaciones de los mismos.

· Objetos
· Relaciones
· Diagramas

Objetos
Todo lo que componen los diagramas son objetos y podemos dividirlo en:

· Estructurales: Clases, Interfaces, Tablas.

· Comportamiento: Estado, secuencia, Actividades.
· Agrupación: Paquetes.
· Anotación: notas, relaciones.

Relaciones
Una relación es la forma en que interactúan los objetos.
 · Asociación: Relación de objetos de estructura, por ejemplo una tabla está relacionada
con otra.

· Asociación direccionada: Relación de objetos especifica la dirección de la relación.

· Dependencia: Afecta la semántica del objeto dependiente. Esto se refiere a agregar o

modificar el comportamiento de otro objeto.

· Agregación: Parte de un todo. Un objeto está compuesto parcialmente por otro.

· Composición: Parte única de un todo. Un objeto está compuesto en su totalidad por

otro.

· Herencia: Generalización. Un objeto tiene comportamientos y propiedades

generalizados de otro.

· Realización: Un objeto realiza o complace la acción de otro.

Diagramas
Los diagramas sirven para modelar estructuras y comportamientos.

· Estructúrales: Estos diagramas sirven para modelar clases, interfaces, objetos, bases
de datos, etc.
· Comportamental: Busca definir el comportamiento “el como y quien” workflows,
transacciones, etc.

Existen muchos diagramas contenidos en estas dos ramas pero el UML no es una camisa de
fuerza que obligue a la creación de diagramas, simplemente se crean los diagramas que se
creen necesarios para modelar un proceso en especifico por lo que un sistema puede tener
algunos diagramas y otro sistema puede tener otros, la idea es especificar el proceso sin
importar la cantidad o los tipos de diagramas.

Estructúrales
· Paquetes: Representan contenedores de otros objetos por ejemplo los NameSpace de
.Net o librerías en otros lenguajes.
· Clases: Diagramas que contienen los tipos de objetos existentes asi como sus
atributos, propiedades, métodos, etc.
· Objetos: Diagramas de clases instanciadas con nombres propios como los perfiles o
usuarios de una aplicación.
 · Datos: Diagrama de la base de datos.
· Componentes: Diagramas que modelen los componentes que conforman una
aplicación dll’s, etc.
· Despliegue: Como está distribuida una solución en un entorno, por ejemplo el servicio
A esta en el servidor B.

Comportamental

· Casos de uso: Este diagrama busca definir que funcionalidades puede usar un
usuario.
· Actividades: Diagrama que especifica el flujo de un proceso.
· Estado: Este diagrama modela los posibles estados de un objeto a partir de unos
eventos o situaciones.
· Secuencia: Muestra la acciones realizadas a través del tiempo.
· Colaboración: Quien y como se realiza un caso de uso

Casos de uso
Los casos de uso los realiza un usuario y pueden tener varios escenarios simples, básicos o
alternos los cuales a su vez son realizados por una colaboración.

Ejemplo:

Actividades
Los diagramas de actividades pueden modelar una colaboración que es la elaboración o
implementación de un caso de uso.

Ejemplo.
Secuencia
Pueden modelar el escenario de un caso de uso o una colaboración.

Ejemplo:
Clases
Diagrama que modela los tipos de objetos con sus relaciones.

Ejemplo:

Estado
Modela los posibles estados de un objeto a partir de eventos el mejor ejemplo es un semáforo.

Ejemplo:
Datos
Modela los objetos persistentes que se llevaran a base de datos.

Ejemplo:

Paquetes
Modela los contenedores de objetos

Ejemplo:
Como nombré anteriormente estos diagramas no son camisa de fuerza y por el contrario se
deben crear tantos diagramas como el sistema lo requiera y puede que no se requiera hacer
alguno de ellos.

Y se puede modelar por ejemplo la estructura de usuarios de le sistema.

O las interfaces graficas para recibir aprobación.

Yo puedo sugerirles un método para realizar los diagramas de un sistema de información y que
mejor que modelarlo en un diagrama de secuencia.
Casos de uso Documental
¿Qué es?
Es un documento narrativo que describe la secuencia de eventos de un actor.

Características
-Capta alguna función visible para el usuario
- Puede ser pequeño o grande
-Logra un objetivo discreto para el usuario

¿Cómo identificar casos de uso?

Opción A: Basada en Actores
1. Identificar los actores relacionados con el sistema o la empresa.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
Opción B: Basada en Eventos
1. Identificar los eventos externos a los que un sistema ha de responder.
2. Relacionar los eventos con los actores y con los casos de uso.

Casos de uso de alto nivel

Se utilizan al principio del proyecto, para comprender mejor los requerimientos del
sistema. Intentan ser una breve descripción de cada una de los casos de uso del diagrama.

Formato
Caso de Uso: Nombre del Caso de Uso
Actores: Según el Diagrama de Casos de Uso
(Si hay más de uno simultáneamente, se debe indicar cuál es el iniciador)
Tipo: < Primario / Secundario / Opcional >
Descripción: Pasos generales que realiza el actor para ejecutar el caso de uso.
Tipos de caso de uso
Primario: Representan los procesos comunes más importantes del sistema. Se consideran
indispensables y urgentes.
Secundarios: Representan los procesos menores o poco frecuentes, pero que complementan el
sistema. Se consideran indispensables pero no urgentes.
Opcional: Se consideran no indispensables y no urgentes.

Un caso de uso expandido muestra más detalles que un caso de uso de alto nivel. Los casos de
uso expandidos son útiles para alcanzar un conocimiento más profundo de los procesos y los
requerimientos. Ej.:

Caso de uso: Registrar empresa

Actores: Usuario
Propósito: Registrar una empresa en el sistema.
Tipo: Primario
Descripción: El usuario registra una empresa en el sistema rellenando los datos de la empresa.
El sistema comprueba si la empresa existe. Si no existe registra la empresa en el sistema.
Curso normal de los eventos:
1.El usuario introduce los datos de la empresa que quiere registrar.
2.El sistema busca entre las empresas registradas si existe una empresa con el mismo
identificador.
3.El sistema informa al usuario que la empresa se ha registrado satisfactoriamente.
Cursos alternos:
Línea 3: El sistema informa al usuario que ya existe una empresa con el mismo identificador
registrada en el sistema.
Caso esenciales de uso y casos reales de uso

Los casos esenciales de uso son casos que se expresan de forma muy abstracta, sin detalles de
implementación. Los detalles de diseño se dejan para la etapa del diseño.
En la etapa del diseño veremos los casos reales de uso. Estos casos de uso describen
concretamente el proceso de negocios con detalles de diseño y sujeto a tecnologías de entrada
y salida, como por ejemplo la interfaz gráfica.

Contratos de operación

Los contratos de operaciones ayudan a describir el comportamiento del sistema. Un contrato

de operación describe el cambio de un estado a otro de los objetos del dominio como resultado
de la ejecución de una operación. Su creación depende de la creación previa del modelo de
dominio, los diagramas de secuencia de sistema, y la identificación de las operaciones de
sistema. Los contratos de operaciones se refieren a las operaciones del sistema, las operaciones
ofrecidas por el sistema como caja negra a través de su interfaz pública de datos en respuesta a
los eventos entrantes al sistema. El sistema como un todo se puede representar en UML como
una clase.
 Los casos de uso constituyen el principal mecanismo de descubrimiento del
comportamiento del sistema; los contratos de operación no son obligatorios, se construyen
cuando los detalles y complejidad de los cambios de estado implicados en la operación hacen
difícil su captura en los casos de uso.
Los contratos suelen escribirse en forma declarativa, indicando las condiciones previas y
posteriores a la operación.

Secciones de un Contrato.

Nombre: nombre de la operación y parámetros.

Referencias cruzadas: casos de uso en los que puede realizarse la operación.
Precondiciones: estado del sistema antes de la ejecución. Suposiciones relevantes sobre el
estado del sistema o de los objetos del modelo de dominio antes de la ejecución de la
operación. La operación no verifica estas condiciones, las da por cumplidas. En el flujo de
ejecución del programa el analista deberá asegurar la consecución de las condiciones previas
por la ejecución exitosa de operaciones anteriores y el cumplimiento de las restricciones
requeridas.
Postcondiciones: estado del sistema después de la ejecución de esta operación. El estado del
sistema está dado por el estado de los objetos del modelo de dominio después de completada
la operación. Comprende la creación de instancias, la formación o rotura de asociaciones, y los
cambios en los atributos. A nivel conceptual la eliminación explícita de instancias no suele tener
relevancia; la eliminación de objetos es más un problema de implementación, por la liberación
de recursos, algo ajeno al modelo conceptual en construcción en estas etapas. La expresión de
las postcondiciones es en tiempo pasado: se hicieron tales y tales cosas.

UC - 10 Registrar contacto desde seguimiento

Versión 1.0

Autor(es) Elías Gómez Castro

Fuentes Álvaro Cordero

Pou Wen Lin

Importancia Crítico

Tipo: Primario, esencial

Dependencias Req #65

Actores primarios Asistente
Actores secundarios N/A.

Acción inicial El usuario selecciona la opción registrar contacto.

Descripción El caso de uso inicia cuando el usuario desea registrar un contacto en el momento en que
está dando seguimiento a la encuesta. El usuario proporciona los datos requeridos y se
almacenan en el sistema.

Curso Típico de Acción del Actor Respuesta del Sistema

Eventos 1. Este caso de uso inicia cuando el 2. El sistema solicita los datos requeridos.
usuario desea registrar un contacto.
3. El usuario proporciona los datos 4. El sistema valida los datos ingresados.
requeridos y selecciona “aceptar”.

5. El sistema almacena la información.

6. El sistema muestra una retroalimentación.

El caso de uso finaliza con éxito.

Curso Alterno:
Línea: Error: Mensaje: Reacción del Sistema:
5 Datos en Ingrese los datos requerido. Regresa a la línea 4.
blanco.

5 Contacto ya El contacto que desea Regresa a la línea 4.

registrado. registrar, ya existe en el
sistema.

6 Error de No se encontró conexión con Regresa a la línea 1.

conexión. la base de datos.

Comentarios N/A

Nombre registrarContacto(pid:int,pnombre:String,pprimerApellido:String,
psegundoApellido:String,pcorreo:String, pcodigoEmpresa:int)
Responsabilidades Debe poder agregar los diferentes datos de un contacto en específico para que
éstos sean almacenados.

Tipo Software
Dependencias UC – 10
Notas N/A
Excepciones - Ya existe una instancia de contacto.
- No hay conexión con la BD.
Salidas N/A
Precondiciones - Debe existir una instancia empresa.
- El usuario en ejecución debe ser un Administrador o Asistente.
Post condiciones - Asociación formada entre Empresas y contactos.
- Creación de instancia Contacto.