UNIVERSIDAD AUTONOMA

“GABRIEL RENE MORENO”

FACULTAD DE INGENIERIA EN CIENCIAS DE LA COMPUTACIÓN Y
TELECOMUNICACIONES

PRACTICOS

“MODELO C4, DIAGRAMA DE COMPONENTE Y DIAGRAMA ORGANIZADO EN CAPAS”

Santa Cruz, 30 de Junio de 2020

EL MODELO C4 DE DOCUMENTACIÓN PARA LA ARQUITECTURA DE
SOFTWARE
Puntos principales

 La creación de diagramas de software se redujo como resultado del cambio en el uso de

metodologías ágiles. Cuando se crean diagramas, a menudo son confusos y poco claros.

 El modelo C4 consiste en un conjunto jerárquico de diagramas de arquitectura de software para

contexto, contenedores, componentes y código.

 La jerarquía de los diagramas C4 proporciona diferentes niveles de abstracción, cada uno de los
cuales es relevante para una audiencia diferente.

 Evite la ambigüedad en sus diagramas incluyendo una cantidad suficiente de texto, así como
una clave o leyenda para la notación utilizada

Los diagramas de arquitectura de software son una manera fantástica de comunicar cómo planea
construir un sistema de software (diseño inicial) o cómo funciona un sistema de software existente
(documentación retrospectiva, intercambio de conocimientos y aprendizaje).

Sin embargo, es muy probable que la mayoría de los diagramas de arquitectura de software que ha
visto sean un lío confuso de cajas y líneas. Un desafortunado e involuntario efecto secundario del
Manifiesto para el Desarrollo Ágil de Software es que muchos equipos han detenido o reducido sus
esfuerzos de diagramación y documentación, incluyendo el uso de UML.

Ahora, estos mismos equipos tienden a confiar en diagramas ad hoc que dibujan en una pizarra o
ensamblan utilizando herramientas de diagramación de propósito general, como Microsoft Visio. Ionut
Balosin escribió el año pasado “The Art of Making Architectural Diagrams” (El arte de hacer diagramas
arquitectónicos), que describe una serie de problemas comunes al hacerlo, relacionados con
notaciones semánticas incomprensibles y poco claras.

Los diagramas ambiguos de arquitectura de software conducen a malentendidos, lo que puede

ralentizar a un buen equipo. En nuestra industria, deberíamos esforzarnos por crear mejores
diagramas de arquitectura de software. Después de años de crear software y trabajar con equipos de
todo el mundo, he creado algo que llamo el “modelo C4”. C4 significa contexto, contenedores,
componentes y código — un conjunto de diagramas jerárquicos que puede utilizar para describir la
arquitectura de su software en diferentes niveles de zoom, cada uno útil para diferentes audiencias.
Piensa en ello como Google Maps para tu código.

Para crear estos mapas de su código, primero necesita un conjunto común de abstracciones para crear
un lenguaje ubicuo que describa la estructura estática de un sistema de software. El modelo C4
considera las estructuras estáticas de un sistema de software en términos de contenedores
(aplicaciones, almacenes de datos, microservicios, etc.), componentes y código. También considera a
las personas que utilizan los sistemas de software que construimos.
NIVEL 1: EL DIAGRAMA DE CONTEXTO DEL SISTEMA
El Nivel 1, un diagrama de contexto del sistema, muestra el sistema de software que está construyendo
y cómo encaja en el mundo en términos de las personas que lo utilizan y los otros sistemas de software
con los que interactúa. Aquí hay un ejemplo de un diagrama de contexto que describe un sistema de
banca por Internet que usted puede estar construyendo:

Sus clientes bancarios utilizan el sistema de banca por Internet para visualizar información sobre sus
cuentas bancarias y realizar pagos. El sistema de banca por Internet utiliza el sistema del banco en el
mainframe existente del banco para hacer esto y utiliza el sistema de correo electrónico existente del
banco para enviar correo electrónico a los clientes. El código de color en el diagrama indica los
sistemas de software que ya existen (las cajas grises) y los que se van a construir (azules).
NIVEL 2: EL DIAGRAMA DEL CONTENEDOR
El nivel 2, un diagrama de contenedor, amplía el sistema de software y muestra los contenedores
(aplicaciones, almacenamiento de datos, microservicios, etc.) que componen este sistema de software.
Las decisiones tecnológicas son también una parte fundamental de este diagrama. El siguiente es un
ejemplo de un diagrama de contenedor para el sistema de banca por Internet. Esto muestra que el
sistema de banca por Internet (el cuadro punteado) consta de cinco contenedores: una aplicación web
del lado del servidor, una aplicación de una sola página del lado del cliente, una aplicación móvil, una
aplicación API del lado del servidor y una base de datos.

