Está en la página 1de 52

TALLER DE INGENIERIA DE SOFTWARE I

SESION 5:

ARQUITECTURA DE SOFTWARE

Mg. Ing. WILFREDO CARRANZA


1
Preguntas iniciales

¿Qué es la arquitectura de software?

¿Por qué es importante la arquitectura de


software?

¿Qué hace un arquitecto de software?

¿Qué habilidades necesita un arquitecto de


software?

2
SESION 5: ARQUITECTURA DE SOFTWARE

5.1 ¿Qué se entiende por Arquitectura?

5.2 Estilos de arquitectura:


 Arquitectura de capas

5.3 Patrón arquitectónico


• Patrón Modelo-Vista-Controlador (MVC)

5.4 Diseño de la Arquitectura

5.5 Diseño guiado por el domino (DDD)

LECTURAS:

- Simon Bennett y Otros, Cap. 12

Mg. Ing. WILFREDO CARRANZA


3
5.1 ¿Qué se entiende por Arquitectura?
¿Cuáles son los factores que influyen en el desarrollo de una
arquitectura?
¿Qué tipo de problemas se solucionan con una arquitectura?

Conceptos:
• Característica del Proceso Unificado (RUP):
Centrado en la arquitectura.
La solución temprana de problemas durante el ciclo de desarrollo
de sistemas, se logra mitigando los riesgos al tomar decisiones en
función de la arquitectura

• El arquitecto de sistemas tiene que generar una arquitectura


explícita, considerando:
- los requisitos no funcionales (rendimiento, seguridad, tolerancia
a fallos)
- el contexto del sistema
- el uso y desarrollo futuro del sistema y sus componentes

• La arquitectura abarca el conjunto del sistema:


siendo una visión de alto nivel, muestra sus componentes
importantes y la forma cómo se interconectan.
4
… ¿Qué se entiende por Arquitectura?

La arquitectura abarca el conjunto del sistema:

• La arquitectura contempla las funciones a gran escala del sistema y


cómo estas funciones trabajan como un todo.

• El arquitecto agrupa las clases en paquetes, modela el sistema como un


conjunto de componentes que interactúan y considera las plataformas para
desplegar dichos componentes a fin de conseguir las cualidades requeridas
para el sistema.

Definiciones de algunos términos fundamentales,


según standard IEEE- 1471- 2000 (IEEE-2000):

• Sistema es un conjunto de componentes que cumplen una función o un


conjunto de funciones específicas.

• Arquitectura es la organización fundamental de un sistema incorporada


en sus componentes, en sus relaciones mutuas y en el entorno, y los
principios que guían su diseño y evolución.

5
Arquitectura .- definición UML

Arquitectura: estructura organizativa de un sistema que


incluye su descomposición en partes, conectividad,
mecanismos de interacción y principios de guía que
proporcionan información sobre el diseño del mismo.

La arquitectura es el conjunto de decisiones significativas


sobre la organización de un sistema software.

Por ejm. La decisión de construir un sistema en dos


capas, cada una de las cuales contiene un pequeño
número de subsistemas que se comunican de una forma
particular es una decisión arquitectónica.

6
Arquitectura .- definición UML

La arquitectura de un software no está relacionada sólo con


la estructura y el comportamiento, sino también con:

• el uso,
• la funcionalidad,
• el rendimiento,
• la flexibilidad,
• la reutilización,
• la facilidad de comprensión,
• las restricciones y compromisos económicos y tecnológicos y
• con la estética.

7
La arquitectura de un sistema es la
descripción de los elementos que lo forman y
de las interrelaciones entre ellos.

• Arquitectura
Forma en que algo es construido u organizado.

• Arquitectura Software
Descripción de los subsistemas y componentes de
un sistema software y de las interrelaciones entre
ellos.

8
Arquitectura del Software
Se suele expresar mediante un diagrama de
bloques que resume la estructura del sistema.

9
Otra definición
¿Qué es la arquitectura de software?

El proceso de arquitectura de software toma los


requisitos de los clientes, los analiza y produce un
diseño para obtener un software que satisfaga sus
necesidades.

Un diseño exitoso de software debe:

• Gestionar los requisitos conflictivos;

• Cumplir con los principios de diseño y las buenas


técnicas de procedimiento que han evolucionado con
el tiempo; y

• Complementar el hardware moderno, las redes y los


sistemas de administración.

