El proceso de Definicion de la Arquitectura.doc

Turismo Por Colombia Diego Ortiz, Francisco Torres, Carlos Lizarazo

1. El proceso de Definición de la Arquitectura

• Normalmente comienza• Con un conocimiento inicial del problema y su alcance• Sin conocer el tamaño total del producto• Sin conocer todos los riesgos• Sin entender los conflictos internos entre los Stakeholders

• Principios– Basado en las necesidades de los Stakeholders– Comunicación de las decisiones– Debe ser un proceso estructurado– Debe ser pragmatico (tiempo, dinero, etc.)– Debe ser flexible– Debe ser independiente de tecnología– Debe ser integrado al proceso de desarrollo– Estar alineado con las políticas de calidad

• Productos Esperados– Principal

• Documento de Arquitectura– Secundarios

• Claridad en los requerimientos• Expectativas de los Stakeholders• Indentificación y evaluación de posibles arquitecturas• Criterios de aceptación de la arquitectura• Un conjunto de artefactos para iniciar el diseño detallado


Producir Arquitectura Candidata

La arquitectura de software es una solución a los problemas de gran tamaño y complejidad que no pueden solucionarse efectivamente con algoritmos y estructuras de datos pero cabe mencionar que si el tipo de arquitectura no es el correcto puede llevar a resultados desastrosos.

Para llegar a la arquitectura de software se paso por dos etapas importantes que fueron los lenguajes de alto nivel de programación en donde se desarrollo los ensambladores simbólicos al reconocer que el diseño de memoria y actualización de las referencias podría ser automatizado, y los tipo de datos abstractos que son un conjunto de objetos junto con un conjunto de operaciones.

El estilo arquitectónico escogido es tuberías y filtros, debido a que es el que más de adapta en los procesos de búsqueda y transacciones realizados por la aplicación, ya que los filtros pueden ser tratados como cajas negras, y esto facilita el tratamiento de la información, en flujo con las transacciones bancarias.

En los diagramas de este estilo arquitectónico se puede ver de forma detallada la interacción entre los procesos o filtros y las bases de datos, ya que el proyecto se basa en desarrollo web, se puede especificar los procesos que tienen los filtros con los puertos, y detallar las clases de los mismos.

Los Filtros de forma independiente y pueden ser tratados como cajas negras. Este aislamiento de la funcionalidad ayuda a asegurar los atributos de calidad, como la ocultación de información, la cohesión alta, modificabilidad y la reutilización.

Filtros de interactuar con otros componentes de manera limitada. Esta simplicidad de conexión ayuda a asegurar bajo acoplamiento.

Las tuberías y los filtros pueden ser jerárquicamente integrada. Filtros de orden más altos se pueden crear a partir de cualquier combinación de las tuberías de menor orden y los filtros.


Objetivos

A continuación se presentan los objetivos generales que guían el desarrollo de la arquitectura propuesta, para la construcción del sistema de gestión de ventas al cliente.

1. Ofrecer una percepción del sistema a implementar, desde diferentes puntos de vista, con el propósito de lograr la satisfacción de las necesidades planteadas por los stakeholders identificados en el sistema.

2. Proponer diferentes arquitecturas candidatas que ofrezcan la flexibilidad necesaria, frente a los requerimientos funcionales manifestados por los stakeholders y los requerimientos no funcionales identificados durante la fase de levantamiento de información y a lo largo del desarrollo de la arquitectura y su concertación.

3. Desarrollar una herramienta de comunicación para la definición clara de necesidades e identificación adecuada de caminos de solución por medio del diseño arquitectural realizado, logrando adicionalmente una optimización tanto de los recursos humanos como financieros, que intervienen en la implementación de la arquitectura elegida.

– Producir una primera versión de la arquitectura

La presente arquitectura es descrita a través de los puntos de vista desarrollados y es así que por medio de cada uno de estos se posibilita la visualización de cómo los requerimientos funcionales y no funcionales son satisfechos por los diseños arquitecturales propuestos.

De esta manera, es necesario comenzar por mostrar el deployment viewpoint, en el cual se presenta la infraestructura tecnológica que permitirá la ejecución de la solución de software a implementar y adicionalmente, se muestran algunos de los requerimientos tanto en hardware como en software, indispensables para la implantación del sistema de intermediación del sistema. Adicionalmente es importante destacar que a través de este punto de vista, se puede observar cómo es posible satisfacer el requerimiento no funcional de alta disponibilidad del sistema, por medio de la conformación de clúster de los servidores de aplicaciones, de los servidores web y de los servidores de bases de datos; ofreciendo un servicio de respaldo en caso de fallas en alguno de estos equipos y de manera adicional, logrando un servicio de balanceo de carga; teniendo en cuenta la alta concurrencia a la que será sometido el sistema.

