DIAGRAMAS DE ACTIVIDADES

DEFINICIÓN:

Un diagrama de actividades muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones.Las personas, los componentes de software o los equipos pueden realizar estas acciones.

Puede usar un diagrama de actividades para describir procesos de varios tipos, como los ejemplos siguientes:

• Un proceso de negocio o un flujo de trabajo entre los usuarios y el sistema.Para más información, vea Requisitos del usuario de modelos.
• Los pasos que se realizan en un caso de uso.Para más información, vea Diagramas de casos de uso de UML: Instrucciones.
• Un protocolo de software, es decir, las secuencias de interacciones entre componentes permitidas.
• Un algoritmo de software.

ELEMENTOS:

Flujos de control simple

Puede mostrar una secuencia de acciones con bifurcaciones y bucles.

Forma	Elemento	Descripción y propiedades principales
1	Acción	Paso de la actividad en el que los usuarios o el software realizan alguna tarea. La acción se puede iniciar cuando un token llega a todos sus flujos entrantes.Cuando termina, los tokens se envían en todos los flujos salientes. Body: especifica la acción en detalle. Language: idioma de la expresión en el cuerpo. Local Postconditions: restricciones que deben cumplirse cuando termina la ejecución.Objetivo alcanzado por la acción. Local Preconditions: restricciones que deben cumplirse antes de que empiece la ejecución.
2	Flujo de control	Conector que muestra el flujo de control entre las acciones.Para interpretar el diagrama, imagine que un token fluye de una acción a la siguiente. Para crear un flujo de control, use la herramienta Conector.
3	Initial Node	Indica la primera acción o las primeras acciones de la actividad.Cuando se inicia la actividad, un token fluye desde el nodo inicial.
4	Activity Final Node	Fin de la actividad.Cuando llega un token, la actividad finaliza.
5	Decision Node	Bifurcación condicional de un flujo.Tiene una entrada y dos o más salidas.Un token entrante solo emerge en una de las salidas.
6	Restricción	Condición que especifica si un token puede fluir por un conector.Se usa con más frecuencia en los flujos salientes de un nodo de decisión. Para establecer una restricción, haga clic con el botón derecho en un flujo, haga clic enPropiedades y, después, establezca la propiedad Restricción.
7	Merge Node	Necesario para combinar los flujos que se dividieron mediante un nodo de decisión.Tiene dos o más entradas y una salida.Un token en cualquier entrada emerge en la salida.
8	Comentario	Proporciona información adicional sobre los elementos a los que está vinculado.
9	Call Behavior Action	Acción que se define con más detalle en otro diagrama de actividades. IsSynchronous: si es true, la acción espera hasta que la actividad finaliza. Behavior: actividad invocada.
(sin mostrar)	Call Operation Action	Acción que llama a una operación en una instancia de una clase.
	Actividad	Flujo de trabajo que se representa mediante un diagrama de actividades.Para ver las propiedades de una actividad, debe seleccionarla en el Explorador de modelos UML. Is Read Only: si es true, la actividad no debe cambiar el estado de los objetos. Is Single Execution: si es true, a lo sumo hay una ejecución de este diagrama a la vez.
	Diagrama de actividades UML	Diagrama que muestra una actividad.Para ver sus propiedades, haga clic en una parte vacía del diagrama. Nota Los nombres del diagrama de actividades, el archivo que contiene el diagrama y la actividad que se muestra en el diagrama pueden ser diferentes.

Flujos simultáneos

Puede describir secuencias de acciones que se ejecutan al mismo tiempo.Para más información, vea Dibujar flujos simultáneos.

Forma	Elemento	Descripción
11	Fork Node	Divide un único flujo en flujos simultáneos.Cada token entrante genera un token en cada conector saliente.
12	Join Node	Combina flujos simultáneos en un único flujo.Cuando cada flujo entrante tiene un token en espera, se genera un token en la salida.
13	Send Signal Action	Acción que envía un mensaje o una señal a otra actividad o a un subproceso simultáneo de la misma actividad.El tipo y el contenido del mensaje están implícitos en el título de la acción o se especifican en los comentarios adicionales. La acción puede enviar datos de la señal, que se pueden pasar a la acción de un flujo de objeto o terminal de entrada (16).
14	Accept Event Action	Acción que espera un mensaje o una señal antes de continuar con la acción.El tipo de mensaje que la acción puede recibir está implícito en el título o se especifica en los comentarios adicionales. Si la acción no tiene ningún flujo de control entrante, genera un token cada vez que recibe un mensaje. La acción puede recibir datos de la señal, que se pueden pasar a un flujo de objeto o terminal de salida (17). IsUnmarshall: si es true, puede haber varios terminales de salida con tipo y los datos se deserializan en ellos.Si es false, todos los datos aparecen en un terminal.

