•Arquitectura de Software

•…entonces nuevamente:
•¿qué es Arquitectura de Software ?
 •DEFINICIÓN

• Una Arquitectura de Sofware de un programa o

de un sistema de cómputo es la estructura o
estructuras de un Sistema. Dicha(s) estructura(s)
comprenden:

Elementos de software,
Las propiedades visibles de dichos elementos, y
Las relaciones entre los mismos.
• Una arquitectura de software debe proporcionar cierta
información:

La naturaleza de los elementos.

Si los elementos son procesos, programas, objetos, etc.
Las funciones de los elementos.
El significado de las relaciones entre cada elemento.
El significado de la distribución de los elementos.
Por ejemplo. Elementos localizados en diferentes niveles.
•EJEMPLO. Representación de una Arquitectura de
•Software poco informativa.

•ELEMENTO 1

•ELEMENTO 2 •ELEMENTO 3 •ELEMENTO 4

 •OTRAS DEFINICIONES DE LA ARQUITECTURA
•DE SOFTWARE
•
Arquitectura es un diseño de alto nivel.

Arquitectura es la estructura general del sistema.

Arquitectura es la estructura de componentes,

relaciones, principios y pautas que definen su
diseño y evolución sobre el tiempo.

Arquitectura es componentes y conectores.

 •PATRONES DE ARQUITECTURA

• Un patrón de arquitectura es una descripción de elementos y los

tipos de relación, junto con un grupo de restricciones en cómo deben ser
usados.

Un ejemplo de este tipo, es la Arquitectura

Cliente-Servidor.
 •MODELO DE REFERENCIA

• Un modelo de referencia es una descomposición de un problema

en un cierto número de partes que cooperativamente resuelven el
mismo.

•Ejemplos
Partes de un Compilador.
Partes de un Sistema manejador de Base de
Datos.
 •ARQUITECTURA DE REFERENCIA

• Es un modelo de referencia planeado sobre elementos de

software y el flujo de datos entre ellos.

Un elemento de software puede implementar

parte de una función o de varias funciones.
•POR QUÉ ES IMPORTANTE LA ARQUITECTURA
•DE SOFTWARE ?

Comunicación entre las personas involucradas

La arquitectura representa una abstracción que puede ser base para el
entendimiento, concenso, negociación y comunicación.

Decisiones tempranas de diseño

Define limitaciones en la Implementación.
Dicta la Estructura Organizacional.
Oculta o muestra los Atributos del Sistema.
Hace más fácil controlar los cambios.
Ayuda en el prototipado evolutivo.
Proporciona Estimaciones de Costos y Calendarización más exactos.

Abstracción transferible de un sistema

La arquitectura constituye un modelo de cómo esta el sistema estructurado y

como sus elementos trabajan en conjunto; por lo que puede ser aplicada a otros
sistemas que exhiban similares requerimientos y atributos.
•La Arquitectura en el Ciclo de Vida
•Software
•Concept •Ciclo de Vida de Entregas Evolutivas

•Preliminary
Requirements
•Analysis
•Develop Final
Version
•Design of
Architecture and
System Core

•Develop a
•Version

•Incorporate •Deliver the

Customer Version
Feedback

•Ellicit Customer
Feedbak
 •
•
•
•Ciclo de la Arquitectura
•de Negocios
• . La vista arquitectural de un sistema es
abstracta, proporcionando detalles acerca de la
implementación, los algoritmos, la representación de
datos e incluso el comportamiento y la interacción entre
elementos (cajas negras - black box).
 •Architecture Business Cycle - ABC

• Los requerimientos no determinan del todo la

arquitectura, más bien está es además resultado de
influencias en los ambientes técnicos, sociales y del
negocio.

• Llamaremos a este ciclo de influencias, del

ambiente a la arquitectura y de la arquitectura al
ambiente como “El Ciclo de la Arquitectura de Negocios
(Architecture Business Cycle - ABC)”.
•¿Cómo surgen las arquitecturas?

•Influencias en la
Arquitectura
•Stakeholders
•INFLUENCIAS EN LAS ARQUITECTURAS

La composición de la organización.

La formación y la experiencia de los arquitectos.

El ambiente técnico.
•Las arquitecturas afectan a
•los factores que las influencian

•Ciclo de la Arquitectura de Negocios

•Las arquitecturas afectan a
•los factores que las influencian

La composición de la organización.
Los objetivos de la organización.
Los requerimientos del cliente.
La experiencia de los arquitectos.
Muy pocos sistemas influenciarán o cambiarán la
cultura de la ingeniería de software, el ambiente
técnico en el cual los sistemas operan y aprenden.
•El Proceso de Software y El
•Ciclo de la Arquitectura de Negocios (ABC)

Definir el caso de estudio para el sistema

Entender los requerimientos
Crear o seleccionar la arquitectura
Comunicar la arquitectura
Analizar y evaluar la arquitectura
Implementar el sistema basado en la arquitectura
Asegurar que la implementación sea conforme a la
arquitectura
•¿Qué hace buena a una arquitectura?
•Una arquitectura debería ...

ser producto de un arquitecto o un pequeño grupo de arquitectos

con un líder definido.
estar bien documentada, con al menos una vista dinámica y una
vista estática, utilizando una notación que los stakeholders puedan
entender fácilmente.
ser evaluada y analizada con métricas cuantitativas y cualitativas.
presentarse como una implementación incremental, para poder
diseñar un esqueleto del sistema, mostrando primero la mínima
funcionalidad y después como puede ir creciendo.
ser diseñada por arquitectos que cuentan con los requerimientos
funcionales y no funcionales del sistema.
 •Reglas estructurales para
•la arquitectura

La arquitectura debería tener bien definidos los módulos.

Cada módulo debería tener bien definida las interfaces que encapsula.
Estas interfaces permitirán desarrollar de manera independiente cada
módulo.
La arquitectura nunca debe de depender de una versión de un producto o
herramienta comercial.
Los módulos que producen datos deberán estar separados de los módulos
que consumen datos. Esto permitirá que cuando un dato sea añadido solo
tenga que modificarse un módulo.
Cada tarea o proceso deberá ser bien documentado, para que este pueda
ser fácilmente modificado, quizás incluso en tiempo de ejecución.
La arquitectura deberá caracterizarse como un conjunto de simples
interacciones, esto es para incrementar la confiabilidad, la manteneabilidad,
reducir el tiempo de desarrollo, etc.
 •Arquitectura 4+1 Vistas

En esta arquitectura de desarrollo de software un

producto a ser desarrollado tiene 4 puntos de vistas
dependiendo del tipo de personal involucrado en el
proyecto.

Las 4 vistas se concentran en el desarrollo de

escenarios que describen el análisis y los
requerimientos del sistema.
 •Arquitectura 4+1 Vistas

•Arquitectos •Desarrolladores

•Vista
•Vista Lógica
•de Desarrollo

•Analistas
•Escenarios •Del
•Negocio

•Vista
•Vista Física
•del Proceso

•Integradores •Ingenieros de
•Infraestructura
 •Vista Lógica

Se maneja el estilo arquitectónico de la aplicación:

Orientado a objeto
Basado en Componentes
Basado en servicios

La implementación de esta vista utiliza generalmente

patrones arquitectónicos como el MVC (Modelo-Vista-
Controlador)
 •Vista de Desarrollo

Define los módulos de software que han de

ser construidos.
Se deben definir con claridad las interfaces de
E/S de los módulos.
La modularización de componentes depende
del estilo arquitectónico seleccionado en la
vista lógica
 •Vista Física

Mapea los componentes de software con el hardware

(fase de despliegue)
Un buen diseño promueve la flexibilidad de mapear
componentes de software con diferentes confiuraciones
físicas dentro de las diferentes fases del ciclo de vida del
software.
 •Vista del Proceso

La vista de proceso está relacionada en la forma de

darle seguimiento, control y dirección a las etapas del
desarrollo del producto.
 •Escenarios

Son abstracciones de los requerimientos más

importantes.
Están estrechamente relacionados con el uso
de casos de uso
La vista del escenario es redundante entre las
otras vistas.
 Presentacion descargado de:

www.archivosuniversitarios.blogspot.com