Q & A Preguntas y respuestas acerca de los sistemas de bases de datos (DBMS)

1. ¿Qué es la abstracción de datos?

2. ¿Qué hace el administrador de la base de datos?

3. ¿Cuáles son las aplicaciones de los sistemas de datos?

4. ¿Qué contiene un Diccionario de datos?

5. ¿Qué es un ejemplar de la base de datos?

6. ¿Qué es el esquema de la base de datos?

7. ¿Qué es la inconsistencia de datos?

8. ¿Qué es un lenguaje de consultas?

9. ¿Qué es un lenguaje de definición de datos?

10. ¿Qué es un lenguaje de manipulación de datos?

11. ¿Qué son los Metadatos?

12. ¿Qué es el modelo de datos orientados a objetos?

13. ¿Qué es el modelo de datos relacional?

14. ¿Qué es el Modelo de datos relacional orientado a objetos?

15. ¿Qué es un programa de aplicación?

16. ¿Qué es un sistema de gestión de base de datos?

17. ¿Qué es una transacción?

18. ¿Qué es una agregación?

19. ¿Qué es un atributo derivado?

20. ¿Qué son los atributos?

21. ¿Qué son los atributos descriptivos?

22. ¿Qué son los atributos monovalorados y multivalorados?

23. ¿Qué son los atributos simples y compuestos?

24. ¿Qué es un conjunto de entidades?

25. ¿Qué es un conjunto de relaciones?

26. ¿Qué es el conjunto de relaciones binario?

27. ¿Qué es un conjunto de relaciones recursivo?

28. ¿Qué son los conjuntos de entidades débiles y fuertes?

29. ¿Qué son los atributos discriminantes?

30. ¿Qué son las relaciones identificadoras?

31. ¿Qué es la correspondencia de cardinalidad?

32. ¿Qué es la relación uno a uno?

33. ¿Qué es la relación varios a uno?

34. ¿Qué es la relación varios a varios?

35. ¿Para que se utiliza el diagrama E-R (Entidad-relación)?

36. ¿Cuál es la diferencia entre clave candidata y clave primaria?

37. ¿Qué es el valor nulo?

Respuestas

R1. La recuperación de datos debe ser eficiente por lo que se requieren elaboradas estructuras de datos, los desarrolladores utilizan niveles de abstracción a nivel físico, lógico y de vistas para esconder la complejidad a los usuarios

R2. La persona que tiene el control central sobre el sistema de gestión de base de datos, sus tareas son: definición del esquema, definición de la estructura y del método de acceso, modificación del esquema y de la organización, concesión de la autorización para el acceso a datos y el mantenimiento rutinario.

R3. Las bases de datos son usadas en: banca, líneas áreas, universidades, transacciones de tarjetas de crédito, telecomunicaciones, finanzas, ventas, producción y recursos humanos.

R4. Un diccionario de datos contiene metadatos es decir datos acerca de los datos. El esquema de una tabla es un ejemplo de metadatos.

R5. Es la colección de la información almacenada en la base de datos en un momento en particular. Ya que las bases de datos van cambiando a lo largo del tiempo conforme la información se inserta y se borra.

R6. Es el diseño completo de la base de datos y son raramente modificados.

• Esquema físico: El esquema físico describe el diseño físico en el nivel más bajo de abstracción, describe como se almacenan realmente los datos, las estructuras complejas de bajo nivel.
• Esquema lógico: describe el diseño de la base de datos en un nivel más alto de abstracción, describe que datos se almacenan y que relaciones existen entre esos datos.

R7. Debido a que los archivos y programas de aplicación son creados por diferentes programadores en un largo período de tiempo, los diversos archivos tienen probablemente diferentes formatos y los programas pueden estar escritos en diferentes lenguajes. Las diversas copias de los mismos datos pueden no coincidir.

R8. Es la parte de un LMD (Lenguaje de manipulación de datos) que implica recuperación de información.

R9. Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado lenguaje de definición de datos.

R10. Es un lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado.

R11. Es decir son los datos acerca de los datos. El esquema de una tabla es un ejemplo de metadatos.

La navaja de Ockham o principio KISS en el desarrollo de software

La navaja de Ockham o el principio de parsimonia es el principio metodológico ideado por William of Ockham (1285-1347) filósofo nominalista que se utiliza para “cortar” o "rasurar" todo aquel conocimiento que no provenga de los datos de los sentidos, es decir invalidar los conceptos que no sean comprobables por la experiencia misma.

La formulación correcta de Ockham es:

No hay que multiplicar los entes sin necesidad (entia non sunt multiplicanda praeter necessitaem).

La navaja funciona de la siguiente manera: cuando se nos ofrecen dos o más hipótesis en igualdad de circunstancias para explicar un determinado fenómeno, es razonable aceptar la hipótesis más simple o sea la que incluye menos supuestos no probados.

