sábado, 23 de mayo de 2015

   
6.4 MECANISMOS DE DETECCIÓN Y CORRECCIÓN DE ERRORES
 
 
En matemáticas, computación y teoría de la información, la detección y corrección de errores es una importante práctica para el mantenimiento e integridad de los datos a través de diferentes procedimientos y dispositivos como medios de almacenamiento confiables. Se considera como precursor de este tipo de tecnologías el Acme Comodity and Phrase Code usado en los telegramas
 
 

Tipo de códigos detectores

Paridad simple (paridad horizontal)

Consiste en añadir un bit de más a la cadena que queremos enviar, y que nos indicará si el número de unos (bits puestos a 1) es par o es impar. Si es par incluiremos este bit con el valor = 0, y si no es así, lo incluiremos con valor = 1.

Ejemplo de generación de un bit de paridad simple:

Queremos enviar la cadena “1110100”:
1º Contamos la cantidad de unos que hay: 4 unos
2º El número de unos es par por tanto añadimos un bit con valor = 0
3º La cadena enviada es 11101000


Verificación de errores o corrección de errores

La codificación binaria es de gran utilidad práctica en dispositivos electrónicos como ordenadores, donde la información se puede codificar basándose en la presencia o no de una señal eléctrica.
 
Sin embargo, esta señal eléctrica puede sufrir alteraciones (como distorsiones o ruidos), especialmente cuando se transportan datos a grandes distancias. Por este motivo, ser capaz de verificar la autenticidad de estos datos es imprescindible para ciertos propósitos (incluido el uso de información en entornos profesionales, bancarios, industriales, confidenciales o relacionados con la seguridad).
Por este motivo existen algunos mecanismos que garantizan un nivel de integridad de los datos, es decir, que el destinatario obtiene una confirmación de que los datos recibidos son, de hecho, similares a los datos transmitidos.
 
Existen dos maneras de proteger la transferencia de datos para que no se produzcan errores:
 
· instalando un medio de transmisión más seguro, es decir, una capa de protección física. Una conexión convencional tiene, por lo general, un porcentaje de error entre 10-5 y 10-7.
· implementando mecanismos lógicos para detectar y corregir errores.
La mayoría de los sistemas de control lógico de errores se basan en la suma de información (esto se denomina "redundancia") para verificar la validez de los datos. Esta información adicional se denomina suma de comprobación.
Verificación de errores
Se han perfeccionado mejores sistemas de detección de errores mediante códigos denominados:
 
· Códigos de autocorrección
· Códigos de auto verificación
Verificación de paridad
La verificación de paridad (a veces denominada VRC o verificación de redundancia vertical) es uno de los mecanismos de verificación más simples. Consiste en agregar un bit adicional (denominado bit de paridad) a un cierto número de bits de datos denominado palabra código (generalmente 7 bits, de manera que se forme un byte cuando se combina con el bit de paridad) cuyo valor (0 o 1) es tal que el número total de bits 1 es par. Para ser más claro, 1 si el número de bits en la palabra código es impar, 0 en caso contrario.
Tomemos el siguiente ejemplo:
 
 
En este ejemplo, el número de bits de datos 1 es par, por lo tanto, el bit de paridad se determina en 0. Por el contrario, en el ejemplo que sigue, los bits de datos son impares, por lo que el bit de paridad se convierte en 1:
 
 
Supongamos que después de haber realizado la transmisión, el bit con menos peso del byte anterior (aquel que se encuentra más a la derecha) ha sido víctima de una interferencia:
 
 
El bit de paridad, en este caso, ya no corresponde al byte de paridad: se ha detectado un error.
Sin embargo, si dos bits (o un número par de bits) cambian simultáneamente mientras se está enviando la señal, no se habría detectado ningún error.
 
 
 
Ya que el sistema de control de paridad puede detectar un número impar de errores, puede detectar solamente el 50% de todos los errores. Este mecanismo de detección de errores también tiene la gran desventaja de ser incapaz de corregir los errores que encuentra (la única forma de arreglarlo es solicitar que el byte erróneo sea retransmitido).
Verificación de redundancia longitudinal
La verificación de la redundancia longitudinal (LRC, también denominada verificación de redundancia horizontal) no consiste en verificar la integridad de los datos mediante la representación de un carácter individual, sino en verificar la integridad del bit de paridad de un grupo de caracteres.
Digamos que "HELLO" es el mensaje que transmitiremos utilizando el estándar ASCII. Estos son los datos tal como se transmitirán con los códigos de verificación de redundancia longitudinal:  
 Letra

 
