UML DIAGRAMAS

Introducción

UML es adoptado por OMG como el lenguaje estándar para le modelado se han definido un buen numero de modelos de procesos para el desarrollo de aplicaciones OO. Las propuestas están dirigidas por casos de uso, que definen los requisitos funcionales del sistema.

Los procesos del negocio definen los límites del proceso de modelado posterior. Los procesos del negocio se capturan a partir de los objetivos principales de la empresa. Primero considerar los objetivos estratégicos de la organización. Se descompone estos objetivos estratégicos en subobjetivos, que deberán cumplirse Los subobjetivos pueden ser descompuestos de manera que se defina una jerarquía de objetivo.

Diagramas de actividades UML

En un diagrama de actividades se muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones. Estas acciones las pueden llevar a cabo personas, componentes de software o equipos.

CASOS DE USO

En un diagrama de casos de uso, no se muestran los casos de uso en detalle; solamente se resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas. En concreto, en el diagrama no se muestra el orden en el que se llevan a cabo los pasos para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros diagramas y documentos, que pueden vincularse a cada caso de uso.

En las descripciones que se proporcionen de los casos de uso se utilizarán diversos términos relacionados con el dominio en el que trabaja el sistema, como Ventas, Menú, Cliente, etc. Resulta importante definir estos términos y sus relaciones y, para ello, puede resultar útil un diagrama de clases de UML. Para obtener más información, vea Diagramas de clases de UML: Instrucciones.

Los casos de uso solamente se utilizan para los requisitos funcionales de un sistema. Otros requisitos, como las reglas de negocios, los requisitos de calidad del servicio y las restricciones de implementación, deben representarse por separado. La arquitectura y los detalles internos también deben describirse de forma independiente. Para obtener más información acerca de cómo se definen los requisitos del usuario, vea Crear modelos de los requisitos de los usuarios.

Los ejemplos que se utilizan en este tema están relacionados con un sitio web en el que los clientes pueden hacer pedidos de comida de restaurantes locales.

 Un actor (1) es una clase de persona, organización, dispositivo o componente de software externo que interactúa con el sistema. Los actores del ejemplo son Cliente, Restaurante, Sensor de temperatura y Titular de tarjeta de crédito.

 Un caso de uso (2) representa las acciones que uno o varios de los actores realizan a fin de conseguir un objetivo determinado. Los casos de uso del ejemplo son Pedir menú, Actualizar menú y Procesar pago.

 En un diagrama de casos de uso, los casos de uso están asociados (3) a los actores que los realizan.

 El sistema (4) es aquello que se está desarrollando. Podría tratarse de un pequeño componente de software, cuyos actores simplemente fueran otros componentes de software, o podría tratarse de un gran conjunto de aplicaciones que se implementan en muchos equipos y dispositivos. Los subsistemas del ejemplo son Sitio web de pedidos de menú, Empresa de envío

...