Está en la página 1de 6

Solución de preguntas orientadoras

Estudiante(s):
Miller Manuel Ruales Luna

Docente:
Dra. Diana Marcela Vasquez

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD)


ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERA
MAESTRIA EN GESTIÓN DE TI
ARQUITECTURA DE TI Y DE LA SOLUCIÓN
2021
¿Qué es una familia de estilos de arquitectura?
Una familia de estilos de arquitectura se define como un sistema de patrones comunes
de una organización estructurada, estos estilos determinan las clases de arquitectura,
teniendo en cuenta los tipos de elemento de la arquitectura, su topología, patrones de
datos y control entre elementos (Rapanotti et al., 2004).
Los estilos arquitectónicos, definen importantes decisiones sobre los elementos
arquitectónicos y su relación. Estos estilos se pueden usar para restringir la arquitectura
como para coordinar a los arquitectos que interactúan en su desarrollo, son útiles
durante el análisis y diseño de un sistema, al utilizar los estilos, se puede mejorar
algunos atributos de calidad definidos para un sistema, pero disminuir otros, un ejemplo
muy claro es el uso de un estilo en capas, aumenta la flexibilidad del software pero
generalmente disminuye el rendimiento, por lo tanto, según (Science, 1999) nos dice
que es importante implementar y adecuar un estilo que se adapte con las necesidades del
sistema.

Estilos de arquitectura.
1. Abstractos de Datos y POO. Los componentes de este estilo son tomados como
objetos abstractos cuyos conectores son llamados invocaciones de métodos. Su
función es ocultar las características de los objetos y obviarlas puesto que
necesariamente se debe conocer la funciones tiene.

2. Sistemas en Capas. Se basa en escalas donde las capas superiores son servidas
por las inferiores y las inferiores proveen servicios a las superiores. Los
componentes son llamados capas y los conectores son llamados protocolos los
cuales interactúan entre las capas.

3. Arquitectura Orientada a Servicios. Este estilo se basa en la comunicación de


varios sistemas de información independientes desarrollados en diferentes
lenguajes, desplegados en diferentes servidores de aplicaciones tales como IIS,
tomcat, glassfish, JBoss, WebLogic, ejecutados en diferentes Sistemas
Operativos como lo son Windows, Mac, Linux, y con motores de base de datos
diferentes como SQL Server, MySql, Oracle, Postgress, los cuales se pueden
comunicar por la red para ofrecer sus funcionalidades por medio de publicación
de servicios.

4. Cliente – Servidor. Este estilo siempre se debe ejecutar en una máquina que
hará la tarea de cliente y por lo menos un servidor que se ejecutará en una
segunda máquina. El cliente y el servidor son procesos computacionales que se
ejecutan desde la memoria de sus respectivas máquinas, estos son procesos
independientes y pueden ser ejecutados en cualquier plataforma, haciendo uso
de sistemas de gestión cliente-servidor proporcionan una nueva capacidad para
crear elementos habilitados.

¿Cuáles son las características de un estilo de arquitectura basado en capas?


El estilo de arquitectura basado en capas proporciona una gran cantidad de beneficios
para las empresas que necesitan solución flexible y fiable para resolver problemas
complejos inmersos en cambios constantes. De acuerdo a (Villagómez Bermeo, P. E,
2012) las principales características de la arquitectura en capas son:

1. Mejoras en las posibilidades de mantenimiento. Debido a que cada capa es


independiente de la otra los cambios o actualizaciones pueden ser realizados sin
afectar la aplicación.
2. Escalabilidad. Como las capas están basadas en diferentes maquinas, el
escalamiento de la aplicación hacia afuera es razonablemente sencillo.
3. Flexibilidad. Como cada capa puede ser manejada y escalada de forma
independiente, la flexibilidad se incrementa.
4. Disponibilidad. Las aplicaciones pueden aprovechar la arquitectura modular de
los sistemas habilitados usando componentes que escalan fácilmente lo que
incrementa la disponibilidad.

¿Cuáles variantes de estilo se derivan del estilo en capas?

1. Capas estrictas. Cada capa solo puede invocar a la capa directamente debajo de


a ella.
2. Saltos de Capas. Las capas pueden invocar otras capas más profundas que las
que están directamente debajo de ellas. Esto puede incrementar el rendimiento,
pero impacta la portabilidad.
3. Capa de Caja Negra. Los límites de las capas y sus dependencias esta definidas
de forma estricta usando interfaces, lo que soporta extensiones en run-time,
intercepción y mejora la capacidad de realiza pruebas.
4. Capa de Caja Blanca. Clases que colaboran entre los límites de las capas y
están altamente acopladas.