Posteriormente, se realizará una descripción del sistema desde el punto de vista funcional, siendo este en el cual se tomaron las mayores decisiones arquitecturales, dado que los modelos que conforman este viewpoint influyen en una gran media en la


modularidad, flexibilidad y la estructura de servicios que se pretende ofrecer al implementar el sistema de intermediación comercial.

Por último, se describirá por medio del information viewpoint, las entidades informacionales en la que se realizará el almacenamiento y gestión de la información de la aplicación de intermediación comercial, describiendo sus ciclos de vida y flujos a través del sistema. De esta manera, es necesario hacer énfasis en que dado el diseño de componentes e interfaces del punto de vista funcional, se determinó utilizar un conjunto de unidades informacionales de acuerdo a la especialidad de los componentes desarrollados anteriormente. Es así, que aún más desde este último punto de vista se puede evidenciar la gran cohesión que existe dentro de los componentes diseñados como subsistemas de la aplicación de intermediación del sistema, buscando mecanismos directos de comunicación en aras de lograr un mejor rendimiento en los recursos utilizados para el funcionamiento global del sistema.

– Concerns

Específicamente, se espera que la arquitectura no se vea comprometida de manera crítica, al inducir un cambio en su estructura de componentes y por ende, es su estructura de unidades informacionales.

– Architectural Styles

El contexto de las tuberías y filtros de estilo es un sistema que necesita para procesar flujos de datos.

El estilo resuelve el problema de la aplicación de un sistema que debe procesar los datos en una secuencia de pasos, donde el uso de un único proceso no es posible y donde los requisitos para los pasos de procesamiento pueden cambiar con el tiempo.

El problema tiene las siguientes principales características.

Los cambios futuros debe ser posible mediante el cambio o recombinación pasos.

Pequeños pasos de procesamiento son más fáciles de reutilizar que los grandes.

Pasos no adyacentes en el proceso no comparten información.

Existen diferentes fuentes posibles de datos de entrada.

Almacenamiento explícito de los resultados intermedios se debe evitar.

Multiprocesamiento entre los pasos no debe ser descartada.

La solución a este problema es dividir la tarea en una serie de pasos secuenciales y para conectar los pasos por el flujo de datos del sistema.


El procesamiento se lleva a cabo por los componentes del filtro, que consumen y los datos de proceso incremental. Los datos de entrada al sistema es suministrado por una fuente de datos, mientras que la salida desemboca en un sumidero de datos. La fuente de datos, receptor de datos, y los componentes del filtro están conectadas por tuberías. La tubería implementa el flujo de datos entre dos componentes adyacentes. El tubo es la única manera permitida para conectar los otros componentes, y que define un formato simple, estándar para los datos que pasan a través de ella, permitiendo filtros para ser combinados sin conocimiento previo de la existencia del otro.

La secuencia de filtros combinados por tuberías se llama una canalización de procesamiento. Como se indica por los comentarios de estilo UML, las cajas representan los filtros y las flechas representan tubos unidireccionales enlazan los filtros. Cada filtro realiza una tarea para un solo ejemplo, el filtro VAN calcula el valor presente neto; el valor presente de los flujos futuros de una inversión fluye menos la inversión inicial.

– Architectural Views

Arquitectura vistas son representaciones de la arquitectura general que son significativos para una o más partes interesadas en el sistema.

Una arquitectura por lo general se representa por medio de uno o más modelos de arquitectura que en conjunto proporcionan una descripción coherente de la arquitectura del sistema. Un modelo único y completo es a menudo demasiado complejas para ser entendidas y comunicadas en su forma más detallada, mostrando todas las relaciones entre los distintos negocios y los componentes técnicos. Al igual que con la arquitectura de un edificio, normalmente es necesario el desarrollo de múltiples puntos de vista de la arquitectura de un sistema de información, para que la arquitectura que debe comunicarse a, y comprendida por los diferentes actores del sistema.

Por ejemplo, al igual que un arquitecto del edificio podría crear esquemas eléctricos, planos de planta y elevaciones para describir las diferentes facetas de un edificio para sus diferentes grupos de interés (electricistas, propietarios, funcionarios de planificación), por lo que un arquitecto de TI puede crear vistas físicas y de seguridad de un sistema informático para los grupos de interés que tienen inquietudes relacionadas con estos aspectos.


