Arquitectural Patterns: Units of mitigation

Patterns for Fault Tolerant Software

Arquitectural Patterns: Units of mitigation

¿Como puedes prevenir que un sistema completo llegue a estar no disponible cuando ocurre un error?

Existen sistemas de software que están compuesto por un solo componente, a estos sistemas se les conoce como monolíticos. El problema con estos sistemas es que cuando ocurre un error, el sistema completo puede mantenerse inaccesible por un momento, mientras se hace la recuperación de tal error. Otra desventaja es que el manejo de errores(incluye la identificación, mitigación y tratamiento) puede ser menos flexible.

Una estrategia para sistemas grandes es crear unidades de mitigación, esto es: separar el sistema en componentes, estos componentes deben de tener algunas propiedades que se comentan mas adelante, lo importante por el momento es considerar que al separar un sistemas en diferentes componentes tenemos la posibilidad de aislar los componentes que presenten alguna falla y no afectar el sistema completo, es decir, los demás módulos pueden seguir trabajando. Entre mas pequeñas sean las unidades de mitigación, mas opciones tenemos para recuperar y mitigar errores por que el sistema puede tratar los errores por unidad mientras las otras unidades se mantienen trabajando.

Durante el diseño de la Arquitectura del sistema se decide cuales son las unidades de mitigación o los componentes que compondrán el sistema completo, entendiendo que cada una de las unidades debe de ser tolerante a fallas, para que el sistema completo también lo sea.

Las interfaces entre las unidades de mitigación deben de ser claras y muy bien definidas. Es a través de estas interfaces que las acciones de mitigación actúan para la recuperación de errores o reducir el impacto de los errores.

Las unidades de mitigación deben de contener acciones atómicas que no confíen fuertemente en la comunicación con otras unidades de mitigación para completar su tarea.

De manera general podemos identificar 4 fases en la tolerancia a fallas, las cuales son: Detección del Error, Recuperación del Error, Mitigación del Error y Tratamiento de la falla.

Se parte de una Falla Latente que tenga el sistema, cuando la falla se activa, genera un error, el sistema debe de ser capaz de detectar el error, en este caso se debe de disponer de la información necesaria para saber el tipo de error que se genero, una vez que el error ha sido detectado tenemos las fases de recuperación y de mitigación, ambas fases son indispensables para que la unidad de mitigación pueda volver a estar disponible, una vez que el procesamiento del error ha sido terminada se puede tener la unidad de mitigación disponible y empieza la fase de tratamiento de la falla, la última fase puede requerir mas tiempo para completarse, ya que se trata de correcciones de software(bugs), cambios de hardware, restablecimiento de recursos,......

El patrón de Unidades de mitigación es una actividad que se lleva a cabo a nivel de diseño, durante el diseño es donde se toma la decisión de que unidades de mitigación compondrán el sistema completo.

No existe reglas o procedimientos que sean aplicados de manera tajante para realizar la identificación de las unidades de mitigación, a continuación se describen algunas sugerencias:

- Divide el sistema en partes que puedan contener ambos, probables errores y recuperación de errores.

- Selecciona la división que haga mas sentido al sistema completo.

- Una vez identificadas las unidades de mitigación, construye el resto del sistema alrededor de estas unidades.

Referencia:

Patterns for Fault Tolerant Software, By Robert Hanmer

Factory Pattern

 

Problemática

Factory Patter quizá es el patrón mas usado en el desarrollo de software, su uso es básico para tener un control de instanciación dentro de nuestro código y facilitar el cambio de implementaciones.

Con el uso de interfaces en el desarrollo de software, se crea al menos una implementación de tal interface. Imaginemos un proyecto  mediano o grande, si no se tiene control de los lugares en los cuales se realiza la instanciación de las implementaciones, cuando se desee cambiar una implementación el trabajo será arduo y peligroso.