En otros campos del conocimiento la navaja de Ockham se utiliza para eliminar objetos o tipos de objetos que no aportan o cambian en nada las particularidades efectivas de las cosas. En informática a la navaja de Ockham se le conoce como el principio KISS, siglas que significan:

Keep It Simple, Stupid! (Mantenlo simple, estúpido)

Aplicando el KISS al desarrollo de software tenemos que pequeño y sencillo es mejor que grande y complejo. En pocas palabras, entre más pequeño sea el número de componentes o de código involucrado en un proyecto menor será la cantidad de errores o problemas asociados al mantenimiento. Lo que incrementa la probabilidad de una entrega exitosa a tiempo.

Hay un principio de la filosofía UNIX que ejemplifica la aplicación de un principio KISS:

*“En lugar de tener pocos programas grandes, cada uno tratando de hacer muchas cosas, el sistema UNIX proporciona muchas herramientas simples que pueden combinarse para realizar un amplio rango de cosas.”

*Rosen Kenneth, Rosinki Richard, UNIX System V release 4. An introduction. Second Edition, Mc Graw Hill

Algunos ejemplos del KISS en el desarrollo de software son:

• No intentes complicar el modelo de base de datos agregando entidades que nada aportan al negocio funcional. Solo agrega las entidades que requieren una persistencia.
• No toda la persistencia necesita estar en una base de datos, hay ocasiones en que los archivos de texto plano son la mejor opción para el rendimiento.
• No requieres un RDBMS para guardar una agenda de contactos.
• No intentes optimizarlo si ni siquiera funciona o no esta terminado.
• La complejidad de los algoritmos o el número de capas que se agreguen a una arquitectura son inútiles si estos no resuelven los requerimientos funcionales, y al serán ignorados por los usuarios finales.

Hay una frase que también es un claro ejemplo de este principio:

Premature optimization is the root of all evil. (la optimización prematura es la raíz de todos los males)

--Sir Charles Anthony Richard Hoare, inventor del algoritmo Quicksort.

Hay que aclarar que la navaja de Ockham no sostiene que la hipótesis más simple sea la correcta, sino sencillamente que es la que tiene más probabilidades de ser la correcta.

Notas acerca de los riesgos en un proyecto de software

¿Qué es un riesgo?

No importa que tan bien se hagan los planes, siempre surgirán problemas inesperados. En ningún proyecto hay garantías, incluso la actividad más trivial conlleva problemas inesperados. En cualquier momento puede ocurrir algo que desvié el resultado de una actividad. Es un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en los objetivos del proyecto.

Factores de riesgo en un proyecto

• Requerimientos excesivos
• Falta de involucramiento del usuario o del cliente
• Subestimación de la naturaleza dinámica o de la complejidad del proyecto
• Costos o calendarios no realistas
• Ineficiente administración de proyectos
• Deficiencias en cada una etapas del ciclo de vida
• Utilización de procesos o tecnologías inmaduras o no adecuadas para la medida del proyecto
• Pobre capacitación

Algunos de los problemas que ocasionan los riesgos

• Baja calidad en los productos de software
• Retraso en el calendario
• Perdidas en los costos
• Moral baja

Características de un riesgo bien analizado

• Tiene umbrales definidos claramente
• La probabilidad e impacto estimados son realistas
• Su plan de mitigación y de contingencias debe ser claro y efectivo
• La responsabilidad de su monitoreo y control, está claramente asignada a uno o varios responsables

Existen los riesgos positivos

No todos los riesgos son negativos. Algunos eventos o condiciones pueden ser de ayuda para el proyecto por ejemplo: Alguna descuento en los costos de capacitación, encontrar un componente que ahorre tiempo de construcción, etc. Si esto sucede sin duda se le conocerá como una oportunidad, sin embargo desde la perspectiva de la administración de proyectos se le catalogará como riesgo.

Pasos para manejar un riesgo

22
• Evitarlo: Una de las mejores maneras para manejar un riesgo es evitarlo, si es posible hacer todo lo posible para que no suceda.
• Mitigarlo: Si no es posible evitar el riesgo, deben tomarse acciones para disminuir los efectos que se originen cuando el riesgo se transforme en un problema.
• Transferirlo: Buscar la ayuda de otra instancia que tenga la capacidad para mitigarlo o desaparecerlo.
• Aceptarlo: Cuando no puede evitarse, mitigarse o transferirse deberá de aceptarse para no caer en la frustración y el desanimo.

Imagen de http://www.coreyhelfordgallery.com/artists/

¿Qué es el análisis postmortem en un proyecto de software?

En el contexto de los proyectos de desarrollo de software, un análisis Postmortem es el proceso de revisar la historia del proyecto para entender cómo cada uno de los eventos contribuyo al éxito o fracaso del proyecto.