La Aplicación Web es un sistema Java/Spring MVC que simplemente muestra contenido estático
(HTML, CSS y JavaScript), incluyendo el contenido que constituye la aplicación de una sola página. La
aplicación de una sola página es una aplicación Angular que se ejecuta en el navegador web del cliente,
proporcionando todas las características de la banca por Internet. Alternativamente, los clientes
pueden utilizar una aplicación móvil integrada en Xamarin, plataforma cruzada, para acceder a un
subconjunto de funcionalidades de banca por Internet. La aplicación de una sola página y la aplicación
móvil utilizan una API JSON/HTTTPS, que proporciona otra aplicación Java/Spring MVC que se ejecuta
en el lado del servidor. La aplicación en la API obtiene información de usuario de la base de datos (un
esquema de base de datos relacional). La aplicación de la API también se comunica con el sistema
bancario en el mainframe existente, utilizando una interfaz XML/HTTTPS propietaria, para obtener
información sobre cuentas bancarias o realizar transacciones. La aplicación de la API también utiliza el
sistema de correo electrónico existente si necesita enviar correo electrónico a los clientes.
NIVEL 3: EL DIAGRAMA DE COMPONENTES
El nivel 3, un diagrama de componentes, expande un contenedor individual para mostrar los
componentes que contiene. Estos componentes deben asignarse a abstracciones reales (por ejemplo,
una agrupación de códigos) en función de su código. A continuación se muestra un ejemplo de un
diagrama de componentes para el sistema ficticio de banca por Internet que muestra algunos (en lugar
de todos) de los componentes de la aplicación API.

Dos controladores MVC Spring en Rest proporcionan puntos de acceso a la API de JSON/HTTTPS, y cada
controlador utiliza posteriormente otros componentes para acceder a los datos de la base de datos y
del sistema bancario en el mainframe.
NIVEL 4: EL CÓDIGO
Por último, si realmente lo desea o necesita, puede ampliar un componente individual para mostrar
cómo se implementa este componente. Este es un diagrama de ejemplo (y parcial) de clases UML para
el sistema ficticio de banca por Internet que muestra los elementos de código (interfaces y clases) que
componen el componente MainframeBankingSystemFacade.

Este diagrama muestra que el componente consta de varias clases y que los detalles de
implementación reflejan directamente el indicador. No recomendaría necesariamente la creación de
diagramas a este nivel de detalle, especialmente cuando se pueden obtener bajo demanda de la
mayoría de los IDEs.
UNA ANOTACIÓN
El modelo C4 no prescribe ninguna notación específica, y lo que usted ve en estos diagramas
presentados es una notación simple que funciona bien en pizarras, papeles, notas adhesivas, fichas y
una variedad de herramientas de diseño. También puede utilizar UML como notación, con el uso
apropiado de paquetes, componentes y estereotipos.

Independientemente de la notación que utilice, le recomiendo que cada elemento incluya un nombre,
el tipo de elemento (es decir, “Persona”, “Sistema de software”, “Contenedor” o “Componente”), una
opción tecnológica (si procede) y algún texto descriptivo. Puede parecer inusual incluir tanto texto en
un diagrama, pero este texto adicional elimina gran parte de la ambigüedad que se ve típicamente en
los diagramas de arquitectura de software.

Asegúrese de tener una clave o leyenda para describir cualquier anotación que esté usando, incluso si
es obvio para usted. Esto debe cubrir colores, formas, acrónimos, estilos de líneas, bordes, escalado,
etc. Lo ideal es que su anotación sea coherente en todos los niveles de detalle. A continuación,
presento la clave/leyenda del diagrama para el diagrama del contenedor que se muestra arriba.