¿Qué son las vistas y puntos de vista de arquitectura?

Vistas de arquitectura. Según (Romero Díaz, M, 2013) las vistas se refieren a un


conjunto de intereses de diferentes stakeholders del sistema, para decidir que incluir en
una vista se deben tener en cuenta el alcance de lo que se desea representar, los tipos de
elementos que hacen parte del sistema y como se pueden categorizar, a continuación, se
detalla cada una de las vistas.

1. La vista lógica. Describe el modelo de objetos del diseño cuando se usa un


método de diseño orientado a objetos.
2. La vista de procesos. Describe los aspectos de concurrencia y sincronización del
diseño.
3. La vista física. Describe el mapeo del software en el hardware y refleja los
aspectos de distribución.
4. La vista de desarrollo. Describe la organización estática del software en su
ambiente de desarrollo.
En la figura 1 se puede observar la relación de las vistas en la arquitectura.
Figura 1. Vistas de arquitectura.

Vista de
desarrollo

Vista de Vista
lógica Escenarios física

Vista de
proceso

Fuente: Este trabajo.

Punto de vista de aqruitectura. Hace referencia al conjunto de patrones, plantillas y


convenciones para construir un tipo de vista. Este define para que stakeholders va
dirigida una o varias vistas, reflejando sus preocupaciones en los puntos de vista, las
directrices, principios y modelos de plantillas para la construcción de vistas. Por lo cual
la definición de un punto de vista podría incluir una o varias vistas.

¿Cómo elaborar y documentar las vistas de arquitectura?


Para seleccionar las vistas se sigue un procedimiento basado con las estructuras que se
encuentran presentes de manera inherente en el sistema a construir, y en los intereses
primarios del personal involucrado, este proceso se describe a continuación.
1. Elaborar una lista de vistas. En este paso se elabora una tabla con la siguiente
información, en las columnas se enumera el conjunto de posibles vistas a
documentar, mientras que en las filas se enumera el personal involucrado.
Posteriormente en cada una de las celdas se especifica el grado de información
que requiere cada una de las personas involucradas en el proyecto.
2. Combinar las vistas. Puede que las vistas elegidas en el paso anterior sean
imprácticas de documentar debido al número de vistas seleccionadas, en este
paso se reduce la lista de vistas de una manera que pueda ser manejable por el
arquitecto.
3. Priorizar las vistas. En este paso, el arquitecto debe tener el conjunto mínimo
de vistas que satisfacen los intereses del personal involucrado. Después, en
conjunto con el administrador del proyecto se procede a priorizar cada una de las
vistas resultantes.

¿Cuál es la importancia y cómo se documentan las decisiones de arquitectura?


Las decisiones de arquitectura resuelven problemas particulares que se encuentran en un
proceso de creación de arquitectura (PEDRAZA, Astudillo, Hernán & Correal, 2014).
Estas implican en cierta manera adiciones, sustracciones y modificaciones a una
arquitectura, lo que transporta a un proceso de racionalización e identificación de reglas
y restricciones de diseño y los requerimientos adicionales
La racionalización hace referencia a las razones que están detrás de una decisión de
diseño de arquitectura, estas explican porque se ha hecho un cambio a una arquitectura.
Las reglas de diseño describen que está permitido realizarse cuando se esté
desarrollando el diseño. Las restricciones son las contrarias a las reglas, estas nos dicen
que no podemos realizar en un futuro, es decir prohíben ciertos comportamientos. Por
último, cuando se esté en proceso de toma de decisiones, usualmente se presentan
requerimientos adicionales que deben ser satisfechos y añadidos.

Referencias
PEDRAZA-GARCIA, Gilberto, Astudillo, Hernán and Correal, Darío. Modeling
Software Architecture Process with a Decision-Making Approach. 2014. 33rd
International Conference of the Chilean Computer Science Society (SCCC), Talca,
2014, pp. 1-6. doi: 10.1109/SCCC.2014.27.
Rapanotti, L., Hall, J. G., Jackson, M., Nuseibeh, B., Hall, W., Keynes, M., …
Nuseibeh, B. A. (2004). Architecture-driven Problem Decomposition.
Romero Díaz, M. (2013). Frameworks de arquitectura soportados bajo un enfoque
MDE-desarrollo de vistas y puntos de vista a partir de un metamodelo (Bachelor's
thesis, Bogotá-Uniandes).
Science, C. (1999). Design and Evaluation of Software Architecture
Villagómez Bermeo, P. E. (2012). Análisis de la Arquitectura de desarrollo de sistemas
N-Capas (Bachelor's thesis, Quito: Universidad Israel, 2012).

También podría gustarte