10
La arquitectura de software implica:
 definir una solución estructurada que
satisfaga todos los requisitos técnicos y
operacionales y,
 optimizar los atributos comunes de calidad
como rendimiento, seguridad y capacidad de
administración.

El software moderno rara vez es independiente:

 interactuará con un origen de datos


(ejm. una BD corporativa que expone la información
con la que trabajan los usuarios del software).

 interactuará con otros servicios y funciones de


red
(ejm. para realizar autenticación, obtener y publicar
información, y ofrecer una experiencia de usuario
integrada).

11
¿Por qué es importante la arquitectura de
software?

Los requerimientos del software moderno


son cada vez más complejos puesto que los
usuarios esperan más de sus aplicaciones.

En nuestro mundo conectado, la aplicación debe


interactuar con otras aplicaciones y servicios y
ejecutarse en una serie de entornos, como la
nube, y en dispositivos portátiles.

Los diseños son de software basado en


componentes y orientado al servicio, que
utiliza:

• marcos de referencia, sistemas operativos,


• hosts en tiempo de ejecución y redes para
implementar características innovadoras.

12
El software debe cumplir varios criterios
fundamentales para tener éxito:

• Debe proporcionar seguridad de manera que la


aplicación y sus datos estén protegidos contra
ataques malintencionados y errores accidentales.

• Debe ser robusto y confiable para minimizar los


errores y los costos asociados.

• Debe ejecutarse dentro de los parámetros


requeridos para satisfacer las necesidades del
cliente, como un tiempo de respuesta máximo o
una capacidad de carga de trabajo específica.

• Debe ser sostenible para poder minimizar los costos


de administración y soporte técnico, y

• Debe ser suficientemente extensible para permitir


los cambios y actualizaciones inevitables que se
requerirán con el tiempo.

13
Todos estos factores implican algunas
desventajas,

por ejemplo:
 La implementación de los mecanismos más
seguros mediante un cifrado complejo afectará
el rendimiento.

 La implementación de opciones de
configuración y actualización de amplio rango
puede hacer que la implementación y
administración sean más complicadas.

Además, cuanto más complejo sea el diseño, más


costará implementarlo.

Una buena arquitectura tendrá como objetivo equilibrar


estos factores para producir el resultado óptimo en el
escenario específico.

14
¿Qué hace un arquitecto de software?

La arquitectura de software comienza con un


conjunto de requisitos, expresados como:

diagramas, diagramas de flujo de proceso,


modelos o listas documentadas de tareas
operacionales que el software debe realizar.
El cliente expresa requisitos menos precisos:
la apariencia o la manera en que ciertas
interfaces de usuario deben funcionar en tareas
comunes.

Los requisitos también deben incluir información sobre el


software, sistemas, hardware y redes existentes con que
va a interactuar el nuevo software; y otros factores:

el plan de implementación y mantenimiento y,


el presupuesto disponible para el proyecto.

15
¿Qué hace un arquitecto de software?

El arquitecto de software debe considerar las


necesidades del cliente, comprendidas en tres áreas
de responsabilidad en conflicto:

 los requisitos empresariales,

 los requisitos del usuario, y


Negocio
 los requisitos del sistema.

Usuario Sistema

Fig. Los requisitos en conflicto de un


cliente típico

16
… ¿Qué hace un arquitecto de software?
Considera:

 Los requisitos empresariales por lo general


definen una serie de factores, como los
procesos de negocios, los factores de
rendimiento (como seguridad, confiabilidad
y capacidad de proceso) y las restricciones
de presupuesto y costos.

 Los requisitos del usuario incluyen el


diseño de interfaz, capacidades operativas
y facilidad de uso del software.

 Los requisitos del sistema incluyen el


hardware, las redes y las capacidades y
restricciones del entorno en tiempo de
ejecución

17
… ¿Qué hace un arquitecto de software?
 Cada arquitecto de software tiene su propio enfoque para
recopilar y analizar requisitos y para definir la arquitectura.
 Preguntas que generalmente debe responder son:
 ¿cómo trabajarán los usuarios con la aplicación?;
 ¿cómo se implementará la aplicación en producción y cómo se
administrará?;
 ¿cuáles son los requisitos de atributos de calidad para la
aplicación, como seguridad, rendimiento, concurrencia,
internacionalización y configuración?;
 ¿cómo se puede diseñar la aplicación para que sea flexible y
