Entendiendo los diagramas de casos de uso (use cases diagrams)

Aunque los casos de uso son descripciones de la funcionalidad del sistema que deben existir en forma textual (Ver esta entrada). Estos son usualmente acompañados por diagramas que capturan detalles como los nombres de los casos de uso, los límites de los sistemas, los actores y las relaciones entre ellos. El estándar UML proporciona notación para cada uno de estos detalles.

Estos diagramas siempre se dibujan desde la perspectiva de la organización sin distinguir entre procesos automáticos y manuales, hay que tener presente que los diagramas de caso de uso son la vista estática del sistema.

Lista de los elementos generales para un diagrama de casos de uso:

Actor: Un actor representa un rol ejecutado por una persona externa, por un proceso o por cualquier cosa que interactue con el sistema.

Caso de uso (use case): Un caso de uso es un clasificador que representa una unidad de funcionalidad proporcionada por un sistema, un subsistema o una clase que puede intercambiar mensajes entre las acciones del sistema y uno o más actores.

Paquete (package): Sirve para la agrupación de elementos, puede contener otros paquetes.

Límite (System Boundary): El limite del sistema consiste de todos los casos de uso que están relacionados con el dominio del sistema.

Asociación (association): La participación de un actor en un caso de uso, instancias del actor e instancias del caso de uso se comunican una con otra.

Extend: Esta relación desde un caso de uso A a un caso de uso B indica que una instancia de un caso de uso B puede ser aumentado por el comportamiento especificado en A.

Include: Este relación se utiliza para indicar que un caso de uso es una subrutina de otro caso de uso.

Los casos de uso son organizados de forma jerárquica con las relaciones: extend, e include.

Una herramienta muy buena para hacer diagramas es visual paradigm, hay versiones para Windows, Mac y Linux, se puede descargar una versión community edition del sitio.

Entendiendo los casos de uso (use cases)

Los casos de uso (use cases) son unos artefactos muy recomendados para el entendimiento, descripción, documentación y trazabilidad de los requerimientos funcionales de un sistema. Hacer un modelo de casos de uso es un primer paso en el análisis de requerimientos para describir el comportamiento del sistema desde la perspectiva de los actores y los objetivos a realizar con él. Ivar Jacobson el creador de los casos de uso los describe de la siguiente manera:

Un caso de uso son todas las maneras en las que se usa un sistema para lograr una meta particular para un usuario particular. Si juntamos el conjunto de todos los casos de uso te da todas las maneras útiles para usar el sistema, e ilustra el valor que el sistema proporciona

El modelo de casos de uso es una de las vistas del modelo de arquitectura 4+1 de Philippe Kruchten, como en la siguiente imagen, el modelo de casos de uso es la quinta vista (+1).

Los casos de uso se emplean en muchos procesos de ingeniería de software entre todos ellos dos de los más ampliamente utilizados son: MSF (Microsoft Solution Framework) y RUP (Rational Unified Process).

Aunque ambos procesos cumplen el mismo objetivo (proyectos de software con éxito) cada uno de ellos ubica el modelo de casos de uso de forma un poco distinta.

En MSF se tienen 5 fases:

• Envisioning (Visualizar)
• Planning (Planear)
• Developing (Desarrollar)
• Stabilizing (Estabilizar)
• Deploying (Despliegue)

Los casos de uso (algunas veces en MSF los nombran usage cases en vez de use case), estos se crean en la fase Planning en la etapa de diseño conceptual (Conceptual Design).

En RUP se tienen 4 fases:

• Inception (Inicio)
• Elaboration (Elaboración)
• Construction (Construcción)
• Transition (Transición)

En RUP el modelo de casos de uso se crea durante la fase de inicio. en la disciplina de requisitos.

A un caso de uso informalmente se le conoce como una colección de escenarios. Un escenario es una secuencia especifica de acciones e interacciones exitosas y erróneas entre actores y el sistema bajo diferentes condiciones de operación.

A los escenarios también se le conocen como instancias de casos de uso.

Formatos para casos de uso

Los casos de uso de caja negra son la clase más común ya que no describen el funcionamiento interno del sistema sino sus responsabilidades, especifican la interacción entre el sistema y el mundo exterior en este contexto el mundo exterior se refiere a los actores, un actor en este contexto es alguien que interactua con el sistema.