El modelo C4 es una forma sencilla de comunicar la arquitectura del software en diferentes niveles de
abstracción, de modo que se pueden contar diferentes historias a diferentes audiencias. También es
una manera de introducir (a menudo reintroducir) algo de rigor y modelado ligero para los equipos de
desarrollo de software. Visite c4model.com para obtener más información sobre el modelo C4, así
como diagramas suplementarios (tiempo de ejecución e implementación), ejemplos, una lista de
verificación de notación, preguntas frecuentes, vídeos de conferencias y opciones de herramientas.

DIAGRAMA DE COMPONENTES
Mientras que otros diagramas UML describen la funcionalidad de un sistema, los diagramas de
componentes se utilizan para modelar los componentes que ayudan a hacer esas funcionalidades,
representando la forma en la que estos se organizan y sus dependencias.

En esta entrada dedicada al diagramas de componentes veremos qué es un diagrama de

componentes, los símbolos de este diagrama y cómo dibujar uno de forma muy sencilla. Al final del
artículo podrás encontrar unos cuantos diagramas para ilustrar a modo de ejemplo toda la teoría.

Qué es un diagrama de componentes

El diagrama de componentes es uno de los principales diagramas UML. Está clasificado como
diagrama de estructura y, como tal, representa de forma estática el sistema de información.
Habitualmente se utiliza después de haber creado el diagrama de clases, pues necesita información
de este diagrama como pueden ser las propias clases.

Este diagrama proporciona una vista de alto nivel de los componentes dentro de un sistema. Los
componentes pueden ser un componente de software, como una base de datos o una interfaz de
usuario; o un componente de hardware como un circuito, microchip o dispositivo; o una unidad de
negocio como un proveedor, nómina o envío.

Algunos usos de este tipo de diagrama es el siguiente:

 Se utilizan en desarrollo basado en componentes para describir sistemas con arquitectura

orientada a servicios.
 Mostrar la estructura del propio código.
 Se puede utilizar para centrarse en la relación entre los componentes mientras se ocultan los
detalles de las especificaciones.
  Ayudar a comunicar y explicar las funciones del sistema que se está construyendo a los
interesados o stakeholders.

Para su construcción se debe plantear en primer lugar identificar los componentes que utilizará el
sistema de información, así como las distintas interfaces. Una forma típica y común para una primera
aproximación en sistemas sencillos es utilizar un componente central al que los demás componentes
se unen, y que se utiliza como componente gestor del sistema.

Primera aproximación al diagrama de componentes

 Elementos del diagrama de componentes

El diagrama de componentes está formado por tres elementos: Componente, Interfaz y Relación de

dependencia.

Componente

Un componente es un bloque de unidades lógicas del sistema, una abstracción ligeramente más alta
que las clases. Se representa como un rectángulo con un rectángulo más pequeño en la esquina
superior derecha con pestañas o la palabra escrita encima del nombre del componente para ayudar a
distinguirlo de una clase.

Un componente puede representar dos tipos de elementos: componentes lógicos (como por ejemplo
componentes de negocio o proceso) o componentes físicos (como componentes .NET, EJB…). Por
ejemplo, en una aplicación desarrollada en java habrá, con total seguridad, varios componentes
“.java”, que son componentes lógicos del sistema.

Es representado a través de un rectángulo que tiene, a su vez, dos rectángulos a la izquierda, tal y
como se muestra en la siguiente imagen:

Notación de componente

Otra notación, utilizada en las últimas versiones de UML consiste en un rectángulo con un rectángulo
más pequeño en la esquina superior derecha con pestañas.

Otra notación de componente

También es posible utilizar el diagrama de paquetes para hacer un conjunto de varios módulos. Con
esto se consigue representar la unión de esos módulos para un fin concreto.

Paquete con varios componentes

Ejemplos de componentes podrían ser los siguientes: Gestión de E/S, Animal, Persona, Gestión de
incidencias, Gestor de workflow,… Como ves son conceptos muy amplios y que pueden ser más o
menos específicos dependiendo de la profundidad que se puede dar al diagrama.
 Ejemplos de componentes

Lo ideal es que los componentes estén diseñados de forma que tengan una gran cohesión y un bajo
acoplamiento, para favorecer su reutilización.

Interfaz

La interfaz está siempre asociada a un componente y se utiliza para representar la zona del módulo
que es utilizada para la comunicación con otro de los componentes.

Se representa con una línea que tiene al final un circulo no relleno:

Notación de una interfaz

