martes, 28 de febrero de 2012

Sobrecarga de operadores en C# utilizando vectores

Además de los operadores para los tipos primitivos, C# tiene una característica conocida como sobrecarga de operadores la cuál permite que los operadores para tipos primitivos puedan utilizarse con objetos, permitiéndonos definir el tipo de operación, como se va a efectuar, los tipos involucrados y valor que devuelve, un ejemplo típico de esta funcionalidad lo tenemos en la concatenación de objetos String en donde se utiliza el símbolo "+" para la concatenación de cadenas que igualmente es utilizado para la adicción de enteros, como se muestra en los siguientes ejemplos:


Adicción de enteros
--------------------
int a = 18;
int b = 66;
Console.Write(a + b); //imprime 84

Concatenación de cadenas
-------------------------

String s1 = "Once upon ";
String s2 = "a hero ";
Console.Write(s1 + s2); //imprime Once upon a hero

Para ejemplificar como funciona la sobrecarga de operadores en objetos utilizaremos las operaciones con vectores que se estudian en el álgebra lineal, por lo que antes de codificar daremos algunas definiciones.

Un vector es un objeto perteneciente a un espacio vectorial, que para los casos particulares de espacios R2 y R3 podemos representarlos gráficamente como segmentos de línea dirigidos con un punto inicial y un punto final describiendo la asociación de una magnitud y una dirección.

Un espacio vectorial consiste de:

  1. Un campo F de escalares (en general los número reales).
  2. Un conjunto V de elementos llamados vectores.
  3. Un conjunto de reglas (u operaciones) llamadas suma y multiplicación que según los textos especialistas en la materia se dividen en dos categorías, una para la adicción y otra para la multiplicación.

Los axiomas para la adición espacios vectoriales son:
  • A1. Si u y v están en V, entonces u + v está dentro de V
  • A2. u + v = v + u para todos u y v que estan en V
  • A3. u + (v + w) = (u + v) + w para todos los u,v y w en V
  • A4. Un elemento 0 en V existe tal que v + 0 = v para cada v en V.
  • A5. Para cada v en V, existe un elemento -v en V tal que -v + v = 0 y v + (-v) = 0


Los axiomas para la multiplicación son:
  • S1. Si v esta en V entonces av esta en V para cada a en R.
  • S2. a(v + w) = av + aw para cada v y w en V y para cada a en R.
  • S3. (a+b)v = av + bv para cada v en V y para cada a y b en R.
  • S4. a(bv) = (ab)v para cada v en V y para todos cada a y b en R.
  • S5. 1v = v para cada v en V.

Ahora con estos conceptos pasemos al código, primeramente crearemos nuestra clase Vector en donde utilizando la palabra reservada operator definiremos las operaciones para demostrar algunos de los axiomas expuestos. A continuación el listado de dicha clase.


Como vemos en este código utilizamos la sobrecarga de operadores utilizando la palabra clave operator en los siguientes métodos:


public static Vector operator +(Vector u,Vector v)
public static Vector operator *(Vector u, Vector v)
public static Vector operator -(Vector u)
public static Vector operator *(double d,Vector v)
public static Vector operator *(Vector v,double d)

Aquí definimos la operación, el número de parámetros con los que se llevará a cabo y por supuesto su implementación.
Ahora con el siguiente listado mostraremos la utilización de clase Vector y el uso de la sobrecarga de operadores para vectores de números reales:

Si agregamos estas clases a un proyecto de consola en MonoDevelop podemos tener una solución lista para corregir y compilar.

Al ejecutar la solución, veremos el resultado como en la siguiente imagen:

martes, 21 de febrero de 2012

El Plan de pruebas

De las diferentes etapas del ciclo de desarrollo de sistemas, la etapa de pruebas es una de las que más recursos técnicos, administrativos y humanos puede necesitar, incluso hay ocasiones en donde dicha etapa supera o iguala el tiempo requerido para el resto de las etapas previas, por poner como ejemplo utilizando el tiempo como variable, supongamos que para el desarrollo de un sistema necesitamos x meses para las etapas de análisis, diseño y construcción entonces dependiendo del negocio y la criticidad de dicho sistema podemos requerir 2x de tiempo para las pruebas, lo cuál agrega costos adicionales al proyecto que afectan el presupuesto, sobretodo si no se esta seguro de que el sistema funcionará y se tiene una fecha compromiso.


Uno de los documentos iniciales de la fase de pruebas es el documento denominado Plan de pruebas el cuál y de forma general nos indica la estrategia de pruebas, los tipos, los roles y los criterios tanto de entrada como de salida de dichas pruebas.


A continuación como ejemplo, describo lo que dicho documento debe contener (pongo entre corchetes los párrafos que deben cambiar o complementarse ya que únicamente estan a manera de guía) lo siguiente:


Plan de pruebas



1-. Introducción

[Este plan de Pruebas o Programa de Pruebas describe la forma estándar de realizar las actividades de pruebas necesarias para cumplir con los controles de calidad y la verificación del funcionamiento del sistema XXX en cada uno de sus módulos y del sistema de manera global.]

1.1 Propósito

[Describe la estrategia de pruebas utilizada para el sistema XXX para establecer como se diseñan, ejecutan y se administran las pruebas, así también los tipos de pruebas y los recursos necesarios para su ejecución. Esto se realiza con el objetivo de identificar defectos y fallas, evaluar la calidad y determinar el cumplimiento de los requerimientos.]

1.2 Alcance