sostenible a través del tiempo?;
 ¿cuáles son las tendencias arquitectónicas que podrían tener
impacto en la aplicación ahora o después de su
implementación?

 Un buen diseño de software no sólo satisface los


requisitos del cliente ahora, sino que continúa
haciéndolo en el futuro inmediato.

18
¿Qué habilidades necesita un arquitecto
de software?

1. Habilidades generales para producir un mejor


plan inicial y un conjunto más preciso de
requisitos, ahorrando tiempo y esfuerzo más
adelante.

Durante el análisis de requisitos y las etapas de


revisión, el arquitecto debe trabajar con el cliente,
consultar al equipo y actuar como un intermediario
para gerentes, usuarios y administradores de
sistemas.

19
¿Qué habilidades necesita un arquitecto
de software?
2. Habilidades técnicas para comprender:
• cómo los modernos sistemas de software, los marcos y
el hardware admiten los requisitos;
• cómo los factores de red y sistema operativo pueden
afectar las decisiones de diseño; y
• cómo las tendencias y los cambios tendrán un impacto
sobre el diseño.

También, definir patrones de diseño, estándares de


comunicación y mensajería, capacidades de código,
problemas de seguridad y restricciones de rendimiento.

Asimismo, requiere tener visión y capacidad para ver:


• cómo los sistemas se integrarán y pueden interoperar,
• cómo serán particionados e implementados y,
• cómo interactúan con los usuarios.

20
5.2 Estilos de Arquitectura
En arquitectura de sistemas, el término estilos arquitectónicos se utiliza
para esas formas de diseñar sistemas que se adaptan a la moda actual.
Cada estilo tiene características que lo convierten en más o menos
adecuado para ciertas aplicaciones.

 Subsistemas

Un subsistema agrupa elementos del sistema que comparten propiedades


comunes.
Un subsistema OO encapsula un conjunto coherente de responsabilidades
para garantizar que tiene integridad y que puede mantenerse.

Ventajas de la subdivisión de un SI en subsistemas :

 Genera unidades de desarrollo manejables.


 Posibilita maximizar la reutilización de componentes
 Alternativa de solución frente al problema de la complejidad
 Facilita la portabilidad
 Mejora el servicio de mantenimiento
21
….. Subsistemas
Hay 2 estilos diferentes de comunicación para que un subsistema
proporcione servicios a otros subsistemas:
 Comunicación cliente-servidor (client-server): el cliente debe conocer
la interfaz del subsistema servidor; siendo la comunicación en una sola
dirección.
El subsistema servidor no depende del subsistema cliente y no es
afectado por cambios en la interfaz del cliente.
 Comunicación igual a igual (peer-to-peer): cada uno de los subsistemas
puede solicitar servicios del otro (comunicación bidireccional) y puede ser
afectado por cambios en la interfaz del otro.

<<cliente>> <<peer>>
Subsistema A Subsistema C

<<servidor>> <<peer>>
Subsistema B Subsistema D

Estilos de comunicación
entre subsistemas
22
… Estilos de Arquitectura: capas
Subsistemas en capas
Las arquitecturas en capas están entre las estructuras de alto nivel de uso frecuente.
Cada capa puede tener uno o más subsistemas.
Las capas se diferencian entre si por los distintos niveles de abstracción o
por un enfoque distinto de su funcionalidad.

-Arquitectura en capas cerrada: una capa sólo puede utilizar los servicios de la capa
inmediata debajo de ella.
Ventajas:
. minimiza la dependencia entre las capas y
. reduce el impacto de cambio en la interfaz de cualquier capa.

Capa N
Capa N -1
Los mensajes sólo pueden enviarse
a la capa inferior adyacente

Capa 2
Capa 1
23
…. Subsistemas en capas

-Arquitectura en capas abierta: una capa puede utilizar los servicios de


cualquiera que se encuentra debajo de ella.
Ventajas:
. Genera un código más compacto, al no necesitar código extra para pasar
los mensajes a través de cada capa intermedia.
Desventajas:
. Rompe el encapsulado de las capas,
. Aumenta las dependencias entre capas y ,
. Mayores dificultades cuando hay que cambiar alguna capa.

Capa N
Capa N -1
Los mensajes pueden enviarse
a cualquier capa inferior

Capa 2
Capa 1

24
… Estilos de Arquitectura

Presentación
Presentación

