LECTURA 5 – ATRIBUTOS DE CALIDAD

CHAPTER 4: UNDERSTANGING QUALITY ATTRIBUTES

Pregunta 1: ¿Cuál es la relación entre un caso de uso y un escenario de atributo de calidad?

Si quisieras agregar información de atributos de calidad para un caso de uso, ¿cómo lo haría?

Respuesta 1:

Normalmente hay algunas relaciones entre casos de uso y escenarios de atributos de calidad,
pero puede haber escenarios sin casos de uso y viceversa.

A la izquierda está el caso de uso, o función, y a la derecha está el escenario de atributo de

calidad. Aquí están las relaciones entre las piezas de información que se han discutido y cómo
se relacionan entre sí. Esto supone que el escenario describe algo que también se describe en
el caso de uso. No se requiere una relación uno a uno, puede tener un caso de uso sin un
escenario relacionado, o un escenario sin un caso de uso relacionado.

Tienes a los actores, que usan lo que impulsa el estímulo. Tiene los pasos, por lo que el punto
de partida de cualquier paso al que se refiera, ese es el desencadenante, el usuario hace algo.
Tiene los requisitos previos, que normalmente escribiría en el entorno, y la respuesta que se
produce como resultado de esos pasos.

Pregunta 2: ¿Supone que el conjunto de tácticas para un atributo de calidad es finito o

infinito? ¿Por qué?

Respuesta 2:

Definición de Táctica: es una decisión de diseño que influye en el control de una respuesta de
calidad. Una estrategia de arquitectura es el conjunto de tácticas aplicadas. Por ejemplo
escogemos la táctica de Disponibilidad:
Estas prácticas aseguran que los atributos de calidad sean alcanzados, no siempre se pueden
implementar porque dependen de otros factores del proyecto, como son los costos que
involucran, el tiempo disponible, y políticas de la organización.

Algunas prácticas van en contra del desempeño, como son las tácticas para el atributo de
seguridad, las auditorías sobre los datos generan un sobre proceso sobre el sistema.

Por lo tanto, se concluye que son finitos y cada táctica está definido para cada atributo de
calidad que se desee aplicar.

Pregunta 3: Discuta la elección del lenguaje de programación (un ejemplo de elección de

tecnología) y su relación con la arquitectura en general, y las decisiones de diseño en las
otras seis categorías. Por ejemplo, ¿cómo pueden ciertos lenguajes de programación
habilitar o inhibir la elección de modelos de coordinación?

Respuesta 3:

Las siete categorías de decisiones de diseño son 1. Asignación de responsabilidades 2. Modelo

de coordinación 3. Modelo de datos 4. Gestión de recursos 5. Mapeo entre elementos
arquitectónicos 6. Decisiones de tiempo vinculante 7. Elección de tecnología.

Estas categorías no son la única forma de clasificar las decisiones de diseño arquitectónico,
pero proporcionan una división racional de las preocupaciones. Estas categorías pueden
superponerse, pero está bien si una decisión particular existe en dos categorías diferentes,
porque la preocupación del arquitecto es asegurar que cada importante se considera la
decisión. Nuestra categorización de decisiones se basa parcialmente en nuestra definición de
software arquitectura en que muchas de nuestras categorías se relacionan con la definición de
estructuras y las relaciones entre ellos. Hablando de los lenguajes, podemos ver el otro sello
de la moneda ya que podríamos aplicar un diseño predeterminado para un sistema X, pero al
usar, por ejemplo, Python vemos que no satisface este diseño, y nos vemos obligado a cambiar
el lenguaje, por lo tanto los lenguajes de programación no inhiben la elección de ningún tipo
de comunicación entre las partes, sea cual sea el tipo de modelo desarrollado.
Pregunta 4: Utilizaremos el cajero automático como ejemplo a lo largo de los capítulos sobre
atributos de calidad. Enumere el conjunto de responsabilidades que debe soportar un cajero
automático y proponga un diseño inicial para acomodar ese conjunto de responsabilidades.
Justifica tu propuesta.

Respuesta 4:

El conjunto estándar de responsabilidades de los cajeros automáticos es:

 Rol del usuario

 Verificar saldo de la cuenta Depositar efectivo.
 Retirar dinero.
 Transfiera fondos a otra cuenta.
 Actualización de cuenta.
 Rol de administrador del estado de cuenta impreso, entre otras.

-Rol del usuario

-Verificar saldo de la cuenta
-Depositar efectivo.
-Retirar dinero.
-Transfiera fondos a otra
cuenta…

Usuario Microservicios
Respuesta del
Pregunta 5: Piense en las pantallas que usa su cajero automático favorito. ¿Qué hacen ATM
esas
pantallas? ¿le cuenta acerca de las decisiones vinculantes de tiempo reflejadas en la
arquitectura?

Respuesta 5: Analizando ya desde la pregunta 4, la pequeña arquitectura desarrollada,

podemos deducir que cada pantalla mostrada por el ATM, nos mostraría una respuesta
inmediata, esta respuesta sería interpretada por el usuario sin ningún problema y las
decisiones de este relacionado con la arquitectura no afectaría en lo absoluto.

Por lo tanto el tiempo reflejado en la respuesta del ATM según la arquitectura, será la misma
que se expresará al momento que un usuario desee usar este, para entrar más en detalle
tenemos el perfomance del cuál, analizándolo uno a uno, tenemos que:

Escenario:

 Fuente: interna
 Estímulo: Llega una respuesta (inmediata)
 Artefacto: sistema
 Entorno: normal
 Respuestas: Se procesa la anterior selección de la interfaz.
 Medición: Latencia y se ve el consumo de memoria interna, por parte humana, se
siente la velocidad de respuesta.
Pregunta 6: Considere la opción entre comunicación síncrona y asíncrona (una opción en la
categoría de mecanismo de coordinación). ¿Qué requisitos de atributos de calidad pueden
llevarlo a elegir uno sobre el otro?

Respuesta 6:

Un diseño a nivel de componente se puede representar utilizando alguna representación

intermedia (por ejemplo, gráfica, tabular o basada en texto) que se puede traducir al código
fuente. El diseño de estructuras de datos, interfaces y algoritmos debe cumplir con pautas bien
establecidas para ayudarnos a evitar la introducción de errores. El sistema de software se
descompone en unidades de componentes reutilizables, cohesivas y encapsuladas. Cada
componente tiene su propia interfaz que especifica los puertos requeridos y los puertos
provistos; cada componente oculta su implementación detallada.

 Un componente debe extenderse sin la necesidad de hacer código interno o modificar

el diseño de las partes existentes del componente.
 Depende del componente de abstracciones no depende de otros componentes
concretos, lo que aumenta la dificultad en el gasto.
 Los conectores conectan componentes, especificando y controlando la interacción
entre componentes. El tipo de interacción está especificado por las interfaces de los
componentes.
 La interacción de componentes puede tomar la forma de invocaciones de métodos,
invocaciones asíncronas, difusión, interacciones dirigidas por mensajes,
comunicaciones de flujo de datos y otras interacciones específicas de protocolo.
 Para una clase de servidor, se deben crear interfaces especializadas para servir a las
principales categorías de clientes. Solo aquellas operaciones que son relevantes para
una categoría particular de clientes deben especificarse en la interfaz.
 Un componente puede extenderse a otros componentes y aún así ofrecer sus propios
puntos de extensión. Es el concepto de arquitectura basada en complementos. Esto
permite que un complemento ofrezca otro complemento API.
Pregunta 7: Considere la elección entre comunicación con estado y sin estado (una opción en
la coordinación categoría de mecanismo). ¿Qué requisitos de atributos de calidad pueden
llevarlo a elegir uno sobre el otro?

Respuesta 7: Stateful Stateless Stateless Protocol no requiere que el servidor retenga la

información del servidor o los detalles de la sesión. El protocolo con estado requiere que el
servidor guarde el estado y la información de la sesión. En el protocolo sin estado, no hay una
dependencia estrecha entre estas. El software funciona al hacer que los elementos interactúen
entre sí a través de mecanismos diseñados. Estos mecanismos se denominan colectivamente
como modelo de coordinación. Las decisiones sobre el modelo de coordinación incluyen:

 Identificar los elementos del sistema que deben coordinarse o que tienen prohibido
coordinar.
 Determinar las propiedades de la coordinación, como puntualidad, actualidad,
integridad, corrección y consistencia.
 Elegir los mecanismos de comunicación (entre sistemas, entre nuestro sistema y
externos entidades, entre elementos de nuestro sistema) que realizan esas
propiedades. Propiedades importantes de los mecanismos de comunicación incluyen
estado con estado sin estado, sincrónico versus entrega asincrónica, garantizada
versus no garantizada, y propiedades relacionadas con el rendimiento como el
rendimiento y la latencia.

Pregunta 8: La mayor parte de la arquitectura punto a punto emplea el enlace tardío de la

topología. ¿Qué atributos de calidad promueve o inhibe esto?

Respuesta 8: Una organización de desarrollo contribuye con muchos de los objetivos

comerciales que influyen en una arquitectura. Por ejemplo, si la organización cuenta con una
gran cantidad de programadores experimentados e inactivos expertos en comunicaciones
entre pares, entonces una arquitectura de igual a igual podría ser el enfoque respaldado por la
administración. Si no, bien puede ser rechazado. Esto apoyaría el objetivo comercial, tal vez
dejado implícito,

de no querer contratar personal nuevo o despedir al personal existente, o no querer invertir

significativamente en la recapacitación del personal existente.

En términos más generales, una organización a menudo tiene una inversión en activos, como
las arquitecturas existentes y los productos basados en ellas. La base de un proyecto de
desarrollo puede ser que el sistema propuesto es el siguiente en una secuencia de sistemas
similares, y las estimaciones de costos suponen un alto grado de reutilización de activos y un
alto grado de habilidad y productividad de los programadores.

Además, una organización puede desear hacer una inversión comercial a largo plazo en una
infraestructura para perseguir objetivos estratégicos y puede ver el sistema propuesto como
un medio para financiar y extender esa infraestructura. Por ejemplo, una organización puede
decidir qué quiere desarrollar una reputación de soporte de soluciones basadas en
computación en la nube o arquitectura orientada a servicios o computación en tiempo real de
alto rendimiento. Este objetivo a largo plazo estaría respaldado, en parte, por inversiones en
infraestructura que afectarán a la organización en desarrollo: es necesario contratar o hacer
crecer un grupo de computación en la nube, comprar infraestructura o tal vez planificar la
capacitación.