Magister en Ingeniería Informática
Arquitectura de Software ii. Conceptualizando la Arquitectura de Software Prof. Guillermo E. Badillo Astudillo Semestre I, 2014
Qué es 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
prof. G. Badillo, 2014_1
2
Modelo conceptual de la descripción de la arquitectura, ref. IEEE 1471‐2000 Architecture 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]
prof. G. Badillo, 2014_1
3
Contexto de la descripción de la arquitectura, ref: ISO/IEC/IEEE 42010
prof. G. Badillo, 2014_1
4
Modelo conceptual de la descripción de una arquitectura, ref: ISO/IEC/IEEE 42010
prof. G. Badillo, 2014_1
5
Por qué es importante la arquitectura de software
• 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.
prof. G. Badillo, 2014_1
6
Para el software, no se puede definir su arquitectura, en forma aislada del contexto más amplio del sistema
prof. G. Badillo, 2014_1
7
La arquitectura dentro del proceso de desarrollo de software
prof. G. Badillo, 2014_1
8
El procesos de Requisitos (ref. RUP de IBM)
prof. G. Badillo, 2014_1
9
El proceso de definición de la arquitectura
prof. G. Badillo, 2014_1
10
Comunicando y documentando la arquitectura de software •
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.
prof. G. Badillo, 2014_1
11
•
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 .
prof. G. Badillo, 2014_1
12
Vistas – Diagramas – Modelos (View, Diagrams – Models)
prof. G. Badillo, 2014_1
13
Algunos Frameworks de descripción de arquitectura • 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) prof. G. Badillo, 2014_1
14
ejemplos
prof. G. Badillo, 2014_1
15
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 Una visión global de la arquitectura crea como un croquis en una pizarra se crea como un producto de trabajo formal que se mantiene. y/o un documento básico (no se mantiene al día).
Producto de trabajo
Una arquitectura a prueba de concepto se crea sólo en papel (sin software ejecutable tiene que ser construido).
Una arquitectura a prueba de concepto se crea como software ejecutable.
Los puntos de vista de los requisitos, los puntos de vista de los requisitos, de las funciones, de implementación, de validación, de las funciones ,de implementación y rendimiento se rendimiento y seguridad se utilizan utilizan para documentar la para documentar la arquitectura. arquitectura. . prof. G. Badillo, 2014_1
16
Fuerzas que influyen en la labor del arquitecto
prof. G. Badillo, 2014_1
17
Un caso de estudio: “Your Tour”
prof. G. Badillo, 2014_1
18
Actividad 1: definir el contexto
prof. G. Badillo, 2014_1
19
Actividad 2: esquematizando los requisitos
prof. G. Badillo, 2014_1
20
Clasificando los requisitos funcionales y no funcionales con “FURPS+”
¿ Puede el software (por si solo) satisfacer todos estos requisitos ?
El Software no puede, por sí solo, satisfacer todas las necesidades de requisitos, especialmente las siguientes categorías:
•
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.
prof. G. Badillo, 2014_1
22
Tipos y niveles de requisitos, ref: Software Requirements Engineering: What, Why, Who, When, and How By Linda Westfall
prof. G. Badillo, 2014_1
23
Actividad 3: priorizando los requisitos
prof. G. Badillo, 2014_1
24
Los arquitectos obtienen las soluciones dirigidas por las necesidades del negocio
prof. G. Badillo, 2014_1
25
Actividad 4: defina la vista general de la arquitectura
prof. G. Badillo, 2014_1
26
Actividad 5: Describiendo los elementos funcionales
prof. G. Badillo, 2014_1
27
Describiendo los elementos funcionales
prof. G. Badillo, 2014_1
28
Describiendo los elementos funcionales
prof. G. Badillo, 2014_1
29
Asignando los requerimientos no funcionales a los componentes
prof. G. Badillo, 2014_1
30
Detallando los elementos funcionales
prof. G. Badillo, 2014_1
31
Detallando los elementos funcionales
prof. G. Badillo, 2014_1
32
Describiendo los elementos de despliegue
prof. G. Badillo, 2014_1
33
Detallando los elementos de despliegue
prof. G. Badillo, 2014_1
34
Los arquitectos refinan la solución según las tendencias tecnológicas
prof. G. Badillo, 2014_1
35
Arquitectura de referencia J2EE
prof. G. Badillo, 2014_1
36
Tecnologías específicas
prof. G. Badillo, 2014_1
37
Tecnologías específicas
prof. G. Badillo, 2014_1
38
Desde los requisitos a la solución 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 solución, antes de darse cuenta de los requisitos a través de ellos
prof. G. Badillo, 2014_1
39
Tendencias actuales en Desarrollo de Software
prof. G. Badillo, 2014_1
40
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.
http://theagileadmin.com/what‐is‐devops/
prof. G. Badillo, 2014_1
41
The Architecture Business Cycle • El barco de guerra sueco “Vasa”
prof. G. Badillo, 2014_1
42
The Architecture Business Cycle. (ABC) • •
•
•
•
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 Practice
43
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á? • 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. 2. 3.
Los Stakeholders del sistema Factores organizacionales y técnicos. La experiencia del arquitecto.
The Architecture Business Cycle
prof. G. Badillo, 2014_1
44
1.
La arquitectura está influenciada por Los stakeholders del sistema
• 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. prof. G. Badillo, 2014_1
45
La figura muestra al Arquitecto recibiendo algunas “sugerencias” de los stakeholders.
Ref: tomado del libro Software Architecture in Practice prof. G. Badillo, 2014_1
46
…cont. 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 . prof. G. Badillo, 2014_1
47
Una arquitectura responde a las necesidades de las partes interesadas
prof. G. Badillo, 2014_1
48
Ej. Clasificación de Stakeholders
prof. G. Badillo, 2014_1
49
2. La arquitectura está influenciada por el desarrollo organizacional • 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. prof. G. Badillo, 2014_1
50
• 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.
prof. G. Badillo, 2014_1
51
3.
La arquitectura está influenciada por su entorno
• 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. prof. G. Badillo, 2014_1
52
La arquitectura está influenciada por su entorno…
prof. G. Badillo, 2014_1
53
4.
La arquitectura está influenciada por la trayectoria y experiencia del arquitecto
• 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. prof. G. Badillo, 2014_1
54
Resumen de las influencias en la arquitectura
prof. G. Badillo, 2014_1
55
El proceso de desarrollo de software y el ABC • Actividades involucradas en la creación de la arquitectura de software: 1. 2. 3. 4. 5. 6. 7.
Creación del modelo de negocio para el sistema La comprensión de los requisitos La creación o la selección de la arquitectura Documentar y comunicar la arquitectura Análisis y evaluación de la arquitectura Implementar el sistema basado en la arquitectura Asegurarse de que la aplicación se ajusta a la arquitectura
prof. G. Badillo, 2014_1
56
Considere las siguientes preocupaciones de alto nivel cuando se piensa acerca de la arquitectura de software: • ¿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.
prof. G. Badillo, 2014_1
57
Considere las siguientes tendencias clave: • 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 . prof. G. Badillo, 2014_1
58
Considere los siguientes objetivos de la arquitectura • 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.
prof. G. Badillo, 2014_1
59
Todas las fuerzas que influyen en el diseño la arquitectura,
60
ref: SEI, www.sei.cmu.edu/library/abstracts/news‐at‐sei/architect20052.cfm
Vista general del método de diseño industrializado
prof. G. Badillo, 2014_1
61
Magister en Ingeniería Informática
Arquitectura de Software ii. Conceptualizando la Arquitectura de Software Prof. Guillermo E. Badillo Astudillo Semestre I, 2014