Flujos de datos

Puede describir el flujo de datos de una acción a otra.Para más información sobre los elementos que se usan en esta sección, vea la sección Dibujar flujos de datos del tema Instrucciones para dibujar un diagrama de actividades.

Forma	Elemento	Descripción
15	Object Node	Representa los datos que pasan por un flujo. Ordenación: cómo se almacenan varios tokens. Selection: invoca un proceso, que se puede definir en otro diagrama, que filtra los datos. Upper Bound: 0 indica que los datos deben pasar directamente por el flujo; * indica que los datos pueden almacenarse en el flujo. Type: tipo de objetos que se almacenan y se transmiten.
16	Input Pin	Representa los datos que puede recibir una acción cuando se ejecuta. Type: tipo de objetos que se transmiten.
17	Output Pin	Representa los datos que genera una acción cuando se ejecuta. Type: tipo de objetos que se transmiten.
18	Activity Parameter Node	Nodo de objeto a través del cual la actividad recibe o genera datos. Se usa cuando la actividad representada en el diagrama se llama desde otra actividad, o bien cuando el diagrama describe una operación o función. Type: tipo de objetos que se transmiten.
(sin mostrar)	Flujo de objetos	Conector que muestra el flujo de datos entre las acciones y los nodos de objeto. Para crear un flujo de objeto, use la herramienta Conector para vincular un terminal de entrada o salida, o bien un nodo de objeto a otro elemento. Selection: invoca un proceso, que se puede definir en otro diagrama, que filtra los datos. Transformation: invoca un proceso, que se puede definir en otro diagrama, que transforma los datos. IsMulticast: indica que puede haber varios componentes u objetos de destinatario. IsMultiReceive: indica que pueden recibirse entradas de varios objetos o componentes.

EJEMPLO PRACTICO:

Ejemplo de diagrama de actividades

Este tipo de diagrama le resulta familiar a la mayoría de programadores, pues en cualquier curso básico de programación se comienza por trabajar con los diagramas de flujo para conocer la lógica que llevará un programa. Los tradicionales diagramas de flujo muestran una secuencia de pasos, procesos, puntos de decisión y bifurcaciones. Con sus diversas características y tipos de diagramas, el UML se podría decir que es en cierta medida, un diagrama de flujo robustecido o reforzado. Para el caso particular del diagrama de actividades, es muy parecido a los viejos diagramas de flujo, pues muestra los pasos (conocidos como actividades) así como puntos de decisión y bifurcaciones. Lo que hacen es mostrar una visión simplificada de lo que ocurre durante una operación o proceso. Se puede decir también que es una extensión del diagrama de estados. El diagrama de estados muestra los estados de un objeto y representa las actividades como flechas que conectan a los estados. Por su parte, el diagrama de actividades resalta, precisamente, las actividades.

Cada actividad se representa por un rectángulo con las esquinas redondeadas (más angosto y ovalado que la representación del estado). El procesamiento dentro de una actividad se lleva a cabo y, al realizarse, se continúa con la siguiente actividad. Una flecha representa la transición de una a otra actividad. Al igual que el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un círculo relleno) y uno final (representado por una diana).

Los diagramas de actividades tienen la poderosa herramienta de permitir tomar decisiones, como se muestra en la siguiente figura:

Es posible también modelar actividades que serán ejecutadas al mismo tiempo (es decir, de forma concurrente) y que luego se reúnan. Para representar esto, se utiliza una línea gruesa perpendicular a la transición y las rutas parten de ella. Para representar la reincorporación, ambas rutas apuntan a otra línea gruesa, de esta forma:

Se muestra ahora un ejemplo en el que se utilizará un diagrama de actividades para utilizar una aplicación de oficina (software) para crear un documento. La secuencia sería la siguiente:

• 1. Abrir la aplicación para procesamiento de textos.
• 2. Crear un archivo con un nombre único en una carpeta.
• 3. Guardar el archivo con un nombre único en una carpeta.
• 4. Teclear el documento.
• 5. Si se necesitan ilustraciones, se abre la aplicación relacionada, se generan los gráficos y se colocan en el documento.
• 6. Si se necesita una hoja de cálculo, se abre la aplicación relacionada, se crea la hoja correspondiente y se coloca en el documento.
• 7. Se guarda el archivo.
• 8. Se imprime el documento.
• 9. Se sale de la aplicación de oficina.

El diagrama de actividades queda representado así:.

RESUMEN:

Un diagrama de actividades muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones.Las personas, los componentes de software o los equipos pueden realizar estas acciones.Puede usar un diagrama de actividades para describir procesos de varios tipos, como los ejemplos siguientes:

• Un proceso de negocio o un flujo de trabajo entre los usuarios y el sistema.Para más información, vea Requisitos del usuario de modelos.
• Los pasos que se realizan en un caso de uso.Para más información, vea Diagramas de casos de uso de UML: Instrucciones.
• Un protocolo de software, es decir, las secuencias de interacciones entre componentes permitidas.
• Un algoritmo de software.

SUMMARY:

An activity diagram shows a business process or a software process as a workflow through a series of acciones.Las people , software components or equipment can perform these actions .

You can use an activity diagram describing processes of various types, as the following examples :

• A business process or workflow between users and sistema.Para more information, see User Requirements Model .
• The steps are performed in a case uso.Para more information, see use case diagram UML Instructions .
• A software protocol , ie sequences allowed interactions between components .
• A software algorithm .

RECOMENDACIONES:

• No obstaculizar los procesos de las actividades y disminuir distancias de recorrido y tiempo de desarrollo de los procesos dándole un  mejor uso a los espacios que se encuentran vacíos creando nuevos lugares para almacenaje.

CONCLUSIONES:

• Los diagramas de actividades ayuda al programador, diseñador y analista a entender de forma especifica que ocurre dentro de una operación o un proceso del sistema donde se interactúa con un objeto; además tiene también como finalidad determinar las responsabilidades que tiene los procesos de negocios o el sujeto en cuestión.

LINKOGRAFIA: 

https://msdn.microsoft.com/es-pe/library/dd409360.aspx

http://www.monografias.com/trabajos67/diagramas-uml/diagramas-uml2.shtml

Diapositivas : SlideShare

DIAGRAMAS DE INTERACCIÓN(SECUENCIA Y COLABORACIÓN)

DEFINICIÓN:

Conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. Estos  objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. En sí, los diagramas de interacción muestran cómo se comunican los objetos.

La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes. 

Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo que conlleva modelar instancias concretas o prototípicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de objetos colaboran para proveer un comportamiento. Mientras que un diagrama de casos de uso presenta una visión externa del sistema, la funcionalidad de dichos casos de uso se recoge como un flujo de eventos utilizando para ello interacciones entre sociedades de objetos. 

El flujo de eventos de un caso de uso puede recogerse en una especificación texto acompañada de distintos escenarios especificados mediante diagramas de interacción (interaction diagrams), donde cada diagrama será una visión gráfica de un escenario.

DIAGRAMAS DE SECUENCIA:

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

DIAGRAMAS DE COLABORACIÓN:

Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

                    

ELEMENTOS:

• OBJETO

        

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

• Mensaje a Otro Objeto:

  

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

• Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

EJEMPLO:

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente modelo estático:

Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee internamente un botón.


Entonces el diagrama de interacción para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a Paint() por el objeto Botón.

RESUMEN:

Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo que conlleva modelar instancias concretas o prototípicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de objetos colaboran para proveer un comportamiento. Mientras que un diagrama de casos de uso presenta una visión externa del sistema, la funcionalidad de dichos casos de uso se recoge como un flujo de eventos utilizando para ello interacciones entre sociedades de objetos. 

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

SUMMARY:

Interaction diagrams are used to model the dynamic aspects of a system, leading to model specific instances or classes prototypical interfaces, components and nodes, with messages sent between them, particularly in the context of a scenario that illustrates a behavior . In the context of the classes described how groups of objects collaborate to provide a behavior. While a use case diagram shows an external view of the system, the functionality of these use cases is collected as a stream of events using for this object interactions between societies.

A sequence diagram shows the interaction of a set of objects in an application over time and is modeled for each use case. While the use case diagram allows modeling a business view of the stage, the sequence diagram contains implementation details of the scenario, including the objects and classes that are used to implement the scenario and messages exchanged between objects.

