1. Arquitectura de Software
Fundamentos de Ingeniería de Software
Por: Liliana Pacheco .
Tutor: Danilo Jaramillo

2. Diseño en el contexto de la
ingeniería de software
El diseño del software siempre debe
empezar con en el análisis de los
datos, pues son los fundamentos de
todos los demás elementos del diseño.

3. Lineamientos y atributos de la
calidad del software
Características que funcionan como guía
para un buen diseño:
Debe implementar todos los requerimientos contenidos
en el modelo de requerimientos.
Debe ser una guía legible y comprensible para quienes
generan el código y para quienes lo prueban.

4. Lineamientos de Calidad
Debe tener una arquitectura que:
• Se haya creado con el empleo de estilos arquitectónicos reconocibles.
• Esté compuesta de componentes con buenas características de diseño.
• Se implementen en forma evolutiva
Debe ser modular: dividido lógicamente en elementos y
subsistemas.
Debe contener distintas representaciones de datos
arquitectura, interfaces y componentes.
Debe llevar componentes que tengan características
funcionales independientes.
Debe representarse con una notación que comunique con
eficacia su significado

5. Atributos de la Calidad
Funcionabilidad
Características y
Capacidades
Usabilidad
Factor Humano
Confiabilidad
Exactitud de los
resultados
Rendimiento
Velocidad
Mantenibilidad
Capacidad de
Ampliación

6. Conceptos de diseño
 Abstracción
Es uno de los modos fundamentales
con los que los humanos luchamos con
la complejidad.
 Arquitectura
Es el producto del trabajo de
desarrollo que tiene la rentabilidad más
alta para una inversión en cuanto a
calidad, secuencia de actividad y costo.

7.  Patrones
Describe un problema que ocurre una
y otra vez en nuestro ambiente, por lo
que describe el núcleo de la solución de
ese problema, en forma tal que puede
usarse ésta un millos de veces sin
repetir lo mismo ni una sola vez.
División de problemas
Cualquier problema complejo puede
manejarse con mas facilidad si se
subdivide

8.  Modularidad
Es la manifestación mas común de la
división de problemas, cada una de las
cuales debe ser tan independiente
como sea posible de la aplicación en sí
y de las restantes partes.
 Ocultamiento de la Información
Es esconder los detalles de las
estructuras de datos y el procesamiento
tras una interfaz de modulo.

9.  Rediseño
Proceso de cambiar un sistema de
software en forma tal que no se altera
el comportamiento externo del código
(diseño), pero si mejora la estructura
interna.

10. Definición de Arquitectura de
Software
Una arquitectura software consiste en
un conjunto de patrones y
abstracciones coherentes que
proporcionan el marco de referencia
necesario para guiar la construcción del
software para un sistema de
información.

11. Importancia de la Arquitectura
Permiten la comunicación entre las partes interesadas
en el desarrollo de un sistema basado en un sistema
de computadora.
Resalta las primeras decisiones que tendrán un efecto
profundo en todos los trabajos de IS siguiente.
Constituye un modelo relativamente pequeño y
asequible por la vía intelectual sobre como esta
estructurado el sistema y la forma en que sus
componentes trabajan juntos

12. Géneros Arquitectónicos
 Inteligencia artificial  Industrial
 Comerciales y no  Legal
lucrativos  Médicos
 Comunicaciones  Militares
 Contenido de autor  Sistemas Operativos
 Dispositivos  Plataformas
 Entretenimiento y  Científicos
deportes  Herramientas
 Financieros  Transporte
 Juegos  Utilidades
 Gobierno

13. Estilos arquitectónicos
Son una transformación que se impone
al diseño de todo el sistema. El objetivo
es establecer una estructura para todos
los componentes del sistema.

14. Taxonomía de estilos de
arquitectura
Arquitecturas:
◦ Centradas en los datos
◦ De flujo de datos
◦ De llamar y regresar
◦ En capas

15. Arquitectura centrada en
datos
Como parte central en esta arquitectura
aparece un almacén de datos es cual es
accedido frecuentemente por otros
componentes que actualizan añaden y
borran dichos componentes. El software
cliente accede a un repositorio vacío.
Las arquitecturas centradas en datos
proporcionan integridad, es decir los
componentes existentes pueden
cambiar y pueden añadirse nuevos
componentes a la arquitectura sin que
afecte a otros clientes.