En resumen: es el análisis retrospectivo realizado por todos los miembros del equipo de trabajo una vez que el proyecto concluye, sea exitosa o no esta conclusión.

Al realizar este análisis se busca identificar los aspectos positivos aplicados en el proyecto para que puedan repetirse, así como plantear soluciones y mejoras de los aspectos negativos, asimilando la experiencia para que no vuelvan a repetirse. Todo ello se conoce de forma simple como Lecciones Aprendidas.

Beneficios

Realizar un análisis de las experiencias buenas y malas adquiridas en el proyecto, es necesario para:

• Identificar los aspectos que pueden mejorarse en proyectos futuros.
• Obtener las experiencias de todos los involucrados en el proyecto, concentrando opiniones , puntos de vista y generando conclusiones en grupo.
• Formar una base de conocimientos de “Lecciones Aprendidas” para que sean conocidas, revisadas y consideradas en otros proyectos con características similares.
• Si hay un proyecto nuevo los recursos nuevos que tengan acceso a las lecciones aprendidas no tendrán justificación para repetir los mismos errores que se cometieron en sus proyectos anteriores.
• Aplicar las lecciones aprendidas al proceso de estimación de un proyecto de software proporciona un par de beneficios, en principio, ayuda a la organización a prevenir desarrollar proyectos que no generan ganancias. Segundo, se orilla a que la estimación sea más precisa y exacta ya que la organización podría emplear un presupuesto inflado. Cuando la organización tiene confianza en sus estimaciones, es una organización más competitiva.

Actividades

1. Aplicar cuestionario Postmortem.
2. Realizar la reunión Postmortem.
3. Registrar lecciones aprendidas.

Aplicar cuestionario Postmortem esta actividad se realiza para obtener las experiencias de los recursos que participan en algún momento en el proyecto y que por algún motivo salen antes de que este concluya. En la ejecución de esta actividad participan: el responsable del proyecto quien se asegura de que todos los recursos que salen antes de que el proyecto concluya, apliquen el cuestionario y el miembro del equipo de trabajo que sale del proyecto se requiere que conteste el cuestionario. Los cuestionarios que se recopilen serán revisados por el responsable del proyecto para concentrar las experiencias obtenidas y resumirlas en la presentación Postmortem.

Realizar la reunión postmortem Los datos del proyecto que deben considerarse en esta presentación, son:

• Datos generales del proyecto
• Evaluación del alcance
• Evaluación de la planeación
• Evaluación de la capacitación
• Evaluación de la calidad
• Evaluación del proceso
• Oportunidades y conocimientos adquiridos
• Evaluación de la percepción del cliente

Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.

Consideraciones

Al ejecutar esta actividad es muy importante tomar en cuenta los siguientes aspectos:

• Planear las actividades necesarias para ejecutar el proceso postmortem en todos los proyectos.
• La reunión postmortem debe ejecutarse inmediatamente al concluir el proyecto.
• Es necesario contar con las aportaciones de todos los recursos que en algún momento se vieron involucrados en el proyecto.
• Deben exponerse los aspectos positivos y negativos registrados en el proyecto.
• Calificar al proyecto, no a las personas.
• Realizar recomendaciones que complementen las lecciones aprendidas.
• Los datos obtenidos en la presentación postmortem son utilizados en la presentación de cierre del proyecto.

Cuestionario Postmortem

La recopilación de las experiencias adquiridas por todos los recursos que participaron en algún momento en el proyecto se realiza a partir de la aplicación del cuestionario Postmortem en el caso de los recursos que participaron hasta el cierre del proyecto. A continuación un ejemplo de las secciones de un cuestionario Postmortem

1.Datos generales

[Aquí describe tu participación dentro del proyecto]

1. Nombre completo:
2. Rol:
3. Periodo de participación: [Total o parcial, especifique el periodo en el que permaneció en el proyecto, este será total si participo en todas las fases del proyecto, será parcial si solo participo en una fase del proyecto]
4. Jefe inmediato/ Rol:[Especifique el nombre del jefe inmediato y su participación]

2. Evaluación de la planeación

[Sección dedicada a describir la percepción respecto a la planeación de actividades en el proyecto, poner las razones en cada respuesta]

1. ¿Existieron diferencias entre el número planeado de artefactos/productos contra el real?
2. ¿Se presentó alguna diferencia entre el tiempo planeado contra el real?
3. ¿Existe alguna diferencia entre las disciplinas en las que se tiene planeada tu participación y en las que realmente participaste?

3. Evaluación de la Capacitación

[Aquí se pone la percepción respecto a las actividades de entendimiento del negocio]

1. ¿Recibiste la capacitación técnica necesaria para realizar tus funciones?
2. ¿Consideras que recibiste la capacitación necesaria del conocimiento del negocio de acuerdo a tu perfil?

4. Evaluación de la calidad

