El encapsulamiento es una característica de la programación modular en general, y más concretamente de programación orientada a objetos (entendiéndose un objeto como una clase de módulo).
El encapsulamiento consiste en ocultar los detalles de la implementación de un objeto, a la vez que se provee una interfaz pública por medio de sus métodos permitidos. También se define como la propiedad de los objetos de permitir acceso a su estado solamente a través de su interfaz o de relaciones preestablecidas con otros objetos.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
martes, 30 de octubre de 2007
CLASE ABSTRACTA
Clase Abstracta La herencia permite que existan clases que nunca sean instanciadas directamente. En el ejemplo anterior, una clase "perro" heredaría los atributos y métodos de la clase "mamífero", así como también "gato", "delfín" o cualquier otra subclase; pero que ocurra que en el sistema no haya ningún objeto "mamífero" que no pertenezca a alguna de las subclases. En ese caso, a una clase así se la conocería como Clase Abstracta. La ausencia de instancias específicas es su única particularidad, para todo lo demás es como cualquier otra clase
HERENCIA
La herencia es uno de los mecanismos de la programación orientada a objetos, por medio del cual una clase se deriva de otra, llamada entonces superclase, de manera que extiende su funcionalidad. Una de sus funciones más importantes es la de proveer Polimorfismo y late binding.
La idea es la de partir de las situaciones más generales e ir derivando hacia las más particulares, creando categorías, de la misma forma en que piensa el ser humano.
La idea es la de partir de las situaciones más generales e ir derivando hacia las más particulares, creando categorías, de la misma forma en que piensa el ser humano.
METODOS
Implementan la funcionalidad asociada al objeto. Los métodos son el equivalente a las funciones en los lenguajes estructurados. Se diferencian de ellos en que es posible acceder a las variables de la clase de forma implícita.
Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción.
Habitualmente, los métodos suelen ser verbos.
Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción.
Habitualmente, los métodos suelen ser verbos.
CLASES
Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase.
Componentes Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje.
Componentes Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje.
domingo, 23 de septiembre de 2007
ETAPA DE PRUEBAS
Etapa: Pruebas
La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica:
Verificar la interacción de componentes.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida: podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad, cobertura y rendimiento de la arquitectura; probar el producto final, etc. Lo que conduce al principal beneficio de la prueba: proporcionar feedback mientras hay todavía tiempo y recursos para hacer algo.
La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
Cualquier proceso de ingeniería puede ser probado de una de dos formas:
Se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa.
Se pueden desarrollar pruebas que aseguren que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.
La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la caja blanca.
Prueba de caja blanca:
Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que garanticen que:
Se ejercitan todos los caminos independientes de cada módulo.
Se ejercitan todas las decisiones lógicas.
Se ejecutan todos los bucles.
Se ejecutan las estructuras de datos internas.
Prueba de caja negra:
Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretende demostrar que:
Las funciones del software son operativas.
La entrada se acepta de forma adecuada.
Se produce una salida correcta, y
La integridad de la información externa se mantiene.
Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa.
La prueba de la caja negra intenta encontrar errores de las siguientes categorías:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores de rendimiento.
Errores de inicialización y de terminación.
Los casos de prueba deben satisfacer los siguientes criterios:
Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba adicionales.
Que digan algo sobre la presencia o ausencia de clases de errores.
TIPOS DE PRUEBAS
Pruebas de unidad:
La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca.
Prueba de integración:
El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.
Hay dos formas de integración:
Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto.
Integración incremental: El programa se construye y se prueba en pequeños segmentos.
En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software.
Las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra, aunque se pueden llevar a cabo unas pocas pruebas de caja blanca.
Prueba del sistema:
Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son:
Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente.
Prueba de seguridad: Verificar los mecanismos de protección.
Prueba de resistencia: Enfrenta a los programas a situaciones anormales.
Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución.
Prueba de instalación: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.
Pruebas de regresión:
Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que:
Los defectos identificados en la ejecución anterior de la prueba se ha corregido.
Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.
La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior.
Estrategias de pruebas del software:
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.
Las características generales son:
La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
La prueba y la depuración son actividades diferentes.
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
Planificación de las pruebas.
Diseño de las pruebas.
Implementación de las pruebas.
Ejecución de las pruebas.
Evaluación de las pruebas.
La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica:
Verificar la interacción de componentes.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida: podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad, cobertura y rendimiento de la arquitectura; probar el producto final, etc. Lo que conduce al principal beneficio de la prueba: proporcionar feedback mientras hay todavía tiempo y recursos para hacer algo.
La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
Cualquier proceso de ingeniería puede ser probado de una de dos formas:
Se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa.
Se pueden desarrollar pruebas que aseguren que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.
La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la caja blanca.
Prueba de caja blanca:
Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que garanticen que:
Se ejercitan todos los caminos independientes de cada módulo.
Se ejercitan todas las decisiones lógicas.
Se ejecutan todos los bucles.
Se ejecutan las estructuras de datos internas.
Prueba de caja negra:
Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretende demostrar que:
Las funciones del software son operativas.
La entrada se acepta de forma adecuada.
Se produce una salida correcta, y
La integridad de la información externa se mantiene.
Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa.
La prueba de la caja negra intenta encontrar errores de las siguientes categorías:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores de rendimiento.
Errores de inicialización y de terminación.
Los casos de prueba deben satisfacer los siguientes criterios:
Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba adicionales.
Que digan algo sobre la presencia o ausencia de clases de errores.
TIPOS DE PRUEBAS
Pruebas de unidad:
La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca.
Prueba de integración:
El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.
Hay dos formas de integración:
Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto.
Integración incremental: El programa se construye y se prueba en pequeños segmentos.
En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software.
Las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra, aunque se pueden llevar a cabo unas pocas pruebas de caja blanca.
Prueba del sistema:
Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son:
Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente.
Prueba de seguridad: Verificar los mecanismos de protección.
Prueba de resistencia: Enfrenta a los programas a situaciones anormales.
Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución.
Prueba de instalación: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.
Pruebas de regresión:
Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que:
Los defectos identificados en la ejecución anterior de la prueba se ha corregido.
Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.
La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior.
Estrategias de pruebas del software:
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.
Las características generales son:
La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
La prueba y la depuración son actividades diferentes.
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
Planificación de las pruebas.
Diseño de las pruebas.
Implementación de las pruebas.
Ejecución de las pruebas.
Evaluación de las pruebas.
ENTORNO DE DESARROLLO INTEGRADO
Entorno integrado de desarrollo
Un entorno de desarrollo integrado o en inglés Integrated Development Environment ('IDE') es un programa compuesto por un conjunto de herramientas para un programador.
Puede dedicarse en exclusiva a un sólo lenguaje de programación o bien, poder utilizarse para varios.
Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica GUI. Los IDEs pueden ser aplicaciones por si solas o pueden ser parte de aplicaciones existentes. El leguaje Visual Basic por ejemplo puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.
Los IDEs proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, Java, C#, Visual Basic, Object Pascal, Velneo, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.
Es posible que un mismo IDE pueda funcionar con varios lenguajes de programación. Este es el caso de Eclipse, que mediante pluggins se le puede añadir soporte de lenguajes adicionales
Un entorno de desarrollo integrado o en inglés Integrated Development Environment ('IDE') es un programa compuesto por un conjunto de herramientas para un programador.
Puede dedicarse en exclusiva a un sólo lenguaje de programación o bien, poder utilizarse para varios.
Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica GUI. Los IDEs pueden ser aplicaciones por si solas o pueden ser parte de aplicaciones existentes. El leguaje Visual Basic por ejemplo puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.
Los IDEs proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, Java, C#, Visual Basic, Object Pascal, Velneo, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.
Es posible que un mismo IDE pueda funcionar con varios lenguajes de programación. Este es el caso de Eclipse, que mediante pluggins se le puede añadir soporte de lenguajes adicionales
Suscribirse a:
Entradas (Atom)