El diseño arquitectónico representa la estructura de los datos y los componentes del programa que se requieren para construir un sistema de computadora.
Constituye el estilo arquitectónico que tendrá el sistema, las estructuras de datos y las propiedades de los componentes y la interrelación que tiene con otros componentes arquitectónicos.
Diagrama evolutivo de la familia Ipod
DISEÑO DE DATOS
El diseño de datos también llamado arquitectura de datos, crea un modelo de datos y/o información que se representa con un nivel de abstracción (visión de datos cliente/usuario). Este modelo de datos, es refinado en progresivas representaciones específicas de la implementación, que pueden ser procesadas por un sistema basado en computadora.
Al nivel de los componentes del programa, el diseño de las estructuras de datos y de los algoritmos asociados requeridos para su manipulación, son la parte esencial en la creación de aplicaciones de alta calidad. Al nivel de aplicación, la traducción de un modelo de datos en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema. Al nivel de negocios, el conjunto de información almacenada en las diferentes bases de datos y reorganiza en el almacén de datos facilita la minería de datos o el descubrimiento de conocimiento que puede influir en el próximo éxito del negocio.
Principios para la especificación de los datos:
1. Los principios del análisis sistemático aplicado a la función y al comportamiento deberían aplicarse también a los datos.
2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.
3. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa
4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.
5. La representación de las estructuras de los datos deberían conocerla solo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
6. Deberían desarrollarse una biblioteca de estructuras de los datos útiles y de las operaciones que se les pueden aplicar.
7. Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos.
Principios para la especificación de los datos:
1. Los principios del análisis sistemático aplicado a la función y al comportamiento deberían aplicarse también a los datos.
2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.
3. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa
4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.
5. La representación de las estructuras de los datos deberían conocerla solo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
6. Deberían desarrollarse una biblioteca de estructuras de los datos útiles y de las operaciones que se les pueden aplicar.
7. Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos.
Las interfaces básicas de usuario son aquellas que incluyen cosas como menús, ventanas, teclado, ratón, los "beeps" y algunos otros sonidos que la computadorahace, en general , todos aquellos canales por los cuales se permite la comunicación entre el hombrey la computadora .
La idea fundamental en el conceptode interfaz es el de mediación, entre hombre y máquina. La interfaz es lo que "media", lo que facilita la comunicación , la interacción, entre dos sistemas de diferente naturaleza, típicamente el ser humano y una máquina como el computador. Esto implica , además, que se trata de un sistema de traducción, ya que los dos "hablan" lenguajes diferentes: verbo-icónico en el caso del hombre y binario en el caso del procesador electrónico.
De una manera más técnica se define a Interfaz de usuario, como conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. El usuario dirige el funcionamiento de la máquina mediante instrucciones, denominadas genéricamente entradas . Las entradas se introducen mediante diversos dispositivos, por ejemplo un teclado , y se convierten en señales electrónicas que pueden ser procesadas por la computadora. Estas señales se transmiten a través de circuitos conocidos como bus, y son coordinadas y controladas por la unidad de procesocentral y por un soporte lógico conocido como sistema operativo. Una vez que la UPC ha ejecutado las instrucciones indicadas por el usuario, puede comunicar los resultados mediante señales electrónicas, o salidas, que se transmiten por el bus a uno o más dispositivos de salida, por ejemplo una impresora o un monitor.
Interfaces orientadas a la aplicación | Interfaces orientadas a objetos |
La aplicación consiste en un icono, una ventana principal y varias secundarias | El producto consiste en una colección de objetos que cooperan y vistas de dichos objetos |
Los iconos representan aplicaciones o ventanas abiertas | Los iconos representan objetos que se pueden manipular directamente |
Los usuarios deben abrir una aplicación antes de | Los usuarios abren objetos como vistas en el escritorio |
Proporciona al usuario las funciones necesarias para realizar las tareas | Proporciona al usuario los materiales necesarios para realizar las tareas |
Se centra en la tarea principal determinada por la aplicación | Se centra en las entradas y salidas de los objetos y tareas |
Las tareas relacionadas son soportadas por otras aplicaciones | Las tareas relacionadas son soportadas por el uso de otros objetos |
Estructura rígida: | Estructura flexible: objeto |
Los usuarios pueden quedar atrapados en una tarea | Los usuarios no deben quedar atrapados en una tarea |
Los usuarios deben seguir la estructura de la aplicación | Los usuarios pueden realizar tareas a su propio gusto |
Se requieren muchas aplicaciones: una por tarea | Se requieren pocos objetos, que se reutilizan en muchas tareas |
PRUEBAS DEL SOFTWARE
Una de las características típicas del desarrollo de software basado en el ciclo de vida es la realización de controles periódicos, normalmente coincidiendo con los hitos del proyectos o la terminación de documentos. Estos controles pretenden una evaluación de la calidad de los productos generados (especificación de requisitos, documentos de diseño, etc.) para poder detectar posibles defectos cuanto antes. Sin embargo, todo sistema o aplicación, independientemente de estas revisiones, debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminación del código del software, se denominan habitualmente pruebas.
Las pruebas constituyen un método más para poder verificar y validar el software. Se puede definir la verificación como [IEEE, 1990] “el proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase”. Por ejemplo, verificar el código de un módulo significa comprobar si cumple lo marcado en la especificación de diseño donde se describe. Por otra parte, la validación es “el proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados”. Así, validar una aplicación implica comprobar si satisface los requisitos marcados por el usuario. Podemos recurrir a la clásica explicación informal de Boehm de estos conceptos:
· Verificación: ¿estamos construyendo correctamente el producto?
· Validación: ¿estamos construyendo el producto correcto?
Como hemos dicho, las pruebas permiten verificar y validar el software cuando ya está en forma de código ejecutable. A continuación, expondremos algunas definiciones de conceptos relacionados con las pruebas.
3.1. Definiciones
Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en relación a las pruebas [IEEE, 1990], que complementamos con otras más informales
Pruebas (test): “una actividad en la cual un sistema o uno de sus componentes se ejecuta 2 en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto”. Para Myers [MYERS, 1979], probar (o la prueba) es el “proceso de ejecutar un programa con el fin de encontrar errores”. El nombre “prueba”, además de la actividad de probar, se puede utilizar para designar “un conjunto de casos y procedimientos de prueba” [IEEE, 1990].
Caso de prueba (test case): “un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito”. También se puede referir a la documentación en la que se describen las entradas, condiciones y salidas de un caso de prueba.
· Defecto (defect, fault, “bug”): “un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa”.
· Fallo (failure): «La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados».
· Error (error): tiene varias acepciones:
1. La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o teóricamente correcto. Por ejemplo, una diferencia de dos centímetros entre el valor calculado y el real.
2. Un defecto. Por ejemplo, una instrucción incorrecta en un programa.
3. Un resultado incorrecto. Por ejemplo, un programa ofrece como resultado de la raíz cuadrada de 36 el valor 7 en vez de 6.
4. Una acción humana que conduce a un resultado incorrecto (una metedura de pata). Por ejemplo, que el operador o el programador pulse una tecla equivocada.
Técnicas de diseño de casos de prueba
El diseño de casos de prueba está totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que sólo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente, todos los valores válidos que se pueden sumar, deberíamos probar 10.000 combinaciones distintas de cien posibles números del primer sumando y cien del segundo. Pensemos que aún quedarían por probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un número). La conclusión es que, si para un programa tan elemental debemos realizar tantas pruebas, pensemos en lo que supondría un programa medio.
En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarán los defectos existentes (ya que la seguridad total sólo puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad de consumir una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecución). Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difícil que está lejos de parecerse a la imagen de actividad rutinaria que suele sugerir.
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea fundamental para el diseño de casos de prueba consiste en elegir algunas de ellas que, por sus características, se consideren representativas del resto. Así, se asume que, si no se detectan defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la elección de los casos) en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una elección puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos números, elegir cuatro pares de sumandos al azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de elección que veremos a continuación.
Técnicas de diseño de casos de prueba
El diseño de casos de prueba está totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que sólo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente, todos los valores válidos que se pueden sumar, deberíamos probar 10.000 combinaciones distintas de cien posibles números del primer sumando y cien del segundo. Pensemos que aún quedarían por probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un número). La conclusión es que, si para un programa tan elemental debemos realizar tantas pruebas, pensemos en lo que supondría un programa medio.
En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarán los defectos existentes (ya que la seguridad total sólo puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad de consumir una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecución). Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difícil que está lejos de parecerse a la imagen de actividad rutinaria que suele sugerir.
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea fundamental para el diseño de casos de prueba consiste en elegir algunas de ellas que, por sus características, se consideren representativas del resto. Así, se asume que, si no se detectan defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la elección de los casos) en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una elección puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos números, elegir cuatro pares de sumandos al azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de elección que veremos a continuación.
Existen tres enfoques principales para el diseño de casos:
1. El enfoque estructural o de caja blanca (véase la figura 2). Consiste en centrarse en la estructura interna (implementación) del programa para elegir los casos de prueba. En este caso, la prueba ideal (exhaustiva) del software consistiría en probar todos los posibles caminos de ejecución, a través de las instrucciones del código, que puedan trazarse.
2. El enfoque funcional o de caja negra (véase la figura 2). Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software consistiría en probar todas las posibles entradas y salidas del programa.
3. El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. La prueba exhaustiva consistiría en probar todas las posibles entradas al programa.
Estos enfoques no son excluyentes entre sí, ya que se pueden combinar para conseguir una detección de defectos más eficaz. Veremos a continuación una presentación de cada uno de ellos.
