UNIVERSIDAD PRIVADA

DOMINGO SAVIO
FACULTAD DE INGENIERIA

Ingeniería de Sistemas

MODULO 2
EXAMEN DE GRADO

DOCENTE:
Ing. Yanet Colque Alarcon

TARIJA, DICIEMBRE 2023

 1

PROGRAMACIÓN ORIENTADA A OBJETOS

El paradigma de programación orientada a objetos es una nueva forma de más estructurada para
desarrollar software. La orientación a objetos es un modelo que utiliza nociones del mundo real, en
el cual vivimos los seres humanos, donde encontramos objetos por todas partes, los cuales se
relacionan, interactúan y se asocian para permitir la solución de un problema, se pueden manipular
individualmente o en conjunto, e incluso muchos de ellos pueden poseer o adquirir
comportamiento inteligente.

La programación orientada a objetos nos es más que un modelo de programación donde un

programa es dividido en módulos de software independientes unos de otros, pero con capacidad
de interactuar entre sí para cumplir con un objetivo.

El concepto fundamental de la programación orientada a objetos es la clase y existen muchas de

ellas implementadas en .NET, y están listas para permitirnos crear la gran mayoría de objetos que
podemos llegar a necesitar en un programa de consola, tipo Windows o tipo web. Aquellos objetos
para los cuales no existan clases en .NET podemos crearlas utilizando cualquier lenguaje de
programación y un compilador que cumplan la especificación para ejecutarse sobre el framework
.NET. C# es uno de esos muchos lenguajes, pero por ahora es el único que ha sido diseñado y
desarrollado entera y exclusivamente para este entorno, y todos aquellos que cumplan con la misma
especificación .NET.

Clases

La clase es el elemento fundamental de la programación orientada a objetos con el lenguaje C#.

Aunque, dentro de este modelo de programación, existen muchas definiciones válidas para el
concepto de clase, en la práctica una clase no es más que una plantilla de software que sirve para
construir cualquier cantidad de objetos.

Desde la perspectiva del lenguaje de programación, una clase es un tipo, que al igual que los tipos
estándar, sirve para declarar variables cuya estructura es una fiel copia de ella. Estas variables
reciben el nombre de objetos y son los elementos que manipula el programador para desarrollar su
programa.

En C# una clase se define mediante la palabra clave class y una sintaxis básica que encontramos para
definirla, es la siguiente:

class NombreClase

// Miembros

[public | private | protected | internal]

class NombreClase
 1

// Miembros

Objetos

Los objetos permiten definir variables en memoria que se conocen con el nombre de objetos o
instancias de clase.

Desde esta perspectiva, el término clase gana mayor significado, ya que se puede definir como una
plantilla que permite generar una clase de objetos.

Para crear un objeto de una determinada clase, se procede básicamente en dos pasos:

primero se declara una variable con el tipo que representa la clase y luego se le asigna memoria con
el operador new. Por ejemplo, tomando la clase Complejo definida anteriormente, la siguiente línea
crea un objeto a partir de esta plantilla:

Complejo z=new Complejo();

Elementos de una clase

Las clases están conformadas por miembros, los cuales se clasifican básicamente en atributos y
métodos.
 1

using System;
class Complejo
{
// Campos
public double real;
public double imaginario;
}
public class NumerosComplejos
{
static void Main()
{

// Declarar dos objetos p y q de la clase Complejo

Complejo p;
Complejo q;

// Asignar memoria a los objetos

p = new Complejo();

q = new Complejo();

// Cargar los datos del número complejo p

p.real = 4;

p.imaginario = 10;
 1

// Cargar los datos del número complejo q

q.real = -4;

q.imaginario = 1;

// Mostrar los números complejos p y q

Console.WriteLine("p = {0} + {1}i", p.real, p.imaginario);

Console.WriteLine("q = {0} + {1}i", q.real, q.imaginario);

}}

Elementos básicos de la orientación a objetos

Una de las características fundamentales que identifican a cualquier lenguaje orientado a objetos y
la forma como C# las implementa. Aunque la descripción en detalle de estos conceptos es
demasiado amplia.

- Abstracción

- Encapsulamiento

- Modularidad

- Herencia

- Polimorfismo

Abstracción

En términos generales se entiende por abstracción la posibilidad de visualizar únicamente aquellos

aspectos que interesen de un todo, dejando de lado los detalles que, aunque importantes, no son
de interés para un determinado propósito. Por ejemplo, el ratón de nuestro computador es el
resultado de la abstracción de todo un sistema de hardware y software que permite realizar algunas
acciones sobre un programa de computador. La ingeniería aplicada a este mecanismo ha permitido
alcanzar un nivel de abstracción tal, que para los usuarios lo único que interesa son los efectos
visualizados en la pantalla del computador como consecuencia de los movimientos y pulsaciones de
los botones de este dispositivo. Se dirá entonces, que el ratón es el resultado de la abstracción de
un complejo mecanismo que permite interactuar con la interfaz gráfica de un programa de
computador.

La capacidad de lograr buenos niveles de abstracción es el pilar fundamental de un buen lenguaje

orientado a objetos como C#. Pero la forma como se logra una buena abstracción no solo depende
del lenguaje de programación sino también de la creatividad y capacidad del programador para
identificar y abstraer aquellos elementos que resulten fundamentales y relevantes en determinadas
situaciones.

Encapsulamiento

El encapsulamiento hace referencia a la protección que debe hacer una clase de los elementos que
la conforman, especialmente de aquellos que contienen los datos. En general una clase es una
 1

capsula blindada que protege a sus miembros del mundo exterior y solo permite acceder a ellos
mediante mecanismos que garanticen su adecuada modificación o lectura. Establecer esos
mecanismos es una tarea del programador.

class Estudiante
{
public string codigo;
public string nombres;
}

Estudiante alumno = new Estudiante ();

alumno.codigo = "1";

Una propiedad tiene un aspecto semejante a un método. Se encarga de leer un valor contenido en
un campo (get) y mostrarlo hacia el exterior; o al contrario, leer un valor desde el exterior y asignarlo
a un campo (set). En general su sintaxis es como sigue:

public tipo NombrePropiedad

get

// Devuelve con return el valor de un campo

set

{
 1

// Asigna el valor de value al campo

El descriptor get devuelve al exterior el valor contenido en el campo que manipula la propiedad.
Este descriptor es equivalente a leer el valor de un campo. Utiliza la palabra clave return para
identificar el campo devuelto.

El descriptor set se encarga de asignar a un campo un valor proveniente desde exterior. Para ello
utiliza el parámetro implícito value que contiene el valor que se haya asignado a la propiedad desde
el exterior.

class Estudiante
{

// Campos

private string codigo;

private string nombres;

// Propiedades

public string Codigo

{
get
{

return codigo;
}
set
{
codigo = value;
}
}
private bool CodigoValido(string cadena)
{

int i = 0;

// Si la longitud del código es diferente de 4...

 1

if (cadena.Length != 4) return false;

// Determinar si el código es una cadena de dígitos

while(i <= cadena.Length)

{
i++;
if (!Char.IsDigit(cadena, i)) return false;
}
return true;
}
Modularidad

El modularidad es la propiedad, de la programación orientada a objetos, que permite dividir una

aplicación de software en componentes más pequeños, generalmente llamados módulos.

Inicialmente la clase básica del componente se ve como sigue:

public class Codigo

{
string prefijo = "";
string sufijo = "";
int longitud;
string valor;

public string Prefijo

{
get { return prefijo; }
set { prefijo = value; }
}
public string Sufijo
{
get { return sufijo; }
set { sufijo = value; }
}
public int Longitud
{
get { return longitud; }
set { longitud = value; }
}
public string Valor
{
get { return valor; }
}
public bool Valido()
 1

{
int longitudPrefijo = prefijo.Length;
int longitudSufijo = sufijo.Length;
string cadena = sufijo;
int i = longitudSufijo;

if (longitudPrefijo + longitudSufijo == longitud)

valor = prefijo + sufijo;
else if(longitudPrefijo + longitudSufijo < longitud
{
// Se rellena con ceros de por medio
while (i < longitud - longitudPrefijo)
{
cadena = "0" + cadena;
i++;
};
valor = prefijo + cadena;
}
else

{
MessageBox.Show("No se pudo generar...");
return false;
}
MessageBox.Show("El código es: " + valor);

return true;
}

Herencia
La herencia es la característica más importante de la programación orientada a objetos porque
permite crear clases que se derivan de otras clases y este es uno de los aspectos vitales en la
reutilización de componentes.
Específicamente, la herencia es la capacidad que ofrece un lenguaje de programación de poder crear
nuevas clases a partir de clases existentes, aprovechando el código de estas últimas. La herencia
supone la existencia de una clase base y una o más clases derivadas. Tomando la analogía del mundo
real se dice que una clase derivada hereda las características de la clase base, agregando sus propios
elementos.
 1

Tanto los estudiantes como los trabajadores tienen elementos o datos comunes, tales
como nombres, apellidos, fecha de nacimiento y edad, y otros que no lo son. Aplicar la
propiedad de la herencia en este caso, implica rediseñar las clases creando una nueva
clase a partir de los campos que se encuentran repetidos en ambas. A esa clase bien
podríamos llamarla Persona y su estructura sería como se muestra a continuación. A
partir de esta clase se derivan las clases Estudiante y Trabajador con los campos que les hacen falta
a cada una de ellas.

La herencia es una propiedad supremamente potente que exige especial cuidado al momento de
diseñar un software. Esta propiedad bien utilizada simplifica enormemente la programación y sobre
todo permite sacar el máximo provecho a los elementos que pone a disposición, tanto el entorno
de desarrollo, como aquellos que sea capaz de crear el ingeniero de software.
Dentro de la programación orientada a objetos existen dos tipos de herencia: simple y múltiple.
Existe herencia simple cuando una clase solo se deriva de una clase base; y herencia múltiple cuando
una clase se deriva de dos o más clases base. Este es un aspecto donde C# presenta una debilidad,
al menos en la opinión de algunos expertos, ya que solo es capaz de soportar la herencia simple.
Algunos opinan que un lenguaje que no de soporte a la herencia múltiple pone en duda su
pertenencia a la familia orientada a objetos.
class ClaseDerivada : ClaseBase
{

// Implementación de la clase derivada

}
En el ejemplo de nuestro sistema de datos para una entidad educativa, podemos definir
la clase base Persona como,
class Persona
{

// Implementación de la clase base

}
y las clases Estudiante y Trabajador, que heredan de ella, se debe hacer de la siguiente
forma:
 1

class Estudiante : Persona

{

// Elementos propios de esta clase

}
class Trabajador : Persona
{

// Elementos propios de esta clase

}
Ejemplo
// Clase base
public class Persona
{
// Campos

string nombres;

string apellidos;

DateTime fechaNacimiento;

int edad;

// Propiedades

public string Nombres

{
get { return nombres; }

set { nombres = value; }

}
public string Apellidos
{
get { return apellidos; }

set { apellidos = value; }

}

public DateTime FechaNacimiento

{

get { return fechaNacimiento; }

set {

fechaNacimiento = value;
 1

CalcularEdad();

}
}

public int Edad

{
get { return edad; }
}
private void CalcularEdad()
{

TimeSpan intervalo;

intervalo = DateTime.Now - fechaNacimiento;

edad = (int)(intervalo.Days / 365.25);

}

/ Clases derivadas
public class Estudiante : Persona

string codigo;
string facultad;
string programa;

public string Codigo

{
get { return codigo; }
set { codigo = value; }
}
public string Facultad
{
get { return facultad; }
set { facultad = value; }
}
public string Programa
{
get { return programa; }
set { programa = value; }
}

public class Trabajador : Persona

int sueldo;
string cargo;
public int Sueldo
{
get { return sueldo; }
 1

set { sueldo = value; }

}
public string Cargo
{
get { return cargo; }
set { cargo = value; }
}
using System;

public class Programa

{
public static void Main(string[] args)
{
Trabajador empleado = new Trabajador();
Estudiante alumno = new Estudiante();
// Datos de un estudiante

Console.WriteLine("Estudiante");
alumno.Codigo = "01";
alumno.Nombres = "Juan";
alumno.Apellidos = "Rodríguez";
alumno.FechaNacimiento = Convert.ToDateTime("12/05/1990");
Console.Write("Código : {0}\n", alumno.Codigo);
Console.Write("Nombres : {0}\n", alumno.Nombres);
Console.Write("Apellidos: {0}\n", alumno.Apellidos);
Console.Write("Fecha N : {0}\n", alumno.FechaNacimiento);
Console.Write("Edad : {0} años\n", alumno.Edad);

// Datos de un trabajador
Console.WriteLine("Trabajador");
Console.Write("Nombres: ");
empleado.Nombres = Console.ReadLine();
Console.Write("Apellidos: ");
empleado.Apellidos = Console.ReadLine();
Console.Write("Fecha N: ");
empleado.FechaNacimiento = Convert.ToDateTime(Console.ReadLine());
Console.Write("Sueldo: ");
empleado.Sueldo = Convert.ToInt32(Console.ReadLine());
Console.Write("Edad: {0}", empleado.Edad);
}
}
Polimorfismo
En general se dice que el polimorfismo es la posibilidad de que una entidad tome muchas formas.
En términos de programación orientada a objetos, y de forma práctica, el polimorfismo permite
hacer referencia a objetos de diferentes clases por medio de una misma operación, la cual se ejecuta
y aplica de acuerdo al objeto que la invoca.
Existen dos formas de redefinir un miembro de una clase en una clase derivada. El
primero consiste en implementar un miembro en la clase base en forma corriente,
 1

public tipo NombreMiembro

{
// Implementación en la clase base
}
y redefinirlo en la clase derivada utilizando el operador new. Así,

public new tipo NombreMiembro

{

// Implementación en la clase derivada

}
Pero la forma más utilizada en C#, es aquella donde el programador de una clase base
prevé cuales miembros se podrían eventualmente redefinir y los marca como virtuales.
Para ello se utiliza la palabra clave virtual, así
public virtual tipo NombreMiembro
{
// Implementación en la clase base
}

Cuando se hace de esta forma, en el momento de sobrescribir el miembro en la clase

derivada se debe utilizar la palabra clave override, así.

public override tipo NombreMiembro

{
// Implementación en la clase derivada
}
using System;
using System.Windows.Forms;

public class Empleado

{
string nombres;
string apellidos;
double salarioBasico;
double seguridadSocial;
public string Nombres
{
get { return nombres; }
set { nombres = value; }
}

public string Apellidos

{
get { return apellidos; }
set { apellidos = value; }
 1

public double SalarioBasico

{
get { return salarioBasico; }
set { salarioBasico = value; }
}
public double SeguridadSocial
{
set { seguridadSocial = value; }
}

// Método para calcular el salario devengado

public virtual void CalcularSalario()
{
double salario;
double social;
string mensaje;

// Calcular la seguridad social

social = salarioBasico * seguridadSocial / 100;
// Determinar el salario devengado
salario = salarioBasico - social;

// Construir el mensaje que se va a mostrar

mensaje = "Seguridad social: " + social;
mensaje += "\nSalario devengado: " + salario;

MessageBox.Show(mensaje, "Empleado");

}
}

public class Contratista : Empleado

{
double numeroHoras;
public double NumeroHoras
{
set { numeroHoras = value; }
}

// Reescritura del método CalcularSalario()

public override void CalcularSalario()
{
double salario;
 1

double valorHora;
string mensaje;

// Calcular el valor de la hora con base en el

valorHora = base.SalarioBasico / 160;

// Determinar el salario devengado

salario = valorHora * numeroHoras;

// Construir el mensaje que se va a mostrar

mensaje = "Valor por hora: " + valorHora;
mensaje += "\nSalario devengado: " + salario;
MessageBox.Show(mensaje, "Contratista");

}
}
///****
using System;
public class SalarioDevengado
{
static void Main()
{

Empleado trabajador = new Empleado();

trabajador.Nombres = "Juan";
trabajador.Apellidos = "Pérez";
trabajador.SalarioBasico = 450000;
trabajador.SeguridadSocial = 16;
trabajador.CalcularSalario();
Contratista obrero = new Contratista();
obrero.Nombres = "José";
obrero.Apellidos = "Rodríguez";
obrero.SalarioBasico = 450000;
obrero.SeguridadSocial = 0;
obrero.NumeroHoras = 80;
obrero.CalcularSalario();

Interfaces
Las interfaces son módulos que solo definen un conjunto de métodos, pero no proporcionan
implementación alguna. Su definición se realiza siguiendo la sintaxis,

interface NombreInterfase
{
// Listado de firmas de propiedades y métodos
}
 1

Una interfaz solo contiene las firmas de métodos y propiedades que serán implementados por las
clases que la implementen.
Supongamos que se tiene la interfaz IPagos,

interface IPagos
{
double SalarioBasico{get; set;}
double SeguridadSocial{get; set;}
}
Para indicar que una clase Nomina se encargará de implementar esta interfaz se utiliza
el operador dos puntos (:), de la misma forma como se establece la herencia,

class Nomina : IPagos

{
public double SalarioBasico
{
// Implementación del método
}
public double SeguridadSocial
{
// Implementación del método
}
}
Las interfaces son un elemento que puede ser de gran utilidad a la hora de dar comportamiento
polimórfico a una implementación. Sin embargo, esta es una cualidad poco explotada por la gran
mayoría de programadores, quienes únicamente ven a las interfaces como elementos que ayudan
a forzar la estructura que deben poseer una o varias clases.

public interface IPagos

{
double SalarioBasico{get; set;}
double SeguridadSocial{get; set;}
}

using System;
public class Bancos : IPagos
{
double salarioBasico;
double seguridadSocial;
string sucursal;

public Bancos(){}
public double SalarioBasico
{
get {return salarioBasico;}
set {salarioBasico = value;}
 1

public double SeguridadSocial

{
get {return seguridadSocial;}
set {seguridadSocial = value;}
}

public string Sucursal

{
get {return sucursal;}
set {sucursal = value;}
}
}

public class Nomina : IPagos

{
double salarioBasico;
double seguridadSocial;
int numeroNomina;

public Nomina(){}

public double SalarioBasico

{
get {return salarioBasico;}
set {salarioBasico = value;}
}

public double SeguridadSocial

{
get {return seguridadSocial;}
set {seguridadSocial = value;}
}

public int NumeroNomina

{
get {return numeroNomina;}
set {numeroNomina = value;}
}
}

class CuentasContables
{
public static void Main(string[] args)
{
 1

Bancos banco = new Bancos();

banco.SalarioBasico = 1000;
banco.SeguridadSocial = 200;

// Un objeto se puede definir a partir de la interfaz

IPagos nomina = new Nomina();
nomina.SalarioBasico = 500;
nomina.SeguridadSocial = 60;

Cuenta cuenta = new Cuenta();

double total1 = cuenta.Total(banco);
double total2 = cuenta.Total(nomina);

Console.WriteLine("Total1 = " + total1.ToString());

Console.WriteLine("Total2 = " + total2.ToString());
Console.Write("Presione una tecla para continuar. . . ");
Console.ReadKey(true);
}
}

Recursividad
Las funciones recursivas son un tipo de función en la programación en el cual una función se llama
a sí misma de manera directa o indirecta. Es decir, una función recursiva es aquella que se llama a
sí misma para resolver un problema.

En el desarrollo de aplicaciones, las funciones recursivas son muy útiles para resolver problemas
complejos y dividirlos en problemas más pequeños y manejables. Algunos ejemplos de problemas
que pueden ser resueltos mediante recursión incluyen el cálculo de la factorial de un número, la
generación de números de la serie de Fibonacci, la búsqueda en un árbol binario y la resolución de
laberintos.
Ejemplo
(n-1)! = (n-1) · (n-2) · (n-3) · ... · 3 · 2 · 1
using System;

public class Ejemplo_05_10a

{

public static long Factorial(int n)

{
if (n==1) // Aseguramos que termine (caso base)
return 1;
return n * Factorial(n-1); // Si no es 1, sigue la recursión
}

public static void Main()

{
int num;
 1

Console.WriteLine("Introduzca un número entero: ");

num = Convert.ToInt32(System.Console.ReadLine());
Console.WriteLine("Su factorial es: {0}", Factorial(num));
}

Preguntas sobre el tema

1. Defina una clase
2. Explique los niveles de acceso de una clase
3. Defina un objeto
4. Explique los elementos básicos de la programación orientada de objetos
5. Explique qué se entiende al proceso de abstracción
6. Defina el encapsulamiento dentro de una clase
7. Explique cómo se define el modularidad en la programación orientada a objetos
8. Que es la herencia y como se representa
9. Explique cómo represento el polimorfismo
10. Como se representa una interface
11. Que es la recursividad explique cómo se puede aplicar en la programación orientada a
objetos

Plataforma de desarrollo Microsoft .NET.

Qué es .NET
.NET es una plataforma de aplicaciones que permite la creación y ejecución de servicios web y
aplicaciones de Internet. En la plataforma de desarrollo se pueden utilizar una serie de lenguajes,
implementaciones, herramientas y bibliotecas para el desarrollo de las aplicaciones.

En definitiva, es hoy en día la plataforma de desarrollo de software más usada para nuevos
proyectos de desarrollo de software además de Java.

Microsoft .NET es una colección de diferentes plataformas de software de Microsoft. El framework

original fue desarrollado como una competencia directa a la plataforma Java. Así pues, los entornos
de aplicación pueden ser desarrollados y ejecutados en base a .NET.

Hasta aproximadamente 2003, el término .NET sirvió a Microsoft como término de marketing y
como palabra de moda para productos nuevos, pero muy diferentes, como sistemas operativos,
servidores y software de oficina. Más tarde, el término se concentró en el desarrollo de software.

Inicialmente no tuvo mucho éxito, pero el entorno .NET ha cambiado significativamente a lo largo
de los años y ha ganado en importancia. Hoy en día, el framework .NET se ha vuelto indispensable
en la práctica diaria.

Componentes de la Arquitectura .NET

 1

Los dos componentes principales de .NET Framework son Common Language Runtime y la biblioteca
de clases .NET Framework.

Common Language Runtime (CLR) es el motor de ejecución que controla las aplicaciones en
ejecución. Proporciona servicios como la administración de subprocesos, la recolección de
elementos no utilizados, la seguridad de tipos, el control de excepciones, etc.
La Biblioteca de clases proporciona un conjunto de API y tipos para funciones comunes. Proporciona
tipos para cadenas, fechas, números, etc. La biblioteca de clases incluye API para leer y escribir
archivos, conectarse a bases de datos, dibujar y más.
Las aplicaciones .NET están escritas en el lenguaje de programación C#, F# o Visual Basic. El código
se compila en un lenguaje intermedio común (CIL) independiente del lenguaje. El código compilado
se almacena en ensamblajes: archivos con una extensión de archivo .dll o .exe.

Cuando se ejecuta una aplicación, CLR toma el ensamblado y usa un compilador Just-in-Time (JIT)
para convertirlo en código máquina que se puede ejecutar en la arquitectura específica del equipo
en el que se ejecuta.

1. Implementaciones
.NET Framework está dividido en diferentes subcategorías y categorías de programas y, por lo tanto,
contiene diferentes modelos de ejecución entre los que el usuario debe elegir al desarrollar el
software. La base del desarrollo es la biblioteca de clases, que ha estado disponible en general como
fuente compartida desde 2014. La llamada biblioteca de clases base permite el desarrollo de
aplicaciones no sólo para entornos Windows, sino también para plataformas como Android o
MacOS.

Esta plataforma de desarrollo se utiliza normalmente para crear aplicaciones de windows, windows
movile, windows server, etc con Asp.net, WPF y Windows Forms

Por otro lado, .NET Core es una nueva alternativa que se separó por primera vez del .NET Framework
en 2015. Debido a la mejora del modularidad y a la portabilidad aún más sencilla del software a
plataformas que no sean de Microsoft, .NET Core es particularmente apreciado por muchos
desarrolladores.
 1

Generalmente, desarrolla aplicaciones para la plataforma universal de Windows UWP y

Asp.NetCore. Además, se utiliza para desarrollar aplicaciones en la nube. La biblioteca de clases Core
Ex es compatible con Windows, MacOs y Linux.

Otra implementación a destacar es la plataforma Xamarin en la que se pueden desarrollar

aplicaciones para Android, iOS, tvOS, watchOS, macOS y Windows. Ésta, disponía de herramientas
y bibliotecas específicas.

Por último, incluir UWP, la plataforma universal de Windows. Aunque algunos desarrolladores la
situan dentro de la plataforma .NET Core al compartir algunas bibliotecas de este, a Microsoft le
gusta que se la considere una implementación más.

2. .NET Standard Library

Otro de los componentes que formaban parte de la arquitectura era la biblioteca de clases portable
PCL. Con ella se podía compartir el código entre varios proyectos específicos de la plataforma, tanto
en IOS, Android, Windows y Windows Phone.

Pero, las PCL presentaban muchas desventajas de compatibilidad entre implementaciones. Para
ello, los desarrolladores crearon la API .NET Standard Library. Se trata de una fusión de las
bibliotecas base y PCL compatible con todas las implementaciones.

En la actualidad, con la última versión de Visual Studio en 2017, las PCL quedaron obsoletas y
borradas del sistema, así como las bibliotecas base de cada implementación. En su lugar fueron
reemplazadas por .NET Standard Library.

También, existen otras API suplementarias que son específicas de los sistemas operativos en los que
se ejecuta.

3. Entorno en Tiempo de Ejecución

Una de las partes relevantes de la arquitectura es el Entorno en Tiempo de Ejecución, que como su
nombre indica es donde se ejecuta el programa administrado o el intervalo de tiempo en el que un
software se ejecuta en un sistema operativo. Según la implementación utilizada:

• .NET framework: CLR (Common Language Runtime).

• .NET Core: Core CLR (CoreCommon Language Runtime).
• Xamarin: entorno de implementación Mono.
• UWP: .NET Native.
4. Infraestructura Común
Siguiendo con los componentes de la arquitectura, encontramos la Infraestructura Común donde
están los lenguajes de programación: C#, F#, VB y el motor de compilación Ms Build para compilar
los proyectos.

5. Herramientas de Desarrollo
Finalmente, otro componente son las Herramientas de Desarrollo para la creación de aplicaciones
web o móviles en los diferentes sistemas operativos mencionados:

Administrador de paquetes para microsoft: Nuget.

 1

Entorno de desarrollo integrado (IDE): Visual Studio, Xamarin Studio, Visual Studio para Mac,
JetBrains Rider.
Editores de Código: Visual Studio Code y Plugin OmniSharp.

Cómo funciona .NET

Para desarrollar un programa basado en el .NET Framework no se necesita mucho. Para escribir el
programa, en casos simples es suficiente un editor de texto y un compilador, que se incluye en el
framework. Con estos dos componentes ya se pueden crear aplicaciones sencillas de Windows.

Para proyectos más grandes, Microsoft ofrece el entorno de desarrollo Visual Studio en diferentes
ediciones. Además de un editor de código, contiene muchas herramientas útiles, por ejemplo, para
el análisis, la solución de problemas o las pruebas. El compilador, por otro lado, es el responsable
de traducir el código escrito del programa a un idioma que pueda ser leído por la computadora.

En las primeras versiones de .NET, este lenguaje intermedio generado se llamaba MSIL (Microsoft
Intermediate Language). Debido a la estandarización, desde entonces ha sido renombrado como CIL
(Common Intermediate Language).
El CIL permite a los programadores trabajar en el mismo proyecto en diferentes lenguajes de
programación, ya que el código escrito del programa siempre se traduce al mismo lenguaje
intermedio. Ademas, el framework permite a los programadores desarrollar partes de programas
en C++, C# y VB.NET y luego combinarlos y usarlos juntos en un proyecto.

Mientras tanto, Microsoft también ofrece la posibilidad de desarrollar programas con HTML5 y
JavaScript basados en el .NET Framework. Esta tecnología se puede encontrar, por ejemplo, en
aplicaciones para Windows 8.1 o Windows Phone 8.1.

Lenguajes de programación en .NET

Los dos principales lenguajes de programación en .NET son C# y Visual Basic .NET. El lenguaje de
programación F#
 1

ambién es muy utilizado. Desde 2013, JavaScript también está totalmente adherida y aceptada.

El C++ no se ha usado durante mucho tiempo, pero también puede ser utilizado como una extensión
del lenguaje C++/CLI en. La extensión del lenguaje C++/CLI ofrece la posibilidad de transferir objetos
directamente con otros lenguajes de objetos. El lenguaje de programación Python también se usa
de forma regular.

Además, existen otros innumerables lenguajes de programación, que a menudo tienen un carácter
más bien experimental y no son adecuados para productos comerciales.

Para que sirve .NET

El objetivo de .NET es crear una plataforma de desarrollo de software moderna, flexible y neutral
para el desarrollo de todo tipo de software. De esta forma, proporciona a los consumidores y a los
programadores de las empresas
una interfaz de usuario perfectamente interoperable. Esta circunstancia ocasiona que la informática
esté cada vez más orientada a los navegadores.

Con la excepción de la programación de controladores de hardware, el .NET abarca todo tipo de

aplicaciones, desde aplicaciones de escritorio hasta aplicaciones web; desde servicios de sistema
hasta servicios web; y desde rutinas de bases de datos hasta programación de aplicaciones IoT y
Machine Learning.

Microsoft diseñó esta plataforma para ser un sistema neutral desde el principio, pero no hizo ningún
esfuerzo para implementarlo en Mac y Unix/Linux. Debido a la iniciativa de otras compañías
(especialmente Novell), grandes
partes de .NET están ahora disponibles para otros sistemas operativos.

Y esto es incluso apoyado por Microsoft en vista del creciente número de sistemas operativos que
compiten entre sí, especialmente en el mercado de los dispositivos móviles. El propio Microsoft
ofrece una variante para Mac OS con Silverlight.

Ventajas de .NET
Básicamente, las diferentes variantes de los entornos de desarrollo .NET ofrecen a los
programadores toda una gama de ventajas. Estas son, entre otras:

• Interoperabilidad: Los elementos de software y programas desarrollados pueden utilizar las

funcionalidades de los programas desarrollados fuera de .NET.
• Common Language Runtime (CLR): Un entorno de tiempo en ejecución uniforme de todos
los lenguajes de programación .NET disponibles. Esto asegura un comportamiento consis-
tente en las áreas de uso de memoria y seguridad.
• Independencia del lenguaje utilizado: La base es una arquitectura de lenguaje común, que
permite el intercambio de datos entre dos programas en diferentes lenguajes de programa-
ción.
• Una biblioteca de clases comunes: Una biblioteca de códigos para las funciones más utiliza-
das para evitar la duplicación y la programación innecesaria.
• Seguridad: Todas las soluciones de software desarrolladas se basan en un modelo de segu-
ridad común y efectivo.
Preguntas para este capitulo
 1

1. Que es .NET
2. Cuáles son los componentes de la arquitectura .NET
3. Explique como el JIT(Just in Time) trabaja en la compilación
4. Cuáles son las implementaciones de .NET
5. Cuál es el componente que forma parte de la biblioteca de clases
6. Como funciona .NET
7. Cuáles son los lenguajes de programación de .NET
8. Cuál es la diferencia entre .NET y .NET framework

ARQUITECTURA DE SOFTWARE

DEFINICIÓN

La arquitectura de software de un sistema es el conjunto de estructuras necesarias para razonar

sobre el sistema. Comprende elementos de software, relaciones entre ellos, y propiedades de
ambos. (Bass, Clements y Kazman, 2012).

ARQUITECTURA, ATRIBUTOS DE CALIDAD Y OBJETIVOS DE NEGOCIO

Además de ayudar a identificar módulos individuales que permitan llevar a cabo el desarrollo en
paralelo de un sistema por parte de un equipo de desarrollo, la arquitectura de software tiene otra
importancia especial: la manera en que se estructura un sistema tiene impacto directo sobre la
capacidad de este para satisfacer los requerimientos, en particular aquellos que se conocen como
atributos de calidad del sistema.

BENEFICIOS DE LA ARQUITECTURA

Se mencionó al principio de este capítulo que el desarrollo de sistemas enfrenta por lo general
restricciones en relación con el tiempo, el costo y la calidad. Como se describe a continuación,
enfatizar las actividades del ciclo de desarrollo de la arquitectura de software aporta diversos
beneficios respecto de estas restricciones.

Aumentar la calidad de los sistemas

La relación entre arquitectura y calidad es directa: la arquitectura permite satisfacer los atributos
de calidad de un sistema y estos son, a su vez, una de las dos dimensiones principales asociadas con
la calidad de los sistemas, siendo la segunda el número de defectos. Hacer una inversión significativa
en el diseño arquitectónico contribuye a reducir la cantidad de defectos, la cual, de otra forma,
podría traducirse en fallas que impactan negativamente en la calidad.

Un ejemplo de falla asociada con un diseño deficiente ocurre cuando se pone un sistema en
producción y se descubre que no da soporte al número de usuarios previsto en un principio.

Mejorar tiempos de entrega de proyectos

La arquitectura de software juega un rol importante para que los sistemas sean desarrollados en
tiempo y forma. En principio, algunos de los elementos que se identifican dentro de las estructuras
 1

arquitectónicas ayudan directamente a llevar a cabo estimaciones más precisas del tiempo
requerido para el desarrollo. Por otro lado, una estructuración adecuada ayuda a asignar el trabajo
y facilita el desarrollo en paralelo del sistema por parte de un equipo. Lo anterior optimiza el
esfuerzo realizado y reduce el tiempo que toma el desarrollo del sistema.

El diseño de la arquitectura involucra con frecuencia la reutilización, ya sea de soluciones

conceptuales o de componentes existentes, y esto ayuda también a reducir de manera significativa
el tiempo de desarrollo. Por último, y relacionado con la calidad de manera directa, la reducción de
defectos resultante de un buen diseño da como resultado una necesidad menor de volver a realizar
el trabajo, lo cual contribuye a que los sistemas se entreguen en los plazos previstos.

Reducir costos de desarrollo

Respecto del costo de un sistema, la arquitectura también es fundamental. La reutilización es un

factor importante en el momento de hacer un diseño arquitectónico porque ayuda a reducir costos.
Por otra parte, es posible considerar la reutilización como un atributo de calidad del sistema y tomar
decisiones de diseño al respecto con la finalidad de lograr una disminución de costos en el desarrollo
de sistemas subsecuentes. Reiteramos asimismo que un buen diseño contribuye a aminorar la
necesidad de volver a hacer el trabajo y facilita el mantenimiento, lo cual también conduce a bajar
los gastos

Requerimientos

Los objetivos de negocio del sistema pueden satisfacerse mediante comportamientos o

características provistas por este. Por ejemplo, el objetivo de una organización que vende boletos
de autobús, de ingresar a mercados internacionales, puede satisfacerse al permitir la compra en
línea por medio de un portal y al tener facilidad para adaptar el sistema a diferentes idiomas,
navegadores web y dispositivos móviles. Técnicamente hablando, y como se indica en la siguiente
definición tomada de del libro Software, en el ámbito de la ingeniería de software las
especificaciones de estos comportamientos y características reciben el nombre de requerimientos.

Requerimiento es una especificación que describe alguna funcionalidad, atributo o factor de calidad
de un sistema de software. Puede describir también algún aspecto que restringe la forma en que se
construye ese sistema.

Requerimientos funcionales y no funcionales

Requerimientos funcionales

Enunciados acerca de los servicios del sistema que debe proporcionar, como el sistema debe
reaccionar a entradas generales y cómo el sistema debe comportarse en situaciones particulares.

Pueden explicar lo que el sistema no debe hacer.

Requerimientos no funcionales

Limitaciones en los servicios o funciones que ofrece el sistema, como restricciones de tiempo,
restricciones del proceso de desarrollo, normas, etc.

A menudo se aplica al sistema en su conjunto, en lugar de a las funciones o servicios individuales.

 1

Requerimientos de dominio

Las restricciones en el sistema del dominio de la operación

UML y su diseño relacionado con la arquitectura

Diferencias entre Arquitectura y Diseño

Una vez que se reconoce la diferencia, que nunca debió ser menos que obvia, entre diseño e
implementación, o entre vistas conceptuales y vistas tecnológicas ¿Es la AS solamente otra palabra
para designar el diseño? Como suele suceder, no hay una sola respuesta, y las que hay no son
taxativas. La comunidad de AS, en particular la de extracción académica, sostiene que ésta difiere
sustancialmente del mero diseño. Pero Taylor y Medvidovic [TM00], por ejemplo, señalan que la
literatura actual mantiene en un estado ambiguo la relación entre ambos campos, albergando
diferentes interpretaciones y posturas:
 1

1) Una postura afirma que arquitectura y diseño son lo mismo.

2) Otra, en cambio, alega que la arquitectura se encuentra en un nivel de abstracción por encima
del diseño, o es simplemente otro paso (un artefacto) en el proceso de desarrollo de software.

3) Una tercera establece que la arquitectura es algo nuevo y en alguna medida diferente del diseño
(pero de qué manera y en qué medida se dejan sin especificar).

Taylor y Medvidovic estiman que la segunda interpretación es la que se encuentra más cerca de la
verdad. En alguna medida, la arquitectura y el diseño sirven al mismo propósito. Sin embargo, el
foco de la AS en la estructura del sistema y en las interconexiones la distingue del diseño de software
tradicional, tales como el diseño orientado a objetos, que se concentra más en el modelado de
abstracciones de más bajo nivel, tales como algoritmos y tipos de datos. A medida que la
arquitectura de alto nivel se refina, sus conectores pueden perder prominencia, distribuyéndose a
través de los elementos arquitectónicos de más bajo nivel, resultando en la transformación de la
arquitectura en diseño.

Estilos arquitectónicos

El tópico más urgente y exitoso en arquitectura de software en los últimos cuatro o cinco años es,
sin duda, el de los patrones (patterns), tanto en lo que concierne a los patrones de diseño como a
los de arquitectura. Inmediatamente después, en una relación a veces de complementariedad, otras
de oposición, se encuentra la sistematización de los llamados estilos arquitectónicos. Cada vez que
alguien celebra la mayoría de edad de la arquitectura de software, y aunque señale otros logros
como la codificación de los ADLs o las técnicas de refinamiento.

MODEL-VIEW-CONTROLLER (MVC)

Reconocido como estilo arquitectónico por Taylor y Medvidovic, muy rara vez mencionado en los
surveys estilísticos usuales, considerado una micro-arquitectura por Robert Allen y David Garlan, el
MVC ha sido propio de las aplicaciones en Smalltalk por lo menos desde 1992, antes que se
generalizaran las arquitecturas en capas múltiples. En ocasiones se lo define más bien como un
patrón de diseño o como práctica recurrente, y en estos términos es referido en el marco de la
estrategia arquitectónica de Microsoft. En la documentación correspondiente es tratado a veces en
términos de un estilo decididamente abstracto y otras como patrón de aplicación ligado a una
implementación específica en Visual C++ o en ASP.NET. Buschmann y otros lo consideran un patrón
correspondiente al estilo de los sistemas interactivos.

El patrón conocido como Modelo-Vista-Controlador (MVC) separa el modelado del dominio, la

presentación y las acciones basadas en datos ingresados por el usuario en tres clases diferentes:
 1

Modelo. El modelo administra el comportamiento y los datos del dominio de aplicación, responde
a requerimientos de información sobre su estado (usualmente formulados desde la vista) y
responde a instrucciones de cambiar el estado (habitualmente desde el controlador).

Vista. Maneja la visualización de la información.

Controlador. Interpreta las acciones del ratón y el teclado, informando al modelo y/o a la vista para
que cambien según resulte apropiado.

Tanto la vista como el controlador dependen del modelo, el cual no depende de las otras clases.
Esta separación permite construir y probar el modelo independientemente de la representación
visual. La separación entre vista y controlador puede ser secundaria en aplicaciones de clientes ricos
y, de hecho, muchos frameworks de interfaz implementan ambos roles en un solo objeto. En
aplicaciones de Web, por otra parte, la separación entre la vista (el browser) y el controlador (los
componentes del lado del servidor que manejan los requerimientos de HTTP) está mucho más
taxativamente definida.

Entre las ventajas del estilo señaladas en la documentación de Patterns & Practices de Microsoft
están las siguientes:

Soporte de vistas múltiples. Dado que la vista se halla separada del modelo y no hay dependencia
directa del modelo con respecto a la vista, la interfaz de usuario puede mostrar múltiples vistas de
los mismos datos simultáneamente. Por ejemplo, múltiples páginas de una aplicación de Web
pueden utilizar el mismo modelo de objetos, mostrado de maneras diferentes.

Adaptación al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor
rapidez que las reglas de negocios. Los usuarios pueden preferir distintas opciones de
representación, o requerir soporte para nuevos dispositivos como teléfonos celulares o PDAs. Dado
que el modelo no depende de las vistas, agregar nuevas opciones de presentación generalmente no
afecta al modelo. Este patrón sentó las bases para especializaciones ulteriores, tales como Page
Controller y Front Controller.

Entre las desventajas, se han señalado:

Complejidad. El patrón introduce nuevos niveles de indirección y por lo tanto aumenta ligeramente
la complejidad de la solución. También se profundiza la orientación a eventos del código de la
interfaz de usuario, que puede llegar a ser difícil de depurar. En rigor, la configuración basada en
eventos de dicha interfaz corresponde a un estilo particular (arquitectura basada en eventos) que
aquí se examina por separado.

ARQUITECTURAS EN CAPAS

Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen con mayor
frecuencia mencionados como categorías mayores del catálogo, o, por el contrario, como una de las
posibles encarnaciones de algún estilo más envolvente. En Garlan y Shaw definen el estilo en capas
como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente
superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. Instrumentan así
una vieja idea de organización estratigráfica que se remonta a las concepciones formuladas por el
patriarca Edsger Dijkstra en la década de 1960.
 1

Las ventajas del estilo en capas son obvias. Primero que nada, el estilo soporta un diseño basado en
niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un
problema complejo en una secuencia de pasos incrementales. En segundo lugar, el estilo admite
muy naturalmente optimizaciones y refinamientos. En tercer lugar, proporciona amplia
reutilización. Al igual que los tipos de datos abstractos, se pueden utilizar diferentes
implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces
de cara a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa estándar,
a partir de las cuales se pueden construir extensiones o prestaciones específicas.

También se han señalado algunas desventajas de este estilo [GS96]. Muchos problemas no admiten
un buen mapeo en una estructura jerárquica. Incluso cuando un sistema se puede establecer
lógicamente en capas, consideraciones de performance pueden requerir acoplamientos específicos
entre capas de alto y bajo nivel.

El modelo posee virtudes estilísticas de distribución, preservación de identidad, seguridad,

performance, escalabilidad, sincronicidad, balanceo de carga, robustez y acidez transaccional que
siguen siendo competitivas y que no se valoran hasta que uno se muda a un contexto que obliga a
atenerse a un estilo que carece de ellas.

ARQUITECTURAS ORIENTADAS A OBJETOS

Nombres alternativos para este estilo han sido Arquitecturas Basadas en Objetos, Abstracción de
Datos y Organización Orientada a Objectos. Los componentes de este estilo son los objetos, o más
bien instancias de los tipos de dato abstractos. En la caracterización clásica de David Garlan y Mary
Shaw, los objetos representan una clase de componentes que ellos llaman managers, debido a que
son responsables de preservar la integridad de su propia representación. Un rasgo importante de
este aspecto es que la representación interna de un objeto no es accesible desde otros objetos.

Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y polimorfismo.
Son asimismo las unidades de modelado, diseño e implementación, y los objetos y sus interacciones
son el centro de las incumbencias en el diseño de la arquitectura y en la estructura de la aplicación.
 1

En la literatura sobre estilos, las arquitecturas orientadas a objeto han sido clasificadas de formas
diferentes, conforme a los diferentes puntos de vista que alternativamente enfatizan la jerarquía de
componentes, su distribución topológica o las variedades de conectores. En su famosa disertación
sobre REST, Roy Fielding subordina las arquitecturas de objetos distribuidos a los estilos peer-to-
peer, al lado de la integración basada en eventos y el estilo C2. Si se sitúa la idea de llamado y
respuesta como organizadora del estilo, los sub-estilos serían: Programa principal y subrutinas. Es
el paradigma clásico de programación. El objetivo es descomponer un programa en pequeñas piezas
susceptibles de modificarse independientemente.

ARQUITECTURAS BASADAS EN COMPONENTES

Los sistemas de software basados en componentes se basan en principios definidos por una
ingeniería de software específica (CBSE). En un principio, hacia 1994, se planteaba como una
modalidad que extendía o superaba la tecnología de objetos, como en un famoso artículo de BYTE
cuyo encabezado rezaba así: “ComponentWare – La computación Orientada a Objetos ha fracasado.
Pero el software de componentes, como los controles de Visual Basic, está teniendo éxito.

En un estilo de este tipo:

Los componentes en el sentido estilístico son componentes en el sentido de CBSE y son las unidades
de modelado, diseño e implementación. Las interfaces están separadas de las implementaciones, y
las interfaces y sus interacciones son el centro de incumbencias en el diseño arquitectónico. Los
componentes soportan algún régimen de introspección, de modo que su funcionalidad y
propiedades puedan ser descubiertas y utilizadas en tiempo de ejecución.

ESTILOS DE CÓDIGO MÓVIL

Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intérpretes, los sistemas
basados en reglas y los procesadores de lenguaje de comando. Fuera de las máquinas virtuales y los
intérpretes, los otros miembros del conjunto han sido rara vez estudiados desde el punto de vista
estilístico. Los sistemas basados en reglas, que a veces se agrupan como miembros de la familia de
estilos basados en datos, han sido estudiados particularmente por Murrell, Gamble, Stiger y Plant.

ARQUITECTURA DE MÁQUINAS VIRTUALES

La arquitectura de máquinas virtuales se ha llamado también intérpretes basados en tablas. De

hecho, todo intérprete involucra una máquina virtual implementada en software. Se puede decir
que un intérprete incluye un seudo-programa a interpretar y una máquina de interpretación. El
seudo-programa a su vez incluye el programa mismo y el análogo que hace el intérprete de su estado
de ejecución (o registro de activación). La máquina de interpretación incluye tanto la definición del
intérprete como el estado actual de su ejecución. De este modo, un intérprete posee por lo general
cuatro componentes:

(1) una máquina de interpretación que lleva a cabo la tarea, (2) una memoria que contiene el seudo-
código a interpretar, (3) una representación del estado de control de la máquina de interpretación,
y (4) una representación del estado actual del programa que se simula.

El estilo comprende básicamente dos formas o sub-estilos, que se han llamado intérpretes y
sistemas basados en reglas. Ambas variedades abarcan, sin duda, un extenso espectro que va desde
los llamados lenguajes de alto nivel hasta los paradigmas declarativos no secuenciales de
 1

programación, que todo el mundo sabe que implementan un proxy (una especie de nivel de
impostura) que encubren al usuario operaciones que en última instancia se resuelven en
instrucciones de máquinas afines al paradigma secuencial imperativo de siempre.

ESTILOS HETEROGÉNEOS

Antes de pasar a la familia más fuertemente referida en los últimos tiempos, incluyo en este grupo
formas compuestas o indóciles a la clasificación en las categorías habituales.

Es por cierto objetable y poco elegante que existan clases residuales de este tipo en una taxonomía,
pero ninguna clasificación conocida ha podido resolver este dilema conceptual. En este apartado
podrían agregarse formas que aparecen esporádicamente en los censos de estilos, como los
sistemas de control de procesos industriales, sistemas de transición de estados, arquitecturas
específicas de dominios o estilos derivados de otros estilos, como GenVoca, C2 o REST.

SISTEMAS DE CONTROL DE PROCESOS

Desde el punto de vista arquitectónico, mientras casi todos los demás estilos se pueden definir en
función de componentes y conectores, los sistemas de control de procesos se caracterizan no sólo
por los tipos de componentes, sino por las relaciones que mantienen entre ellos. El objetivo de un
sistema de esta clase es mantener ciertos valores dentro de ciertos rangos especificados, llamados
puntos fijos o valores de calibración; el caso más clásico es el de los termostatos. Existen
mecanismos tanto de retroalimentación (feedback) como de prealimentación (feedforward), y tanto
reductores de oscilación como amplificadores; pero el tipo de retroalimentación negativa es el más
común. En uno de los pocos tratamientos arquitectónicos de esta clase de modelos cibernéticos,
Shaw y Garlan recomiendan separar los tres elementos del bucle de control (mecanismos para
cambiar los valores de variables y algoritmos de control, elementos de datos; esquema del bucle).
La ventaja señalada para este estilo radica en su elasticidad ante perturbaciones externas.

ARQUITECTURAS BASADAS EN ATRIBUTOS

Aunque algunas otras veces se ha inventado un nuevo estilo para agregarlo al inventario de las
variedades existentes, como en este caso, en el de Arch, C2 o REST, la literatura estilística suele ser
de carácter reactivo e historicista antes que creativa e innovadora, como si el número de estilos se
quisiera mantener deliberadamente bajo. La arquitectura basada en atributos o ABAS fue propuesta
 1

por Klein y Klazman. La intención de estos autores es asociar a la definición del estilo arquitectónico
un framework de razonamiento (ya sea cuantitativo o cualitativo) basado en modelos de atributos
específicos. Su objetivo se funda en la premisa que dicha asociación proporciona las bases para crear
una disciplina de diseño arquitectónico, tornando el diseño en un proceso predecible, antes que en
una metodología ad hoc. Con ello se lograría que la arquitectura de software estuviera más cerca
de ser una disciplina de ingeniería, aportando el beneficio esencial de la ingeniería (predictibilidad)
al diseño arquitectónico.

ESTILOS PEER-TO-PEER

Esta familia, también llamada de componentes independientes, enfatiza la modificabilidad por

medio de la separación de las diversas partes que intervienen en la computación. Consiste por lo
general en procesos independientes o entidades que se comunican a través de mensajes. Cada
entidad puede enviar mensajes a otras entidades, pero no controlarlas directamente. Los mensajes
pueden ser enviados a componentes nominados o propalados mediante broadcast. Miembros de la
familia son los estilos basados en eventos, en mensajes (Chiron-2), en servicios y en recursos.

ARQUITECTURAS BASADAS EN EVENTOS

Las arquitecturas basadas en eventos se han llamado también de invocación implícita. Otros
nombres propuestos para el mismo estilo han sido integración reactiva o difusión (broadcast)
selectiva. Por supuesto que existen estrategias de programación basadas en eventos, sobre todo
referidas a interfaces de usuario, y hay además eventos en los modelos de objetos y componentes,
pero no es a eso a lo que se refiere primariamente el estilo, aunque esa variedad no está del todo
excluida. En términos de patrones de diseño, el patrón que corresponde más estrechamente a este
estilo es el que se conoce como Observer, un término que se hizo popular en Smalltalk a principios
de los ochenta; en el mundo de Java se le conoce como modelo de delegación de eventos.

ARQUITECTURAS ORIENTADAS A SERVICIOS

Sólo recientemente estas arquitecturas que los conocedores llaman SOA han recibido tratamiento
intensivo en el campo de exploración de los estilos. Al mismo tiempo se percibe una tendencia a
promoverlas de un sub-estilo propio de las configuraciones distribuidas que antes eran a un estilo
en plenitud.

Web services basados en XML, en los cuales los formatos de intercambio se basan en XML 1.0
Namespaces y el protocolo de elección es SOAP. SOAP significa un formato de mensajes que es XML,
comunicado sobre un transporte que por defecto es HTTP, pero que puede ser también HTTPs,
SMTP, FTP, IIOP, MQ o casi cualquier otro, o puede incluir prestaciones sofisticadas de última
generación como WS-Routing, WSAttachment, WS-Referral, etcétera.

Alrededor de los Web services, que dominan el campo de un estilo SOA más amplio que podría
incluir otras opciones, se han generado las controversias que usualmente acompañan a toda idea
exitosa. Al principio hasta resultaba difícil encontrar una definición aceptable y consensuada que no
fuera una fórmula optimista de mercadotecnia.

El grupo de tareas de W3C, por ejemplo, demoró un año y medio en ofrecer la primera definición
canónica apta para consumo arquitectónico, que no viene mal reproducir aquí:
 1

Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina

sobre una red. Posee una interfaz descripta en un formato procesable por máquina
(específicamente WSDL). Otros sistemas interactúan con el Web service de una manera prescripta
por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una
serialización en XML en conjunción con otros estándares relacionados a la Web

ARQUITECTURAS BASADAS EN RECURSOS

Una de las más elocuentes presentaciones de arquitecturas peer-to-peer ha sido la disertación

doctoral de Roy Fielding, elaborada con anterioridad, pero expuesta con mayor impacto en el año
2000. Es en ella donde se encuentra la caracterización más detallada del estilo denominado
Representational State Transfer o REST. Aunque la literatura especializada tiende a considerar a
REST una variante menor de las arquitecturas basadas en servicios, Fielding considera que REST
resulta de la composición de varios estilos más básicos, incluyendo repositorio replicado, cache,
cliente-servidor, sistema en capas, sistema sin estado, máquina virtual, código a demanda e interfaz
uniforme.

En síntesis, muy apretada, podría decirse que REST define recursos identificables y métodos para
acceder y manipular el estado de esos recursos. El caso de referencia es nada menos que la World
Wide Web, donde los URIs identifican los recursos y HTTP es el protocolo de acceso. El argumento
central de Fielding es que HTTP mismo, con su conjunto mínimo de métodos y su semántica
simplísima, es suficientemente general para modelar cualquier dominio de aplicación.
 1

Preguntas sobre este tema

1. Defina una arquitectura

2. Cuáles son los beneficios de una arquitectura de software
3. Defina los requerimientos
4. Explique un requerimiento funcional
5. Explique un requerimiento no funcional
6. Explique los atributos de productos
7. Explique los atributos de organización
8. Explique los atributos externos
9. Cuál es la diferencia entre requerimiento funcional y no funcional
10. Cuál es la diferencia entre una arquitectura y diseño
11. Explique cómo trabaja el estilo modelo vista controlador MVC
12. Explique las ventajas de las arquitecturas en capas
13. Defina la arquitectura de objetos y su funcionamiento
14. Defina la arquitectura de componentes
15. Cuando se aplica la arquitectura de máquinas virtuales
16. Menciona arquitecturas que componen los estilos Peer to Peer
17. Diferencia entre servicios REST y SOAP

FRAMEWORK

¿Qué es un Framework?

Dado que a menudo son construidos, probados y optimizados por varios ingenieros y
programadores de software experimentados, los frameworks de software son versátiles, robustos
y eficientes.
 1

El uso de un framework de software para desarrollar aplicaciones le permite concentrarse en la

funcionalidad de alto nivel de la aplicación. Esto se debe a que el framework se ocupa de cualquier
funcionalidad de bajo nivel.

¿Por qué usamos Frameworks?

Desarrollar software es un proceso complejo. Requiere una gran cantidad de tareas, incluida la
codificación, el diseño y las pruebas. Solo para la parte de codificación, los programadores tenían
que encargarse de la sintaxis, las declaraciones, la recolección de basura, las excepciones y más.

Los frameworks de software facilitan la vida a los desarrolladores al permitirles tomar el control de
todo el proceso de desarrollo de software, o la mayor parte, desde una única plataforma.

Ventajas de utilizar un framework de software:

• Ayuda a establecer mejores prácticas de programación y al uso adecuado de patrones de

diseño.
• El código es más seguro.
• Se puede evitar el código duplicado y redundante.
• Ayuda a desarrollar código de manera consistente con menos errores.
• Facilita el trabajo en tecnologías sofisticadas.
• Se podría crear su framework de software o contribuir a frameworks de código abierto. Por
lo tanto, hay una mejora continua en la funcionalidad.
• Varios segmentos de código y funcionalidades están prediseñados y probados previa-
mente. Esto hace que las aplicaciones sean más confiables
• Probar y depurar el código es mucho más fácil y pueden hacerlo incluso los desarrolladores
que no son propietarios del código.
• El tiempo necesario para desarrollar una aplicación se reduce significativamente.

Diferencias entre una biblioteca y un framework

Algunos pueden suponer que un framework de software es una colección de bibliotecas al igual que
las bibliotecas son una colección de rutinas precompiladas. Sin embargo, esto no es cierto ya que
no todos los frameworks de software utilizan o dependen de bibliotecas.

La diferencia entre una biblioteca y un framework es que este último llama al código. Frente a esto,
el código llama a la biblioteca de software. Entendamos esto con un ejemplo:

Tipos de frameworks

Como desarrollador, debe estar atento a los frameworks que mejor se adapten a sus necesidades.
Ya sea que esté trabajando en un sitio web, ciencia de datos, administración de bases de datos o
aplicaciones móviles, existen frameworks de software para todos los géneros de programación de
software.

Existen muchos tipos de frameworks de software para facilitar el desarrollo de aplicaciones para
una amplia gama de dominios de desarrollo de aplicaciones. Analicemos algunos de los frameworks
de software que están de moda hoy en día:
 1

1)Framework de aplicaciones web

ANGULAR

Angular es un framework JS de código abierto basado en mecanografiado que facilita la creación de

aplicaciones en la web. Angular resuelve los desafíos del desarrollo de aplicaciones combinando
plantillas declarativas, inyección de dependencia, herramientas de extremo a extremo y mucho más.

Angular permite a los desarrolladores crear aplicaciones que se encuentran en la web, el dispositivo
móvil y el escritorio.

El popular framework de JavaScript se utiliza en aplicaciones y sitios públicos como Google Cloud
Platform y AdWords, así como en muchas herramientas internas de Google.

Algunos sitios web populares desarrollados con AngularJS son:

• Netflix
• Paypal
• Youtube

LARAVEL

Laravel es un framework de aplicación web basado en PHP con una sintaxis elegante y expresiva. El
framework de trabajo de código abierto sigue un patrón de diseño modelo-vista-controlador que es
robusto y fácil de entender.

2) Frameworks de DataScience

APACHE SPARK

Apache Spark es un motor de análisis unificado para el procesamiento de datos a gran escala. Puede
escribir aplicaciones rápidamente en Java, Scala, Python, R y SQL utilizando Apache Spark.

PYTORCH

Laravel es un framework de aplicación web basado en PHP con una sintaxis elegante y expresiva. El
framework de trabajo de código abierto sigue un patrón de diseño modelo-vista-controlador que es
robusto y fácil de entender.

TENSORFLOW

TensorFlow es un framework de trabajo de código abierto de extremo a extremo para el aprendizaje

automático (ML). Tiene un ecosistema integral y flexible de herramientas, bibliotecas y recursos
comunitarios que permite a los investigadores sumergirse en el aprendizaje automático y a los
desarrolladores crear e implementar rápidamente aplicaciones impulsadas por el aprendizaje
automático.

3) Frameworks de desarrollo móvil

IÓNICO
 1

Ionic es un kit de herramientas de interfaz de usuario móvil de código abierto y gratuito para
desarrollar aplicaciones nativas multiplataforma de alta calidad para Android, iOS y la Web, todo
desde una única base de código.

Ionic es una plataforma de desarrollo para todo el ciclo de vida de las aplicaciones que permite a los
equipos crear aplicaciones mejores y más rápidas.

XAMARIN

Xamarin es una plataforma de desarrollo de aplicaciones de código abierto y gratuita para crear
aplicaciones de Android, iOS con .NET y C #. Xamarin es parte de la famosa plataforma .NET.

ALETEO

Flutter es el conjunto de herramientas de interfaz de usuario de Google para crear hermosas

aplicaciones compiladas de forma nativa para dispositivos móviles, web y de escritorio a partir de
una única base de código. Tiene una interfaz de usuario expresiva y flexible y ofrece un rendimiento
nativo en plataformas iOS y Android.

Preguntas sobre este tema

1. Defina un framework
2. Mencione las ventajas de usar framework
3. Mencione diferencia entre biblioteca y framework
4. Explique los tipos de framework
5. Mencione ejemplos de framework de acuerdo al tipo

PATRONES DE DISEÑO

“Los patrones de diseño son descripciones de objetos y clases conectadas que se personalizan para
resolver un problema de diseño general en un contexto particular”.

Los patrones de diseño ofrecen soluciones comunes a problemas recurrentes de diseño de

aplicaciones. En la programación orientada a objetos, los patrones de diseño normalmente están
dirigidos a resolver los problemas asociados con la creación e interacción de objetos, en lugar de
los problemas a gran escala que afrontan las arquitecturas generales del software. Proporcionan
soluciones generalizadas en forma de repeticiones que se pueden aplicar a problemas de la vida
real.

Los patrones de diseño son soluciones útiles y probadas para los problemas que inevitablemente
aparecen. No solo albergan años de conocimiento y experiencia colectiva, sino que además los
patrones de diseño ofrecen un vocabulario común entre los desarrolladores y arrojan luz sobre
muchos problemas.

Los patrones de diseño se clasificaron originalmente en tres grupos:

● Creacionales.

● Estructurales.
 1

● De comportamiento.

PATRONES CREACIONALES

Builder

Este patrón pretende separar la lógica de construcción de su representación. Para ello, define una
clase abstracta, Builder, que es la encargada de crear las instancias de los objetos. Los elementos
que intervienen son los siguientes:

● Builder: interfaz abstracta que crea los productos.

● Builder concreto: implementación concreta del builder que crea productos de un cierto tipo.

● director: el encargado de utilizar la clase builder para crear los objetos.

Singleton

Este patrón consiste en utilizar una sola instancia de clase, definiendo así un único punto global de
acceso a ella. Dicha instancia es la encargada de la inicialización, creación y acceso a las propiedades
de clase.

Este patrón es muy utilizado cuando se quiere controlar el acceso a un único recurso físico (fichero
de lectura de uso exclusivo), o haya datos que deban estar disponibles para el resto de objetos de
la aplicación (una instancia de log, por ejemplo).

Se define un método de acceso para recuperar la instancia de la clase. Este método también se
encargará de crear la instancia en el caso de que se solicite por primera vez. Hay que prestar
atención a los problemas que pudiera haber de acceso exclusivo.

Dependency Injection
 1

Se trata de un patrón de diseño que se encarga de extraer la responsabilidad de la creación de

instancias de un componente para delegarla en otro. Permite que un objeto reciba otros objetos de
los que depende, en lugar de ser el propio objeto el que los cree. Estos otros objetos
se llaman dependencias. En la típica relación de "uso", el objeto receptor se llama cliente y el objeto
pasado (es decir, "inyectado") se llama servicio. El código que pasa el servicio al cliente puede ser
de muchos tipos y se llama inyector. En lugar de que el cliente especifique qué servicio
usará, el inyector le dice al cliente qué servicio usar. La "inyección" se refiere al paso de una
dependencia (un servicio), al objeto (un cliente) que lo usaría.

La inyección de dependencias es una forma de lograr la inversión de control.

El cliente únicamente necesita conocer las interfaces de los servicios sin preocuparse de la
implementación real de los mismos.

Abstract Factory

El propósito de Abstract Factory es proporcionar una interfaz para crear familias de objetos
relacionados, sin especificar clases concretas.

Normalmente, el cliente crea una implementación concreta de la fábrica abstracta y luego utiliza la
interfaz genérica de la misma para crear los objetos concretos. El cliente no sabe (ni le importa) qué
objetos concretos obtiene de cada una de estas fábricas internas, ya que utiliza solo las
interfaces genéricas de sus productos. Este patrón separa los detalles de la
implementación de un conjunto de objetos de su uso general y se basa en la composición del objeto,
ya que la creación de objetos se implementa en los métodos expuestos en la interfaz de fábrica.

La estructura típica del patrón Abstract Factory es la siguiente:

● Cliente: la clase que llamará a la factoría adecuada ya que necesita crear uno de los objetos que
provee la factoría.

● Abstract Factory: es la definición de las interfaces de las factorías.

Debe de proveer un método para la obtención de cada objeto que pueda crear.
● Factorías Concretas: estas son las diferentes familias de productos.
 1

Provee la instancia concreta del tipo de objeto que se encarga de crear

Producto abstracto: definición de las interfaces para la familia de productos genéricos.

● Producto concreto: implementación de los diferentes productos.

Este patrón es otra implementación del principio de inversión de control (IoC).

Factory Method

Provee una interfaz o clase abstracta (creator) que permite encapsular la lógica de creación de los
objetos en subclases y éstas deciden qué clase instanciar. Los objetos se crean a partir de un método
(factory method) y no a través de un constructor como se hace normalmente. Además, los
ConcreteCreators devuelven siempre la interfaz (Product), esto permite que el cliente trate a los
productos por igual, tengan una implementación u otra.

La estructura típica del patrón Factory method es la siguiente:

● Product: definición de las interfaces para la familia de productos genéricos.

● ConcreteProduct: implementación de los diferentes productos.

● Creator: declara el factory method que se encargará de instanciar nuevos objetos. Es importante
que este método devuelva la interfaz

Product. Normalmente el Creator suele ser una clase abstracta con cierta lógica de negocio
relacionada con los productos a crear.

Dependiendo de la instancia de producto que se devuelva, se puede seguir un flujo u otro.

● ConcreteCreator: crea la instancia del producto concreto.

 1

PATRONES ESTRUCTURALES

Adapter

Este patrón "proporciona una interfaz unificada a un conjunto de interfaces en un subsistema".

Head First Design Patterns da la misma explicación y señala que convierte la interfaz de una clase
en otra interfaz que los clientes esperan. El adaptador permite que las clases puedan trabajar juntas
ya que, de otro modo, no podrían debido a tener interfaces incompatibles.

● Adaptadores de clase: generalmente usan herencia múltiple o varias interfaces para

implementarlo.

● Adaptadores de objetos: realizan las composiciones de objetos para adaptarlos.

Un adaptador se puede considerar como la aplicación del principio de inversión de dependencias

(DIP), cuando la clase de alto nivel define su propia interfaz (adaptador) para el módulo de bajo nivel
(implementado por una clase adaptada).

Decorator
 1

El propósito de este patrón es el de asignar responsabilidades adicionales a un objeto

dinámicamente, proporcionando una alternativa flexible a la herencia para extender la
funcionalidad.

La estructura está compuesta por:

● Component: define la interfaz que deben implementar los objetos a los que se les pueden añadir
funcionalidades.

● ConcreteComponent: define un objeto al cual se le pueden agregar responsabilidades adicionales.

Implementa la interfaz Component.

● Decorator: mantiene una referencia al Component asociado. Implementa la interfaz de la super

clase Component, delegando en el Component asociado. El Decorator, en general, añade
comportamiento antes o después de un método que ya existe en el Component.

● ConcreteDecorator: añade responsabilidades al Component.

Entre las ventajas de implementar este patrón, podemos encontrar:

● Es más flexible que la herencia.

● Permite añadir y eliminar responsabilidades en tiempo de ejecución.

● Evita la herencia con muchas clases y la herencia múltiple.

● Limita la responsabilidad de los componentes para evitar clases con excesivas responsabilidades
en los niveles superiores de la jerarquía.

Bridge

Tiene como objetivo desacoplar laabstracción de laimplementación.

Permite que la abstracción y la implementación se desarrollen de forma independiente a través de

un puente (bridge) entre ambas. El código del cliente podrá acceder a la abstracción sin preocuparse
por la parte de implementación.
 1

Participantes:

● Abstraction: recibe por parámetro la interfaz que servirá de puente con las implementaciones y
es la que se comunicará con el cliente.

● ConcreteAbstraction: puede trabajar con distintas implementaciones a través de la interfaz.

● Implementator: declara una interfaz con sus respectivos métodos que serán los que actúen de
enlace entre la abstracción y las implementaciones.

● ConcreteImplementator: contiene código concreto sobre cada implementación.

Entre las ventajas de implementar este patrón podemos encontrar:

● El cliente siempre trabaja con abstracciones y nunca con implementaciones.

● Cumple con el principio Open/Closed ya que se pueden añadir nuevas implementaciones

independientes unas de otras.

● Permite reducir el número de subclases que si usaremos herencia pura.

PATRONES DE COMPORTAMIENTO

Command

Se usa el patrón de Comando para “encapsular una solicitud” como un objeto, permitiendo definir
una interfaz común para invocar acciones diversas.

Simplificando, el objetivo de un comando es ejecutar una serie de acciones en su receptor

(Receiver). El cliente crea un objeto Command y generalmente, le pasa el Receiver para poder
acceder a él. Cuando el Client desea ejecutar el Command, se utiliza el Invoker que almacena el

Command y se encarga de iniciar su ejecución en algún momento, invocando al método execute del
Command.

Esto permite añadir otras funcionalidades a las acciones como encolamiento, registro, acciones de
deshacer o rehacer las operaciones, etc., gracias a desacoplar la solicitud de una acción de su
ejecución.
 1

Chain of Responsibility

El libro The Gang of Four [GoF] indica que se usa el patrón “evitar acoplar el remitente de una
solicitud a su receptor, al darle a más de un objeto la oportunidad de manejar la solicitud. Se
encadenan los objetos receptores y pasa la solicitud a lo largo de la cadena hasta que un receptor
lo maneja.”

Aquí se procesan una serie de receptores uno por uno (es decir, de forma secuencial). Una fuente
iniciará este procesamiento. Con este patrón, constituimos una cadena donde cada uno de los
objetos de receptores puede tener cierta lógica para manejar un tipo particular de objeto. Una vez
que se realiza el procesamiento, si aún hay algo pendiente, se puede reenviar al siguiente receptor
de la cadena.

Cabe indicar que este tipo de patrón establece una jerarquía entre los receptores, pues los primeros
en la cadena tienen prioridad sobre los siguientes. Podemos agregar nuevos receptores en cualquier
momento al final de una cadena.

Strategy

Este patrón para definir una familia de algoritmos que se encapsulan cada uno de forma que sean
intercambiables. El patrón estrategia permite que el algoritmo varíe independientemente
de un cliente a otro.
 1

La clave para aplicar el patrón Strategy es diseñar interfaces para la estrategia y su contexto, que
sean lo suficientemente generales como para admitir una variedad de algoritmos. No debería tener
que cambiar la estrategia o la interfaz de contexto para admitir un nuevo algoritmo.

Según el patrón de estrategia, los comportamientos de una clase no deben heredarse. En su lugar,
deben encapsularse utilizando interfaces. Esto es compatible con el principio Open/Closed (OCP),
que propone que las clases deben estar abiertas para la extensión, pero cerradas para la
modificación.

Template Method

Este patrón para definir el esqueleto de un algoritmo en una operación, delegando algunos pasos a
subclases. El método plantilla permite que las subclases redefinan ciertos pasos de un algoritmo sin
cambiar la estructura del algoritmo.

En un template method, definimos la estructura mínima o esencial de un algoritmo. Luego diferimos

algunas funcionalidades (responsabilidades) a las subclases. Como resultado, podemos redefinir
ciertos pasos de un algoritmo manteniendo la estructura clave fija para ese algoritmo.

En tiempo de ejecución, el algoritmo representado por el método de plantilla se ejecuta enviando

el mensaje de plantilla a una instancia de una de las subclases concretas. A través de la herencia, el
método de plantilla en la clase base comienza a ejecutarse delegando parte de los detalles de la
implementación en las clases hijas. Este mecanismo garantiza que el algoritmo general
siga los mismos pasos cada vez, al tiempo que permite que los detalles de algunos pasos dependan
de qué instancia recibió la solicitud original para ejecutar el algoritmo.
 1

Observer

Este patrón define una dependencia entre objetos de forma que cuando un objeto cambia su
estado, todos los objetos que dependen de él son notificados y pueden reaccionar si lo desean a
una acción.

El objeto de datos, o Subject, provee de métodos para que cualquier objeto

Observer pueda suscribirse o cancelar la suscripción, pasando una referencia de sí mismo al

Observable o Subject. El Subject mantiene una lista con las referencias a sus Observers para
notificarles cada cambio de estado (si procede).

Los Observers a su vez están obligados a implementar los métodos que utiliza el Subject para
notificar a sus Observers de los cambios que sufre para que todos ellos tengan la oportunidad de
reaccionar a ese cambio de manera que, cuando se produzca un cambio en el Subject, éste pueda
recorrer la lista de Observers notificando a cada uno.
Este patrón es aplicable cuando:

● Una abstracción tiene dos puntos de vista dependientes uno del otro.

Encapsular estos puntos de vista en objetos separados permite cambiarlos y reutilizarlos.

● Un cambio en un objeto requiere cambiar otros y no sabemos cuántos objetos van a cambiar.

● Un objeto debería poder notificar a otros sin saber quiénes son.

Entre las ventajas de utilizar este patrón encontramos:

● Podemos modificar el Subject y los Observers de forma independiente al estar desacoplados.

● Nos permite reutilizar tanto Observers como Subjects.

● Respeta el principio Open/Closed, permitiendo añadir Observers sin modificar los Subjects.

● Reduce el acoplamiento entre Subject y Observer, ya que un Subject sólo conoce su lista de
Observers a través de un interfaz, pero no la clase concreta.

● El Subject se comunica con los Observers mediante broadcast o difusión.

 1

State

El patrón State “permite que un objeto modifique su comportamiento cada vez que cambie su
estado interno. Parecerá que cambia la clase del objeto”. Podemos dibujar el comportamiento de
nuestro objeto como si se tratase de una “máquina de estados finita”.

El patrón estado se usa para encapsular todo el comportamiento variable de un objeto en función
de su estado interno. Es una manera más limpia de construir un objeto que cambia su
comportamiento en tiempo de ejecución sin recurrir a declaraciones condicionales, respetando el
principio Open/Closed y el Single Responsibility Principle, ya que cada estado está
representado por una clase que implementa una interfaz. Esto facilita la mantenibilidad del código.

Participantes:

● Context:

○ Define la interfaz que será usada por los clientes.

○ Mantiene una instancia que representa el estado actual del objeto.

● State:

○ Define una interfaz para encapsular el comportamiento asociado con un determinado estado del
Context.
 1

● Subclases de State:

○ Cada subclase implementa un comportamiento asociado a los diferentes estados del Context.

Visitor

Permite añadir funcionalidad sin necesidad de cambiar las clases de los elementos en los que va a
ejecutarse, a través de los denominados Visitors.

El patrón sugiere que situemos el comportamiento en una nueva clase llamada Visitor, en vez de
integrarlo todo en la clase base. Cada vez que se necesite añadir un nuevo comportamiento, se hará
en una nueva implementación de un Visitor y la clase base solo tiene que aceptar o
delegar este comportamiento en el Visitor correspondiente.

Participantes:

● Visitor: interfaz que declara una serie de métodos, normalmente llamados visit y que reciben
como parámetro elementos concretos a los que se les va a añadir funcionalidad. Se deben crear
tantos métodos visit como clases concretas tengamos por lo que, al llamarse igual, se diferenciarán
por la firma del método.

● ConcreteVisitor: implementan la interfaz Visitor y definen las funcionalidades que se aplicarán a

los elementos o clase base. Aquí es donde se debe definir el comportamiento que debe tener
nuestra clase base. En caso de querer hacer alguna modificación, se hará siempre en los
ConcreteVisitors y nunca directamente en el elemento. Recordemos que la clase base únicamente
delega al Visitor que realice estas modificaciones.

● Element: interfaz que declara un mque declara un método que acepta los Visitors.

● ConcreteElement: clase base que implementa la interfaz Element y tiene como objetivo redirigir
al Visitor concreto que se encargará de añadir el comportamiento específico.

Iterator

Provee una forma de acceder secuencialmente a los elementos de una colección sin necesidad de
exponer su representación interna. El objetivo principal es el de extraer el comportamiento de una
colección en un objeto llamado Iterator que se encargará de tener toda la información necesaria
 1

para manipularla. El cliente está siempre trabajando con abstracciones a través de sus interfaces.
Esto le permite hacer uso de varios tipos de colecciones e iteradores con el mismo código.

Participantes:

● Client: interactúa tanto con Iterator como Iterable a través de sus interfaces para no acoplarse a
clases concretas.

● Iterable: declara un método responsable de instanciar el objeto

Iterator. Importante que el método devuelva la interfaz para no acoplarnos a implementaciones.

● Concrete Iterable: implementa la interfaz e instancia el Iterator concreto que iterará sobre una
colección específica.

● Iterator: declara los métodos necesarios para recorrer la colección.

Puede declarar varios métodos como remove, getFirst, currentItem, size, next, etc.

● ConcreteIterator: implementa los métodos declarados en la interfaz y es responsable de gestionar

la posición de la iteración.

Preguntas sobre el tema

1. Defina un patrón de diseño

2. Cuál es la clasificación de los patrones
3. Explique patrón Singleton
4. Explique patrón Builder
5. Explique patrón Abstract Factory
6. Explique patrón Adapter
7. Explique patrón Decorator
8. Explique patrón Brigde
9. Explique patrón Chain of Responsibility
10. Explique patrón Strategy
11. Explique patrón Observer