Otros módulos pueden conectarse a una interfaz. Esto se hace cuando un componente requiere o
utiliza al otro componente mediante su interfaz, que son las operaciones externas que ofrece el
componente. Se representa con un linea que termina en un semicírculo que rodea la interfaz del otro
componente. En el diagrama se vería de la siguiente manera:

Utilización de interfaz
Relación de dependencia

Aunque puedes mostrar más detalles sobre la relación entre dos componentes utilizando la notación
de interfaces (interfaz proporcionada y la interfaz requerida), también puedes usar una flecha de
dependencia para mostrar la relación entre dos componentes. Es una relación más general.

La relación de dependencia representa que un componente requiere de otro para ejecutar su trabajo.
Es diferente a la interfaz, pues esta identifica que un componente ofrece una serie de operaciones. En
cualquier caso, en ocasiones para simplificar el diagrama no se usan las interfaces sino que solamente
se utilizan relaciones de dependencia.

Una relación de dependencia se representa mediante una flecha discontinua que va desde el
componente que requiere de otro componente hasta el requerido.

Notación de una relación de dependencia

Las relaciones de dependencia pueden unir, además de componentes con otros componentes,
componentes con interfaces.

Cómo dibujar un diagrama de componentes

Puedes utilizar un diagrama de componentes cuando quieras representar tu sistema como una
colección de componentes e interfaces. Esto te ayudará a tener una idea de la futura implementación
del sistema. Los siguientes son los pasos que pueden servir de guía al dibujar un diagrama de
componentes.
  Paso 1: Determina el propósito del diagrama e identifica los artefactos como los archivos,
documentos, etc. en tu sistema o aplicación que necesitas representar en su diagrama.
 Paso 2: A medida que descubres las relaciones entre los elementos que identificaste
anteriormente, crea un diseño mental de tu diagrama de componentes.
 Paso 3: Al dibujar el diagrama, agrega primero los componentes, agrupándolos dentro de
otros componentes como mejor te parezca.
 Paso 4: El siguiente paso es agregar otros elementos, como interfaces, clases, objetos,
dependencias, etc. al diagrama de componentes y completarlo.
 Paso 5: Puede adjuntar notas en diferentes partes de su diagrama de componentes para
aclarar ciertos detalles a otros usuarios.

Diagramas de componentes, ejemplos

Estos son algunos ejemplos del diagrama de componentes, cada uno ha sido dibujado a distinto nivel
de abstracción.
Diagrama de componentes de una clínica veterinaria.

En este caso se han utilizado paquetes para dar una visión de alto nivel del sistema.

Diagrama de componentes clínica veterinaria

Diagrama de componentes de una tienda online

Diagrama de componentes tienda online

Diagrama de componentes de un cajero

Diagrama de componentes cajero

Diagrama de componentes de gestión de biblioteca
 DIAGRAMA ORGANIZADO EN CAPAZ
Arquitectura de Software

Una arquitectura de software es una descripción de los subsistemas y componentes de un sistema de software
y las relaciones entre ellos. Subsistemas y componentes se especifican normalmente en diferentes vistas para
mostrar las propiedades funcionales y no funcionales relevantes de un sistema de software. La arquitectura de
software de un sistema es un artefacto. Es el resultado de la actividad de diseño de software.

Componente

Un componente es una parte encapsulada de un sistema de software. Un componente tiene una interfaz. Los
componentes sirven como bloques de construcción para la estructura de un sistema. A nivel de lenguaje de
programación, los componentes pueden ser representados en forma de módulos, clases, objetos o un conjunto
de funciones relacionadas.

Vista

Una vista representa un aspecto parcial de una arquitectura de software que muestra propiedades específicas
de un sistema de software.

Mantenibilidad

Esta se ocupa principalmente de la fijación de un problema, "reparar" un sistema de software después de que
ocurran errores. Una arquitectura de software que está bien preparado para el mantenimiento tiende a
localizar cambios y minimizar sus efectos secundarios en otros componentes.

Extensibilidad

Este se centra en la extensión de un sistema de software con nuevas características, así como la sustitución de
los componentes con las versiones mejoradas y la eliminación de las características y componentes no
deseados o innecesarios. Para lograr extensibilidad un sistema de software requiere componentes débilmente
acoplados.

Se trata de una estructura que le permite intercambiar componentes sin afectar a sus clientes. El apoyo a la
integración de nuevos componentes en una arquitectura existente también es necesario.

¿Qué es un Patrón?

Un patrón es una regla de tres partes, que expresa una relación entre un cierto contexto, un problema, y una
solución.

Un patrón aborda un problema de diseño recurrente que surge en situaciones específicas de diseño, y presenta
una solución a ella.

Los patrones identifican y especifican abstracciones que están por encima del nivel de las clases individuales e instancias, o de
los componentes. Por lo general, un patrón describe varios componentes, clases u objetos, y detalles de sus responsabilidades y
relaciones, así como su cooperación. Los patrones son una forma de documentar arquitecturas software. Los patrones
proporcionan un esqueleto del comportamiento funcional y por lo tanto ayudan a implementar la funcionalidad de la aplicación.
Un patrón arquitectónico expresa un esquema de organización estructural fundamental de los sistemas de
software. Proporciona un conjunto de

subsistemas predefinidos, especifica sus responsabilidades, e incluye reglas y directrices para la organización
de las relaciones entre ellos.

Un patrón de diseño proporciona un esquema para refinar los subsistemas o componentes de un sistema de
software, o las relaciones entre ellos. En él se describe una estructura común recurrente de comunicar
componentes que resuelve un problema de diseño general en un contexto particular.

Patrón Capas

El patrón arquitectónico Capas ayuda a estructurar las aplicaciones que se pueden descomponer en grupos de
subtareas en la que cada grupo de subtareas está en un nivel particular de abstracción.

Contexto: Un sistema de gran tamaño que requiere la descomposición.

Problema: Imagínese que usted está diseñando un sistema cuya característica predominante es una mezcla de
temas de alto y bajo nivel, donde las

operaciones de alto nivel se basan en los niveles inferiores.

Tales sistemas a menudo también requieren alguna estructuración horizontal que es ortogonal a su subdivisión
vertical. Este es el caso en el que varias operaciones están en el mismo nivel de abstracción, pero son en gran
parte independientes entre sí.

En tal caso, es necesario equilibrar las fuerzas siguientes:

Cambios tardes en el código fuente no debe enredar a través del sistema. Ellos deben limitarse a un
componente y no afectar a los demás.

Las partes del sistema deben ser intercambiables. Los componentes deben ser capaces de ser reemplazado por
implementaciones alternativas sin afectar al resto del sistema. Diseño para el cambio, en general, es un
importante facilitador de la evolución normal del sistema.

Solución: Desde el punto de vista de alto nivel de la solución es muy simple. Estructura tu sistema en un
número apropiado de capas y colocarlas una encima de otra. Comience en el nivel más bajo de abstracción,
llámalo capa 1. Esta es la base de tu sistema. Trabaja la abstracción poniendo la capa J en la parte superior de
la capa de J-1 hasta llegar al nivel superior de la funcionalidad, llámalo capa N.

La principal característica estructural del patrón de capas es que los servicios de la capa J sólo son utilizados
por la capa J+1, no hay más

dependencias directas entre capas. La responsabilidad de la capa J es proveer servicios usados por la capa J+1 y
delegar sub tareas a la capa J-1.
 Figura 1: Patrón Capas.

Patrón N-Capas con Orientación al Dominio

Este patrón es una extensión al patrón Capas tradicional explicado en el punto anterior. En el nivel más alto y
abstracto, la vista de arquitectura lógica de un sistema puede considerarse como un conjunto de servicios
relacionados agrupados en diversas capas, similar a la figura 2.

Figura 2: Arquitectura N-Capas orientada al Dominio.

En Arquitecturas “Orientadas al Dominio” es crucial la clara delimitación y separación de la capa del Dominio
del resto de capas. Es realmente un pre-requisito para DDD (Domain Driven Design). “Todo debe girar
alrededor del Dominio”.

En las aplicaciones complejas, el comportamiento de las reglas de negocio (lógica del Dominio) está sujeto a
muchos cambios y es muy importante poder modificar, construir y realizar pruebas sobre dichas capas de
lógica del dominio de una forma fácil e independiente. Debido a esto, un objetivo importante es tener el
mínimo acoplamiento entre el Modelo del Dominio (lógica y reglas de negocio) y el resto de capas del sistema
(capas de presentación, capas de infraestructura, persistencia de datos, etc.). Así pues, las razones por las que
es importante hacer uso de una “Arquitectura N-Capas Orientada al Dominio” es especialmente en los casos
donde el comportamiento del negocio a automatizar (lógica del dominio) está sujeto a muchos cambios y
evoluciones .

En concreto, las capas y sub-capas propuestas para aplicaciones “N-Capas con Orientación al Dominio” son:

a. Capa de Presentación
Esta capa es responsable de mostrar información al usuario e interpretar sus acciones.

b. Capa de Servicios Distribuidos

Cuando una aplicación actúa como proveedor de servicios para otras aplicaciones remotas, o incluso si la
capa de presentación esta

también localizada físicamente en localizaciones remotas, normalmente se publica la lógica de negocio

(capas de negocio internas) mediante una capa de
 servicios. Esta capa de servicios (habitualmente Servicios Web) proporciona un medio de acceso remoto
basado en canales de comunicación y mensajes de datos.

c. Capa de Aplicación

Define los trabajos que la aplicación como tal debe de realizar y redirige a los objetos del dominio y de
infraestructura (persistencia, etc.) que son los que internamente deben resolver los problemas. Sirve
principalmente para coordinar la lógica del flujo del caso de uso. También permite implementar
conversores de formatos o adaptadores.

d. Capa del Dominio

Esta capa es responsable de representar conceptos de negocio e implementación de las reglas del dominio.
Esta capa, Dominio, es el corazón del software. Así pues, estos componentes implementan la funcionalidad
principal del sistema y encapsulan toda la lógica de negocio relevante (genéricamente llamado lógica del
Dominio según nomenclatura DDD).

e. Capa de Persistencia de Datos

Esta capa proporciona la capacidad de persistir datos así como lógicamente acceder a ellos. Pueden ser
datos propios del sistema o incluso acceder a datos expuestos por sistemas externos (Servicios Web
externos, etc.). Así pues, esta capa de persistencia de datos expone el acceso a datos a las capas
superiores. Esta exposición deberá realizarse de una forma desacoplada (esto se puede lograr aplicando el
patrón fábrica abstracta).

Patrón Fábrica Abstracta

En términos simples, una fábrica abstracta es una clase que proporciona una interfaz para producir una familia
de objetos [3]. El diseño general del patrón se muestra en la figura 3.

Figura 3: Patrón Fábrica Abstracta.

Las clases que participan en este patrón son:

 Fabrica Abstracta (de la figura 3: AbstractFactory): declara una interfaz para operaciones que crean
objetos productos abstractos.
 Fabrica Concreta (de la figura 3:

ConcreteFactory1, ConcreteFactory2): implementa las operaciones para crear objetos productos

concretos.

 Producto Abstracto (de la figura 3: AbstractProductA, AbstractProductB): declara una interfaz para un tipo
de objeto producto.

 Producto Concreto (de la figura 3:

ProductA1, ProductA2, ProductB1, ProductB2): define un objeto producto para que sea creado por la
fábrica correspondiente; implementa la interfaz producto abstracto.

 Cliente (de la figura 3: Client): sólo usa interfaces declaradas por las clases Fabrica Abstracta y Producto
Abstracto.

Úsese el patrón principalmente cuando:

 Un sistema debe ser independiente de cómo se crean, componen y representan sus productos.

 Quiere proporcionar una familia de clases de productos, y sólo quiere revelar sus interfaces, no sus
implementaciones.

MODELO DE DISEÑO

El modelo de diseño que se presenta en esta sección permite demostrar la aplicación del patrón de
arquitectura N-Capas con Orientación al Dominio y la aplicación del patrón de diseño Fábrica Abstracta. El uso
del patrón de diseño Fábrica Abstracta va a permitir lograr el desacoplamiento entre la Capa de Aplicación y la
Capa de Persistencia de Datos.

El modelo de diseño representa la vista lógica de la arquitectura, el cual permite mostrar las capas, subcapas y
clases que participan en la realización de un caso de uso significativo o de alta prioridad.

Para el caso de ejemplo, se diseña el caso de uso “Generar pago de trabajador”. El propósito del caso de uso es
calcular y registrar el pago a un trabajador que se ha contratado por un periodo de tiempo para realizar un
conjunto de tareas. El pago dependerá de cuantas tareas haya realizado según lo programado y en cuantas
horas. La hora de trabajo programada y la hora de trabajo extra tiene fijado un valor en su contrato.

