CICLO DE DESARROLLO DE ARQUITECTURA DE SOFTWARE

1. Semestre: 2022-1
Ciclo: IV
Docente: Godofredo Ayquipa Cordova
PATRONES DE DISEÑOY
ARQUITECTURA DE SOFTWARE

2. Semana 02
Temas de la clase: Ciclo de desarrollo de arquitectura de software
• Requerimientos de la arquitectura
• Diseño de la arquitectura
• Documentación de la arquitectura
• Evaluación de la arquitectura
• Implementación de la arquitectura
IES WERNHER VON BRAUN 2

3. Objetivo de la clase
Describir y entender el ciclo de desarrollo de la arquitectura de
software
IES WERNHER VON BRAUN 3

4. IES WERNHER VON BRAUN 4
Dentro de un proyecto de desarrollo, e
independientemente de la metodología que se
utilice, se puede hablar de “desarrollo de la
arquitectura de software”. Este desarrollo, que
precede a la construcción del sistema, esta
dividido en las siguientes etapas:
requerimientos, diseño, documentación y
evaluación. Cabe señalar que las actividades
relacionadas con el desarrollo de la arquitectura
de software generalmente forman parte de las
actividades definidas dentro de las metodologías
de desarrollo.

5. IES WERNHER VON BRAUN 5

6. IES WERNHER VON BRAUN 6
La etapa de requerimientos se enfoca en la
captura, documentación y priorización de
requerimientos que influencian la
arquitectura. Como se mencionó
anteriormente, los atributos de calidad
juegan un papel preponderante dentro de
estos requerimientos, así que esta etapa
hace énfasis en ellos. Otros requerimientos,
sin embargo, son también relevantes para
la arquitectura, estos son los
requerimientos funcionales primarios y las
restricciones.

7. IES WERNHER VON BRAUN 7

8. IES WERNHER VON BRAUN 8
Recordemos un poco sobre
qué son los requerimientos.
Generalmente se considera
que los requerimientos de un
sistema se pueden dividir en
dos categorías:
Requerimientos Funcionales
(RFs) y Requerimientos No
Funcionales (RNFs).

9. IES WERNHER VON BRAUN 9
los RFs engloban los distintos tipos de
requerimientos que se reflejan en los
comportamientos de la aplicación y que incluyen:
• Requerimientos de negocio: Motivación de
negocio para que exista un sistema.
• Requerimientos de usuario: Comportamiento del
sistema, frecuentemente se expresan en forma de
casos de uso.
• Requerimientos funcionales detallados:
Complementan a los casos de uso (generalmente
se describen usando el verbo “deber”).
• Requerimientos de sistema: Describen el mínimo
hardware y software para que un sistema de
información pueda funcionar.

10. IES WERNHER VON BRAUN 10
Por otra parte, los RNFs tienen que ver con la
manera en que el sistema soporta a los RFs. Estos
incluyen:
• Reglas de negocio: expresan reglas de la
organización que deben ser soportadas por el
sistema.
• Atributos de calidad: se describen más
adelante.
• Restricciones: Expresan aspectos que deben
considerarse al realizar el diseño y limitan las
decisiones que se pueden tomar.
• Interfaces externas: Especificaciones de
interfaces de otros sistemas con los que se
interactúa.

11. IES WERNHER VON BRAUN 11

12. IES WERNHER VON BRAUN 12

13. IES WERNHER VON BRAUN 13
• La etapa de diseño es probablemente la más
compleja del ciclo de desarrollo de la arquitectura.
Durante ella se definen las estructuras de las que se
compone la arquitectura mediante la toma de
decisiones de diseño. Esta creación estructural se
hace por lo habitual con base en dos clases de
soluciones abstractas probadas, llamadas patrones
de diseño y tácticas, al igual que en soluciones
concretas como las elecciones tecnológicas, tales
como los frameworks.
• El diseño que se realiza debe buscar ante todo
satisfacer los requerimientos que influencian a la
arquitectura, y no simplemente incorporar diversas
tecnologías por que están “de moda”.