Código ASCII
(7 bits)
    Bit de paridad
     (LRC)
H              
1001000               
0
E
1000101
1
L
1001100
1
L
1001100
1
0
1001111
1
VRC
1000010
0
Verificación de redundancia cíclica

La verificación de redundancia cíclica (abreviado, CRC ) es un método de control de integridad de datos de fácil implementación. Es el principal método de detección de errores utilizado en las telecomunicaciones.
Concepto
La verificación de redundancia cíclica consiste en la protección de los datos en bloques, denominados tramas. A cada trama se le asigna un segmento de datos denominado código de control (al que se denomina a veces FCS, secuencia de verificación de trama, en el caso de una secuencia de 32 bits, y que en ocasiones se identifica erróneamente como CRC). El código CRC contiene datos redundantes con la trama, de manera que los errores no sólo se pueden detectar sino que además se pueden solucionar.
Verificación de redundancia cíclica (CRC)

viernes, 22 de mayo de 2015

 

 

3.2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS


Para llevar a cabo la transición del modelo de requisitos al modelo de analisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos.

Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ello se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacion comperensible para el actor.




Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y los actores.

Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:

1.Se pueden identificar con base a los actores.
 
2.Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
 
3.Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.
  • Estrategia correspondiente a los actores.

Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
 
  • Entidad

Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.
 
  • Clases entidad:

Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que  se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.
 
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
 
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
 
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
 
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
 
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
 
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.
 
  •  Control

En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.




CLASES

Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo
de información es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.


Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es una situación común en el mundo físico. Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suéter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a
secar extendido. Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres declase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula. En la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rectángulo. El rectángulo contiene otras dos características importantes: una lista de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una parte principal de lo que llamamos análisis y diseño orientado a objetos. 

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase RentaAuto posee los atributos tamaño, color, marca y modelo. Todos los automóviles poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores. Por ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos que es posible serrnás específico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minúscula. 

Un método es una acción que se puede solicitar a cualquier objeto de la clase. Losmétodos son los procesos que una clase sabe cómo realizar. Los métodos también se llaman operaciones. La clase RentaAuto podría tener los siguientes métodos: inicioRenta( ), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra es minúscula.




miércoles, 20 de mayo de 2015

Tema 4.4 REVISION DEL DISEÑO


4.4 REVISION DEL DISEÑO 

 


En ingeniería de software, una revisión estructurada es una forma de revisión de software por colegas en la cual un diseñador o programador lidera a los miembros de un equipo de desarrollo y otra de las partes involucradas a través de un producto de software, y los participantes hacen preguntas y comentarios acerca de posibles errores, violación de estándares de desarrollo, y otros problemas.
El "producto de software" normalmente se refiera a un tipo de documento técnico. Tal como es indicado por la definición de la IEEE, esto puede ser un documento de diseño de software o código fuente de un programa, pero también casos de uso, definiciones del proceso de negocios, especificaciones de casos de prueba y una variedad de otra documentación técnica también puede ser revisada.
Una revisión estructurada difiere de una revisión de software técnica en la forma abierta de su estructura y su objetivo de familiarización.
Según la IEEE 610.12, una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

La revisión se desarrolla según la planificación para determinar si el diseño satisface los requisitos, identificar cualquier problema percibido y proponer acciones de rectificación.

•Será necesario mantener registros.





Explicación:

Revisión de diseño y desarrollo:
Mantenga los datos de registro de las reuniones de revisión del proyecto. Estas reuniones deberían realizarse según el plan del proyecto.
Deberían tener lugar, como mínimo, con la frecuencia definida en su plan, o más a menudo. Su plan debería indicar quién debe participar en las reuniones de revisión del proyecto.
Estas “reuniones” pueden ser encuentros formales, e-mails, conferencias telefónicas u otros medios de comunicación del grupo.
Una checklist de las reuniones de revisión y sus respectivas fechas, con las actas adjuntas, sirve para coordinar esta parte de los requisitos.