Universidad De Occidente

Ing. Dulce Fabiola Díaz Lemus

Introducción a la Ingeniería de
Software
Arquitectura de Software
Arquitectura de Software
Especificación de Requerimientos del sistema (SRS)

En este camino hay mucho por

hacer.
¿Comenzamos a programar
para terminar lo antes posible?
- ¿Cuáles serían los riesgos?

Sistema instalado y funcionando

3
Arquitectura de Software
Especificación de Requerimientos del sistema (SRS)

-Arquitectura de Software
-Diseño detallado
No es un
proceso en -Implementación
cascada. No se -Verificación
está definiendo
un proceso.

Sistema instalado y funcionando

4
Arquitectura de Software
Los sistemas complejos están compuestos de
subsistemas que interactúan bajo el control de un
diseño de sistema

Arquitectura de Software
 Los subsistemas que componen el sistema,
 las interfaces y
 las reglas de interacción entre ellos.

5
Definición
A software architecture for a system is the structure or
structures of the system, which consist of elements, their
externally visible properties, and the relationships among
them.

Documenting software architectures, views and beyond

6
Importancia
Ventajas de diseñar y documentar explícitamente
una arquitectura de software:
 Comunicación entre stakeholders

 Decisiones tempranas de diseño

 Reuso a gran escala

Bass, et al, Software Architecture in

Practice 2ed.
Addison-Wesley.
7
¿Qué Afecta y qué la Determina?
• La arquitectura de software afecta la
 Performance
 Seguridad (security y safety)
 Disponibilidad
 Mantenibilidad
 …

• Entonces, el estilo y estructura particular elegido

para una aplicación dependen fuertemente de
los requerimientos no funcionales.

8
Conflictos entre Soluciones
• El sistema debe ser “muy” performante y “muy”
mantenible

• ¿Cuál es el conflicto al momento de elegir el

estilo arquitectónico?

• ¿Cómo se puede solucionar?

 Solución de compromiso
 Diferentes estilos para distintas partes del sistema

9
¿Qué tan Fácil es Modificarla?
• Sears
EEUU
527 metros
• Petronas
Malasia
452 metros
• Taipei 101
China
508 metros

10
¿Qué tan Fácil es Modificarla?
Me gustaría que el
ascensor quedara del
otro lado

Estaría bárbaro que el

puente estuviera 23
pisos más arriba, la
vista sería mejor

11
¿Qué tan Fácil es Modificarla?
Burj Dubai, otros metros más arriba, Emiratos Árabes

12
Aún más Complicado

13
Patrones de Software
• Propósito
 Compartir una solución probada,
 ampliamente aplicable
 a un problema particular de diseño.
 El patrón se presenta en una forma estándar que
permite que sea fácilmente reutilizado.
• Cinco piezas importantes de un patrón
 Nombre
 Contexto
 Problema
 Solución
 Consecuencias (positivas y negativas)
14
Estilos, Patrones e Idioms
• Los patrones de diseño se agrupan en tres tipos
 Estilos arquitectónicos: Soluciones de organización
a nivel del sistema

 Patrones de diseño: Soluciones a problemas

detallados de diseño de software

 Idioms: Soluciones útiles para problemas específicos

en algún lenguaje de programación

15
Estilos Arquitectónicos
• Un estilo arquitectónico
 expresa un esquema de organización estructural para
sistemas de software.
 Provee un conjunto de tipos de elementos
predefinidos,
 especifica sus responsabilidades e
 incluye reglas y guías para organizar las relaciones
entre ellos Capa n

Capa n - 1

Capa 2

Capa 1
16
Patrones de Diseño
• Un patrón de diseño
 provee un esquema para refinar los elementos de un
sistema de software o las relaciones entre ellos.
 Describe una estructura recurrente de elementos de
diseño interconectados que soluciona un problema
general de diseño dentro de un contexto particular

• Mencionen algún patrón de diseño que

conozcan

17
Idioms
• Un idiom
 es un patrón de bajo nivel, específico para un
lenguaje de programación.
 Describe como implementar aspectos particulares de
elementos o de las relaciones entre ellos usando las
características de un lenguaje particular.

18
Arquitectura de Software

Estilos Arquitectónicos
Beneficios de Usar Estilos
• Permite seleccionar una solución entendible y
probada a ciertos problemas, definiendo los
principios organizativos del sistema

• Al basar la arquitectura en estilos que son

conocidos las personas entienden más
fácilmente las características importantes de la
misma

20
Formas de Uso de los Estilos
• Solución para el diseño del sistema
 Algún estilo sirve.
 Se adopta y se usa como una de las estructuras
centrales de la arquitectura.

• Base para una adaptación

 Algún estilo soluciona parcialmente los problemas.
 Se puede buscar adaptar el estilo para las
restricciones particulares que se tienen.

21
Formas de Uso de los Estilos (2)
• Inspiración para una solución relacionada
 Ningún estilo sirve.
 Sin embargo, entender problemas que solucionan