14. IES WERNHER VON BRAUN 14
1. Diseño de la arquitectura:
este nivel se enfoca en la
toma de decisiones en
relación con los drivers
(guía) de la arquitectura y la
creación de estructuras para
satisfacerlos.

15. IES WERNHER VON BRAUN 15
2. Diseño de las interfaces: este nivel ocurre
parcialmente cuando se diseña la
arquitectura, pero la mayor parte del trabajo
ocurre una vez que este proceso ha concluido.
Es en este momento en que:
a) se identifican todos los módulos y
otros elementos faltantes requeridos
para soportar la funcionalidad del
sistema, y
b) se diseñan sus interfaces, es decir, los
contratos que deben satisfacer estos
módulos y otros elementos de acuerdo
con los lineamientos que establece el
propio diseño de la arquitectura.

16. IES WERNHER VON BRAUN 16
3. Diseño detallado de los
módulos: este nivel ocurre
generalmente durante la
construcción del sistema. Una
vez que se han establecido los
módulos y sus interfaces, se
pueden diseñar los detalles de
implementación de esos
módulos previo a su
codificación y prueba.

17. IES WERNHER VON BRAUN 17
Este procedimiento consiste en elegir en cada
iteración un subconjunto de todos los drivers
(guía) de la arquitectura y tomar decisiones de
diseño al respecto, lo cual resulta en estructuras
que permiten satisfacerlos.
El diseño resultante se evalúa, se elige
enseguida otro subconjunto de los drivers, y se
procede de la misma manera hasta que se
completa el diseño. El proceso termina cuando
se considera que se han tomado suficientes
decisiones de diseño para satisfacer el conjunto
de drivers, o bien, cuando concluye el tiempo
que el arquitecto tiene asignado para realizar las
actividades de diseño.

18. IES WERNHER VON BRAUN 18

19. IES WERNHER VON BRAUN 19
Una vez que ha sido creado el diseño de la arquitectura,
es necesario darlo a conocer a otros interesados en el
sistema, como desarrolladores, responsables de
implantación, líderes de proyecto o el cliente mismo. La
comunicación exitosa depende por lo habitual de que el
diseño sea documentado de forma apropiada. A pesar de
que durante el diseño se hace una documentación inicial
que puede incluir bocetos de las estructuras, o bien
capturas de las decisiones de diseño, la documentación
formal involucra la representación sus estructuras por
medio de vistas.
Una vista representa una estructura y contiene por lo
habitual un diagrama, además de información adicional
que apoya en la comprensión de este.

20. IES WERNHER VON BRAUN 20
1. Vista lógica. Modela elementos que
soportan la funcionalidad que el sistema
provee al usuario final de un punto de
vista estático o dinámico mediante
diagramas tales como clases, paquetes y
secuencia.
2. Vista de proceso. Esta vista opcional
modela los aspectos dinámicos del
sistema y captura aspectos tales como
concurrencia y sincronización mediante
diagramas tales como el de actividades.

21. IES WERNHER VON BRAUN 21
3. Vista de desarrollo. Modela la
organización estática del software en su
ambiente de desarrollo, típicamente
mediante diagramas de componentes.
4. Vista física. Modela el mapeo del
software con el hardware, típicamente
con diagramas de implantación.
5. Vista de casos de uso. Esta es la vista
adicional que es central al modelo y que
agrupa escenarios de casos de uso
principales. Para su representación se
puede usar un diagrama de casos de uso
acompañado de descripciones textuales
de los escenarios

22. IES WERNHER VON BRAUN 22
La documentación de la arquitectura es
una actividad fundamental para poder
realizar una comunicación adecuada del
diseño. Es importante recalcar que no
existen criterios precisos que permitan
determinar el grado exacto de
documentación que se debe realizar, y
esto se debe determinar considerando
diversos aspectos que incluyen a los
involucrados, el tipo de proyecto y la
experiencia del equipo de desarrollo.

23. IES WERNHER VON BRAUN 23

