Las pruebas de software, (testing) son los procesos que permiten verificar la calidad de un producto software. Identifican posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento con respecto a las especificaciones iníciales.
Una definición de "testing" es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción.Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producción.
Tipos de pruebas:
Pruebas unitarias:una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código.
Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
Caracteristicas:
1.Automatizable
2.Completas
3.Repetibles o Reutilizables
4.Independientes
5.Profesionales
Pruebas funcionales: es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software.
Pruebas de Integración:Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.
es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.
Pruebas de validación:Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales.
las Pruebas de validación son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido.
Caja blanca (sistemas):es tipo de pruebas de software que se realiza sobre las funciones internas de un módulo concreto para luego realizar las de caja negra sobre varios subsistemas (integración)(componente autocontrolado de un sistema).
En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas .
Caja negra (sistemas):es aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno.Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.
pruebas de regresion:Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores.con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error.
miércoles, 15 de septiembre de 2010
Patrón de diseño
Los patrones de diseño (design patterns) son una solución a un problema de diseño y además son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos que tienen referencia con el diseño de interacción o interfaces. Un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad solucionando problemas similares en circunstancias anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a distintos problemas de diseño en diferentes situaciones.
Los patrones de diseño pretenden:
• ofrecer catálogos de elementos reusables en el diseño de sistemas software.
• No repetir la búsqueda de soluciones a problemas ya solucionados
• nivelar el modo en que se realiza el diseño.
• Hacer mas fácil el aprendizaje de nuevos diseñadores sintetizar conocimiento ya existente.
Es aconsejable utilizar los patrones de diseño en el caso de tener el mismo problema o parecido que soluciona el patrón, teniendo en cuenta que en ocasiones no aplica. Forzar el uso de los patrones puede ser errático.
Categorías de patrones
• Patrones de arquitectura
• Patrones de diseño
• Dialectos
Estructuras o plantillas de patrones
Para describir un patrón se usan plantillas más o menos estandarizadas, que puedan constituir efectivamente un medio de comunicación entre diseñadores.
La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:
• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
• Patrones relacionados: Referencias cruzadas con otros patrones.
GoF (Gang Of Four)
Patrones creacionales
• Abstract Factory: (Fábrica abstracta)
• Builder (Constructor virtual)
• Factory Method (Método de fabricación)
• Prototype (Prototipo)
• Singleton (Instancia única)
Patrones estructurales
• Adapter (Adaptador)
• Bridge (Puente)
• Composite (Objeto compuesto)
• Decorator (Envoltorio)
• Facade (Fachada)
• Flyweight (Peso ligero)
• Proxy
Patrones de comportamiento
• Chain of Responsibility (Cadena de responsabilidad)
• Command (Orden)
• Interpreter (Intérprete)
• Iterator (Iterador)
• Mediator (Mediador)
• Memento (Recuerdo)
• Observer (Observador)
• State (Estado)
• Strategy (Estrategia)
• Template Method (Método plantilla)
• Visitor (Visitante)
GRASP
"General Responsibility Assignment Software Patterns". se considera que más que patrones, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.
Experto en información
El GRASP de experto en información es el principio básico de asignación de responsabilidades.
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?
Solución: Asignar una responsabilidad al experto en información.
Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Son más fáciles de entender y mantener.
Creador
El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación de nuevos objetos o clases.
Controlador
El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.
Alta cohesión y bajo acoplamiento
Los conceptos de cohesión y acoplamiento están íntimamente relacionados. Un mayor grado de cohesión implica uno menor de acoplamiento. Maximizar el nivel de cohesión intramodular en todo el sistema resulta en una minimización del acoplamiento intermodular.
Polimorfismo
Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento
Fabricación Pura
La fabricación pura se da en las clases que no representan un ente u objeto real del dominio del problema, sino que se ha creado intencionadamente para disminuir el acoplamiento, aumentar la cohesión y/o potenciar la reutilización del código.
Indirección
El patrón de indirección nos aporta mejorar el bajo acoplamiento entre dos clases asignando la responsabilidad de la mediación entre ellos a un tercer elemento (clase) intermedio.
Alta cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.
Bajo acoplamiento
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.
Polimorfismo
Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento- utilizando operaciones polimorficas- a los tipos para los que varia el comportamiento. Asigna el mismo nombre a servicios en diferentes objetos.
Los patrones de diseño pretenden:
• ofrecer catálogos de elementos reusables en el diseño de sistemas software.
• No repetir la búsqueda de soluciones a problemas ya solucionados
• nivelar el modo en que se realiza el diseño.
• Hacer mas fácil el aprendizaje de nuevos diseñadores sintetizar conocimiento ya existente.
Es aconsejable utilizar los patrones de diseño en el caso de tener el mismo problema o parecido que soluciona el patrón, teniendo en cuenta que en ocasiones no aplica. Forzar el uso de los patrones puede ser errático.
Categorías de patrones
• Patrones de arquitectura
• Patrones de diseño
• Dialectos
Estructuras o plantillas de patrones
Para describir un patrón se usan plantillas más o menos estandarizadas, que puedan constituir efectivamente un medio de comunicación entre diseñadores.
La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:
• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
• Patrones relacionados: Referencias cruzadas con otros patrones.
GoF (Gang Of Four)
Patrones creacionales
• Abstract Factory: (Fábrica abstracta)
• Builder (Constructor virtual)
• Factory Method (Método de fabricación)
• Prototype (Prototipo)
• Singleton (Instancia única)
Patrones estructurales
• Adapter (Adaptador)
• Bridge (Puente)
• Composite (Objeto compuesto)
• Decorator (Envoltorio)
• Facade (Fachada)
• Flyweight (Peso ligero)
• Proxy
Patrones de comportamiento
• Chain of Responsibility (Cadena de responsabilidad)
• Command (Orden)
• Interpreter (Intérprete)
• Iterator (Iterador)
• Mediator (Mediador)
• Memento (Recuerdo)
• Observer (Observador)
• State (Estado)
• Strategy (Estrategia)
• Template Method (Método plantilla)
• Visitor (Visitante)
GRASP
"General Responsibility Assignment Software Patterns". se considera que más que patrones, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.
Experto en información
El GRASP de experto en información es el principio básico de asignación de responsabilidades.
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?
Solución: Asignar una responsabilidad al experto en información.
Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Son más fáciles de entender y mantener.
Creador
El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación de nuevos objetos o clases.
Controlador
El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.
Alta cohesión y bajo acoplamiento
Los conceptos de cohesión y acoplamiento están íntimamente relacionados. Un mayor grado de cohesión implica uno menor de acoplamiento. Maximizar el nivel de cohesión intramodular en todo el sistema resulta en una minimización del acoplamiento intermodular.
Polimorfismo
Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento
Fabricación Pura
La fabricación pura se da en las clases que no representan un ente u objeto real del dominio del problema, sino que se ha creado intencionadamente para disminuir el acoplamiento, aumentar la cohesión y/o potenciar la reutilización del código.
Indirección
El patrón de indirección nos aporta mejorar el bajo acoplamiento entre dos clases asignando la responsabilidad de la mediación entre ellos a un tercer elemento (clase) intermedio.
Alta cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.
Bajo acoplamiento
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.
Polimorfismo
Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento- utilizando operaciones polimorficas- a los tipos para los que varia el comportamiento. Asigna el mismo nombre a servicios en diferentes objetos.
patron vista control
Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes diferentes.
El estilo fue descrito por primera vez en 1979 por Trygve Reenskaug, entonces trabajando en Smalltalk en laboratorios de investigación de Xerox.
Descripción del patrón
• Modelo: se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también opera con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.
el flujo que sigue el control generalmente es el siguiente:
1.El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón)
2.El controlador recibe la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback(retrollamado).
3.El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4.El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.
5.La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
El estilo fue descrito por primera vez en 1979 por Trygve Reenskaug, entonces trabajando en Smalltalk en laboratorios de investigación de Xerox.
Descripción del patrón
• Modelo: se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también opera con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.
el flujo que sigue el control generalmente es el siguiente:
1.El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón)
2.El controlador recibe la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback(retrollamado).
3.El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4.El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.
5.La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
Suscribirse a:
Entradas (Atom)