RECOMENDACIONES:

• Utilizar diagrama de caso de uso, para construcción del sistema

CONCLUSIONES:

• Los diagramas de interacción nos permite ver el comportamiento e interacción de los objetos entre si dentro de un casos de uso.
• Permite entender los mensajes que se envían .

APRECIACIÓN DEL EQUIPO:

Diagramas de secuencia que nos muestran las interacciones expresadas en función de secuencias temporales y diagramas de colaboración que nos muestran las relaciones entre los objetos y los mensajes que intercambian

LINKOGRAFIA:

• http://users.dcc.uchile.cl/~psalinas/uml/interaccion.html
• https://deberesfacilitos.files.wordpress.com/2009/11/diagramas_interaccion.doc
• https://es.wikipedia.org/wiki/Diagrama_de_secuencia
• https://es.wikipedia.org/wiki/Diagrama_de_colaboraci%C3%B3n

presentación en diapositiva: slideShare

DIAGRAMAS DE CLASES

DEFINICIÓN:

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.
Son los diagramas más comunes en el modelado de sistemas orientados a objetos.

Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.

Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).

Los diagramas de clase son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutables. Ingeniería hacia adelante e ingeniería inversa.

La construcción de software tiene muchas características similares, excepto, que la calidad(Fluidez) de software, uno tiene la habilidad de definir la construcción de bloques básicos para ir detallando(scratch).


ELEMENTOS:

CLASE:Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.)

ATRIBUTOS:son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso.

OPERACIONES:son aquellas actividades o verbos que se pueden realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrir Puerta, cerrar Puerta, buscar Puerta, etc.

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:

TIPOS DE DATOS:En el diagrama de clases debemos especificar el conjunto de posibles valores que puede tomar cada atributo. Estos valores pueden ser valores numéricos, cadenas de caracteres, booleanos, o incluso otras clases de nuestro diagrama (aunque esto no es muy común ni recomendable).

Representaremos los tipos de datos de los atributos de la siguiente manera: 

RESUMEN:

Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.
Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).

SUMMARY:

A class diagram shows a set of classes , interfaces, and collaborations and their relationships with each other.

Class diagrams are used in designing the static model for a system . For the other parties, this involves modeling the vocabulary of the system, modeling collaborations, or modeling schemes . Class diagrams are also the basis for a couple of related diagrams : component diagrams and diagrams Installation ( Deployment) .

RECOMENDACIONES:

Para un buen diseño es importante  tener un buen análisis y saber utilizar las herramientas en los diagramas de clases.

CONCLUSIONES:

Los diagramas de clases nos ayudan a comprender de una mejor manera ,  la aplicación  .

APRECIACIÓN DE EQUIPO:

los diagramas de clases  es una vista de la forma que va a tomar el sistemas a desarrollar.

LINKOGRAFIA:

https://es.wikipedia.org/wiki/Diagrama_de_clases
http://www.mcc.unam.mx/~cursos/Objetos/Cap8/cap8.html

Presentacion en Diapositiva: SlideShare

Juan Julca Landacay

DIAGRAMAS DE CASO DE USO

DEFINICIÓN:

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.

Casos de uso UML para un modelo simple de restaurante.

El diagrama de la derecha 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.

ELEMENTOS:

Actores

Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema unos mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar.

Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol. Gráficamente se representa con la figura de "stickman".

Encontrando a los actores de un diagrama de casos de uso.

Es posible obtener a los actores de un diagrama de casos de uso a través de las siguientes preguntas:

¿Quién utilizará la funcionalidad principal del sistema (actores primarios)?

¿Quién necesitará soporte del sistema para realizar sus actividades diarias?

¿Quién necesitará mantener, administrar y trabajar el sistema (actores secundarios)?

¿Qué dispositivos de hardware necesitará manejar el sistema?

¿Con qué otros sistemas necesitará interactuar el sistema a desarrollar?

CASOS DE USO:

Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Gráficamente se representan con una elipse y tiene las siguientes características:

Un caso de uso siempre es iniciado por un actor.

Un caso de uso provee valores a un actor.

Un caso de uso es completo.

Encontrando casos de uso

El proceso para encontrar casos de uso inicia encontrando al actor o actores previamente definidos. Por cada actor identificado, hay que realizar las siguientes preguntas:

¿Qué funciones del sistema requiere el actor? ¿Qué necesita hacer el actor?

¿El actor necesita leer, crear, destruir, modificar o almacenar algún tipo de información en el sistema?

¿El actor debe ser notificado de eventos en el sistema o viceversa? ¿Qué representan esos eventos en términos de funcionalidad?

¿El trabajo diario del actor podría ser simplificado o hecho más eficientemente a través de nuevas funciones en el sistema? (Comúnmente, acciones actuales del actor que no estén automatizadas)

Otras preguntas que nos ayudan a encontrar casos de uso pero que no involucran actores son:

¿Qué entradas/salidas necesita el sistema? ¿De dónde vienen esas entradas o hacia dónde van las salidas?

¿Cuáles son los mayores problemas de la implementación actual del sistema?

RELACIONES:

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 .

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."

documentan el comportamiento de un sistema desde el punto de vista de un usuario

En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azúcar y podemos seleccionar de entre azúcar rubia, blanca o su unidad de medida bolsa , kilo, etc.

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."

En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

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).

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.

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.

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.

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:

Describe lo depositado

El valor de cada item

Total

El usuario/cliente presiona el botón de comienzo

Existe un operador que desea saber lo siguiente:

• Cuantos ítemes han sido retornados en el día.
• 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:

• Información asociada a ítemes.

Dar una alarma en el caso de que:

• Item se atora.
• 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:

RESUMEN: 

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.

Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema unos mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar.

SUMMARY:

UML does not define standards for the written format describes the use cases, and so many people do not understand that this graphical notation defines the nature of a use case; however a graphical notation can only give a simple overview of a use case or set of use cases. The use case diagrams are often confused with the use cases. As the two concepts are related, the use cases are much more detailed than the use case diagrams. In the concepts shLos ould detail more than one use case to identify what makes a use case.

An actor is someone or something that interacts with the system; who is using the system. By the phrase "interacts with the system" should be understood that the actor sends to or receives a message or system interfaces with the system. In short, the actor performs the use case. An actor can be a person or another system that communicates with the system modeling.

RECOMENDACIONES:

• Utilizar correctamente las elementos del Diagrama de casos de uso, debido a que cada uno cumple una función especifica.

CONCLUSIONES:

• Los casos de uso hacen ver el cuerpo completo del  sistema, define el objetivo del sistema, entre otros. 

APRECIACIÓN DE EQUIPO:

• Los Diagramas de Caso de Uso , es una herramienta vital para el diseño que tomará el desarrollo de un sistema.

LINKOGRAFÍA:

http://profesores.fi-b.unam.mx/carlos/aydoo/usecase.html

https://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html

->>Juan Julca Landacay

Presentación >>>>>> SlideShare

ANÁLISIS DE REQUERIMIENTOS

DEFINICIÓN:

Requerimientos: Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.

La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto la preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado con el desarrollo [Norris & Rigby, 1994].

Análisis de requerimientos: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingeniería del software que permite especificar las características operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software.

MOLDEAMIENTO DEL NEGOCIO:

Modelo del Caso de Uso del Negocio:El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado. Debe haber un enfoque a la lógica del negocio de dicho proceso, desde la perspectiva del producto. El modelo de Casos de Uso del Negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interacción con elementos externos (actores), tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y socios. 

Modelo de Objetos del Negocio:Un modelo de datos es una vista de datos analíticos que tiene una correspondencia de uno a uno con un modelo de objetos de negocio (MON) en IBM® Operational Decision Manager. Un MON especifica los elementos de negocio y el vocabulario utilizado para definir las reglas de negocio. El vocabulario permite a los usuarios crear reglas de negocios sin tener conocimientos de cómo se estructuran los datos a los que se refieren las reglas.

Una regla de negocio tiene el formato "si criterios entonces resultado". Por ejemplo, una decisión sobre si rechazar o no una aplicación de préstamo basándose en la capacidad de endeudamiento del aspirante corresponde a la siguiente regla de negocio:

Si la capacidad de endeudamiento del aspirante es menor

a 300 entonces rechace la aplicación.

El aspirante es la entidad de negocios en la que se basa esta regla. La capacidad de endeudamiento del aspirante es la entidad del atributo en el que se realza la decisión. El modelo de objetos de negocio debe incluir un elemento que represente al aspirante y, dicho elemento, debe incluir un atributo que corresponda a la capacidad de endeudamiento. El modelo también especifica el vocabulario utilizado para hacer referencia a los elementos del modelo en las reglas. En este caso el vocabulario incluye "capacidad de endeudamiento del aspirante".