Las responsabilidades del sistema en este tipo de casos de uso describen siempre que es lo que hace el sistema sin decidir como lo hace (esto le corresponde al diseño). Los tipos de casos de uso son:

1. Formato breve (brief): Es la historia del uso del sistema en un solo párrafo, por ejemplo:
   

   Crear una nueva cita: una persona entra al sitio del sistema en el menú de creación de citas, el sistema despliega la pantalla de creación de citas solicitando los siguientes datos: fecha, hora, servicio solicitado, nombre, apellido, teléfono de casa, teléfono celular, email. La persona ingresa los datos y ejecuta la acción guardar. El sistema valida los datos, una cita fue creada en el sistema.

2. Formato casual (casual version): es un un formato informal que cubre varios escenarios, este es el más ampliamente utilizado. Ejemplo:

   Historial de versiones

   Fecha	Descripción	Autor
   Noviembre 6, 2002	Initial draft	Heidi Steen

   Titulo (Title):	Creación de una cita
   Identificador (ID):	UC1
   Breve descripción (Summary):	Este caso de uso inicia cuando la persona entra al menú creación de citas del sistema, el sistema ingresa los siguientes datos: fecha, hora, servicio, nombre, apellido, email, teléfono de casa, teléfono celular. Entonces ejecuta la acción guardar entonces el sistema hace la validación y la cita es creada.

   Actores/Actors (no siempre son seres humanos, pueden ser otros sistemas informáticos o procesos se incluye el propio sistema):

   Persona, sistema médico

   Precondiciones/Preconditions (establecen lo que siempre debe cumplirse antes de iniciar el caso de uso, se asume que son verdaderas):

   1. La persona tiene acceso a Internet
   2. La persona entro en el sitio de la aplicación
   3. Los catálogos esta online y trabajan bien.

   Postcondiciones/Postconditions (establecen que debe cumplirse cuando el caso de uso termina con éxito):

   Se creo la cita en la base de datos del sistema.

   Flujo básico/Basic flow: (por lo regular no incluye ninguna condición o bifurcación, se incluyen interacción entre actores, validaciones y cambios de estados)

   Actor	Sistema
   1-. La persona entra a la aplicación y elije crear una nueva cita.
   	2-.El sistema solicita los siguientes datos: fecha, hora, servicio, nombre, apellido, email, teléfono de casa y teléfono celular.
   3-.La persona ingresa todos los datos solicitados y ejecuta la acción de guardar.
   	4-. El sistema recibe la petición, realiza la validación de los datos si no existe un error entonces crea una la cita en la base de datos y despliega un mensaje de éxito.
   5-. La persona ha creado una nueva cita.

   Flujos alternos/Alternate flows/extensions (indican los otros escenarios de éxito, las bifurcaciones del flujo básico se registran poniendo el número del paso):

   
   

   3a Ingresa solo los datos requeridos.

   3a1. La persona ingresa solo los datos mínimos requeridos: fecha, hora, servicio, nombre, apellido y al menos uno de los teléfonos: home phone y cel phone.

   
   

   Flujos de excepción: (Exception flows: Indican los escenarios de fallo, esta sección también puede incluirse dentro de los flujos alternos)

   3b Selecciona una fecha anterior a la fecha actual.

   3b1. El sistema envía el mensaje “No se permite una fecha anterior a la actual”

   
   

   4b. Faltan campos requeridos

   4b1 El sistema envía el mensaje indicando los campos requeridos que faltan.

   
   

   Requerimientos no funcionales/Non functional requirements:(aqui van los atributos de calidad que se relacionan con el caso de uso)

   • El modulo de citas debe ser visible desde cualquier dispositivo móvil.
   • La interfaz de usuario debe funcionar en cualquier navegador.
   • El tiempo de respuesta para guardar no debe sobrepasar los 10 segs.

3. Formato completo (Fully Dressed): como ejemplos de este tipo de formatos, visitar el sitio usecases.org

Elementos gráficos

El formato de casos de uso tiene una sección para prototipos gráficos (opcionales en algunas ocasiones) llamada “Pantallas del prototipo” en caso de que el sistema tenga GUI.