A continuación se explica el diseño del caso de uso.

Diseño de la Arquitectura

A continuación se muestra un diagrama de paquetes de UML que representa la Arquitectura N-Capas. Cada
capa contiene subcapas y cada subcapa contiene las clases de diseño necesarias para la realización del caso de
uso. La figura 4 muestra la estructura general de la arquitectura con capas y subcapas.
Figura 4: Arquitectura N-Capas orientado al Dominio.

Capa de Presentación

Esta capa contiene la subcapa “formularios” en donde en encuentra la clase FormPagoContrato que representa
la interfaz gráfica de usuario que le permite al actor interactuar con la funcionalidad del sistema relacionado al
caso de uso. La figura 5 representa la capa de presentación con la subcapa y su clase.

Figura 5: Capa de Presentación.

Capa de Aplicación

Esta capa contiene la subcapa “servicios” en donde se encuentra la clase PagoContratoServicio que permite
coordinar las peticiones que vienen de la capa de presentación y delegando tareas a las capas del dominio y
persistencia. La figura 6 representa la capa de aplicación con la subcapa y su clase.

Figura 6: Capa de Aplicación.

Capa de Dominio

Esta capa contiene la subcapa “entidades” en donde se encuentran las clases que representan la información
del dominio o del negocio y que tienen la responsabilidad de manejar las reglas o lógica de negocio. También
contiene la subcapa “contratos” en donde se encuentran las interfaces que serán implementadas por las clases
de la capa de persistencia. Las interfaces definen los contratos que se deben respetar para lograr el
desacoplamiento con la capa de persistencia. La figura 7 representa la capa de dominio con las subcapas y sus
clases.
Figura 7: Capa de Dominio.

La figura 8 muestra el diagrama de clases de la subcapa “entidades” de la capa de Dominio. En esta figura se muestran sólo los
atributos de las clases y no las operaciones por motivo de mejor visualización.

Figura 8: Clases de la Subcapa Entidades.

La clase entidad que contiene operaciones más relevantes en este modelo es la clase Contrato. La figura 9
muestra la clase Contrato con todos sus atributos y operaciones.
 Figura 9: Clase Contrato.

Capa de Persistencia

Esta capa contiene la subcapa “repositorios” en donde se encuentran las clases que implementan las interfaces
de la subcapa “contratos” de la capa de Dominio. Estas clases cumplen lógica de acceso a datos, es decir
consultan o actualizan las fuentes de datos. También contiene la subcapa “fabrica” en donde se encuentran las
clases que implementan el patrón Fabrica Abstracta. La figura 10 representa la capa de persistencia con las
subcapas y sus clases.

Por otra parte, la figura 11 muestra el diagrama de clases de la subcapa “repositorios” de la capa de
Persistencia. En este diagrama de clases se muestran las relaciones de realización entre las clases repositorios y
las interfaces.

Así mismo, la figura 12 muestra el diagrama de clases de la subcapa “fabrica” de la capa de Persistencia. En
este diagrama de clases se muestra la relación de herencia entre las clases, en donde la clase
FabricaRepositorioSQL implementa los métodos abstractos de la clase abstracta FabricaRepositorio.
FabricaRepositorioSQL es la clase que crea los objetos repositorio que acceden a una base de datos SQL.

Figura 10: Capa de Persistencia.

Figura 11: Clases de la Subcapa Repositorios.

Figura 12: Clases de la Subcapa Fábrica.

VENTAJAS Y RECOMENDACIONES

Ventajas

El mantenimiento de mejoras en una solución será mucho más fácil porque las funciones están localizadas.
Además las capas deben estar débilmente acopladas entre ellas y con alta cohesión internamente, lo cual
posibilita variar de una forma sencilla diferentes implementaciones/combinaciones de capas.

Recomendaciones

Este tipo de arquitectura deberá implementarse en las aplicaciones empresariales complejas cuya lógica de
negocio cambie bastante y la aplicación vaya a sufrir cambios y mantenimientos posteriores durante una vida
de aplicación, como mínimo, relativamente larga.

Por otra parte, este tipo de arquitectura no debería implementarse en aplicaciones pequeñas que una vez
finalizadas se prevén pocos cambios, la vida de la aplicación será relativamente corta y donde prima la
velocidad en el desarrollo de la aplicación.