24. IES WERNHER VON BRAUN 24
Dado que la arquitectura de software
juega un papel crítico en el desarrollo, es
conveniente evaluar el diseño una vez que
este ha sido documentado con el fin de
identificar posibles problemas y riesgos. La
ventaja de evaluar el diseño es que es una
actividad que se puede realizar de manera
temprana (aún antes de codificar), y que el
costo de corrección de los defectos
identificados a través de la evaluación es
mucho menor al costo que tendría el
corregir estos defectos una vez que el
sistema ha sido construido.

25. IES WERNHER VON BRAUN 25
1. Análisis de modificabilidad a nivel de
arquitectura (ALMA): El atributo de calidad
que analiza ALMA en una arquitectura de
software es la facilidad de modificación. La
facilidad de modificación en un sistema de
software es la facilidad con la cual éste
puede ser modificado a cambios en el
entorno, cambios en los requerimientos o
cambios a la especificación funcional.

26. IES WERNHER VON BRAUN 26
Este método se compone de cinco pasos:
1. Definir la meta de evaluación.
Dependiendo del objetivo de la
evaluación se selecciona alguna de las
tres metas (predicción del costo de
mantenimiento, evaluación de riesgos,
selección de un conjunto de
arquitecturas).
2. Describir la arquitectura de software.
En este punto se colecta la información de
las partes más relevantes de la
arquitectura como son la descomposición
de ésta en componentes, las relaciones
entre componentes así como las
relaciones que existen en el entorno del
sistema.

27. IES WERNHER VON BRAUN 27
3. Obtener escenarios. Una vez que se
cuenta con la información de la
arquitectura se procede a encontrar y
definir los escenarios de cambio, estos
escenarios son agrupados en
categorías. Dependiendo de la meta
de evaluación se seleccionan los
escenarios. Por ejemplo, si la meta es
estimar el esfuerzo de
mantenimiento, se recomienda
seleccionar aquellos escenarios que
corresponden a los cambios que
tienen una alta probabilidad de que
ocurran durante la vida operacional
del sistema.

28. IES WERNHER VON BRAUN 28
4. Evaluar escenarios. En este punto se
realiza un análisis de impacto que
consiste en identificar los componentes
afectados por los escenarios
previamente definidos, determinar el
efecto del cambio sobre los
componentes así como determinar los
efectos del cambio en otros
componentes. Los resultados de este
análisis se deben expresar ya sea de
manera cuantitativa o cualitativa.
5. Interpretar resultados. Finalmente se
interpretan los resultados así como las
conclusiones del análisis dependiendo de
la meta de evaluación seleccionada.

29. IES WERNHER VON BRAUN 29
2. Análisis de usabilidad del nivel de
arquitectura basado en escenarios
(SALUTA): SALUTA es el primer
método desarrollado para evaluar en
la arquitectura de software la facilidad
de uso del sistema. La facilidad de uso
es la facilidad con la cual el usuario
puede aprender a operar, preparar
entradas e interpretar las salidas de un
sistema o componente

30. IES WERNHER VON BRAUN 30
SALUTA está compuesto de cuatro
pasos y que a continuación se
describen.
1. Crear perfiles de uso. En este
punto se identifican los usuarios
y se organizan en categorías. A
continuación se identifican las
tareas más significativas del
sistema, se identifica el
contexto donde será usado el
sistema, se determinan los
valores para los atributos:
facilidad de aprendizaje,
eficiencia de uso, confiabilidad y
satisfacción.

31. IES WERNHER VON BRAUN 31
2. Describir la facilidad de uso
proporcionada. Se colecta la
información de la arquitectura
de software para determinar
el nivel de soporte en los
escenarios de uso. Esto se
realiza efectuando un análisis
basado en patrones o basado
en propiedades. En ambos
análisis se utiliza el marco de
referencia para determinar la
presencia de patrones o
propiedades de facilidad de
uso en la arquitectura a
evaluar

32. IES WERNHER VON BRAUN 32
3. Evaluar escenarios. En este paso
se evalúa cada uno de los
escenarios que forman parte del
perfil de uso. Por cada escenario
se analizan los patrones y
propiedades previamente
identificados.
4. Interpretar resultados. En este
paso se obtienen los resultados
de la evaluación que contienen
el grado de facilidad de uso que
soporta la arquitectura
evaluada.

