UNIVERSIDAD DE CARTAGENA

ASIGNATURA:

TOPICOS AVANZADOS DE SOFTWARE

ACTIVIDAD: 1

PROGRAMA:
INGENIERA DE SOFTWARE
VIII SEMESTRE

INTEGRANTES:
GERVIS ANTONIO PAJARO PAJARO
JEINER LUIS MANGONES ANAYA
FIDEL HERNANDEZ ALTAMIRANDA

TUTOR:
MARTIN INDABURO

CENTRO TUTORIAL LORICA

2020
argumente las ventajas que encuentre en los principales modelos
arquitectónicos.
Utilización de los estilos arquitectónicos
 Sirven para sintetizar estructuras de soluciones.
 Pocos estilos abstractos encapsulan una enorme variedad de
configuraciones concretas.
 Definen los patrones posibles de las aplicaciones.
 Permiten evaluar arquitecturas alternativas con ventajas y desventajas
conocidas ante diferentes conjuntos de requerimientos no funcionales.
Arquitectura Centrada en Datos
Un almacén de datos se encuentra en el centro de esta arquitectura, otro
componente tiene acceso a él y cuentan con la opción de gestionar los datos de
ese almacén. El software cliente tiene acceso a un almacén central, en algunos
casos este es pasivo, el software cliente accede a los datos independientemente
de cualquier cambio hecho en los datos o las acciones de otro software cliente.
Una variación de este enfoque transforma el depósito en un pizarrón que envía
notificaciones al software cliente cuando cambian datos de interés para el cliente.
Características
Promueve la capacidad de integración, es decir, que es posible cambiar
componentes existentes y agregar nuevos componentes a la arquitectura sin
preocuparse por otros clientes, además es posible pasar datos entre clientes
empleando el mecanismo del pizarrón. Los componentes clientes ejecutan los
procesos de manera independiente.
Arquitectura de Flujo de Datos
Es una arquitectura de computadores que contrasta directamente con la
tradicional Arquitectura de von Neumann o de estructuras de control.
Características
Las arquitecturas de flujo de datos no se basan en un contador de programa (al
menos conceptualmente) en tanto en cuanto la posibilidad de ejecución de las
instrucciones solamente viene determinada por la disponibilidad de los
argumentos de entrada de las instrucciones.
Ventajas
La ejecución fuera de orden se ha convertido en el paradigma computacional por
excelencia desde los años 90. Es una forma de flujo de datos restringido. Este
paradigma introdujo la idea de ventana de ejecución, que sigue el orden
secuencial de la arquitectura de von Neumann; sin embargo, dentro de la ventana
se permite que las instrucciones sean completadas en el orden de las
dependencias de datos.
Desventajas
La complejidad lógica de mantener el rastro de las dependencias de datos de
forma dinámica restringe a los procesadores basados en ejecución fuera de orden
a un reducido número de ejecuciones (de 2 a 6) y limita el tamaño de la ventana
de ejecución de 32 a 200 instrucciones, mucho menor que las utilizadas en las
máquinas puras de flujo de datos.
Arquitectura de Llamada y retorno
Estilo clásico desde los años 1960. Descomposición jerárquica en subrutinas
(componentes) que solucionan una tarea o función definida. Los datos son
pasados como parámetros y el manejador principal proporciona un ciclo de control
sobre las subrutinas. Reflejan la estructura del lenguaje de programación. Permite
al diseñador del software construir una estructura de programa relativamente fácil
de modificar y ajustar a escala. Se basan en la bien conocida abstracción de
procedimientos/funciones/métodos.
Características
 Hilo de control simple soportado por los lenguajes de programación.
 Usa una estructura implícita de subsistemas.
 Razonamiento jerárquico, cambios en una subrutina implican cambios en
las subrutinas que hacen la invocación.
 Pretenden incrementar el desempeño distribuyendo el trabajo en múltiples
procesadores.
Ventajas
 Utilizados en grandes sistemas de software.
 La descomposición en módulos disminuye la complejidad.
 Persiguen escalabilidad y modificabilidad.
Desventajas
 Dependencia y acoplamiento entre módulos.
 La reutilización y el mantenimiento son difíciles
Arquitectura Orientada a Objetos
Los componentes de un sistema encapsulan los datos y las operaciones que se
deben realizar para manipular los datos. La comunicación y la coordinación entre
componentes se consiguen a través del paso de mensaje. La representación de
los datos y sus operaciones primitivas asociadas son encapsuladas en un tipo de
dato abstracto u objeto.
Características
 En este estilo los componentes son los objetos, o instancias de tipos de