Vista lógico: los servicios que el sistema ofrece a los usuarios finales que aparecen con los tipos de modelo UML: diagrama de clases, diagrama de Comunicación, diagrama de secuencia.

Vista de desarrollo: El sistema desde la perspectiva de un programador, interesados en la gestión de software. Este punto de vista también se conoce como la vista de la implementación. Se utiliza el diagrama de componentes de UML para describir los componentes del sistema. Diagramas de UML utilizados para representar la vista del desarrollo incluyen el diagrama del paquete.

Vista del proceso: Las ofertas visión de proceso con los aspectos dinámicos del sistema, explica los procesos del sistema y la forma en que se comunican, y se centra en el comportamiento de tiempo de ejecución del sistema. La vista del proceso se dirige concurrencia, distribución, integradores, el rendimiento y la escalabilidad, etc Diagramas UML para representar vista del proceso incluyen el diagrama de actividades.

Vista físico: El punto de vista físico representa el sistema desde el punto de vista de un ingeniero de sistemas. Se ocupa de la topología de componentes de software en la capa física, así como las conexiones físicas entre estos componentes. Este punto de vista también se conoce como el punto de vista de implementación. Diagramas UML utilizados para representar vista físico incluyen el diagrama de implementación.

Escenarios: La descripción de una arquitectura se ilustra el uso de un pequeño conjunto de casos de uso o escenarios que se convierten en una quinta vista. Los escenarios describen secuencias de interacciones entre los objetos y entre los procesos. Ellos se utilizan para identificar elementos arquitectónicos y para ilustrar y validar el diseño de la arquitectura. También sirven como punto de partida para el análisis de una arquitectura prototipo . UML Diagrama (s) que se utiliza para representar la opinión de escenario incluye el diagrama de casos de uso.

2.PUNTOS DE VISTA (VIEWPOINTS/VIEWS)• Algunas preguntas relevantes durante la definición de la arquitectura

– Cuáles son los principales elementos funcionales

– Cómo interactúan entre ellos?– Qué información almacenar y presentar?– Qué hardware y software se va a necesitar?– Cómo serán los ambientes de desarrollo, pruebas y producción ?

• Opciones para responder estas y otras preguntas– Hacer un único modelo – Utilizar las vistas arquitecturales

http://www.chambers.com.au/glossary/use_case.php

http://www.chambers.com.au/glossary/prototype.php


Cubrimiento de los puntos de vista de casos de usoInicialmente se cuenta con el siguiente use case view, construido a partir del contexto y los concerns identificados con la ayuda de los stakeholders.

Figura 1: sistema de gestión de ventas al cliente: Casos de Uso PrincipalesTeniendo en cuenta el anterior diagrama, es posible visualizar a los actores y a los casos de uso inicialmente contemplados, para el desarrollo arquitectural propuesto; y en ese orden de ideas los elementos anteriormente mostrados son descritos en detalle a continuación.

StakeholdersEsta sección presenta una lista de los stakeholders involucrados en el proyecto. Para cada uno de ellos, se deben listar los concerns que van a ser tenidos en cuenta en el documento de arquitectura. Esta información se presenta en forma de matriz, donde las filas representan los stakeholders y las columnas los concerns. Cada celda determina el grado de relevancia del concern para el stakeholder. Finalmente, basados en los concerns relevantes a cada stakeholder se determinan los puntos de vista que se le presentarán. El standard ANSI/IEEE 1471-2000 propone que al menos los siguientes stakeholders sean considerados: usuarios, clientes, desarrolladores y administradores.

Customer Project manager External organizations Application software developers Communications engineers Operational system

managers Infrastructure software developers Chief Engineer/Chief Scientist Trainers

End users Program management Maintainers


Application system engineers

System and software integration and test engineers Auditors

Application hardware engineers

Safety engineers and certifiers

Security engineers and certifiers

EstrategiaDescribir un sistema complejo, utilizando un conjunto de vistas interrelacionadas para ilustrar sus carácterísticas funcionales y propiedades de calidad

"Una vista es una representación de uno o más aspectos estructurales de una arquitectura que ilustra cómo la arquitectura trata uno o más preocupaciones por uno o más de las partes interesadas"

• Qué información incluir en una vista?– A cuál stakeholder esta orientada?– Qué tanto entiende de tecnología el stakeholder?– Cuáles concerns se pretenden resolver en dicha vista?

