Issuu on Google+

Documento de trabajo # 629

Condicionantes de arquitectura, V 1.3

Bogotรก, mayo 13, 2010

1


Historia de revisión Versión 1.0 1.1 1.2 1.3 1.4

Fecha 06/5/2010 01/07/10 15/07/10 5/08/2010 3/6/2010

Autor Álvaro López Daniel Ochoa Vladimir López Álvaro López Álvaro López

Descripción Versión inicial Revisión SSPD Revisión SSPD Incorpora notas SSPD Incorpora notas SSPD

2


Tabla de Contenido

3


DOCUMENTO DE TRABAJO # 629....................................................................1 CONDICIONANTES DE ARQUITECTURA, V 1.3...............................................1 BOGOTÁ, MAYO 13, 2010.................................................................................. 1 HISTORIA DE REVISIÓN.....................................................................................2 TABLA DE CONTENIDO..................................................................................... 3 CONDICIONANTES DE ARQUITECTURA......................................................... 5 1.1 Objetivo...................................................................................................................................................5 1.2 Auditabilidad..........................................................................................................................................6 1.2.1 Auditabilidad de casos de uso que afectan objetos...........................................................................7 1.2.2 Auditabilidad de casos de uso ejecutados por un actor....................................................................8 1.3 Seguridad................................................................................................................................................9 1.3.1 Autenticación....................................................................................................................................9 1.3.2 Autorización................................................................................................................................... 10 1.4 Configurabilidad..................................................................................................................................11 1.5 Mantenibilidad

..............................................................................................................................11

1.6 Migrabilidad .....................................................................................................................................12 1.7 Transaccionalidad .............................................................................................................................12 1.8 Colaboración........................................................................................................................................ 13 1.8.1 Información sobre eventos de Orfeo.............................................................................................. 13 1.8.2 Actualización de Orfeo por software externo.................................................................................14 1.9 Extensibilidad ....................................................................................................................................14 1.9.1 Extensibilidad de la estructura........................................................................................................14 1.9.2 Extensibilidad del comportamiento (Flexibilidad).........................................................................15 1.10 Funcionalidad.....................................................................................................................................16 1.11 Facil de Comprobar (Testability).....................................................................................................16 1.12 Uso de los condicionantes de arquitectura.......................................................................................17

4


Condicionantes de Arquitectura 1.1

Objetivo

La arquitectura del sistema no se diseña en vacío, sino que responde a un conjunto de problemas mayores que deben ser resueltos en forma adecuada para que el sistema pueda cumplir con los objetivos que se le han fijado. Este conjunto de problemas cuya solución guía la arquitectura del sistema se conocen como Condicionantes de Arquitectura, y este documento se enfoca en enumerarlos y describirlos utilizando la metodología de Bass, Clemens and Kazman1. En la mencionada metodología de Bass definen condicionantes de arquitectura compuestos por la interacción del sistema en forma de estímulo respuesta, y descritos por 6 elementos a saber      

Ambiente de operación Artefacto Fuente del estímulo Estímulo Respuesta Medición de la respuesta

El ambiente de operación define en cuál de los ambientes en que puede operar el sistema se va a considerar el condicionante de arquitectura. Puede haber tantos ambientes de operación como desee definir el usuario, por ejemplo operación normal, operación en pruebas, ambiente de desarrollo, en línea, por lotes, replicación, seguro, inseguro, etc. El artefacto es el sistema o subsistema de software, organizacional, o equipo de trabajo que recibe el estímulo y que debe responder a él en forma adecuada. La fuente del estímulo es el sistema, persona, u organización externa al sistema a diseñar, y que emite el estímulo al que debe responder el artefacto. Es estímulo son todas aquellas entradas de datos, software, órdenes administrativas, etc. que debe procesar el artefacto y para las que debe producir una respuesta. 1

Bass, Clemens and Kazman, Software Architecture in Practice, second edition, Addisson Wesley, 2003. Los autores definen “Quality Attributes”; de estos atributos algunos tienen mayor efecto sobre la aquitectura del sistema y se conocen como “Architectural Drivers”, que se han traducido como Condicionantes de Arquitectura, y el mensaje de que los problemas descritos restringen las opciones disponibles para el arquitecto.