datos abstractos.
 Estos objetos son de un tipo de componente denominado manager porque
es responsable por preservar la integridad de un recurso.
 Los objetos interactúan a través de invocaciones a procedimientos y
funciones.
Aspectos importantes
 Un objeto es responsable de preservar la integridad de su representación
(usualmente manteniendo algún invariante).
 La representación se oculta a otros objetos.
Ventajas
 Como un objeto oculta su representación a sus clientes, es posible cambiar
su implementación sin modificar los clientes: modificabilidad.
 La integración de un conjunto de rutinas de acceso con los datos que
manipulan permite a los diseñadores descomponer los problemas en
colecciones de agentes que interactúan.
Desventajas
 Para que un objeto interactúe con otro (mediante la invocación a un
procedimiento) debe conocer la identidad del otro objeto. Luego, cuando la
identidad de un objeto cambie es necesario modificar todas las
invocaciones a tal objeto.
 Se pueden presentar efectos laterales: si los objetos A y C usan al objeto B,
entonces los efectos de C en B lucen como efectos laterales no esperados
en A, y viceversa.
Arquitectura Estratificada
Se crean diferentes capas y cada una realiza operaciones que progresivamente se
aproximan más al cuadro de instrucciones de la máquina. En la capa externa, los
componentes sirven a las operaciones de interfaz de usuario. En la capa interna,
los componentes realizan operaciones de interfaz del sistema. Las capas
intermedias proporcionan servicios de utilidad y funciones de software de
aplicaciones.
Características
 Organización jerárquica, cada capa proporciona servicios a la capa superior
y actúa como cliente de la capa inferior.
 Los componentes se organizan en capas.
 Los conectores son definidos por los protocolos que determinan cómo
interactúan las capas.
 Restricciones topológicas incluyen limitar las interacciones a capas
adyacentes.
Aplicabilidad
Grandes sistemas caracterizados por una mezcla de elementos de alto y bajo
nivel, donde los elementos de alto nivel dependen de los de bajo nivel.
Componentes
 Grupos de subtareas que implementan una "máquina virtual" en alguna
capa en la jerarquía.
 Pueden implementarse como objetos o como procedimientos.
 Cada nivel tiene asociada una funcionalidad:
 Niveles bajos: funciones simples ligadas al hardware o al entorno.
 Niveles altos: funciones más abstractas.
Mecanismos de interacción entre componentes
 Llamadas a procedimientos.
 Llamadas a métodos.
Invariantes/restricciones
 Únicamente llamadas de niveles superiores e inferiores.
 Únicamente llamadas entre niveles adyacentes.
Aplicación
 Pilas de protocolos de comunicación.
 Sistemas operativos.
 Compiladores.
  Máquinas virtuales.
Ventajas
 Facilita la migración. El acoplamiento con el entorno está localizado en las
capas inferiores. Estas son las únicas a reimplementar en caso de
transporte a un entorno diferente.
 Reutilización: como cada nivel implementa unas interfaces claras y lógicas
pueden intercambiarse.
 Mantenimiento: los cambios en una capa apenas afectan a la superior e
inferior.
 Permite trabajar en varios niveles de abstracción. Para implementar los
niveles superiores no se requiere conocer el entorno subyacente, basta con
las interfaces que proporcionan los niveles inferiores.
Desventajas
 No todos los sistemas se pueden estructurar fácilmente como capas.
 Rendimiento: la comunicación a través de las diferentes capas, puede
hacer ineficiente al sistema.

DIFERENCIA ENTRE PATRONES DE DISEÑO Y PATRONES

