16
Lain Jardiel C. E. maestrodelsoftware.blogspot.com 1 Lain Jardiel Cárdenas Escalante [email protected] Fundamentos de Arquitectura

Ar Quite Ctur a Soft

Embed Size (px)

DESCRIPTION

Software

Citation preview

Page 1: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 1

Lain Jardiel Cárdenas Escalante [email protected]

Fundamentos de Arquitectura

Page 2: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 2

El sistema debe ser en sí mismo flexible a los cambios o tolerante a los cambios. El sistema debe ser capaz de evolucionar sin problemas.

Arquitectura de Software

Una arquitectura es el conjunto de decisiones significativas sobre la organización del sistema software, la selección de los elementos estructurales y sus interfaces, junto con su comportamiento, y el estilo de arquitectura que guía esta organización.

Page 3: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 3

¿Por qué necesitamos una arquitectura?

• Para comprender el sistema.

• Para organizar el desarrollo.

• Para fomentar la reutilización.

• Para hacer evolucionar el sistema.

¿Qué influye en la Arquitectura?

Page 4: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 4

Arquetipos de aplicación

• Aplicaciones de Escritorio.

• Aplicaciones Web.

• Aplicaciones de Servicios.

• Aplicaciones RIA (Rich Internet Applications).

• Aplicaciones Móviles.

Proceso centrado en la Arquitectura

La arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construcción.

La arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.

Cada producto tiene tanto una función como una forma. La función corresponde a los casos de uso y la forma a la arquitectura, debe haber interacción en ellos.

Los arquitectos deben trabajar sobre los casos de uso claves del sistema (5% a 10% de todos los casos de uso).

Page 5: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 5

Proceso centrado en la Arquitectura

Proceso centrado en la Arquitectura

• Se seleccionan y desarrollan los casos de uso arquitectónicamente significativos.

• Los casos de uso ayudan a mejorar gradualmente la arquitectura. • La arquitectura se desarrolla mediante iteraciones, hasta lograr

tener una arquitectura estable. • El resultado al final de la fase es la Línea base de la Arquitectura y

una Descripción de la Arquitectura (DAS). • Al terminar la fase, al tener una arquitectura estable, se podrá

implementar la funcionalidad completa durante la Fase de Construcción.

Page 6: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 6

Línea base de la Arquitectura

Patrones de Arquitectura

Page 7: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 7

Patrones de arquitectura

• Patrón Capas

• Patrón Broker

• Patrón Modelo-Vista-Controlador

• Patrón Cliente-Servidor

• Patrón Peer-to-Peer

• Patrón Arquitectura Orientado a Servicios (SOA)

• Patrón Multi-Nivel

El Patrón Capas

Contexto: Se quiere diseñar una aplicación empresarial compleja compuesta por un número considerable de componentes de diferentes niveles de abstracción.

Problema: ¿Cómo estructurar una aplicación para soportar requerimientos complejos operacionales y disponer de una buena mantenibilidad, reusabilidad, escalabilidad, robustez y seguridad?

Page 8: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 8

El Patrón Capas

Solución: Organizar la estructura lógica de gran escala en un sistema en capas separadas de responsabilidades distintas y relacionadas con una separación clara cohesiva de intereses como que las capas “más bajas” son servicios generales de bajo nivel, y las capas más altas son más específicas de la aplicación

El Patrón Capas

Capa N-1

Capa 2

Capa 1

Capa N

Page 9: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 9

El Patrón Capas

Capa N-1

Capa 1

Capa N Cliente Alto nivel de abstracción

Bajo nivel de abstracción

Usa

Capas y Módulos

Modulo 1 Modulo 2

Modulo 1 Modulo 2

Capa 2

Capa 1

Page 10: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 10

Beneficios del Patrón Capas

• Permite localizar los cambios

• Permite la separación de responsabilidades

• Permite la reutilización de componentes

• Equipos diferentes pueden trabajar en diferentes capas

• Los diferentes componentes pueden ser desplegados de una forma independiente

• Cada capa puede contener sus propias pruebas unitarias

Arquitectura N-Capas Orientada al Dominio

Capa de presentación

Capa de servicios distribuidos

Capa de aplicación

Capa del dominio

Capa de infraestructura de persistencia de datos

Cap

a d

e in

frae

stru

ctu

ra t

ran

sve

rsal

Servicios externos

Fuentes de datos

Dependencia directa

Dependencia indirecta

Page 11: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 11

Page 12: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 12

Patrones de Diseño

Page 13: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 13

¿Qué es un Patrón de diseño?

• Es una mejor práctica o núcleo documentado de una solución que se ha aplicado con éxito en varios entornos para resolver un problema que se repite en un conjunto específico de situaciones.

• Es una solución recurrente a un problema común en un contexto (condiciones / situaciones) dado y sistema de fuerzas (restricciones).

Patrones de diseño vs Frameworks

Patrones de diseño frameworks Los patrones de diseño son soluciones

recurrentes a los problemas que surgen

durante la vida de una aplicación de software

en un contexto particular.

Un framework es un grupo de componentes

que cooperan entre sí para proporcionar una

arquitectura reutilizable para aplicaciones con

un dominio dado.

El objetivo principal es:

Ayudar a mejorar la calidad del software

en términos de que el software sea

reutilizable, mantenible y extensible, etc.

Reducir el tiempo de desarrollo.

El objetivo principal es:

Ayudar a mejorar la calidad del software

en términos de que el software sea

reutilizable, mantenible y extensible, etc.

Reducir el tiempo de desarrollo.

Los patrones son lógicos en naturaleza. Los marcos son más de naturaleza física, tal

como existen en la forma de algún tipo de

software.

Page 14: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 14

Patrones de diseño vs Frameworks

Patrones de diseño frameworks Las descripciones de patrones son

generalmente independientes del lenguaje de

programación o los detalles de

implementación.

Debido a que existen frameworks en forma de

algún tipo de software, son específicos de la

implementación.

Los patrones son más genéricos en naturaleza

y se pueden utilizar en casi cualquier tipo de

aplicación.

Los frameworks proporcionan funcionalidad

específica del dominio.

Un patrón de diseño no existe en la forma de

un componente de software. Necesita ser

implementado explícitamente cada vez que se

utiliza.

Los frameworks no son aplicaciones completas

por sí mismos. Las solicitudes completas se

pueden construir heredando los componentes

directamente.

Los patrones proporcionan una manera de

hacer "bueno" diseño y se utilizan para ayudar

al diseño de frameworks.

Los patrones de diseño se pueden utilizar en el

diseño e implementación de un framework. En

otras palabras, los frameworks típicamente

incorporan varios patrones de diseño.

Patrones de diseño: GRASP

• General Responsibility Assignment Software Patterns (patrones generales de software para asignar responsabilidades).

• Los patrones GRASP describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones.

Page 15: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 15

GRASP

1. Experto en información (o Experto)

2. Creador

3. Bajo Acoplamiento

4. Alta Cohesión

5. Controlador

6. Polimorfismo

7. Fabricación Pura

8. Indirección

9. Variaciones Protegidas

Patrones de diseño: GoF

De creación Estructurales De comportamiento

Factory Method Abstract Factory Builder Prototype Singleton

Adapter Bridge Composite Decorator Facade Flyweight Proxy

Interpreter Template method Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

Page 16: Ar Quite Ctur a Soft

Lain Jardiel C. E.

maestrodelsoftware.blogspot.com 16