Respuesta es la respuesta de software, datos, organizacional o de otra naturaleza, que produce el artefacto y que puede ser reconocida por el emisor como una respuesta a su estímulo. La medición de la respuesta incluye la escala de medición con que se mide la respuesta. Esta escala debe permitir juzgar a quien corresponda si la respuesta producida por el artefacto como reacción al estímulo es adecuada para cumplir con los objetivos del sistema. La definición de los condicionantes de arquitectura se ilustra en el siguiente gráfico

A continuación se enumeran los condicionantes de arquitectura que afectan el desarrollo de Orfeo.

1.2

Auditabilidad

Se distinguen dos tipos de problemas  

Casos de uso que afectan objetos Casos de uso ejecutados por un actor

En el primer caso el interés es conocer como se ha llegado al estado actual del sistema. En el segundo caso el interés es estudiar la historia de actuaciones de un actor.


1.2.1 Auditabilidad de casos de uso que afectan objetos Componente

Definición

Artefacto de software

Todos los módulos del sistema

Fuente de estímulo

Usuario del sistema

Estímulo

Usuario ejecuta cualquier caso de uso del sistema.

Ambiente de trabajo

Alguno de    

Respuesta

Normal , en línea Normal, por lotes Prueba, en línea, Prueba, por lotes

El caso de uso puede tener o no tener activada su auditoría. Cuando el caso de uso tiene activada su auditoría, el sistema registra el cambio al estado producido por la ejecución del caso de uso y un conjunto de información auxiliar, tal como fecha, hora, usuario, IP, caso de uso, llaves, etc. Cuando el caso de uso no tiene activada su auditoría el sistema no registra ninguna información. La auditoría puede activarse o desactivarse en el momento que se desee, a nivel de caso de uso.

Medición de la respuesta

1. La producción de la auditoría no debe afectar mucho el desempeño del sistema. La suma del tiempo requerido para ejecutar un caso de uso más el tiempo requerido para ejecutar la auditoría del caso de uso no debe superar los tiempos de respuesta acordados contractualmente. 2. La producción de la auditoría no debe afectar la legibilidad del código funcional. Existen por lo menos tres grados de legibilidad. En el primero, la auditoría se ejecuta en forma subterránea sin que exista ningún código que la implante externamente (vg. Motor bdd). En la segunda, existen instrucciones declarativas en los componentes (anotaciones) que indican cuáles elementos deben ser auditados, pero no existe código explícito en la ejecución de cada caso de uso (vg. Aspect Oriented Programming). En la tercera, cada vez que se requiere auditar un caso de uso, el código explícito aparecen dentro de los métodos que implementan el caso de uso (programación normal). Este criterio trata de evitar la tercera situación pues contaminaría el código funcional con el código de producción de auditoría. 3. La acumulación de historia de ejecución no debe agotar muy rápidamente el espacio en disco. 4. El sistema debe estar en capacidad de presentar al usuario opciones para consulta en forma lógica para examinar la historia de ejecución del sistema según rango de fechas, objetos afectados, usuarios involucrados, casos de uso ejecutados, o combinación de algunas de ellas. Los criterios de aceptabilidad de la respuesta son empíricos. Es


Componente

Definición posible que para una operación pequeña se pueda auditar toda la ejecución de todos sus casos de uso, pero para una operación grande el administrador se vea obligado a seleccionar subconjuntos de los casos de uso para auditar, y a guardar fuera de línea registros de auditoría con cierta periodicidad para no afectar el desempeño del sistema.

1.2.2 Auditabilidad de casos de uso ejecutados por un actor Componente

Definición

Artefacto de software

Todos los módulos del sistema

Fuente de estímulo

Usuario del sistema

Estímulo

Cualquier Usuario ejecuta cualquier caso de uso del sistema.

Ambiente de trabajo

Alguno    

Respuesta

Este caso es una especialización del anterior, pero se examina por la importancia que tiene en ciertas organizaciones como parte de la seguridad del sistema.