Lógica de
la aplicación
Lógica de
empresa

Dominio
Base de datos

Base de datos
Arquitectura de 3 capas

Arquitectura de 4 capas

25
Modelos de Arquitectura SW: Java EE

Java Platform, Enterprise Edition o Java EE es una plataforma para desarrollar y ejecutar
software de aplicaciones en el lenguaje de programación Java. Permite utilizar arquitecturas
de N capas distribuidas y se apoya ampliamente en componentes de software modulares
ejecutándose sobre un servidor de aplicaciones.

26
Modelos de Arquitectura SW: .NET

27
5.3 Patrón arquitectónico

Un patrón arquitectónico, al igual que un estilo, impone una


transformación en el diseño de una arquitectura.
Un patrón difiere de un estilo en elementos fundamentales:

• El alcance de un patrón es menor, ya que se concentra en un


aspecto en lugar de hacerlo en toda la arquitectura
• Un patrón impone una regla sobre la arquitectura, al describir la
forma en que el software manejará algún aspecto de su
funcionalidad al nivel de la infraestructura
Ejm. la concurrencia
• Los patrones arquitectónicos tienden a abarcar aspectos
específicos del comportamiento dentro del contexto de la
arquitectura.
Ejem. cómo maneja una aplicación en tiempo real la
sincronización o las interrupciones.

28
 Modelo-Vista-Controlador (MVC)
El Patrón arquitectónico MVC es utilizado por muchos modelos interactivos,
por la capacidad de soportar requisitos de usuario que se presentan
mediante distintos estilos de interfaz y, por mejorar el mantenimiento y la
portabilidad.
La misma interfaz está dividida en 2 elementos: la presentación de salida
(vista) y el controlador de entrada (controlador)

El patrón MVC divide una aplicación en 3 tipos de componentes:


 Modelo: comprende la funcionalidad principal
 Vista: presenta la interfaz de usuario.
La vista recupera datos del modelo y actualiza sus presentaciones
cuando se han cambiado los datos en una de las otras vistas.
La vista crea su controlador asociado.
 Controlador: gestiona las actualizaciones de las vistas.

Y, posee un componente de propagación de las actualizaciones:


 Mecanismo de propagación: permite al modelo informar a cada vista que
se han cambiado los datos del modelo y, en respuesta, la vista tiene que
actualizarse.

29
Modelo-Vista-Controlador (MVC)

El mecanismo de propagación

Vista A <<propagar>> Vista B

<<propagar>>

<<acceso> <<acceso>

<<acceso> Modelo <<acceso>

<<acceso> <<acceso>
Controlador A Controlador B

Estructura general de MVC

30
Interacciones entre el Modelo, la Vista y
el Controlador (MVC)

31
5.4 Diseño arquitectural

Perspectiva del Proceso

Diseñar es el esfuerzo para definir la


arquitectura, componentes, interfaces y otras
características de un sistema o componente
[IEEE 610-1990].

El Diseño de Software es la actividad del ciclo de vida


del software en la cual se analizan los requisitos para
producir una descripción de la estructura interna del
software que sirva de base para su construcción.
La salida es un conjunto de modelos y artefactos que
registran las principales decisiones adoptadas.

32
Perspectiva del Resultado

Un Diseño es el resultado de dicho esfuerzo.


Un Diseño Software describe:
 La arquitectura del software
(cómo está descompuesto y organizado en
componentes),
 La interfaces entre dichos componentes, y
 Los componentes a un nivel de detalle que
permita su construcción.

33
El estándar ISO 12207 identifica dos tipos de Diseño Software:
Arquitectural [alto nivel]:
Describe la estructura y organización de alto nivel, es decir,
los subsistemas o componentes y sus relaciones.

Detallado:
Describe cada componente y su comportamiento específico, de
forma que puede procederse a su construcción.

34
Diseño Arquitectural
Es el primer paso en el diseño de un sistema, previo al
diseño detallado. Su resultado se conoce como arquitectura
del software.
 Representa el enlace entre la especificación de requisitos
y el diseño. Puede llevarse a cabo en paralelo con
actividades de especificación de requisitos.
 Implica un esfuerzo creativo, de forma que las actividades
a realizar pueden cambiar según la naturaleza del sistema
a desarrollar.