Por lo anterior es necesario centralizar la creación de instancias, de manera que podamos crear instancias desde un Factory, y si deseamos cambiar una implementación solo creamos la nueva implementación y cambiamos la instanciación en el Factory.

Implementación

En el diagrama anterior podemos observar que Factory crea las instancias, de manera que solo dentro de las clases Factory debemos de tener "new".

1. Crea una interface que defina el contrato a cumplir la implementación.

2. Crea una implementación de la interface definida anteriormente.

3. En  clases que usen una instancia del tipo definido por la interface usa este tipo y no el tipo de la implementación.

Ejemplo

interface Figura {
    void dibuja();
}

class Triangulo implements Figura {
    @Override
    public void dibuja() {
        System.out.println("Soy un triangulo");
    }
}

class Circulo implements Figura {
    @Override
    public void dibuja() {
        System.out.println("Soy un circulo");
    }
}

class FactoryFormas {
    public static Figura getFigura(final String tipoFigura) {
        Figura figura = null;
        if (tipoFigura.equals("triangulo")) {
            figura = new Triangulo();
        } else {
            figura = new Circulo();
        }
        return figura;
    }
}

class MuestraFiguras {
    public void main(final String[] args) {
        Figura triangulo = FactoryFormas.getFigura("triangulo");
        Figura circulo = FactoryFormas.getFigura("circulo");
        triangulo.dibuja();
        circulo.dibuja();
    }
}

Referencias

http://www.oodesign.com/factory-pattern.html
http://www.tutorialspoint.com/design_pattern/factory_pattern.htm

Open Close Principle

Open Close Principle

Una de las características del desarrollo de software, es que el software debe de estar diseñado para cambiar, alguna vez leí que el software que no cambia tiende a morir, bajo esta idea, el software que se mantiene evolucionando, agregando nuevas funcionalidades, mejorando las que ya se tienen, innovando, ... es el software que sobrevive. Pero, para que un software sea mejorado y/o aumentado debe de contar con ciertos principios que permitan evitar que un pequeño cambio tenga efectos no deseados en otras secciones de código.

En este blog analizaremos el principio Open Close Principle, este principio establece que el diseño de software deberá ser hecho de una forma que las nuevas funcionalidad sean agregadas con mínimos cambios en el código existente. La idea es que al agregar nuevas funcionalidades se haga mediante nuevas clases, manteniendo lo mas posible sin cambios el código que ya existe.

Por lo anterior, la máxima del principio Open Close es: Open para extensión, Close para modificación.

Lo que quiere decir es que se debe de evitar modificar código ya creado, y tratar de hacer uso de técnicas de diseño orientado a objetos tales como interfaces y clases abstractas.

En el siguiente ejemplo se tiene una clase que envía 3 tipos diferentes de mensajes, las implementaciones para cada tipo de mensaje se encuentra en una clase concreta que implementa la interface Message. La clase MessageSender tiene un método llamado sendNotification que recibe un tipo de objeto Message, de manera que podemos tener muchas implementaciones y esta clase no se ve afectada de ninguna manera.

En el diagrama podemos observar que si se desea agregar un nuevo tipo de mensaje no es necesario modificar nada de las clases ya existentes (Close para modificaciones), por otro lado, solo se requiere crear la nueva implementación del tipo de mensaje que se desee extendiendo de la clase abstracta o interface Message (Open para extensión).

En caso de que las implementaciones se encontraran en una sola clase(rompiendo el principio Open Close), cuando se desea agregar un nuevo tipo de mensaje es necesario modificar esa clase y posiblemente realizar cambios al código ya existen, con lo cual se viola el principio de Open Close.

Código:

public class SenderNotification {

public Boolean sendNotification(final Message message) {

return message.sendMessage();

}

}

public interface Message {

Boolean sendMessage();

}

public class MailMessage implements Message{

@Override

public Boolean sendMessage() {

return true;

}

}