de Normal , en línea Normal, por lotes Prueba, en línea, Prueba, por lotes

El caso de uso puede tener o no tener activada su auditoría. Cuando el caso de uso tiene activada su auditoría, el sistema registra el cambio al estado producido por la ejecución del caso de uso y un conjunto de información auxiliar, tal como fecha, hora, usuario, IP, caso de uso, llaves, etc. Cuando el caso de uso no tiene activada su auditoría el sistema no registra ninguna información. La auditoría puede activarse o desactivarse en el momento que se desee, a nivel de caso de uso. Medición de la respuesta

Además de los criterios establecidos para el escenario general, en este escenario se adicionan los siguientes criterios de medición de la respuesta. 1. El sistema debe estar en capacidad seleccionar un usuario y un rango de fechas, y para esta selección examinar la historia de ejecución según caso de uso u objeto afectado. Por ejemplo, el sistema debe permitir examinar los cambios realizados por un usuario específico a un expediente específico en un rango de fechas.


1.3

Seguridad

De los múltiples problemas relacionados con la seguridad, se estudian los siguientes  

Autenticación Autorización

1.3.1 Autenticación Componente

Definición

Artefacto de software

Módulo de autenticación

Fuente de estímulo

Usuario del sistema Un usuario es toda persona o programa que tiene asignado un código de usuario.

Estímulo

Ejemplos de usuarios son: • Una persona que tiene un código de login en el sistema y ejecuta los casos de uso del sistema a través de una interfaz gráfica web. • Un programa batch que ejecuta los casos de uso del sistema. • Un programa remoto que ejecuta los casos de uso a través de Web Services. • Un esquema de mensajería segura que acumula mensajes enviados por un sistema externo y ejecuta con ellos casos de uso de Orfeo. Módulo de autenticación es presentado con un Usuario que desea ejecutar casos de uso del sistema por cualquiera de los medios provistos para su ejecución, por ejemplo controladores Web, controladores batch, Web Services, controladores de migración, mensajería, etc.

Ambiente de trabajo Alguno de       Respuesta

Normal , en línea Normal, por servicio web Normal, por lotes Prueba, en línea, Prueba, por servicio web Prueba, por lotes

El sistema valida que el usuario es un usuario registrado para el sistema y responde: SI, cuando el usuario es válido y puede utilizar el sistema. SI, cuando el usuario no es válido y no puede utilizar el sistema. NO, de lo contrario.


Componente

Definición Nótese que el mecanismo de autorización NO autoriza la ejecución de casos de uso. Su función única es determinar si el usuario es válido para el sistema.

Medición de la respuesta

El sistema es determinístico el 100% de las veces: Cuando un usuario es reconocido y está vigente responde que SI es autenticado; de otra forma responde que NO es autenticado.

1.3.2 Autorización Componente

Definición

Artefacto de software

Módulo de autorización

Fuente de estímulo

Usuario del sistema

Estímulo

Ejemplos de usuarios son: • Una persona que tiene un código de login en el sistema y ejecuta los casos de uso del sistema a través de una interfaz gráfica web. • Un programa batch que ejecuta los casos de uso del sistema. • Un programa remoto que ejecuta los casos de uso a través de Web Services. • Un esquema de mensajería segura que acumula mensajes enviados por un sistema externo y ejecuta con ellos casos de uso de Orfeo. Módulo de autorización es presentado con un usuario autenticado que desea ejecutar una operación sobre algún objeto del sistema.( e.g. petición para ejecutar una funcionalidad del sistema sobre la cual el usuario no tiene autorización)

Ambiente de trabajo

Alguno      

de Normal , en línea Normal, por servicio web Normal, por lotes Prueba, en línea, Prueba, por servicio web Prueba, por lotes

Respuesta

El sistema verifica si el usuario tiene derecho a ejecutar la operación presentada y responde: SI, cuando el usuario tiene derecho y es autorizado a ejecutar la operación presentada. NO, cuando el usuario no tiene derecho a ejecutar la operación, y el sistema no le permite ejecutar dicha operación.

Medición de la respuesta

El sistema es determinístico el 100% de las veces: Cuando un usuario está autenticado y tiene permisos para ejecutar la operación solicitada, y permiso de acceso a los objetos afectados por la operación, responde que SI está


Componente

Definición autorizado; de otra forma responde que NO es autorizado. Nótese que si un usuario tiene permiso para ejecutar una operación, pero no tiene permiso para acceder a TODOS los objetos afectados por esta, el sistema responde que NO está autorizado. En forma similar, si el usuario no tiene permiso para ejecutar una operación, el sistema responde que NO está autorizado, aún si tiene permiso de acceso a los objetos afectados por la operación.

1.4

Configurabilidad Componente

Definición

Artefacto de software

Módulo X, Y, Z que requieren configuración

Fuente de estímulo

Ingeniero especializado

Estímulo

Ingeniero desea configurar los aspectos que requieren configuración. (e.g. Se implanta el software en una nueva entidad y los parámetros configurables de radicación de entrada necesitan cambiarse) Desarrollo, Pruebas, Producción

Ambiente de trabajo Respuesta

El sistema permite definir los valores de un conjunto de elementos de configuración. (i.e. El sistema adopta la nueva configuración)

Medición de la respuesta

SI, cuando el ingeniero puede configurar los elementos que requieren configuración. NO, de lo contrario. Nótese que el tiempo de respuesta requerido para que el sistema adopte la nueva configuración depende de la naturaleza de los parámetros. Es factible que para algunos parámetros de la configuración el tiempo de respuesta sea de segundos, pero para otros se requiera realizar reiniciar el servidor de aplicaciones.

1.5

Mantenibilidad Componente

Definición

Artefacto de software

Módulos de software del sistema

Fuente de estímulo

Institución que implanta Orfeo

Estímulo

Institución desea modificar o adicionar el comportamiento del sistema. Desarrollo, Pruebas, Producción

Ambiente de trabajo


Componente Respuesta

Medición de la respuesta

1.6

Definición El ingeniero asignado al mantenimiento puede modificar los aspectos requeridos del sistema 1. Un nuevo caso de uso debe poder diseñarse, probarse, y programarse en máximo dos semanas hábiles. 2. Un caso de uso existente debe poder modificarse en su diseño, programación y prueba en cuatro días hábiles.

Migrabilidad Componente

Definición

Artefacto de software

Módulos del sistema que tienen persistencia.

Fuente de estímulo

Ingeniero especializado

Estímulo

Ingeniero desea incorporar al sistema objetos que están localizados fuera del sistema. Desarrollo, Pruebas, Producción

Ambiente de trabajo Respuesta Medición de la respuesta

1.7

El ingeniero puede incorporar los objetos almacenados en medio externo al sistema 1. El ingeniero debe poder utilizar los casos de usos programados en la lógica de negocio para realizar la migración. 2. Después de la migración los nuevos objetos siguen la lógica de negocio del nuevo sistema, 3. Los objetos existentes en el sistema antiguo que no tienen representación en el nuevo sistema son ignorados en la migración. 4. El diseño y construcción de la lógica de migración de cada objeto del nuevo sistema no excede a 5 días hábiles. 5. La ausencia de información requerida en los objetos del nuevo sistema y no provistos por el viejo es contemplada en la lógica de negocio del nuevo sistema. 6. Las incongruencias de tipo y codificación entre los atributos de los objetos del sistema a migrar y el nuevo sistema son contempladas en la lógica de negocio del nuevo sistema.

Transaccionalidad Componente

Definición

Artefacto de software

Módulos del sistema que tienen concurrencia.

Fuente de estímulo

Múltiples usuarios normales

Estímulo

Múltiples usuarios desean acceder o actualizar información en el sistema al mismo tiempo.


Componente

Definición

Ambiente de trabajo

Desarrollo, Pruebas, Producción

Respuesta

El sistema hace ver a cada usuario como si fuese el único usuario en el sistema y los cambios de todos parecen como si fuesen ejecutados en secuencia.

Medición de la respuesta

1. Todas las acciones que definen una transacción se ejecutan en la secuencia establecida o ninguna se ejecuta. Dicho de otra forma, las transacciones se ejecutan en el sistema como una unidad. 2. Todas las transacciones se ejecutan como si el usuario que las ejecuta fuera el único usuario del sistema, o todas fallan, de forma que el sistema siempre pasa de un estado consistente a otro estado consistente.

1.8

Colaboración

La colaboración considera dos condicionantes • •

La información a sistemas externos sobre eventos de Orfeo La utilización de Orfeo por parte de sistemas externos

1.8.1 Información sobre eventos de Orfeo

Componente

Definición

Artefacto de software

Todos los módulos del sistema

Fuente de estímulo

Software externo al sistema

Estímulo

El software externo requiere estar informado de los cambios en Orfeo que afectan su funcionalidad Alguno de  Normal , en línea  Normal, por servicio web  Normal, por lotes  Prueba, en línea,  Prueba, por servicio web  Prueba, por lotes

Ambiente de trabajo

Respuesta

Medición de la respuesta

El sistema permite al software externo registrarse para ser informado de los eventos de Orfeo que sean de su interés. Orfeo informa al software de externo sobre los cambios en su estado que son de interés del software externo. 1. El software externo puede registrarse para ser informado de los eventos de Orfeo que son de su interés, y Orfeo informa al software externo sobre la ocurrencia de dichos eventos. 2. Cuando un sistema externo es informado sobre un evento de su interés, se le provee la información


Componente

Definición complementaria que indica la naturaleza del evento ocurrido.

1.8.2 Actualización de Orfeo por software externo

Componente

Definición

Artefacto de software

Todos los módulos del sistema

Fuente de estímulo

Software externo al sistema

Estímulo

El software externo desea ejecutar un conjunto selecto de casos de uso de Orfeo Alguno de  Normal , en línea  Normal, por servicio web  Normal, por lotes  Prueba, en línea,  Prueba, por servicio web  Prueba, por lotes

Ambiente de trabajo

Respuesta

Medición de la respuesta

1.9

Orfeo expone al software externo un conjunto selecto de casos de uso que pueden ser ejecutados por dicho software, siempre y cuando el software se autentique correctamente y esté autorizado para ejecutar dichos casos de uso. 1. Orfeo provee un mecanismo de autenticación para el software externo. 2. Orfeo provee un mecanismo de autorización para los casos de uso expuestos al software externo. 3. Orfeo provee uno o más mecanismos para que el software externo autenticado y autorizado pueda ejecutar sus casos de uso. 4. Orfeo provee un mecanismo para informar al sistema externo del resultado de la ejecución de los casos de uso ejecutados por dicho sistema.

Extensibilidad

1.9.1 Extensibilidad de la estructura Componente

Definición

Artefacto de software

Entidades de negocio

Fuente de estímulo

Ingeniero especializado


Componente Estímulo Ambiente de trabajo Respuesta

Medición de la respuesta

Definición Ingeniero desea modificar la estructura de algunos de los componentes del sistema. Desarrollo, Pruebas, Producción El ingeniero puede modificar ciertas características de la estructura de los componentes sin afectar el funcionamiento normal del sistema. 1. El sistema permite al ingeniero modificar las características de la estructura de Orfeo en forma ágil, modificando a su vez los casos de uso correspondientes, utilizando los tiempos de respuesta establecidos para el mantenimiento del sistema. 2. El código resultante hace uso de la verificación de tipos que provee el compilador. 3. El código resultante hace uso de la protección de tipos que provee el manejador de base de datos. 4. El desempeño del sistema resultante de la extensión es comparable con aquel antes de la extensión. 5. El mantenimiento del sistema resultante cumple con el condicionante de Mantenibilidad.

1.9.2 Extensibilidad del comportamiento (Flexibilidad)

Componente

Definición

Artefacto de software

Entidades de negocio

Fuente de estímulo

Ingeniero especializado

Estímulo

Ingeniero desea modificar cierto comportamiento selecto de algunos de los componentes del sistema. Desarrollo, Pruebas, Producción

Ambiente de trabajo Respuesta

Medición de la respuesta

El ingeniero puede modificar ciertas características del comportamiento de Orfeo sin tener que modificar directamente el código fuente.

1.

2. 3.

4.

5.

El sistema permite al ingeniero modificar el comportamiento de Orfeo en forma ágil, sin tener que modificar directamente el código fuente. El código resultante hace uso de la verificación de tipos que provee el compilador. El código resultante hace uso de la protección de tipos que provee el manejador de base de datos. El desempeño del sistema resultante de la extensión es comparable con aquel antes de la extensión. El mantenimiento del sistema resultante cumple


Componente

Definición con el condicionante de Mantenibilidad.

Todo sistema tiene estructura y comportamiento. La estructura se refiere a los objetos de negocio, sus relaciones, y sus atributos; el comportamiento se refiere a las acciones observables del sistema en el tiempo (la ejecución de los casos de uso). Los condicionantes, en la forma en que están expresados, establecen que la modificación de la estructura deben seguir las reglas de mantenimiento del sistema, mientras que la actualización de ciertos comportamientos selectos deben facilitar una respuesta más ágil. Nótese también que los condicionantes de extensibilidad, como están concebidos, tienen como fuente del estímulo a un ingeniero especializado. Los condicionantes no consideran la extensibilidad realizada por un usuario que no conoce la estructura ni los programas de Orfeo. 1.10 Funcionalidad Componente Artefacto de software Fuente de estímulo Estímulo Ambiente de trabajo

Definición Módulos que implementan la funcionalidad definida para Orfeo en sus casos de uso. Usuario Realizar sus actividades de negocio en cuanto respecta a los casos de uso definidos. Desarrollo, Pruebas, Producción

Respuesta

El sistema permite al usuario realizar sus actividades del negocio, según el inventario de casos de uso definidos en la especificación funcional

Medición de la respuesta

1. El sistema permite al usuario realizar su función, en un tiempo de respuesta < 3 seg, con operaciones atómicas (transaccional), integrales, y desde cualquier tipo de cliente externo que se desee, con la infraestructura de equipos establecida en los términos de referencia

1.11 Facil de Comprobar (Testability)

Componente Artefacto de software

Definición Módulos que implementan la funcionalidad definida para Orfeo en sus casos de uso.


Componente Fuente de estímulo Estímulo Ambiente de trabajo Respuesta

Medición de la respuesta

Definición Ingeniero especializado, Ingeniero de pruebas. Llevar a cabo la ejecución de las pruebas unitarias automatizadas asociadas a los casos de uso. Desarrollo, Pruebas, Producción El sistema permite al ingeniero ejecutar las pruebas unitarias asociados la lógica de negocio de cada caso de uso definido en la especificación funcional 1. El sistema tiene identificado el inventario de pruebas de los casos de uso establecidos de la lógica de negocio. 2. El sistema permite realizar pruebas de regresión cuando se realizan cambios a la lógica de negocio. 3. El sistema permite probar independientemente la lógica de negocio. 4. El sistema permite probar en forma integrada la ejecución desde una interfaz gráfica.

1.12 Uso de los condicionantes de arquitectura La arquitectura no es el diseño de detalle del sistema, sino que condiciona dicho diseño de detalle. No es fácil decir exactamente cómo es que la arquitectura condiciona el diseño de detalle. En algunos casos la arquitectura provee los criterios para establecer si un diseño de detalle cumple con los condicionantes de arquitectura; en otros casos, la arquitectura sugiere un patrón específico para el diseño del sistema; en otros casos la arquitectura solicita del diseño de detalle la solución a los problemas expresados por un condicionante; en otros casos más la arquitectura sugiere alternativas que cumplirían con los condicionantes, sin establecer cuál es la mejor. En los documentos que siguen, cada uno de los condicionantes se elaborará en un documento específico y, en aquellos casos en donde existan soluciones específicas o alternativas, estas se documentarán y se sugerirá una solución recomendada. De acuerdo con la sugerencia de la SSPD en la revisión de la primera propuesta de condicionantes, los condicionantes de arquitectura se priorizarán de la siguiente forma: 1. 2. 3. 4.

Mantenibilidad Flexibilidad (Extensibilidad del comportamiento) Parametrización Los demás condicionantes



prueba de documetnto