ARQUITECTONICOS
Cuando iniciamos hablar de patrones, hay varios términos que nos alegan de su
entendimiento, por ejemplo, se habla de patrones de arquitectura de software, de
estilos de arquitecturas de software, de patrones de diseño, pero ¿Qué diferencias
hay?, ¿Puedo utilizar esos términos de forma indistinta?, ¿En qué momentos se
pueden aplicar?, me gustaría compartir pequeños matices que los hacen
diferentes.
¿Qué es un patrón?:
Es una solución general y reutilizable para un problema común de acuerdo a un
contexto dado el cual puede aplicarse a cualquier dominio del software y se hacen
presenten en determinadas fases del ciclo de vida del software: análisis/diseño,
construcción/desarrollo.
Un patrón es aplicable según el tipo de problema a resolver.
Patrones de Arquitectura de Software y Patrones de Diseño.
De acuerdo a la imagen anterior podemos identificar diferencias entre los términos
Patrón de Arquitectura de Software y Patrones de diseño, pero que hay acerca de
los estilos(style) de Arquitectura de Software, ¿Es lo mismo que un patrón de
Arquitectura de Software? ¿Existe alguna diferencia?, la respuesta directa es:
Depende a quién se lo preguntes, algunos Arquitectos mencionan que se pueden
utilizar de forma indistintas, otros, comentan que hay pequeños
matices, Wikipedia menciona que si hay pequeñas diferencias, Microsoft menciona
en un artículo del 2009 que los términos se pueden manejar como igual, también
hacen una analogía con la Arquitectura tradicional de Edificios:
Siguiendo la Arquitectura tradicional de edificios un estilo de arquitectura es un
método específico de construcción, caracterizado por las características que lo
hacen notable.
Estilos en la Arquitectura tradicional.
Además, está analogía la podemos aplicar en diferentes áreas como la Pintura, el
comportamiento humano, las naturalezas (animales, plantas), casi en cualquier
parte lo podemos identificar.
En caso del comportamiento humano podemos mencionar: “Esta persona sigue el
mismo patrón que sus padres, siempre llega tarde”, un patrón podría aplicarse a
una persona o incluso a una sociedad.
Hablando de estilos sería algo como: “Esta persona tienen su estilo propio, no usa
calcetines”, entonces podríamos concluir: “Esta persona sigue el
mismo patrón que sus padres porque siempre llega tarde, pero mantiene su
propio estilo al no usar calcetines”.
Hablando de la Arquitectura de Software podríamos concluir que el patrón es algo
que es aplicable de forma general y los estilos va a lo particular de acuerdo a su
patrón, los cuales se complementan, por ejemplo: Para resolver un problema que
requiere interacción con eventos podemos utilizar el patrón Event Drive
Architecture (EDA) bajo un estilo de Arquitectura Publish and Suscribe o el estilo
Pipe and Filter.
Tanto los estilos como los patrones pueden ser aplicables en la fase de
análisis/diseño en el ciclo de vida del software.
Patrones de Arquitectura de Software:
Son aplicables a la fase de diseño o análisis en el ciclo de vida del software y su
principal objetivo es dar solución a problemas comunes que se presentan en
Arquitectura de Software, por mencionar algunos patrones:
 Arquitectura de Capas (Layered Architecture).
 Arquitectura Orientada a Eventos (Event-Driven Architecture)
 Arquitectura de Microservicios. (Microservice Architecture)
 Arquitectura Space-Based. (Space-Based Architecture)
 Arquitectura MicroKernel. (Microkernel Architecture)
Patrones y Estilos de Arquitectura de Software
En siguientes publicaciones profundizaré en cada uno de los patrones
mencionados anteriormente.
Patrones de Diseño:
Este tipo de Patrones son aplicables para la fase de construcción o desarrollo en
el ciclo de vida del software e indica la forma de estructurar tu código, de
organización e interacción entre objetos, clases, instancias, relaciones, existen
cuatro grandes grupos:
Creacionales (Creational)
Corresponden aquellos patrones que proponen la mejor manera para
la creación de instancias como:
 Abstract Factory.
 Builder.
 Factory Method.
 Prototype.
 Singleton.
 Object-Pool.
 Model View and Controller (MVC).
Estructurales (Structural)
Se enfocan en resolver problemas de composición (agregación) de clases y
objetos.
 Adapter.
 Bridge.
 Composite.
 Decorator.
 Facade.
 Proxy.
 Flyweight.
 Module.
De Comportamiento
Ofrecen soluciones para la interacción y responsabilidad entre clases y
objetos.
 Chain of Responsability.
 Command.
  Interpreter.
 Iterator.
 Mediator.
 Memento.
 Observer.
 State.
 Strategy.
 Template Method.
 Visitor.
Conclusiones:
Ahora podemos concluir que entre los Patrones de Arquitectura de Software y los
Patrones de Diseño hay una diferencia clara, el primero se enfoca en la fase de
diseño y nos proporciona elementos para resolver problemas a nivel del diseño de
la Arquitectura de nuestro sistema y el segundo nos proporciona elementos para
resolver problemas a nivel de nuestro código, como se organizarán, se crearán y
se comportarán las clases, los objetos, las instancias en el sistema.