public class SMSMessage implements Message{

@Override

public Boolean sendMessage() {

return true;

}

}

public class VoiceMessage implements Message{

@Override

public Boolean sendMessage() {

return true;

}

}

Referencias:

http://www.oodesign.com/open-close-principle.html

http://www.objectmentor.com/resources/articles/ocp.pdf

http://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle--net-36600

¿Qué es Clean Code?

¿Qué es Clean Code?

En los últimos años en las empresas de desarrollo de Software se han estado adoptando procesos, metodologías y tecnologías que permitan que el desarrollo de sistemas sea mas dinámico y eficiente con la finalidad de tener sistemas mas confiables y robustos. Un punto importante en esta adaptación de metodologías es lo referente al proceso propio del desarrollo de Software, es decir, como hacer un código mantenible, legible, entendible, ...... ible.

El Clean Code mas que una metodología yo lo veo como una filosofía de trabajo, son las practicas que te permiten que el código que desarrollas sea realizado de una manera profesional y cumpla con ciertas características.

A continuación voy a listar algunas definiciones de Clean Code tomadas del libro Clean Code de Robert C. Martin. En cada definición se pueden ver puntos importantes para cada autor,  después de leer las definiciones tu puedes crear tu propia definición y ver que tan importante es adoptar técnicas que te permitan crean Clean Code.

Bjarne Stroustrup, Inventor de C++

Me gusta que el código sea elegante y eficiente. La lógica debería ser sencilla para hacer difícil el ocultar bugs, dependencias mínimas para facilitar mantenimiento, manejo de errores basado en una estrategia articulada y rendimiento optimo.

Grady Booch, autor de Análisis y Diseño orientado a objetos con aplicaciones.

Clean Code es simple y directo, el Clean Code se lee como una prosa bien escrita. Clean Code nunca oscurece las intenciones de los diseñadores, mas bien esta lleno de abstracciones y simples lineas de control.

"Big" Dave Thomas, fundador de OTI.

Clean Code  puede ser leido y mejorado por un desarrollador que no es el autor original, tiene pruebas unitarias  y de aceptación, tiene nombres significativos, provee una forma en lugar de varias formas de hacer una cosa, Tiene mínimas dependencias, y provee claras y mínimas API's.

Michael Feathers, Autor de Working Effectively with Legacy Code.

Yo podría listar todas las cualidades que yo he observado en Clean Code,  pero hay una cualidad general en todos los códigos, Clean Code siempre luce que fue escrito por alguien que tiene cuidado.No hay nada obvio que tu puedas hacer mejor.

Ward Cunningham, inventor de Wiki, inventor de Fit, co-inventor de eXtreme Programming.

Tu sabes que estas trabajando en Clean Code cuando cada rutina que tu lees es bastante mejor de lo que tu esperas. Tu puedes llamar esto código "hermoso"cuando el código hace ver al lenguaje como hecho para resolver el problema.

Tenemos suficientes definiciones para poder crear un propio criterio sobre lo que es el Clean Code, al fin de cuentas todo nos lleva a realizar un código  de manera profesional, teniendo en consideración que muy probablemente en un futuro quien escribe el código o algún otro desarrollador tendrá que realizar modificaciones, y este trabajo de cambio debe de ser lo suficientemente transparente, y con mínimo impacto en otras secciones del sistema.

En las próximas entradas nos enfocaremos en algunas técnicas de Clean Code. Por lo pronto tenemos la tarea de reflexionar que tan limpio es el código que actualmente estamos escribiendo.

Esta imagen refleja en gran medida como saber si estamos tratando con Clean Code, en un revisión de código, cuantos WTF ocurren.

Bibliografía:

Clean Code A Handbook of Agile Software craftsmanship, Robert C. Martin Series.

Bienvenidos

Bienvenidos a este blog, el objetivo principal es compartir pequeños artículos relacionados con el desarrollo de software.

Esperamos tus comentarios y sugerencias.