35
Durante el diseño arquitectural es necesario adoptar algunas
decisiones:
¿Existe una arquitectura genérica que pueda ser usada?
¿Cómo será distribuido el sistema?
¿Qué estilos arquitectónicos son apropiados?
¿Qué aproximación se utilizará para estructurar el sistema?
¿Cómo se descompondrá el sistema en módulos?
¿Qué estrategia de control se utilizará?
¿Cómo se evaluará el diseño arquitectural resultante?
¿Cómo se documentará la arquitectura?

36
En el Diseño de Software hay dos tipos de Descomposición:
1. Estructuración/Organización del sistema:
El sistema en subsistemas
2. Descomposición modular:
Subsistemas en módulos.
Diferenciación entre Subsistemas vs Módulos:

Subsistema: Un sistema en sí mismo, cuyo funcionamiento es


independiente de los servicios provistos por otros subsistemas.

Módulo: Componente de un sistema que provee servicios a otros


componentes y que no se considera un sistema separado.

37
Estrategias y Métodos para el Diseño de Software

Las estrategias generales de diseño de software más


conocidas son:

 Divide y vencerás
 Refinamiento en pasos sucesivos
 Top-down vs bottom-up
 Abstracción de datos y ocultamiento de información
 Uso de heurísticas
 Uso de patrones
 Aproximación iterativa e incremental

38
Estrategias y Métodos para el Diseño de Software

Diseño Orientado a Objetos (OO)


Obviamente el Diseño OO está relacionado con el Análisis y la
Programación OO.

• Análisis OO
Desarrollar un modelo de objetos del dominio de aplicación

• Diseño OO
Desarrollar un modelo del sistema orientado a objetos que
satisfaga los requisitos.

• Programación OO
Implementar un diseño OO usando un lenguaje de
programación OO.

39
En general, en todos los métodos de Diseño OO se
llevan a cabo las siguientes actividades:

1. Definir el contexto y modos de uso del sistema;


2. Diseñar la arquitectura del sistema;
3. Identificar los objetos principales del sistema;
4. Desarrollar los modelos de diseño;
5. Especificar las interfaces de los objetos.

40
Se necesita un sistema de mapas climáticos para generar mapas del
tiempo de una forma regular usando los datos recopilados de estaciones
meteorológicas remotas automáticas y otras fuentes como observadores,
globos y satélites.

Las estaciones meteorológicas transmiten sus datos al computador del


sistema cuando reciben una petición al respecto desde dicha máquina.

El computador del sistema valida los datos recopilados y los integra con
los datos de otras fuentes diferentes.

Los datos integrados se archivan y, usando dichos datos y una base de


datos de mapas digitalizados, se elabora un juego de mapas del tiempo
locales.

Los mapas pueden imprimirse para su distribución en una impresora de


mapas especializada o pueden mostrarse en varios formatos diferentes.
41
42
43
44
45
46
47
48
5.5 Diseño guiado por el dominio (DDD)

El diseño guiado por el dominio, en inglés: domain-driven design


(DDD), es un enfoque para el desarrollo de software con
necesidades complejas mediante una profunda conexión entre la
implementación y los conceptos del modelo y núcleo del negocio.

El DDD no es una tecnología ni una metodología, este provee una


estructura de prácticas y terminologías para tomar decisiones de
diseño que enfoquen y aceleren el manejo de dominios complejos
en los proyectos de software.

49
… Diseño guiado por el dominio (DDD)

Diseño guiado por el dominio engloba un lenguaje común, técnicas


y patrones al igual que la arquitectura.

El foco se pone en el negocio y en modelar los problemas que se


intentan resolver.
Con diseño guiado por el dominio (DDD), los desarrolladores
reciben técnicas que ayudan a minimizar la complejidad y a llevar
las colaboraciones con el resto. La idea es utilizar los requisitos y
mapear el proceso de negocio en el modelo mediante el mismo
lenguaje utilizado por el negocio mismo.

50
… Diseño guiado por el dominio (DDD)

Las premisas del DDD son las siguientes:

 Poner el foco primario del proyecto en el núcleo y la lógica del


dominio.

 Basar los diseños complejos en un modelo.

 Iniciar una creativa colaboración entre técnicos y expertos del


dominio para interactuar lo más cercano posible a los conceptos
fundamentales del problema.

El enfoque DDD fué introducido por Eric Evans en el libro “Domain-


Driven Design: Tackling Complexity in the Heart of Software“.

51
Fin de
la Sesión 5

52

También podría gustarte