Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Versión

Tabla de Contenido

Cumplimiento Normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.

1. Introducción

Esta guía busca facilitar el desarrollo de productos dentro del

Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:

• Desarrollo de nuevos sistemas de información corporativos.
• Refactorización de sistemas de información existentes.
• Evolución de sistemas de información que requieran la implementación de nuevos procesos o funcionalidades y que requiera de desarrollo en funciones "core" del sistema.

sas, proporcionando una serie de pautas para el diseño y el desarrollo que faciliten la mantenibilidad, la legibilidad y el cambio del código.

Estas guías tratan de ser agnósticas al lenguaje de desarrollo por lo que se proporcionarán acceso a ejemplos de implementación en cada lenguaje.

1.1. Ámbito de  aplicación

Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:

• Desarrollo de nuevos sistemas de información corporativos.
• Refactorización de sistemas de información existentes.
• Evolución de sistemas de información que requieran la implementación de nuevos procesos o funcionalidades y que requiera de desarrollo en funciones "core" del sistema.

Se recomienda su aplicación:

• Sistemas comerciales que permitan una arquitectura tecnológica flexible y alineada con este modelo de referencia.
• Desarrollos locales con previsión de escalar a sistemas corporativos.
• Cualquier desarrollo para implementar nuevos procesos sobre los sistemas de información existentes.

Se recomienda analizar en detalle con la unidad de Arquitectura de la STIC y particularizarla para los siguientes casos:

• Sistemas analíticos o que gestionen grandes volúmenes de datos (**).

(*) Cualquier propuesta que difiera de esta arquitectura deberá ser aprobada por el Área de Gobernanza de la STIC, previa solicitud y justificación en su caso.

(**) En proceso de elaboración de una arquitectura de referencia para sistemas analíticos y big data.

1.2. Ciclo de vida de la arquitectura de referencia

Los cambios normativos dentro de la arquitectura de referencia seguirán el siguiente ciclo de vida:

• Pre-release:    Periodo durante el cual la normativa  se hace publica aunque no es necesario adherirse inmediatamente.  En este periodo aún puede sufrir pequeñas correcciones.
• Adopción :  Periodo durante el cual la normativa inicia un periodo de tiempo flexible para su aplicación de forma obligatoria al ámbito en el cual está destinado.
• Activa:  Periodo durante el cual es obligatorio su cumplimiento para el ámbito en el cual está destinado.
• Retiro:  Periodo durante el cual dejará de aplicarse en el ámbito al cual está destinado en sustitución de nuevas versiones o normas.

2. Clean Code

3. Principios SOLID

 3.1 - SOLID - SINGLE RESPONSABILITY

El principio de responsabilidad único establece que un modulo, clase, método, etc, debe tener una y solo una razón para cambiar. Esto significa que una entidad de software debe tener solo una responsabilidad y hacer únicamente la tarea para la cual ha sido diseñada. De lo contrario si asume más de una responsabilidad existirá un alto acoplamiento provocando que nuestra lógica de programación sea frágil ante cualquier cambio.

Ejemplo: Supongamos que tienes una clase Report que puede generar informes y enviarlos por correo electrónico. Según SRP, deberías dividir esta clase en dos: una para manejar la generación de informes (ReportGenerator) y otra para manejar el envío de correos electrónicos (EmailSender).

Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:

• Desarrollo de nuevos sistemas de información corporativos.
• Refactorización de sistemas de información existentes.
• Evolución de sistemas de información que requieran la implementación de nuevos procesos o funcionalidades y que requiera de desarrollo en funciones "core" del sistema.

Ilustración - Ejemplo de SR aplicado a módulos

class Book {
	function getTitle() {Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:

    Desarrollo de nuevos sistemas de información corporativos.
    Refactorización de sistemas de información existentes.
    Evolución de sistemas de información que requieran la implementación de nuevos procesos o funcionalidades y que requiera de desarrollo en funciones "core" del sistema.
        return "A Great Book";
    }
	function getAuthor() {
        return "John Doe";
    }
	function turnPage() {
        // pointer to next page
    }
	// Esta no es responsabilidad de un libro
	function printCurrentPage() {
        echo "current page content";
    }
}

class Book {
	function getTitle() {
        return "A Great Book";
    }
	function getAuthor() {
        return "John Doe";
    }
	function turnPage() {
        // pointer to next page
    }
}

interface Printer {

    function printPage($page);
}

class PlainTextPrinter implements Printer {

    function printPage($page) {
        echo $page;
    }

}

class HtmlPrinter implements Printer {

    function printPage($page) {
        echo '<div style="single-page">' . $page . '</div>';
    }
}

3.2 - SOLID - OPEN/CLOSE PRINCIPLE

Una clase está cerrada a la modificación pero abierta para extenderla. Esto significa que una entidad de software debe ser fácilmente extensible sin necesidad de modificar su código existente. Si diseñamos sistemas extensibles serán menos propensos a errores ante cambios en los requerimientos

Ejemplo: Si tienes una clase Shape con un método draw(), y quieres añadir una nueva forma, en lugar de modificar la clase Shape, puedes extenderla creando una nueva subclase como Circle o Square.