[Aquí indica los productos que fueron generados durante el proyecto, pudiendo ser documentos, código, modelos o diagramas]

5. Evaluación del Proceso

[Sección dedicada a evaluar el proceso de desarrollo de software] En un proyecto similar, qué acciones, actitudes y decisiones tendrían que ser diferentes y cuáles podrían repetirse en cuanto a:

1. La capacitación para el proyecto.
2. Las disciplinas ejecutadas en el proyecto.
3. Las herramientas utilizadas para el proyecto.
4. La infraestructura con la que contó el proyecto.
5. La administración del proyecto.

NOTA: Hay que tener en cuenta que los cuestionarios Postmortem pueden variar de acuerdo a la organización o a la metodología que se utilice.

Utilizando el HTML 5 Boiler template

El HTML 5 Boilerplate es como dicen sus autores (The web's most popular front-end template) o sea una plantilla que contiene una estructura básica para construir el front-end de cualquier aplicación web que utilice como base de su construcción HTML5, CSS y JavaScript.

Una vez descargado el comprimido de este enlace, solamente se descomprime y ya está listo para utilizarse en cualquier proyecto web.

Aquí una imagen de la estructura de la plantilla, una vez extraída.

Como se muestra, tiene todo lo necesario para empezar: directorio css y js para las hojas de estilo y archivo JavaScript respectivamente, hasta un archivo index y 404 listos para personalizarse según las necesidades.

Si se desea conocer la documentación, hay que ir a este sitio.

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.

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.

El patrón singleton

Muchos problemas de rendimiento (performance) y de escalabilidad (scalability) ocurren si no manejamos correctamente las conexiones a las bases de datos, hay que tener en presente que las conexiones para acceder a una base de datos son un recurso que consume memoria y tiempo de procesador, por lo que solo se deben crear las conexiones necesarias para el funcionamiento de las aplicaciones y estas deben cerrarse tan pronto hayan sido ocupadas.
Una buena práctica es que todas las clases que acceden a los recursos de la base de datos utilicen siempre una única conexión sin importar el número de instancias que estas clases generen al ser ejecutadas dentro de una aplicación, una solución recomendada a este escenario es utilizar los patrones de diseño de software.

Conectarse a una base de datos con el patrón Singleton

Es un patrón de diseño del tipo creacional que nos asegura la creación de únicamente la instancia de un objeto sin importar el número de veces que se intenten crear más instancias de ese objeto.
citando el clásico libro de the gang of four Design Patterns:Elements of Reusable Object-Oriented Software, 1995, Pearson Addison Wesley "The Singleton design pattern must ensure a class only has one instance, and provide a global point of access to it"

Este patrón se utiliza para representar un objeto de hardware (por ejemplo una impresora), un componente del sistema operativo (un archivo o un directorio) o bien un recurso externo limitado (como una conexión a una base de datos), esta instancia revisará si ya ha sido creada, atenderá las peticiones de los objetos que la utilicen como un punto global de acceso (similar a una variable global) y sera responsable del mantener el seguimiento de su estado.
El esqueleto clásico de un Singleton es el siguiente:

A continuación voy a mostrar el ejemplo de una clase que representa una conexión a una base de datos sin utilizar el patrón Singleton, para mostrar como se crea una conexión por cada ocasión que nosotros llamamos a la clase lo cual repercute en la escalabilidad y el desempeño de la aplicación si se tuvieran que invocar decenas o cientos las ejecuciones a esta clase. Descarga el código del ejemplo sin utilizar Singleton de este

Al compilar y ejecutar la aplicación se mostrará el siguiente menú.

Escogiendo la opción (a) nos mostrará el menú para solicitarnos los parámetros de la cadena de conexión, si repetimos este procedimiento nos mostrará
las conexiones hechas hacia el servidor, una por cada vez que hayamos completado la opción (a) como se muestra en la siguiente imagen.

Observamos en la imagen como es diferente el tiempo entre cada una de las conexiones ya que se crea una conexión por cada llamado.

Bien ahora mostraremos el mismo ejercicio utilizando el patrón Singleton en el código de la clase DataBase, pero para no sobrescribir la clase DataBase del ejercicio anterior, nombraremos la clase Singleton como DataBase2.

Descarga el código del ejemplo utilizando Singletonde este

Si analizamos el patron Singleton vemos el uso de los modificadores private y static en el constructor hace que no se pueda crear la clase de forma directa, sino solo a traves del método public GetInstance(string conStr) que regresa la instancia creada y por ende sus propiedades y métodos públicos.
Ejecutando la aplicación, seleccionando la opción (a) para conectarse a una base de datos y creando varias conexiones debemos de ver la salida del programa como en la siguiente pantalla:

Observamos en la imagen como el tiempo y las propiedades entre cada una de las conexiones es siempre el mismo, ya que se crea una sola instancia global de acceso.