martes, 26 de abril de 2016

Diagrama de actividades

Elementos básicos de un diagrama de actividad

Los diagramas de actividad permiten describir como un sistema implementa su funcionalidad.

Los diagramas de actividad modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el proceso que se lleva a cabo.

Los diagramas de actividad es uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos directos de los diagramas de flujo.

Los diagramas de actividad son mas expresivo que los diagramas de flujo. También heredan características de: „

  • Los diagramas de estado. „
  • Los diagramas de flujo de datos. „ 
  • Las redes de Petri.

Actividades y acciones

Una acción es un paso de un proceso que tiene la semática “run to completion” (Se inicia para ser terminado) 

Una actividad es un conjunto de acciones que modelan un proceso. No tiene la semántica “run to completion”. Una actividad se modela mediante un diagrama de actividad. 

Enjabonar, enjuagar o secar un coche son acciones de la actividad “Lavar un coche” 


Branching and merges


Las decisiones representan las alternativas de flujo de control en un diagrama que se llevan a cabo en función de una condición. 

La condiciones de guarda asociadas a cada rama de salida determinan la opción de flujo de control que se sigue. 

Las ramas de flujo de control abiertas en una o varias condiciones se cierran en un punto de convergencia (merge).

Decisiones consistentes 

La opciones de una decisión deben ser: „ 
  • Completas. „ 
  • No ambiguas.

Fork y Joint

Los fork y los joint se utilizan en los diagramas de actividad para describir concurrencia entre acciones o actividades.
Las líneas de flujo de salida de un fork representa líneas de ejecución que se ejecutan concurrentemente. 
Las líneas de flujo de entrada de un joint se sincronizan para continuar en una única línea de flujo. 

Todas la acciones de las líneas de flujo previas a un joint deben completarse antes de que se ejecute la primera acción de la línea posterior a él. 

Time events
Los eventos de tiempo modelan: „ 
  • Activaciones temporizadas. „ 
  • Timeouts „ 
  • Retrasos. „ 
Un evento de tiempo puede ser el inicio de una actividad.

Un evento temporizado con flujo de entrada representa una única activación tras llegarle el flujo.

Un evento de tiempo sin flujo de entrada representa una activación que puede ser repetida en el tiempo. 


Calling other activities


Objects 
En un diagrama de actividad se pueden representar los objetos de datos que se generan, se consumen o se intercambian en un proceso y que son relevantes para su descripción. 

Cuando un objeto de datos se representan como una caja, significa que esos datos existen en el punto de flujo de control en que se insertan. 

Cuando un objeto de datos se representa mediante unos pines asociados a las acciones o actividades, representan objetos de datos de entrada o de salida. 

Sending and receiving signals

En un diagrama de actividad las señales representan interacciones del proceso que se Describe con operadores sistemas u otros procesos externos a él. 

• Cuando un receptor de señales tiene flujo de entrada representa que cuando el flujo le llega se habilita para aceptar una única señal. 
• Cuando no tiene flujo de entrada, representa que puede aceptar uno o muchas señales. 


Starting an activity

Una actividad se puede iniciar por: „ 

  • Cuando se invoca de forma regular: se representa mediante un circulo. „ 
  • Cuando se recibe un objeto de dato de entrada „ 
  • Cuando se produce un evento temporizado „ 
  • Cuando se recibe una señal externa.
Interrupting an activity

Una actividad de duración no atómica puede concluirse por la ocurrencia de un evento o una señal externa. Para ello se define una región de interrupción mediante una línea que engloba las actividades o acciones que pueden ser interrumpidas por el evento o señal que también se incluye en la región.



Partitions or swinglanes

Los swinglanes representan los procesos, participantes o elementos responsables de ejecutar un conjunto de acciones.



Diagrama de estados

Los diagramas de máquinas de estado son útiles para describir el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes, así como los eventos o condiciones bajos las que se pasa de una situación a otra (transiciones de estados).
 Los diagramas de estados son intensivamente utilizados en: „ 
  • Sistemas de tiempo real y críticos. „ 
  • La descripción de sistemas reactivos. 
  • „La descripción de sistemas basados en protocolos

Un estado puede cualificarse: „ 
  • Estáticamente en función del valor que tienen sus atributos. „
  •  Dinámicamente, esto es en función de la actividad que ejecuta.

Comportamiento completo de un estado
El comportamiento describe las acciones que se producen mientras que el sistema se encuentra en un estado:

• entrry/behavior => Acción que se realiza cuando se llega a un estado. 
• do/behavior => Actividad que se ejecuta mientras se está en un estado. 
• Exit/behavior => Acciones que se ejecuta cuando se abandona un estado. 
• Transiciones internas => Se formulan como trigger[guard]/behavior.

Transiciones
Una transición representa las causas circunstancias y efectos de un cambio entre dos estados. 

Una transacción tiene un nombre y una descripción completa del tipo trigger[guard]/behavior :
  •  „Trigger: Es el evento que da origen a una transición. „ 
  • Guard:Es una función booleana que esevaluada cuando ocurre el trigger. Si es True la transición se produce. Si vale False la transición no ocurre. „ 
  • Behavior: Es una acción ininterrumpible que tiene lugar cuando se produce la transición.


Múltiples transiciones

La posibles combinación de triggers y condiciones de guardas dan lugar a diferentes conjuntos de transiciones entre estados:


Si una transición no tiene trigger ni guarda, la transición se produce por finalización de la actividad asociada al estado.


Trigger, guardas y repuesta en programas

Es muy frecuente cuando se modela software que: „ 
  • El trigger puede ser la invocación de un metodo de la clase modelada. „ 
  • La guarda es la invocación de un metodo booleano o una relación entre los atributos. „ 
  • La respuesta puede ser la invocación de un metodo sobre el propio objeto o sobre un objeto al que tenga acceso.


Estados compuestos

UML permite que varias máquinas de estados se asocien a una misma clase o sistema. Su situación puede estar descrita en un mismo instante por varios estados, cada uno de ellos pertenecientes a diferentes máquinas.  


Un estado de inicio histórico asociado a una región de estado representa que cuando se accede a la región se accede al estado en que se encontraba la región cuando se abandonó.

Pseudoestados


Recepción y transmisión de señales

Máquinas de estados de protocolo

Una máquina de estados de protocolos es un tipo especial de máquina de estados que se utiliza para describir un protocolo de interacción. 

No describe el comportamiento asociado a los estados y a las transiciones. 

Resalta las secuencias de estados que son posibles y los eventos que dan lugar a esas transiciones. 

Se representa en una caja rectangular con una pestaña que contiene el estereotipo <<protocolo>>

viernes, 22 de abril de 2016

Diagrama de secuencia


Utilidad
Un 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.

Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.






martes, 19 de abril de 2016

Diagrama de clases


¿Qué es un diagrama de clases?
Un diagrama de clases es una representación gráfica que sirve para representar la estructura de un sistema que será implementado utilizando un lenguaje orientado a objetos. Los diagramas de clases se realizan en la fase de diseño del software después de la fase de requisitos. La idea de estos diagramas es representar las clases que tendrá el sistema así como su contenido y sus relaciones con otras clases. La implementación de sistemas medianamente grandes no sería abordable sin este tipo de diagramas, y aunque fuera abordable se tardaría mucho más y sería más fácil cometer errores.

Componentes de un diagrama de clases
Los componentes que describiré son los que se incluyen en UML(Unified Modeling Language) que es el lenguaje de modelado más extendido y más usado en todo el mundo.

Clase
Este es el elemento básico del diagrama de clases. Las clases representan entidades o conceptos. Normalmente cada vez que aparece un sustantivo en un documento de descripción de un sistema ese sustantivo es una clase. En cada clase se definen los atributos y métodos que tendrán los objetos de esa clase. La siguiente imagen es un ejemplo de representación de una clase.

Atributos y métodos
Los atributos y los métodos se muestran con su nombre además de su tipo. En el caso de los métodos también se muestra el tipo de retorno en caso de que retorne algo y el nombre y tipo de sus parámetros. Los atributos pueden tener un valor inicial. Además, los símbolos que se encuentran antes del nombre de los atributos y métodos representan la visibilidad de éstos:
El símbolo – representa atributos privados.
El símbolo + representa atributos públicos.
El símbolo # representa atributos protegidos.

Relaciones
Como he dicho antes las clases se relacionan con otras. En cada relación aparece el nombre del atributo que se usará para representar esa relación y la multiplicidad. Las relaciones que existen son las siguientes: 

Generalización: Esta relación representa la herencia o la extensión de una clase de otra. En la siguiente imagen podemos ver un ejemplo.
 
Asociación: Representa una relación básica entre dos clases. Pueden ser unidireccionales (sólo una de las clases conoce a la otra) o bidireccionales (ambas clases tienen conocimiento de la otra). En la siguiente imagen podemos ver un ejemplo. La primera es una asociación bidireccional que representa que un curso tiene desde 1 hasta varios alumnos y que un alumno puede estar en 0 o varios cursos. La segunda es una asociación unidireccional que representa que una asignatura tiene un único profesor responsable. 

Agregación: Es un tipo de asociación con la que se representa que cada objeto de una de las clases contiene objetos de la otra clase. El objeto contenedor seguirá existiendo aunque los objetos contenidos dejen de existir. 

Composición: Es un tipo de asociación, pero podemos decir que son agregaciones fuertes. La diferencia con las agregaciones es que no tiene sentido que el objeto contenedor siga existiendo si no existen los objetos contenidos.



Narrativa Caso de Uso

El caso de uso se puede ver como un documento narrativo que describe la secuencia de eventos de un actor que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen los requerimientos en las historias que narran. El siguiente ejemplo corresponde a un caso de uso de alto nivel, que describe clara y concisamente el proceso de comprar artículos en una tienda cuando se emplea una caja una caja registradora en el punto de venta.

La explicación del formato es: 
· Caso de uso: nombre del caso de uso.
· Actores: lista de actores en la que se indica quién inicia el caso de uso. 
· Tipo: que puede ser Primario, Secundario, Opcional, entre otros.
· Descripción: repetición del caso de uso de alto nivel o alguna síntesis similar.
· Propósito: intención del caso de uso.
· Referencias Cruzadas: casos de uso y funciones relacionadas con el sistema. 
· Curso Normal de los Eventos: es la parte medular del formato expandido; describe los detalles de la conversión interactiva entre los actores y el sistema. Un aspecto esencial de la sección es explicar la secuencia más común de eventos: la historia normal de las actividades y el término exitoso de un proceso. No incluye situaciones alternativas. 
· Cursos Alternativos: describe importantes opciones o excepciones que pueden presentarse en relación al curso normal. Si son éstas son complejas, se pueden expandir y convertir en nuevos casos de uso.


Actores(caso de uso)

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma.

Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos.

Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores.

Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que usa los servicios de nuestro sistema.

Los Casos de Uso y UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML –Unified Modelling Language– propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de convertirse en un estándar para modelado de sistemas de software de amplia difusión.

A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos.

Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan adoptado las principales ventajas de todos los métodos disponibles en la actualidad (estructurados, métodos formales, métodos orientados a objetos, etc.).

De lo dicho anteriormente podemos concluir que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto del método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se puede diseñar un sistema “estructurado” (manteniendo una separación entre datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.

Historia casos de uso

Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos [McMenamin84]. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace Pedido”. En este caso el sistema deberá responder al estimulo que recibe procesándolo.

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:

 1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.

2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos.

3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante en el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.

Casos de uso

¿Que son los casos de uso?
Los casos de usos son una técnica para especificar el comportamiento de un sistema.
"Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios" 

Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.

martes, 5 de abril de 2016

Qué proporciona UML

Proporciona un vocabulario y las reglas para utilizarlo para así tener una representación conceptual y física de un sistema.

Introducción

UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones.
Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones.
UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles.


Introducción a UML

Se presentará la revision 2 del OMG (Object Management Group) de noviembre de 2007.
UML: Unified Modeling Language.

El objetivo de UML es “proporcionar a desarrolladores de software, arquitectos de sistemas e ingenieros de software de herramientas para el análisis, diseño e implementación de sistemas basados en software, así como modelar procesos de negocio y similares .

El modelado captura las partes esenciales del sistema.

UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones.
• Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones.

• UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles.

• “El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML” - Grady Booch Modelado.

Modelado
• Busca representar los planos del software.

• El modelado es la espina dorsal del desarrollo de software de calidad.

Modelo: Simplificación de la realidad.

• UML busca
     – Visualizar cómo es o queremos que sea un sistema.
     – Especificar la estructura o el comportamiento de un sistema.
     – Proporcionar plantillas que nos guíen en la construcción de un sistema.
     – Documentar las decisiones que hemos adoptado.
Modelado (II) 
Principios básicos del modelado.
     – Seleccionar el modelo adecuado para cada momento, y dependiendo de qué modelo se elija se obtendrán diferentes beneficios y diferentes costes.

El modelado orientado a objetos proporciona sistemas más flexibles y readaptables.
     – Todo modelo puede ser expresado en base a diferentes niveles de precisión.
     – Obtener modelos que representen la realidad lo más claramente posible.
     – Un único modelo no es suficiente.

Caratula

Universidad Latina campus sur.
Proyecto Final.
Informática IV.
Maestra: Adriana Vega Palos.
Alumno: Octavio Santiesteban.
Fecha de entrega: 13 de mayo del 2016.