ciertos estilos puede llevar a entender mejor el
problema actual.
 Entonces, se puede encontrar una solución que de
alguna forma está relacionada con estilos existentes

• Motivación para un nuevo estilo

 El problema no es atacado por ningún estilo
encontrado
 Es una buena oportunidad para encontrar una
solución general al problema y crear un nuevo estilo
22
Algunos Estilos
• Shared Data (Datos Compartidos)
 Pizarrón (Blackboard)
• Cliente-Servidor
• Capas Jerárquicas
• Descomposición Orientada a Objetos
• Tubos y Filtros
• Control Centralizado
• Control Basado en Eventos
• Arquitecturas de Sistemas Distribuidos
 Cliente-Servidor
 Objetos Distribuidos
 Peer-To-Peer
 Service Oriented Architecture (SOA)

23
Shared-Data
• Generalidades
 Hay un almacenamiento central de datos y un
conjunto de componentes que operan sobre éste.

 Interacción - intercambio de datos persistentes

 Múltiples accesos a los datos
 Al menos un almacenamiento compartido
 Si se avisa al consumidor de nuevos datos de interés
es un Pizarrón (Blackboard)
 Si es el consumidor quien busca los datos es un
Repositorio

24
Ventajas y Desventajas
• Forma eficiente de compartir grandes cantidades de
datos.
 No se transmiten datos de un componente a otro.
• Sin embargo, los subsistemas deben estar de acuerdo
en el modelo de datos del repositorio.
• Las componentes que producen datos no necesitan
conocer como van a ser usados esos datos.
• Actividades como respaldos, seguridad, control de
acceso y recuperación están centralizadas.
• Sin embargo, diferentes componentes podría tener
distintas políticas de recuperación, respaldo, etc.

25
Pizarrón (Blackboard)
• Fuentes de Conocimiento
 Procesos independientes que corresponden a particiones del
conocimiento del mundo y del dominio dependientes de la
aplicación
 Responden a cambios en el pizarrón
• Estructura de datos del Pizarrón
 Estado completo de la solución del problema
 único medio por el cual las Fuentes de conocimiento interactúan
para llegar a la solución
• Control
 Guiado enteramente por el estado del pizarrón
 Las Fuentes de conocimiento responden oportunamente cuando
los cambios en el pizarrón aplican
 Puede implementarse en las FC, en el pizarrón, en un
componente separado o cualquier combinación de éstos.

26
Pizarrón (Blackboard)
Memoria (Compartida)
FC 2
FC 1 FC 3

FC 7 Pizarrón
FC 4

FC 5
FC 6

Cálculos
27
Cliente-Servidor
• El sistema se descompone en servicios y sus
servidores asociados y en clientes que acceden y usan
dichos servicios.
• Estilo compuesto por:
 Servidores que ofrecen servicios.
 Clientes que usan servicios ofrecidos por los servidores.
 Una red que permite que los clientes accedan a los servidores.
• Esto no es estrictamente necesario ya que clientes y servidores
pueden estar en una misma máquina.
• Los clientes conocen a los servidores pero no a otros
clientes y los servidores no tienen porqué conocer a los
clientes
• la asignación de procesos a procesadores no tiene
porqué ser 1:1
28
 Cliente-Servidor (2)

c1 c2 c3, c4
Ci = clientes CC1 CC2 CC3

Si = servidores Network
s1, s2 s3, s4 Server
computer
SC2 SC1

Client
computer
c5, c6, c7 c8, c9 c10, c11, c12
CC4 CC5 CC6

29
Capas Jerárquicas
• El sistema se organiza en capas.
• Cada una provee un conjunto de servicios a las
capas superiores y requiere servicios de las
inferiores.
Capa n

Capa n - 1

Capa 2

Capa 1
30
Capas Jerárquicas (2)
• Modelo estricto: una capa sólo utiliza servicios
de la inmediata inferior.
• Modelo relajado: se pueden “saltar” capas.
• Definición de protocolos mediante los que
interactúan las capas

31
Ventajas y Desventajas
• Ventajas
 Facilita la comprensión
 Facilita mantenimiento
 Facilita reutilización
 Facilita portabilidad
• Desventajas
 No siempre es fácil estructurar en capas ni identificar
los niveles de abstracción a partir de los
Requerimientos.
 la interpretación de comandos en múltiples niveles
puede afectar el desempeño.

32
Descomposición O.O.
• Se descompone el sistema en un conjunto de
objetos que se comunican.
• Representación de datos y operaciones
asociadas se encapsulan en un objeto.
• Herencia, polimorfismo, sobrecarga de
operadores, enlace dinámico.

33
Ventajas y Desventajas
• Ventajas
 La implementación de los objetos puede ser
cambiada sin afectar a otros objetos.
 Promueve la reutilización de componentes.
 Muchos objetos representan entidades de la realidad
por lo que es fácil entender la estructura del sistema.
• Desventajas
 Para usar servicios se debe conocer el nombre de la
interface de otro objeto.
 Los cambios en las interfaces afectan a todos los
objetos que la usan.

34