33. IES WERNHER VON BRAUN 33
3. Análisis de redes sobrevivientes(SNA):
SNA es un método desarrollado por el
CERT (Computer Emergency
ResponseTeam) que forma parte del
SEI (Software Engineering Institute).
Este método ayuda a identificar la
capacidad de supervivencia en un
sistema analizando su arquitectura.
La supervivencia es la capacidad que
tiene un sistema para completar su
misión a tiempo ante la presencia de
ataques, fallas o accidentes.

34. IES WERNHER VON BRAUN 34
SNA está compuesto de cuatro
pasos que a continuación se
describen.
1. Definición del sistema. En este
paso se obtiene la misión del
sistema, se discute el entorno
de uso en términos de
capacidades y ubicaciones de
los usuarios, se analizan
posibles riesgos que el sistema
pueda presentar en condiciones
adversas, finalmente se analiza
la arquitectura de software.

35. IES WERNHER VON BRAUN 35
2. Definición de las capacidades
esenciales. A continuación se
seleccionan los servicios
esenciales y los activos que
usan. Se deben de seleccionar
aquellos servicios y activos
que sean críticos para
garantizar en condiciones
adversas la misión del
sistema. Una vez
seleccionados, estos se
trazan a través de la
arquitectura para identificar
los componentes que
participan en proporcionar
los servicios esenciales.

36. IES WERNHER VON BRAUN 36
3. Definición de las capacidades
que comprometen al sistema.
En este paso se selecciona un
conjunto representativo de
posibles ataques basados en el
entorno de operación del
sistema. Se definen los
escenarios de intrusión y se
trazan a través de la
arquitectura para identificar
componentes que
comprometan la supervivencia
del sistema logrando así el
acceso y daño a éste.

37. IES WERNHER VON BRAUN 37
4. Analizar la supervivencia.
Finalmente se identifican los
escenarios de intrusión que
contienen los componentes
esenciales y que
comprometen la
supervivencia del sistema.
Por cada componente
identificado se procede a
analizarlo en términos de las
capacidades de resistencia,
reconocimiento y
recuperación.

38. IES WERNHER VON BRAUN 38
Una vez establecida la
arquitectura, se construye
el sistema. Durante esta
etapa es importante evitar
que ocurran desviaciones
respecto del diseño
definido por el arquitecto.

39. IES WERNHER VON BRAUN 39
La implementación se hace por lo habitual
con base en arquitecturas preestablecidas,
y las técnicas de diseño y construcción de
sistemas se apegan a ellas. La
implementación es la acción de transformar
especificaciones en programas que serán
funcionales para los usuarios. La
implementación comprende:
1. Diseñar la estructura general del
sistema basándose en la arquitectura.
Lo anterior se refiere a identificar todos
los módulos que permitirán soportar los
requerimientos funcionales.
2. Diseñar de manera detallada los
módulos del sistema basándose en la
arquitectura y los requerimientos
funcionales.

40. IES WERNHER VON BRAUN 40
3. Desarrollar y/o adquirir los módulos
especificados en el diseño.
a) Programar código de cada uno de los
módulos funcionales que no son
adquiridos, de acuerdo a la especificación
de sus interfaces.
b) Incorporar cada elemento adquirido.
c) Probar de manera individual cada uno de
los módulos
4. Integrar los módulos desarrollados y/o
adquiridos y probar que juntos funcionan
como se espera.
5. Probar los distintos niveles de integración
hasta lograr la totalidad del sistema.
6. Corregir cualquier error detectado en cada
uno de los pasos.

41. ACTIVIDADES A DESARROLLAR:
IES WERNHER VON BRAUN 41
Investigar todo sobre otros métodos de evaluación de
arquitectura de software:
1. ATAM (ArchitectureTrade-off Analysis Method).
2. SAAM (Software Architecture Analysis Method).
3. ARID (Active Reviews for Intermediate Design).
4. PASA (Performance Assessment of Software Architecture).
Nota:
- Entregar el trabajo en Word
- Enviarlo a mi correo: gayquipa@istvonbraun.edu.pe

42. Muchas Gracias
IES WERNHER VON BRAUN 42
Versión del archivo: 2022
Autores: