Prof. Guillermo E. Badillo Astudillo
Semestre I, 2014
Arquitectura de Software
ii. Conceptualizando la Arquitectura de Software
•
La Arquitectura de Software puede
ser vista como la estructura del
sistema en función de la definición
de
los
componentes
y
sus
interacciones.
•
La Arquitectura de Software puede
considerarse como un puente entre
los requisitos del sistema y la
implementación.
•
La Arquitectura es considerada
como plan de diseño del sistema,
debido a que es usada como guía
para el resto del las tareas de la
etapa de desarrollo
Modelo conceptual de la descripción de la arquitectura,
ref. IEEE 1471‐2000 3 prof. G. Badillo, 2014_1Architecture
is the
fundamental
organization
of
a
system
embodied in
its
components
,
their
relationships
to
each other, and to
the
environment
,
and the
principles
guiding
its
design
and evolution.
[IEEE 1471]
Contexto de la descripción de la arquitectura,
Modelo conceptual de la descripción de una arquitectura,
ref: ISO/IEC/IEEE 42010
5 prof. G. Badillo, 2014_1
• Los sistemas deben ser diseñados teniendo en cuenta los usuarios, el
sistemas propiamente tal (la infraestructura de TI), y los objetivos del
negocio
• Para cada una de estas áreas , Ud. debe esbozar los escenarios clave, e
identificar los atributos de calidad importantes ( por ejemplo , la fiabilidad o
la escalabilidad ) y las áreas claves de satisfacción e insatisfacción.
• Siempre que sea posible , desarrollar y considerar las métricas que miden el
éxito en cada una de estas áreas.
Para el software, no se puede definir su arquitectura, en
forma aislada del contexto más amplio del sistema
7 prof. G. Badillo, 2014_1
La arquitectura dentro del proceso de desarrollo
de software
El procesos de Requisitos (ref. RUP de IBM)
9 prof. G. Badillo, 2014_1
•
Un modelo
contiene los elementos que componen ese modelo. Por ejemplo, un modelo
de datos contendrá entidades y las relaciones entre ellos, un modelo de aplicación
contendrá componentes, interfaces y interacciones de los componentes, y un modelo de
infraestructura contendrá ubicaciones, los nodos, las conexiones entre los nodos, y la
colocación de los componentes en los nodos.
•
Una vista
(que puede representarse mediante varios esquemas) se refiere a todos los
elementos de modelado que necesita a fin de comunicar la arquitectura a un
determinado conjunto de actores que comparten un conjunto común de
preocupaciones. Por ejemplo, una vista de seguridad puede referirse a elementos en un
modelo de datos, modelo de aplicación y modelo de infraestructura. Estos puntos de
vista y luego forman una parte importante de cualquier "empaquetada" descripción de
la arquitectura que a continuación, se comunica a los diferentes grupos de interés.
Comunicando y documentando la arquitectura de software
11 prof. G. Badillo, 2014_1
•
la secuencia lógica de los elementos que se van a utilizar para comunicar la
arquitectura es :
1.
Identificar los grupos de interés (Stakeholders). Como se mencionó anteriormente, cuando
la documentación de una arquitectura de software , la primera cosa a entender es el
público objetivo. Los interesados se pueden organizar en grupos que comparten una serie
de preocupaciones relacionadas. Los dos grupos de partes interesadas que se muestran en
la figura son los desarrolladores y probadores .
2.
Seleccione las vistas (View). Una vez identificados los grupos de interés , entonces
necesitamos identificar los puntos de vista correspondientes que permitirán que sus
preocupaciones sean expresadas . Cada vista requiere la información en poder de
determinados productos de trabajo (como modelos) por lo que la arquitectura puede ser
comunicada a los grupos de interés identificados de forma adecuada
3.
Cree los productos de trabajo . El arquitecto (o equipo de arquitectura ) rellena los
productos de trabajo en consecuencia. Por ejemplo , podemos añadir elementos a
cualquiera de los modelos que hemos decidido crear .
4.
Empaquete la descripción de la arquitectura . En vez de comunicar la arquitectura
utilizando todos los productos de trabajo que se han creado , por lo general empaquetar
elementos en una forma que es más fácilmente consumidos por los grupos de interés ( por
ejemplo, todas las partes interesadas no pueden tener acceso a cualquier herramienta de
modelado que se utilizan para crear cierta productos de trabajo ) . El diagrama anterior
muestra el arquitecto creando una Arquitectura de Software Descripción entregable. Esta
entrega está organizada por los diferentes puntos de vista sobre la arquitectura .
Vistas – Diagramas – Modelos (View, Diagrams – Models)
13 prof. G. Badillo, 2014_1
• Arquitectura de Software
•
Modelo 4 +1 (Krutchen)
•
Rozanski and Woods [Rozanski]
•
Siemens
•
RM‐ODP
• Ingeniería de Sistemas
– Desarrollo de sistema dirigido por modelos, (Model‐Driven Systems
Development (MDSD) [MDSD]. Formerly RUP for Systems Engineering
(RUP‐SE) )
• Arquitectura Empresarial
– The Open Group Architecture Framework (ToGAF)
– The Zachman Framework [Zachman]
• De dominios específicos
– Department of Defense Architecture Framework (DoDAF)
– Ministry of Defence Architecture Framework (MoDAF)
•
ejemplos
15 prof. G. Badillo, 2014_1
Grado de participación del Arquitecto según el tamaño del
proyecto
Proyecto pequeños Proyectos grandes
Rol Se le asigna a una sola persona los diferentes roles del arquitecto: Arquitecto de Aplicación, Arquitecto de Infraestructura, Arquitecto de Datos Diferentes ingenieros son asignados a cada una de las funciones de arquitectura del arquitecto principal, Arquitecto de Aplicación, Arquitecto de Infraestructura, Arquitecto de Datos. Además, el equipo también incluye un arquitecto de seguridad. Tareas Una Introducción a la arquitectura se crea como un croquis en una pizarra y/o un documento básico (no se mantiene al día). Una visión global de la arquitectura se crea como un producto de trabajo formal que se mantiene.
Producto de trabajo Una arquitectura a prueba de concepto se crea sólo en papel (sin software ejecutable tiene que ser construido). los puntos de vista de los requisitos, de las funciones ,de implementación y rendimiento se utilizan para documentar la arquitectura. Una arquitectura a prueba de concepto se crea como software ejecutable. Los puntos de vista de los requisitos, de las funciones, de implementación, de validación, rendimiento y seguridad se utilizan para documentar la arquitectura. .
Fuerzas que influyen en la labor del arquitecto
17 prof. G. Badillo, 2014_1
Actividad 1: definir
el contexto
19 prof. G. Badillo, 2014_1
Actividad 2:
esquematizando los
Clasificando los requisitos funcionales y no funcionales con “FURPS+”
¿ Puede el software (por si
solo) satisfacer todos estos
• Confiabilidad (Reliability) : Es la medida de la habilidad de un sistema a mantenerse operativo a lo largo del tiempo (Barbacci et al., 1995).
• Desempeño, (Performance): Es el grado en el cual un sistema o componente cumple con sus funciones designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o uso de memoria. (IEEE 610.12).
Según Smith (1993), el desempeño de un sistema se refiere a aspectos temporales del comportamiento del mismo. Se refiere a capacidad de respuesta, ya sea el tiempo requerido para responder a aspectos específicos o el número de eventos procesados en un intervalo de tiempo. Según Bass et al. (1998), se refiere además a la cantidad de comunicación e interacción existente entre los componentes del sistema.
• Compatibilidad (Supportability): o la capacidad de soporte se refiere a las características inherentes de diseño e instalación que permiten el mantenimiento y el apoyo eficaz y eficiente del sistema a lo largo del ciclo de vida
• Restricciones físicas (physical constraints): Es una restricción que especifica una propiedad(es) física(s) del dominio de aplicación que no puede ser violada.
El Software no puede, por sí solo, satisfacer todas las necesidades de requisitos,
especialmente las siguientes categorías:
Tipos y niveles de requisitos,
ref: Software Requirements Engineering: What, Why, Who, When, and How By Linda Westfall
23 prof. G. Badillo, 2014_1
Actividad 3: priorizando
los requisitos
Los arquitectos obtienen las soluciones dirigidas por las necesidades del negocio
25 prof. G. Badillo, 2014_1
Actividad 5:
Describiendo los
elementos funcionales
27 prof. G. Badillo, 2014_1
Describiendo los elementos funcionales
29 prof. G. Badillo, 2014_1
Detallando los elementos funcionales
31 prof. G. Badillo, 2014_1
Describiendo los elementos de despliegue
33 prof. G. Badillo, 2014_1
Los arquitectos refinan la solución según las tendencias
tecnológicas
35 prof. G. Badillo, 2014_1
Tecnologías específicas
37 prof. G. Badillo, 2014_1
Desde los requisitos a la solución
39 prof. G. Badillo, 2014_1 Método de Diseño dirigido por Atributos (ADD) • Desarrollado por SEI. • Los atributos de calidad dirigen la Arquitectura Método de las 4 vistas de Siemens (S4V) • Desarrollado por Siemens Corporate Research • Un análisis de los factores globales que dirigen la arquitectura • Aborda de manera iterativa desafíos a través de cuatro puntos de vista (conceptual, ejecución, módulos y la arquitectura de código)The Rational Unified Process (RUP)
• Desarrollado por IBM Rational
• Los requisitos arquitectónicamente representativos dirigen la arquitectura • Cada iteración considera los elementos arquitectónicos principales de la
41 prof. G. Badillo, 2014_1
Development
and
Operations,
participación
efectiva
de
los
administradores de sistemas en el proceso de desarrollo de aplicaciones,
utilizando las mismas técnicas ágiles que usan los desarrolladores.
The Architecture Business Cycle
•
La Historia del barco de guerra Sueco “Vasa”, nos narra la experiencia vivida por el
arquitecto de ese entonces, Henrik Hybertsson, quién tenía a cargo la construcción del
Vasa.
•
Hybertsson tenía que equilibrar atributos de calidad propias de la construcción de
barcos, como el rendimiento, la funcionalidad, la seguridad, la confiabilidad, y el costo,
versus los “deseos” del rey en cuanto a tener un barco de guerra jamás visto en el
mundo, y de extender el armamento del Vasa hasta el límite.
•
Por otra parte Hybertsson tenía una gran reputación como constructor de barcos, y
precedido de una tremenda experiencia, era responsable de los grupos de interés,
como el rey, la tripulación, etc. Frente a una tarea imposible, Hybertsson tuvo la
fortuna de morir cerca de un año antes de que terminara la nave.
•
El proyecto finalizó su construcción de acuerdos a los requerimientos planteados. Y fue
botado al agua un 10 de agosto de 1628, que luego de disparar algunos de sus cañones
se hundió en su primer día en el mar.Luego de ello una serie de conjeturas fueron
hechas, desde que el Vasa había sido bien construido, pero mal proporcionado, o sea
su Arquitectura era defectuosa.
•
Hoy en día,sabemos que Hybertsson fue débil a todos los conflictos de interés que
sobre él actuaban. En particular, hizo un mal trabajo de la gestión de riesgos y un mal
trabajo de gestión de clientes. Él simplemente asintió ante las exigencias imposibles de
los stakeholders.
•
La historia del Vasa tiene mas de 385 años, y nos ilustra el ciclo de negocio de la
arquitectura : los objetivos de la organización generan requisitos, los cuales generan
una arquitectura, y la cual genera un Sistema.
• Ref: tomado del libro Software Architecture in PracticeThe Architecture Business Cycle. (ABC)
• La arquitectura de software es
el resultado de influencias
sociales, de negocio, y técnicas
que existen durante el ciclo de
vida del proyecto.
Esto es el
llamado ABC, “The
Architecture Business Cycle
.
(ref. SEI, www.sei.cmu.edu)
• La arquitectura básicamente
está influenciada por:
1.
Los Stakeholders del sistema
2.
Factores organizacionales y
técnicos.
3.
La experiencia del arquitecto.
La pregunta en cuestión es: ¿Cuál es la relación entre la
arquitectura de software de un sistema y el medio ambiente en el
cual el sistema será construido y luego existirá?
• Los stakeholders de un sistema, son todas aquellas personas
u organizaciones que están interesados en la construcción del
sistema.
• Ejemplos
son
el
cliente,
los
usuarios
finales,
los
inversionistas, los mantenedores, los desarrolladores, el jefe
del proyecto, incluso aquellos que comercializan el software,
etc.
• Cada uno de ellos tiene un interés en particular sobre el
software a construir, y cada uno de ellos podría por ej. definir
su propia funcionalidad, y sus propios atributos de calidad del
software, según sus necesidades e intereses.
1.
La arquitectura está influenciada por Los
stakeholders del sistema
45 prof. G. Badillo, 2014_1
La figura muestra al Arquitecto recibiendo algunas “sugerencias” de los
stakeholders
.
• Tener un sistema aceptable incluye características como el rendimiento,
la confiabilidad, la disponibilidad, la compatibilidad de la plataforma , el
uso de memoria , uso de la red , la seguridad , la modificabilidad , facilidad
de uso y la interoperabilidad con otros sistemas , así como su
comportamiento. (Propiedades que determinan el diseño global de la
arquitectura).
• El problema subyacente , es que cada actor tiene diferentes
preocupaciones y objetivos , algunos de los cuales pueden ser
contradictorios .
• El documento que debiera resolver estos conflictos, y ambigüedades, es
la especificación de requisito de software.
• Pero se trata de un documento de requisitos, que rara vez hace un buen
trabajo de capturar todos los requisitos de calidad de un sistema, a nivel
de detalles comprobables.
• La realidad es que el arquitecto a menudo tiene que llenar los espacios en
blanco y mediar los conflictos .
…cont. Stakeholders
47 prof. G. Badillo, 2014_1
Una arquitectura responde a las necesidades de las
partes interesadas
Ej. Clasificación de Stakeholders
49 prof. G. Badillo, 2014_1
• Además de los objetivos de la organización
expresadas a través de los requisitos, una
arquitectura está influenciada por la estructura o
naturaleza propia de la organización.
• Por ejemplo si la organización cuenta con expertos
en arquitecturas cliente‐servidor, podría ser este el
enfoque apoyado por la organización.
• las habilidades y preferencias del personal del área
de TI, también deben ser tomadas en cuenta, como
posibles influencias.
2. La arquitectura está influenciada por el
• En general hay tres influencias que provienen de la
organización:
– El negocio inmediato
– El negocio a largo plazo
– y la estructura organizacional
• Una organización:
– puede tener una inversión inmediata de negocios en
determinados activos.
– puede desear hacer una inversión de negocio a largo plazo para
perseguir los objetivos estratégicos, y el sistema que se
propone en uno de los medios de financiación y la ampliación
de esa infraestructura.
– y la estructura de la organización puede dar forma a la
arquitectura de software.
51 prof. G. Badillo, 2014_1
• Un caso especial de la trayectoria y la experiencia del
arquitecto se refleja en el entorno técnico.
• El ambiente de desarrollo y las arquitecturas
actuales influirá en esa arquitectura, cuando está
siendo diseñada.
• El arquitecto deberá incluir prácticas de la industria,
o estándares,
o técnicas de la ingeniería de
software, y
que prevalecen en la comunidad
profesional de la ingeniería de software.
3.
La arquitectura está influenciada por su
entorno
La arquitectura está influenciada por su
entorno…
53 prof. G. Badillo, 2014_1
• Si los arquitectos de un sistema han tenido buenos resultados
usando un enfoque de arquitectura en particular, lo más probable
es que van a usar ese mismo enfoque en un nuevo desarrollo. Por el
contrario, si su experiencia previa con este enfoque fue desastroso,
los arquitectos estarán reacios a probarlo de nuevo.
• En cuanto a las habilidades que caracterizan a un buen arquitecto:
– Habilidades personales
: deben tener la capacidad de negociar los
intereses personales de los stakeholders y promover la cooperación entre
ellos.
– Habilidades técnicas
: debe ser capaz de entender las corrientes
tecnológicas, la relación entre sus cualidades y la estructura, y debe
entender que la mayoría de los requerimientos para una arquitectura no
están escritos en el documento de requisitos.
– Habilidades de comunicación:
deben comunicar claramente la
arquitectura al equipo de desarrollo, tanto en forma escrita como
verbalmente. Escuchar y entender los múltiples puntos de vista.
4.
La arquitectura está influenciada por la
trayectoria y experiencia del arquitecto
Resumen de las influencias en la arquitectura
55 prof. G. Badillo, 2014_1
• Actividades involucradas en la creación de la
arquitectura de software:
1. Creación del modelo de negocio para el sistema
2. La comprensión de los requisitos
3. La creación o la selección de la arquitectura
4. Documentar y comunicar la arquitectura
5. Análisis y evaluación de la arquitectura
6. Implementar el sistema basado en la arquitectura
7. Asegurarse de que la aplicación se ajusta a la
arquitectura
El proceso de desarrollo de software y el ABC
• ¿Cómo van los usuarios a utilizar la aplicación?
• ¿Cómo la aplicación se desplegará en producción?
• ¿Cuáles son los requisitos de los atributos de calidad de la aplicación, como
por ejemplo: la seguridad, el rendimiento, la concurrencia, la configuración,
entre otras?
• ¿Cómo puede ser la aplicación diseñada para ser flexible y fácil de mantener
en el tiempo?
• ¿Cuáles son las tendencias arquitectónicas que puedan afectar a su
aplicación ahora o después que se ha implementado?
• Mantenga en mente que debe:
– Exponer la estructura del sistema, pero ocultar los detalles de implementación.
– Llevar a cabo la realización de todos los casos de uso y escenarios.
– Tratar de responder a las necesidades de los diversos grupos de interés (stakeholders).
– Manejar tantos los requisitos de funcionales como calidad.
Considere las siguientes preocupaciones de alto nivel cuando
se piensa acerca de la arquitectura de software
:
57 prof. G. Badillo, 2014_1• Empoderamiento del usuario
. Diseño flexible , configurable, y centrado en la
experiencia del usuario. Diseñe sus aplicaciones con los niveles adecuados de
personalización de usuario. Permita al usuario definir la forma en que
interactúan con su aplicación, no sobrecargue con opciones innecesarias y
ajustes que pueden llevar a confusión .
• La madurez del mercado
. Tome ventaja de la madurez del mercado mediante
el aprovechamiento de opciones de plataforma y tecnología existentes. Basarse
en los entornos de aplicaciones de más alto nivel donde tiene sentido , de modo
que usted pueda centrarse en lo que es un valor único en su aplicación en lugar
de volver a crear algo que ya existe y se puede volver a utilizar. Utilice patrones
que proporcionan una rica fuente de soluciones probadas a problemas comunes .
• Diseño flexible
. Cada vez más, los diseños flexibles aprovechan el acoplamiento
flexible para permitir la reutilización y para mejorar la mantenibilidad .También
puede tomar ventaja de las técnicas de orientación de servicio tales como SOA
para proporcionar interoperabilidad con otros sistemas.
• Las tendencias futuras
. Cuando construya su arquitectura, entienda que las
tendencias futuras pueden afectar su diseño después de la implementación
.
Considere las siguientes tendencias clave:
• La arquitectura de software busca
construir un puente entre las
necesidades de negocio y los requerimientos técnicos
mediante la
comprensión de los casos de uso, y luego encontrar la forma de
aplicarlos en el software.
• La buena arquitectura reduce los riesgos de negocio asociados a la
construcción de una solución técnica.
• Un buen diseño es suficientemente flexible, cuando es capaz de
manejar la deriva natural que se producirá con el tiempo en el
hardware y software, así como en escenarios y necesidades de los
usuarios.
• Un arquitecto debe tener en cuenta el efecto total de las decisiones de
diseño, las inherentes ventajas y desventajas entre los atributos de
calidad (como el rendimiento y la seguridad), y las compensaciones
necesarias para hacer atender las necesidades de los usuarios, el
sistema y los requerimientos del negocio.
Considere los siguientes objetivos de la arquitectura
59 prof. G. Badillo, 2014_1
Todas las fuerzas que influyen en el diseño la
arquitectura,
Vista general del método de diseño industrializado
61 prof. G. Badillo, 2014_1