Estructuralmente, el modelo de objetos de negocio es similar al modelo de objeto Java. Las entidades de negocios corresponden a una clase y pueden agruparse en paquetes. Las clases pueden anidarse en otras clases. Los atributos de la entidad corresponden a atributos de clase que tienen un tipo que indica el tipo de valores de datos permitidos para el atributo. Para la regla de ejemplo, el MON incluye una clase de aspirantes que tiene un atributo de capacidad de endeudamiento del tipo entero.

Los elementos del modelo de datos para una vista de datos analíticos corresponden a los elementos en el modelo de objetos de negocio. Una tabla de modelo de datos corresponde a una clase MON. Un campo en la tabla de modelo de datos corresponde a un atributo para la clase.

Figura 1. Relaciones entre un modelo de datos y el modelo de objetos de negocio

Figura 1ilustra las relaciones entre los elementos de modelos de datos y los elementos del modelo de objetos de negocio para un modelo de datos que incluye una tabla llamada Aspirante. Esa tabla corresponde a la clase MON que tiene el mismo nombre. La verbalización de la clase incluye el término aspirante para la clase. Los campos de la tabla de modelo de datos de ID, nombre y capacidad de endeudamiento corresponden a los atributos de la clase MON. Cada atributo de la clase proporciona una frase de verbalización con el formato {atributo} de {esto}. La variable {esto} se refiere al aspirante término padre en la verbalización.

Puede utilizar la correspondencia del modelo de datos y el MON para combinar los resultados desde distintos métodos analíticos. La salida de modelos predictivos que están basados en la visualización de datos analíticos pueden combinarse con reglas de negocio que se basan en un MON si los campos de modelo de datos coinciden con elementos MON. La interfaz de datos común permite que se integren indicadores desde modelos predictivos con los criterios de reglas de negocio.

Modelo de Dominio:

Un modelo de dominio en la resolución de problemas e ingeniería de software, es un modelo conceptual de todos los temas relacionados con un problema específico. En él se describen las distintas entidades, sus atributos, papeles y relaciones, además de las restricciones que rigen el dominio del problema.

El modelo de dominio se crea con el fin de representar el vocabulario y los conceptos clave del dominio del problema. El modelo de dominio también identifica las relaciones entre todas las entidades comprendidas en el ámbito del dominio del problema, y comúnmente identifica sus atributos. Un modelo de dominio que encapsula los métodos dentro de las entidades se asocia más bien con modelos orientados a objetos. El modelo de dominio proporciona una visión estructural del dominio que puede ser complementado con otros puntos de vista dinámicos, como el modelo de casos de uso.

EJEMPLO:

La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Casos de Uso del Negocio

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega

Modelo del Dominio

RESUMEN:

La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.
El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado.

SUMMARY:

Capturing requirements main objective understanding of what customers and users expect the system to do . A requirement expresses the purpose of the system regardless of how you will implement . In other words, identify the requirements which the system, while designing the system sets the how .
The business model describes the business in terms of business use cases , which corresponds to what is generally called processes. A business process is structured activities that are designed to produce a specific result for a client or the market as a whole.

RECOMENDACIONES:
Diseñar modelos de negocios transparente (fáciles de comprender). 
CONCLUSIONES:
Las CASE han sido creadas para la automatización de procesos de análisis, diseño e implementación,
brindándonos un sin número de componentes que hacen que los proyectos sean cada día más eficientes para los
usuarios finales.
APRECIACIÓN DEL EQUIPO:
La aplicación de las herramientas CASE corresponde el mejor método para el análisis y solución de situaciones empresariales complejas, ya que han venido a mejorar los aspectos claves en el desarrollo de los sistemas de negocios.

GLOSARIOS DE TÉRMINOS:
Requerimiento: petición de una cosa que se considera necesaria.
Esencial: que es lo mas importante y necesario.

LINKOGRAFIA:

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html
http://modeladodelsistema3.blogspot.pe/2012/03/republica-bolivariana-de-venezuela.html
https://es.wikipedia.org/wiki/Modelo_de_dominio

Presentación de diapositivas: SlideSha

Juan Julca Landacay.