Por ejemplo el prototipo del ejemplo quedaría mas o menos así:

Una excelente herramienta para realizar prototipos es el proyecto pencil pencil es un proyecto open-source que incluye versiones para Linux, MacOSX y Windows.

Escritura del caso de uso en estilo esencial (Olvidarse de la GUI)

La idea de No considerar la interfaz de usuario sino concentrase en la intensión según el libro Writing effective use cases de Alistair Cockburn se deben de evitar los detalles de la GUI, recomienda hacer la narración a nivel de las intenciones del usuario y las responsabilidades del sistema suena lógico ya que el GUI cambia con más frecuencia que los procesos de negocio EBP (Elementary Business Process). La definición de EBP según el libro Applying UML and patterns de Craig Larman es:

Una tarea realizada por una persona en un lugar, en un instante, como respuesta aun evento del negocio, que añade un valor cuantificable para el negocio y deja los datos en un estado consistente.

Hay que ser claros lo esencial de los casos de uso son historias y narrativas, el producto de esta técnica son documentos de texto, los diagramas y prototipos son únicamente un complemento.

Error de MonoDevelop "MonoDevelop.GnomePlatform 5.0"

Después de instalar MonoDevelop utilizando el repositorio del sitio Monodevelop.com para OpenSuse, al intentar ejecutar la aplicación me aparecio esta pantalla.

Este error ya me había aprecido con una versión anterior de Monodevelop y Opensuse, al parecer es debido a una dependencia que no esta instalada.

Si vemos el error a detalle, se lanza por la falta de una dependencia , el nombre de esa dependencia es:

  libgnomeui
  

En OpenSuse se instala esta dependencia utilizando el instalador y desinstalador de software de YAST, una vez seleccionando el paquete que contiene la dependencia e instalandola el error se corrige.

Después de la instalación de la dependencia tendremos una versión funcionando y sin error de MonoDevelop.

Introducción a WCF con GTK# y MonoDevelop

Windows Communication Foundation (WCF) es un framework que soporta aplicaciones orientadas a servicios con herramientas que facilitan la construcción y el consumo de servicios independientes de la plataforma, proporciona un modelo unificado de programación para aplicaciones distribuidas con tecnologías como: Web Services, Remoting, COM, DCOM, WSE, MSMQ,etc.

Este modelo está enfocado a desarrollar servicios orientados a procesos de negocio que los clientes pueden acceder y utilizar sin conocer los detalles de su implementación. Los beneficios de las aplicaciones orientadas a servicios son:

1. Los servicios independientes actúan como bloques de construcción que pueden reutilizarse para la construcción de nuevas aplicaciones o servicios.
2. Las aplicaciones en este contexto están totalmente desacopladas de los procesos de negocio y se convierten únicamente en interfaces de usuario (UI) que hacen uso de los servicios, además pueden o no estar construidas con las mismas herramientas de programación que el servicio.
3. El éxito depende más de los procesos de negocio que de la tecnología.
4. Los servicios son un grupo de métodos que comparten funcionalidades, esto permite que las aplicaciones respondan a los requerimientos cambiantes sin que se desarrollen desde cero esos requerimientos.

En este contexto WCF tiene dos niveles:

1. A nivel lenguaje de programación se ve como un sistema compuesto por objetos persistentes, reglas de negocio que pueden estar en objetos de .NET o en store procedures y una interfaz de negocio que expresa las operaciones del servicio en donde se revisan las precondiciones de cada operación, se ejecutan las actividades del negocio y se regresa un resultado para el consumidor del servicio.
2. A nivel servicio se tienen operaciones que pueden ser similares a las funciones a nivel lenguaje pero que son diseñadas para ser parte del servicio. Estas operaciones combinan varias funciones a nivel lenguaje y probablemente utilicen tipos de datos más acorde con ambientes distribuidos.

WCF proporciona funcionalidad a una amplia audiencia de clientes distribuidos que no comparten un mismo espacio de direcciones, estos clientes utilizan el servicio mediante una clase proxy. Los clientes y los servicios se comunican intercambiando mensajes que no están limitados a un conjunto particular de protocolos.

Las aplicaciones orientadas a servicios es un concepto relativo al estilo de la aplicación y a la granularidad de los servicios.