[Para esta versión del Sistema xxx se aplicarán los siguientes tipos de pruebas, las cuales se desarrollan conforme a los requisitos funcionales y a los controles de calidad.]

1.2.1 Pruebas funcionales

[Las pruebas funcionales deben focalizarse en cualquier requerimiento para probar que puedan ser rastreados directamente a los casos de uso, o reglas de negocio. Su objetivo es verificar la correcta aceptación, procesamiento y recuperación de los datos; así como la implementación apropiada de las reglas de negocio.]

1.2.2 Pruebas de Interfaz de usuario

[Estas pruebas verifican la interacción del usuario con el sistema. Su objetivo es asegurar que la interfaz gráfica de usuario (GUI) proporcione al usuario un acceso adecuado y una navegación a través de las pantallas del sistema.]

1.2.3 Pruebas de control de acceso

[Estas pruebas garantizan que, basado en la seguridad deseada, los actores estén restringidos a funciones/ casos de uso específicos o estén limitados a los datos que estén disponibles para ellos de acuerdo a su rol.]

2.1 Ambientes de prueba

[A continuación se listan los requerimientos mínimos de Hardware y Software.]

2.1.1 Hardware

[Listar todo el hardware necesario para el ambiente de pruebas, por ejemplo:
a) Estaciones de trabajo con y de RAM
b) Impresoras
c) Terminales con x,y ó z características.]

2.1.2 Software

[Listar todo el software necesario para el ambiente de pruebas, por ejemplo:
a) Sistemas Operativos x,y ó z
b) Navegadores x,y ó z a partir de la versión x
c) Suite de oficina versión x]

2.2.1 Roles y responsabilidades

[Aquí describir la participación de cada uno de los roles que participarán en la actividad de pruebas]

3 Actividades de prueba

3.1 Estrategia de pruebas

[La estrategia de pruebas se concentra en probar extensivamente el sistema para encontrar el mayor número de hallazgos inconsistencias, errores o excepciones en el sistema como parte de la ejecución de los casos de prueba.]

3.1.1 Procesos y actividades

3.1.1.1 Ciclo 1 Pruebas Unitarias

[Describir paso a paso cada una de las actividades de las pruebas unitarias]

3.1.1.2 Ciclo 2 Pruebas Funcionales

[Describir paso a paso cada una de las actividades de las pruebas funcionales]

3.1.1.3 Ciclo 3 Pruebas integrales

[Describir paso a paso cada una de las actividades de las pruebas integrales]

3.1.2.1 Pruebas Generales

[Documentar el conjunto de condiciones o variables bajo las cuáles el analista de pruebas determinará si el sistema xxx cumple con los requisitos solicitados.
Los requisitos generales que el sistema debe cumplir para su aprobación corresponden con: (aquí se sigue con la lista del tipos de pruebas que se efectuarán) ]

3.1.2.1.1 Interfaz de usuario

[a) Verificar la correspondencia entre el documento de diseño de interfaz aprobado y la implementación ejecutable del sistema.
b) Alineación de los elementos (márgenes).
c) Homogenización de estilos.
d) Corrección de ortografía.
e) Consistencia con diferentes cambios de resolución.
f) Correspondencia pantalla-fase en el Mapa de navegación.
g) Proporcionar mensajes apropiados para el manejo de errores.
h) Proporcionar (si aplica) mensajes con una retroalimentación y guías efectivos.
i) Consistencia en los elementos gráficos.
j) Organización y distribución apropiada de los elementos en la pantalla.
k) Verificar que los iconos sean significativos.]

3.1.2.1.2 Validación de las entradas

[a) Permitir solamente enteros o decimales en las entradas numéricas.
b) No permitir la entrada de caracteres especiales en las entradas para cadenas.
c) Validar los campos obligatorios.
d) Validar los límites mínimos o máximos de los campos.
e) Permitir únicamente fechas en las entradas de fechas.]

3.1.2.1.3 Funcionalidad

[a) Verificar que cada botón en la pantalla realice la funcionalidad para la que fue diseñada.
b) Que corresponda el componente con todos los requisitos solicitados por el usuario.
c) Que el sistema corresponda con los escenarios de funcionalidad esperados por el usuario.
d) Verificar el cumplimiento de la navegación entre componentes (pantallas, subprocesos, reportes).]

3.1.2.2 Documentación base para la ejecución de las pruebas

[Aquí va toda la documentación necesaria para esta etapa que se genero en las etapas anteriores.]

3.1.3 Criterios.

3.1.3.1 Criterios de Entrada

[Para comenzar la fase de pruebas del sistema, se deben de cumplir los siguientes criterios:
a) Construcción finalizada de cada componente
b) Ambiente de pruebas
c) Generación de los datos de prueba.]

3.1.3.2 Criterios de terminación

[a) Cuando no se encuentren hallazgos que impidan la operación del sistema. (ciclo 1)
b) Para los ciclos 2 y 3 se deberá contar con la aceptación del usuario.
c) El usuario deberá ser capaz de borrar los registros que haya creado.
d) Una vez que el usuario haya firmado de conformidad la funcionalidad del sistema. El área de desarrollo de sistemas no hará cambio alguno a la aplicación sin la previa solicitud correspondiente.]

4 Resultados

[Aquí se colocan todos los artefactos (documentos o reportes conteniendo el resultado de cada uno de los casos de prueba.]



El Plan de pruebas puede variar dependiendo de la metodología que se esté utilizando, pero a groso modo este es un ejemplo de como está estructurado este documento inicial e importante para la etapa de pruebas.