public class Rectangle
{
    public double Width { get; set; }
    public double Height { get; set; }
}
public class Circle
{
    public double Radius { get; set; }
}
public class AreaCalculator
{
    public double Area(object[] shapes)
	{
		double area = 0;
		foreach (var shape in shapes)
		{
			if (shape is Rectangle)
			{
				Rectangle rectangle = (Rectangle) shape;
				area += rectangle.Width*rectangle.Height;
			}
			else
			{
				Circle circle = (Circle)shape;
				area += circle.Radius * circle.Radius * Math.PI;
			}
		}

		return area;
	}
}

public interface Shape
{
    public double Area();
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area()
    {
        return Width*Height;
    }
}

public class Circle : Shape
{
    public double Radius { get; set; }
    public override double Area()
    {
        return Radius*Radius*Math.PI;
    }
}

public class AreaCalculator
{
    public double Area(Rectangle[] shapes)
    {
        double area = 0;
		foreach (var shape in shapes)
		{
			area += shape.Area();
		}

		return area;
    }
}

3.3 - SOLID - LISKOV SUBTITUTION PRINCIPLE

Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. Es decir que, si una clase es un subtipo de otra, los objetos de esta clase subtipo podrían sustituir a los objetos de la clase padre sin que el programa sufriera ningún cambio de comportamiento.

Ejemplo: Si tienes una clase base Bird con un método fly(), y una subclase Penguin, la subclase Penguin no debería sobrescribir el método fly() con una implementación que cause un comportamiento incorrecto.

public class Bird {
    public void fly() {
        // Code to fly
    }
}

public class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Penguins can't fly");
    }
}

public abstract class Bird {
    public abstract void move();
}

public class Sparrow extends Bird {
    @Override
    public void move() {
        fly();
    }

    private void fly() {
        // Code to fly
    }
}

public class Penguin extends Bird {
    @Override
    public void move() {
        walk();
    }

    private void walk() {
        // Code to walk
    }
}

// Usage
Bird sparrow = new Sparrow();
sparrow.move();

Bird penguin = new Penguin();
penguin.move();

3.4 - SOLID - INTERFACE SEGREGATION

Los clientes no deben estar obligados a depender de interfaces que no utilizan. Es mejor tener varias interfaces específicas del cliente en lugar de una sola interfaz general.

Ejemplo: Si tienes una interfaz Worker con métodos work() y eat(), y una clase Robot que solo implementa work(), deberías dividir Worker en dos interfaces más específicas: Workable y Eatable.

public interface Worker {
    void work();
    void eat();
}

public class Robot implements Worker {
    @Override
    public void work() {
        // Code to work
    }

    @Override
    public void eat() {
        throw new UnsupportedOperationException("Robots don't eat");
    }
}

public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public class Human implements Workable, Eatable {
    @Override
    public void work() {
        // Code to work
    }

    @Override
    public void eat() {
        // Code to eat
    }
}

public class Robot implements Workable {
    @Override
    public void work() {
        // Code to work
    }
}

// Usage
Workable worker = new Robot();
worker.work();

Eatable eater = new Human();
eater.eat();

3.5 - SOLID - DEPENDENCY INVERSION

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Las abstracciones no deben depender de los detalles; los detalles deben depender de las abstracciones. Significa que una clase concreta, no debe depender directamente de otra clase sino de una abstracción (interfaz) de esta. Nos ayuda a reducir la dependencia en implementaciones específicas y así lograr que el código sea más reutilizable.

Ejemplo: Si tienes una clase Keyboard que se conecta directamente a una clase Computer, deberías usar una interfaz IKeyboard que Keyboard implemente, y Computer debería depender de IKeyboard.

public class Keyboard {
    // Code for keyboard
}

public class Computer {
    private final Keyboard keyboard;

    public Computer() {
        this.keyboard = new Keyboard();
    }
}

public interface IKeyboard {
    // Abstract methods for keyboard
}

public class Keyboard implements IKeyboard {
    // Code for keyboard
}

public class Computer {
    private final IKeyboard keyboard;

    public Computer(IKeyboard keyboard) {
        this.keyboard = keyboard;
    }
}

// Usage
IKeyboard keyboard = new Keyboard();
Computer computer = new Computer(keyboard);

4. DRY - Don’t repeat yourself.

 Este principio enfatiza la importancia de evitar la duplicación de código o lógica en un sistema. La idea es que cualquier pieza de conocimiento o lógica debe tener una única representación en el sistema. Esto ayuda a mantener el código limpio, reducir errores y facilitar el mantenimiento.

5. KISS - Keep It Simple, Stupid.

 El principio aboga por mantener el código lo más simple y claro posible. La simplicidad es clave para facilitar la comprensión, el mantenimiento y la extensión del código. La complejidad innecesaria debe ser evitada, y las soluciones deben ser directas y sin complicaciones.

6. YAGNI

El principio sostiene que no se deben implementar funcionalidades hasta que realmente se necesiten. Esto ayuda a evitar el desperdicio de tiempo y recursos en características que no se usarán, y mantiene el código más limpio y enfocado en los requisitos actuales.

Estos principios son fundamentales en el desarrollo de software ágil y ayudan a mantener un código base limpio, manejable y eficiente.