Toda la información necesaria para los clientes: qué es lo que el servicio hace, como debe ser accedido, en qué lugar está disponible, etc. WCF lo encapsula en un concepto llamado EndPoint, que es básicamente una combinación de address, binding y contract (lo que comúnmente se conoce como el ABC de WCF).

Un servicio WCF consta de los siguientes elementos:

1. Un service host que proporciona el runtime para activar el servicio Web, los hay en tres tipos: Internet Information Services (IIS), Windows Activation Services (WAS) and selfhost managed applications.
2. El contrato del servicio que es una interfaz a nivel lenguaje de programación que define las operaciones que serán expuestas a través del endpoint.
3. Clases ordinarias o componentes de .NET que implementan toda la lógica de negocios.

Hay tres componentes básicos para la creación de un servicio en WCF.

• (a) El servicio WCF
• (b) El service host
• (c) El cliente

Como ejemplo, para la creación de cada uno de estos componentes, voy a programar una aplicación GTK# que recibe un número entero, manda la petición al servicio y finalmente recibe su representación binaria como una cadena.

Tarea 1: Creación del servicio WCF

1-. Ejecuta MonoDevelop y crea una nueva solución del tipo “Blank Solution” con el nombre “Samples.MyFirstWCF”.

2-.A la solución “Samples.MyFirstWCF” agrega un proyecto del tipo “Library” con el nombre “Samples.MyFirstWCF.DisplayBitsService”.

3-. Al proyecto “Samples.MyFirstWCF.DisplayBitsService” agrega los siguientes elementos:

1. Una interface con nombre IDisplayBitsServiceContract
2. Una clase con nombre DisplayBitsServiceImplementation

4-. Antes de escribir el código es importante agregar al proyecto la referencia al ensamblado System.ServiceModel

5- Escribir el siguiente código para la interfaz IDisplayBitsServiceContract:

6-. Escribir el siguiente código para la clase DisplayBitsServiceImplementation:

La solución debe de verse como en la siguiente imagen:

Tarea 2: Creación del programa Host

1-. Agrega un nuevo proyecto a la solución Samples.MyFirstWCF del tipo Console Project con el nombre de Samples.MyFirstWCF.DisplayBitsSelfHost.

2-. Agrega una referencia al ensamblado System.ServiceModel y al proyecto Samples.MyFirstWCF.DisplayBitsService.

3-.Escribe el siguiente código dentro de la clase MainClass.

La solución debe de verse como en la siguiente imagen:

Paso 3: Creación del cliente GTK#

1-. Agrega un nuevo proyecto del tipo GTK# 2.0 Project con el nombre Samples.MyFirstWCFClient.

2-. Utilizando el diseñador de MonoDevelop creamos una interfaz gráfica como se muestra en la siguiente imagen:

3-. Una aplicación cliente de WCF puede comunicarse con un servicio WCF utilizando una clase proxy. Para generar el código de esta clase, se utiliza la herramienta svcutil (ServiceModel Metadata Utility Tool).

4-. Abrimos una terminal y tecleamos el comando svcutil utilizando como argumento el ensamblado del servicio y la opción /out para ponerle nombre al archivo y no utilizar el predeterminado.

$ svcutil Samples.MyFirstWCF.DisplayBitsService.dll /out:ServiceBitsServiceReference.cs

5-. Una vez generada la clase proxy, la agregamos a la solución GTK# para que la aplicación pueda invocar los métodos del servicio. La clase proxy implementa un channel stack del lado del cliente. Todas las respuestas recibidas desde el servicio pasan a través de este stack, por lo que para comunicarse el cliente y el servicio deben utilizar un stack y una configuración equivalente.

6-. Antes de compilar es importante agregar una referencia al ensamblado System.ServiceModel.

7-. Ahora vamos a generar el código para utilizar el proxy, en la ventana Properties, busca dentro de la categoría Button Signals un evento llamado clicked, haz doble-click o pulsa enter para que MonoDevelop genere la plantilla para el evento.

8-. Agrega el siguiente código para completar el método.

9- En el panel Solution explorer, haz click derecho en la solución Samples.MyFirstWCF, y entonces en el menú Options.

10- Configura la solución para que los proyectos Samples.MyFirstWCF.DisplayBitsSelfHost y Samples.MyFirstWCFClient empiecen cuando se ejecute la solución.

11-. Compila y ejecuta la solución, si todo está bien se verán las siguientes imágenes.

Al presionar el botón el cliente envía la petición al programa host y este le regresa el resultado correcto.

Ejemplos con Join,Let y Where utilizando LINQ con C#

LINQ cuyo acrónimo significa Language INtegrated Query es un lenguaje declarativo con una sintaxis tipo SQL para consultar, buscar y manipular datos en estructuras y colecciones de .NET. Estas operaciones denominadas query expressions se aplican a Objetos, Datatables, Archivos XML, entidades, Schemas, llaves de registro, archivos de Excel,Objetos de WMI, etc.

Desde su aparición como una extensión a la versión 3.5 de Microsoft .NET, ha sido una poderosa herramienta que unifica las técnicas de acceso a datos en un modelo orientado a objetos .NET independiente de la fuente de datos.

Para ilustrar algunos ejemplos, usaré colecciones de las siguientes clases que representan la relación entre entre una factura y sus detalles como parte de una entidad factura (esto se supone en un sistema de facturación).

Con el siguiente código cargaré algunos datos para los ejemplos:

Bien ahora unos programas como ejemplos.

El operador Join

El operador Join funciona para encontrar la intersección entre dos colecciones de datos en base a un criterio, similar al INNER JOIN de SQL. El código fuente del ejemplo es el siguiente:

En este código las colecciones a unir son:

var invoices = InvoiceData.GetInvoices ();
var details = InvoiceData.GetDetails ();

El código de la consulta utilizando Join es el siguiente:

var queryjoin = from invoice in invoices
  join detail in details on invoice.InvoiceNumber equals detail.InvoiceNumber
 select new Invoice
 {
  InvoiceNumber = invoice.InvoiceNumber,
  Created = invoice.Created,
  Details = new InvoiceDetails
  {
   InvoiceNumber = detail.InvoiceNumber,
   ProductPrice = detail.ProductPrice,
   Quantity = detail.Quantity
  }
 } ;

Para compilar y ejecutar el programa con Mono se utilizan los siguientes comandos:

• mcs /t:library Invoice.cs InvoiceData.cs InvoiceDetails.cs /o:LinqSamples.dll
• mcs -r:Invoice.dll Main.cs
• mono Main.exe

Aquí la imagen del programa en ejecución.

El operador Let

Este operador permite calcular valores cuando se trabaja con múltiples colecciones de datos, en este ejemplo asignamos el valor de la propiedad Subtotal en la clase Invoice.

El código fuente del programa es el siguiente:

La consulta utilizando Let queda de la siguiente manera:

var queryLet = from invoice in invoices
 join detail in details on
 invoice.InvoiceNumber equals detail.InvoiceNumber
 let subtotal = detail.ProductPrice * detail.Quantity
 select new Invoice
 {
  InvoiceNumber = invoice.InvoiceNumber,
  Created = invoice.Created,
  Details = new InvoiceDetails
  {
   InvoiceNumber = detail.InvoiceNumber,
   ProductPrice = detail.ProductPrice,
   Quantity = detail.Quantity
  } ,
  Subtotal = subtotal
 } ;

El resultado al ejecutar este programa es el siguiente:

El operador Where

Si necesitamos múltiples criterios de selección podemos agregarlos con la palabra where justo después de los operadores let y join.

El código de la consulta utilizando Let, Join y Where es el siguiente:

El resultado al ejecutar este programa es el siguiente:

Notas acerca de las aplicaciones web

La flexibilidad del modelo cliente-servidor consiste en que una aplicación se divide en dos partes: la parte del cliente que interacciona con el usuario y la parte del servidor que coordina el flujo de actividades de los clientes.

Para efectos de desarrollo el cliente o los clientes pueden ejecutarse en la misma computadora o en diferentes computadoras dentro de la misma red LAN.