16. Ejemplo

17. Arquitectura de flujo de datos
Se basa en un patrón tuberías y filtros. Este consta de
un conjunto de componentes denominados “filtros”
conectados entre si por “tuberías” que transmiten los
datos desde un componente al siguiente.
Cada filtro trabaja de manera independiente de los
componentes que se encuentren situados antes o
después de ella
obtiene como resultado datos de salida en un formato
especifico

18. Ejemplo

19. Arquitectura de llamar y regresar
Permite a los diseñadores de software
conseguir estructuras relativamente fáciles de
modificar y escalar.
Podemos encontrar diferentes estilos dentro de
este tipo:
 Programa principal/subprograma
Descompone las funciones en una jerarquía de
control donde el programa principal invoca a
programas subordinados los cual esa su vez
invocan a otros.
 Llamada a procedimiento remoto.
Los componentes de la arquitectura son
distribuidos entre diferentes ordenadores de la
red.

20. Ejemplo

21. Arquitectura Orientada a Objetos
Los componentes del sistema encapsulan
datos y operaciones que deben de
utilizarse para manipular dichos datos.

22. Arquitectura en capas
Se definen como un conjunto de niveles
o capas cada nivel interno que se
atraviesa se aproxima mas al nivel del
conjunto de instrucciones maquina.
Sistemas en capas puros. Cada capa
solo puede comunicarse con las
vecinas. Esta solución aunque menos
eficiente facilita la portabilidad en los
diseños.

23. Ejemplo

24. Diseño arquitectónico
Muchas notaciones y lenguajes existen para representar
el diseño de artefactos de software. Algunos describen un
diseño estructural organizado, otros representan el inicio
del software. Estas notaciones son generalmente usadas
durante un diseño natural y se pueden usar durante
ambos casos.
Una representan notaciones que son usadas en el
contexto de específicos métodos en las estrategias de
diseño y métodos de sub áreas, pero estas categorías
son categorizadas en notaciones para describir la
estructura estática y la dinámicas vistas.

25. Representación del sistema en el
contexto
El contexto arquitectónico representa la
manera en la que el software interactúa
con las entidades externas a sus
fronteras. (fig. 9.6)
Arquetipos
Son bloques constructivos de un diseño
arquitectónico. Sirven de base para la
clasificación y establece caridad.

26. Método de la negociación para
analizar la arquitectura
1. Escenarios de la investigación  caso de uso
2. Obtención de los requerimientos y restricciones requerimientos
3. Descripción de los estilos o patrones de arquitectura elegidos para
abordar los escenarios y requerimientos.
• Perspectiva modular
• Perspectiva de proceso
• Perspectiva de flujo
4. Evaluación de los atributos de calidad por separado.
5. Identificación de la sensibilidad de los atributos de calidad de varios
atributos arquitectónicos para un estilo de arquitectura especifico.
6. Crítica de las arquitecturas candidatas.

27. Lenguaje de descripción
arquitectónica (LDA)
Provee la semántica y
sintaxis para describir una
arquitectura de software.

28. Mapeo de la Arquitectura con el uso del flujo de
datos.
Mapeo de transformación
Paso1: Revisión del modelo del sistema fundamental.
Paso2. Revisar y mejorar los diagramas de flujos de datos para el software
Paso3. Determinar si el DFD tiene características de flujo de
transformación o de transacción.
Paso4. Aísle el centro de transformación, especificando las fronteras de
entrada y salida del flujo.
Paso5. Realizar el rediseño de primer nivel
Paso6. Realizar el rediseño de segundo nivel
Paso7. Refinar la arquitectura de primera iteración con el empleo de
heurísticos de diseño para mejorar la calidad del software.

29. Bibliografía
 http://www-oei.eui.upm.es/Asignaturas/BD/BD/docbd/tema/Arquitectura.pdf
 http://es.scribd.com/doc/11757858/Arquitecturas-Del-Desarrollo-de-Software
 http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/fuentes_k_jf/capitulo2.p
df