"Un punto de vista es una colección de patrones, plantillas y convenciones para un tipo de construcción de la vista. Define a las partes interesadas, cuyas preocupaciones se reflejan en el punto de vista y las directrices, principios y modelos de plantilla para la construcción de sus puntos de vista"

• Beneficios al utilizar vistas– Separación de Concerns– Comunicación con los Stakeholders– Reducción de complejidad– Facilidad en el diseño y desarrollo del sistema

• Problemas al utilizar vistas– Inconsistencia entre las vistas– Error en la selección de las vistas– Fragmentación de la información


Functional:

Identificador: RQ7 Nombre: Registrar respuestas de quejas y reclamos

FUNCIONAL

Descripción: antes de que el cliente reciba una respuesta de su queja o reclamo, el sistema debe guardar una copia de seguridad.

Categoría: No visible

Objetivo: Garantiza la posibilidad de mejorar el sistema y los servicios prestados por medio de recomendaciones de los usuarios.

Alcance: Brinda al usuario final la forma de hacer escuchar sus quejas por medio del sistema.

Datos de entrada: mensaje de reclamo. Datos de Salida: mensaje de respuesta (automatizado).

Criterios de Aceptación: Es una herramienta gerencial y de control que permite, a partir de las necesidades de los usuarios con respecto a los servicios prestados enviar quejas, reclamos, solicitudes de información y sugerencias y se utiliza para optimizar la gestión del sistema.

Precondición: El asistente de ventas haya enviado la respuesta de cierta queja o


reclamo.

Poscondición: enviar respuesta de la queja o reclamo al cliente.

Identificador: RQ8 Nombre: Registro de usuarios no autenticados en el sistema.

FUNCIONAL

Descripción: El registro de los usuarios no autenticados en el sistema o usuarios nuevos, hace referencia a la posibilidad de, con un nombre de usuario y contraseña, acceder al sistema.

Categoría: Visible

Objetivo: Garantizar la autentificación de los usuarios y compradores de planes de turismo en el sistema.

Alcance: Brinda la posibilidad de que el cliente tenga un usuario único para identificarse e identificar las acciones hechas por el en el sistema.

Datos de entrada: Datos de registro (nombre, email, etc.).

Datos de Salida: envió de usuario y contraseña.


Criterios de Aceptación: La autentificación de los usuarios y compradores de planes de turismo en el sistema brinda la posibilidad de poder identificar las acciones hechas en el sistema.

Precondición: el usuario no autenticado ingrese a la página web de la agencia de

viajes.

Poscondición: Enviar el usuario y contraseña al correo electrónico del usuario no autenticado.

Identificador: RQ9 Nombre: Gestionar usuarios

FUNCIONAL

Descripción: La gestión de usuario permite la eliminación, creación, y el envío de mensajes, entre otras operaciones.

Categoría: Visible

Objetivo: Garantizar que el administrador tenga el control de los datos básicos del usuario, para futuras operaciones, como el envío de mensaje personalizado.

Alcance: Brinda una plataforma con la posibilidad de cambiar los datos de usuario, solo por el administrador.


Datos de entrada: Cuenta de Administrador.

Datos de Salida: Acceso a la plataforma de administrador.

Criterios de Aceptación: La gestión de usuario permite la eliminación, creación, entre otras operaciones y garantizar que el administrador tenga el control de los datos básicos del usuario, dando así la posibilidad de, por medio del administrador, cambiar los datos.

Precondición: el administrador debe autenticarse en el sistema.

Poscondición: acceso a la plataforma de administración de cuentas de usuario.

Identificador: RQ10 Nombre: Registrar compras de planes de turismo.

FUNCIONAL

Descripción: El registro de Compras es un libro auxiliar obligatorio de característica tributario. El registro se realiza en forma detallada, ordenada y cronológica de cada uno de los documentos de compras de los planes de viaje que registre diariamente.

Categoría: Visible

Objetivo: Garantizar una plataforma segura, en la cual los datos de las compras del cliente o usuario final no se perderán o se combinaran con la de otros.


Alcance: Brinda la posibilidad de hacer búsquedas o consultas en la base de datos de forma eficaz.

Datos de entrada: Datos de compra del plan y del usuario.

Datos de Salida: Registro completo

Criterios de Aceptación: al llevar un registro con todos los datos de las compras de cada cliente se evitan posibles errores en la transacción de datos.

Precondición: Plan de viaje (validado).

Poscondición: Planes Registrados totales.

El proceso de Definicion de la Arquitectura.doc

Documents

Transcript of El proceso de Definicion de la Arquitectura.doc