Las aplicaciones cliente-servidor se basan en protocolos y estos a su vez se registran en los documentos RFC (Request for Comment). Cualquiera puede escribir un RFC y enviarlo, si es necesario este RFC puede ser implementado de manera masiva, aunque por lo general muchos protocolos se definen pero pocos acaban implementándose, este diseño abierto de las especificaciones de un protocolo permite la independencia a las aplicaciones con respecto al método que se usara para la comunicación y de esta forma se asegura que un variedad de clientes de diferentes fabricantes de software accedan a un servicio estándar, abierto y con especificaciones comunes, sin necesidad de implementar protocolos propietarios.

Un ejemplo práctico de esto es el servicio de correo electrónico donde un cliente email en Mac, un cliente email en Windows o un cliente email en UNIX pueden conectarse al mismo servicio e intercambiar mensajes entre sí, todo esto sin necesidad de hacer cambios al servicio.

La capacidad de las aplicaciones Web proviene de los datos que transportan los protocolos, no de los protocolos en sí. La seguridad no era una preocupación cuando comenzó Internet como una red que conectaba institutos de investigación, sin embargo cuando Internet se usa para aplicaciones de negocios la seguridad se vuelve la preocupación principal por lo que además de los protocolos estándar se desarrollaron los protocolos seguros, como ejemplo: sftp, https, ssh entre otros.

Cuando se construyo ARPAnet el antecesor de Internet, los primeros servicios que se necesitaban fueron la transferencia de archivos y la emulación de terminal además de los servicios de utilidades. Así que los protocolos como chargen, echo y daytime fueron desarrollados.

Obteniendo output parameters de procedimientos PLSQL en PostgreSQL con .NET

En .NET existen dos maneras sencillas de ejecutar una procedimiento PLpgSQL y obtener la información como resultado de su ejecución.

La primera de ellas consiste en utilizar parámetros de salida (output parameters) como argumentos del procedimiento.

Para mostrarles esta manera, en el siguiente código declaro cuatro argumentos para el procedimiento, dos de ellos como parámetros de entrada y dos de ellos como parámetros de salida.

Similar a las funciones o los métodos en otros lenguajes de programación, los procedimientos PlpgSQL son subprogramas que pueden recibir parámetros de entrada (input), salida (output) y ejecutar otros procedimientos, ademas de contar con expresiones para el control del flujo.

Los procedimientos aceptan input parameters (parámetros de entrada), que se utilizan dentro del store procedure como variables locales. También puedes especificar output parameters (parámetros de salida) que permiten que un procedimiento regrese uno o más valores escalares a la rutina que llamo ese procedimiento. Cuando se ejecuta el procedimiento los valores de los parámetros de salida son almacenados en memoria.

Para demostrar su funcionalidad, creo una tabla llamada Products con el siguiente script.

Inserto unos registros de prueba y los ordeno por la columna id de forma descendente de manera que pueda saber cual es el máximo id que me regresá el procedimiento.

Ahora ejecuto el procedimiento, poniéndole valores a sus parámetros. Al terminar su ejecución el procedimiento devolverá el máximo id y la fecha en la que se inserto el registro, estos valores corresponden a sus dos parámetros output.

SELECT usp_insertproduct('M01-04-943419', 'Mesh 3in x 6in');

El código en C# para ejecutar este procedimiento y obtener sus output parameters, quedaría algo así.

La clase principal para ejecutar este código es la siguiente:

Al ejecutar este programa tecleamos el código y el nombre del producto.

Al terminar su ejecución, nos mostrará los valores de los parámetros de salida.

En el arreglo de parámetros definimos los de entrada y de salida. De manera predeterminada todos los parámetros son de entrada excepto los que explícitamente se asignan como salida:

            parameters[2] = new NpgsqlParameter("p_id", p_id);
            parameters[3] = new NpgsqlParameter("p_created",p_created);
            parameters[2].Direction = ParameterDirection.Output;
            parameters[3].Direction = ParameterDirection.Output;

Agregamos los parámetros y ejecutarmos el procedimiento

            cmd.Parameters.AddRange(parameters);
            cmd.ExecuteNonQuery();

Después asignamos los parámetros a variables en C#, para su manipulación en el programa.

       p_id = Convert.ToInt32(cmd.Parameters["p_id"].Value);
       p_created = Convert.ToDateTime(cmd.Parameters["p_created"].Value);

Los output parameters son considerados la mejor opción para regresar valores escalares.