Sample [27/04/2020]

Software
Architecture
Document
[201]
[El siguiente documento se mostrara la descripción de la arquitectura de
software utilizada en el desarrollo del aplicativo de Reservas de Sitios Reservas de Sitios
Turísticos, además se verá el propósito y el alcance del dicho proyecto Turísticos
a continuación ]
Control de Cambios

Creación del documento

Seleccione
Autor Fecha
una Fecha

Nombre
Revisado Seleccione
Fecha
por una Fecha
Cargo

Aprobado Nombre Seleccione

Fecha
por Cargo una Fecha

Versión Descripción Autor Aprobado Por Fecha Aprobación

Seleccione una Fecha

Seleccione una Fecha

Página 2 de 10
TABLA DE CONTENIDO

1. INTRODUCCIÓN..............................................................................................................3
1.1 PROPÓSITO............................................................................................................................3
1.2 ALCANCE............................................................................................................................. 3
1.3 DEFINICIONES, SIGLAS Y ABREVIATURAS.....................................................................................3
1.4 REFERENCIAS........................................................................................................................ 3
1.5 VISTA GLOBAL...................................................................................................................... 3
2. MACRO ARQUITECTURA.................................................................................................3
2.1 METAS Y RESTRICCIONES ARQUITECTÓNICAS..............................................................................3
3. VISTA FÍSICA...................................................................................................................6
4. VISTA FUNCIONAL O LÓGICA..........................................................................................6
5. VISTA DE DESPLIEGUE....................................................................................................7

Página 3 de 10
1. Introducción

El presente documento contiene el diseño del sistema informático denominada:

“Implementación De Un Prototipo Para Reservas de Sitios Turísticos”, partiendo de los
requisitos definidos en la fase de análisis de requerimientos y tomando en cuenta estrictamente
las necesidades de información del sistema, en este documento se describen los atributos de
calidad y no se que mas poner

Se presentan las vistas, y lo necesarios para darles cumplimiento a los

requerimientos de los usuarios, los patrones de diseño que se utilizaron, son los

estándares de interfaces(creo).

2. Propósito

[Define el rol o propósito del DAS, dentro de la documentación del proyecto, y describe brevemente la estructura del
documento. Se identifica la audiencia para el documento, con una identificación de cómo se espera que sea
utilizado.]

El propósito de este documento es dar a conocer la arquitectura del aplicativo, utilizando las
vistas de procesos, logia y despliegue para dirigir al equipo de desarrollo

En este documento se va a presentar a través de diferentes vistas, las que mostrarán cada
una de las características particulares y propiamente dichas de la aplicación. Con esto, lo que
se propone es que por medio de este documento, se tenga una clara visión del diseño de este
proyecto, lo cual podría ser de mucha utilidad para la reserva de sitios turísticos.

Alcance

[Breve descripción de la aplicación del DAS; qué otro documento se ve afectado o influenciado por éste.]

Este documento se concreta de manera puntual, en el desarrollo de la vista lógica y de

implementación correspondiente a este primer Sprint (creo), que comprenderán de cierta
manera el resto de vistas a elaborarse en el proceso, así como también a la identificación de los
diferentes componentes pertenecientes a cada vista. Lo que concierne a los diferentes
componentes externos se anexa una descripción centralizada de los mismos, indicándose
referencias para su consulta.

En el documento se describe como se desarrollara los sistemas de reserva de sitios turísticos, el

cual gestiona la facilidad de visualizar los servicios ofrecidos por la empresa de turismo.
Además de esto el documento se especifican las restricciones, los atributos de calidad las vistas
arquitecturales y los patrones de diseño que se implementaran por parte del equipo de
desarrollo este aplicativo teniendo en cuenta el product backlog

Página 4 de 10
Definiciones, siglas y abreviaturas

[Esta subdivisión proporciona las definiciones de todos los términos, las siglas, y las abreviaciones necesarias para
interpretar apropiadamente el DAS. Esta información puede ser proporcionada a través de la referencia al Glosario
del Proyecto.]

Patrones: Soluciones comprobadas a problemas típicos. Aplicar patrones de diseño a software

aumenta la reusabilidad, la mantenibilidad, y la probabilidad de éxito.

MVC: modelo vista controlador

web service: es una tecnología que utiliza un conjunto de protocolos y estándares que sirven
para intercambiar datos entre aplicaciones.

Facade: es un tipo de patrón de diseño estructural. Viene motivado por la necesidad de

estructurar un entorno de programación y reducir su complejidad con la división en
subsistemas, minimizando las comunicaciones y dependencias entre estos.

Referencias

Documento Versión Fecha de la versión

Ingeniería del Software un enfoque práctico 7 2010
Roger S.Pressman
Product balolok 1.0 2018
Modelo 4+1 1995
Philippe Kruchten
Roger S. Pressman

Vista Global

[Esta subdivisión describe lo que contiene el resto del DAS y explica cómo el documento está organizado.]

Software Architecture Document, en primer

El documento se desarrolla y estructura en base a la plantilla
lugar se especifican las vistas necesarias, luego se encontrara los atributos de calidad y los
patrones asociados, y por último la diagramación del modelo arquitectural, representado
mediante las vistas previamente definidas.

Metas y Restricciones Arquitectónicas

[Se describen los requerimientos y objetivos del software que tienen un impacto significativo sobre la arquitectura:
portabilidad, distribución, reuso. Se capturan las restricciones especiales que pueden aplicar: estrategia de diseño e
implementación, herramientas de desarrollo, estructura del equipo, planificación, código “legacy”, etc.]

Puedes pegar los atributos

Atributos de Calidad “Observables”

Atributo de Calidad Descripción Tácticas /Patrón de Arquitectura Donde se aplica
Confidencialidad Es la ausencia de Patrón: Autorizador- Restricciones de
acceso no autorizado a Autenticador. operatividad de la
la información (Barbacci aplicación por
et al, 1995). Se realizará la implementación permisos sobre el

Página 5 de 10
 usuario de base de
de un mecanismo de datos a través del
autorización que provee acceso servicio web de
granular a la consulta por medio integración con el
de una integración con el PM PM.
(Profile Manager) quien
determina los roles y permisos
de los usuarios, de esta manera
solo se permitirá acceso
autorizado a la información a
través de este mecanismo.
Confiabilidad Es la medida de la Tácticas: Multi-Capa Aunque no es visible
habilidad de un sistema en el código a
a mantenerse operativo Mediante este patrón se está simple vista, se
a lo largo del tiempo propendiendo por la separó la división en
(Barbacci et al., 1995). confiabilidad del sistema, pues campas de acceso
al incrementar la mantenibilidad por medio de los
del sistema, hace que el atributo componentes que se
de confiabilidad sea mayor utilizan al
implementar la
solución y su detalle
funcional.
Desempeño Es el grado en el cual Patrón: Caché Uso de clases e
un sistema o interface DAO
componente cumple con Se establece la implementación
sus funciones del patrón DAO mediante el uso
designadas, dentro de de caché de los objetos.
ciertas restricciones
dadas, como velocidad, Patrón fachada de
exactitud o uso de Se separa la capa de servicio, que
memoria. (IEEE integración en componentes garantiza alto
610.12). independientes administrados rendimiento del
por un BRMS, eliminando la sistema
carga del proceso de las
aplicaciones proveedoras y
consumidoras de la información.

Atributos de Calidad “No observables”

Atributo Descripción Tácticas /Patrón de Donde se aplica
Arquitectura
Modificabilidad Es la habilidad de Patrón: GRASP Crea un puente de
realizar cambios comunicación entre el
futuros al sistema. Planteamiento modular del protocolo HTTP síncrono y
(Bosch et al. 1999). sistema, división por capas las aplicaciones existentes
lógicas de software con con interface que controlan la
responsabilidades definidas información entrante y
de cada capa y protocolos saliente que garantiza la
de comunicación entre granularidad del sistema y la
ellas utilizado en la no perdida de la información.
construcción de los
servicios web.
Mantenibilidad Es la capacidad de Patrón: Capas de software Propende a disminuir la alta
someter a un sistema cohesión de componentes
a reparaciones y Mediante este patrón para garantizar que todo el

Página 6 de 10
 evolución sistema es más dinámico y
permite que las adaptable a las necesidades
(Barbacci et al., 1995). modificaciones a los de expansión según lo
Capacidad de servicios web de requiera el sistema.
modificar el sistema de integración sean más
manera rápida y a bajo sencillas, dado que van a
costo (Bosch et al. puntos específicos del
1999). código.

Estandarización en el
nombramiento de tablas,
módulos, clases, métodos
de clase y variables a nivel
de diseño y programación.
Escalabilidad Es el grado con el que Se implementa un modelo Se aplica en la capa de
se pueden ampliar el arquitectural multicapa lógica de los componentes
diseño arquitectónico, donde la capa de lógica del sistema.
de datos o tiene la habilidad de
procedimental propender a una fácil
(Pressman, 2002). modificación para pasar de
una arquitectura web a una
capacidad de mejorar SOA por medio de la
recursos para ofrecer exposición de servicios
una mejora web.
(idealmente) lineal en
la capacidad de El uso de un ORM como
servicio Hibernate permite un
desarrollo independiente
del DBMS utilizado, por tal
motivo no hay dependencia
con el mismo y puede ser Comunicación con la base de
modificado en cualquier datos.
momento sin que esto
afecte en un alto grado a la
aplicación.
Variabilidad Es el grado en el que Las parametrizaciones de Las configuraciones
se puede adicionar o la consulta, los accesos a requeridas para la aplicación
modificar base de datos se están consolidadas en
funcionalidades de un encuentran en archivos de archivos de texto
software para ser texto independientes de las independientes de las clases
usado en un contexto unidades de código que las ejecutan.
en particular. permitiendo así cambios
rápidos sin impactar
drásticamente las unidades
ya desplegadas.

La separación por
componentes de las La estrategia utilizada
unidades de código permite incluir nuevos
pertenecientes a cada capa componentes de manera
permite cambios rápidos rápida y sin impactar
sin impactar drásticamente drásticamente la solución ya
las unidades ya desarrollada.
desplegadas.

Página 7 de 10
Disponibilidad La capacidad de que Patrón: Sincronización de Se implementa comunicación
el sistema esté total o estado síncrona mediante una
parcialmente operativo verificación de disponibilidad
al mismo tiempo que Mediante la verificación de de los WS.
es requerido para disponibilidad del estado de
manejar eficazmente los servicios web, el
las fallas que puedan sistema sabe cuándo
afectar la puede o no operar. En caso
disponibilidad del de no haber conexión el
sistema. sistema indica mediante un
mensaje al usuario que la
conexión con los servicios
de autorización de ingreso
o de validación de datos
que no dependen de la
aplicación, sino que son
componentes externos, no
están disponibles.

Facilidad de Capacidad de Patrón: Integración Gracias a los clientes de los

integración comunicación con orientada a servicios. servicios web que la
otros sistemas aplicación implementa, se
Mediante el uso de los logra la comunicación con
servicios web que contiene diversas fuentes de
la aplicación se plantea la información.
comunicación con
diferentes fuentes de
información.

Patrón: BRMS.
Permite la posibilidad de
integración basada en
buenas prácticas que
facilitan el proceso
mediante el uso de un
motor de reglas de
negocio.

La arquitectura del sistema está representada siguiendo las recomendaciones de

Las vistas necesarias para especificar el sistema se presentan, a continuación:

Vista Lógica: Describe la arquitectura del sistema, presentando varios niveles de refinamiento. Indica los módulos
lógicos principales, sus responsabilidades y dependencias.

Vista de Procesos: Describe los procesos concurrentes del sistema.

Vista de física: Describe los componentes de despliegue construidos y sus dependencias.
Vista de Despliegue: Presenta aspectos físicos como topología, infraestructura informática e instalación de
ejecutables.
La arquitectura sigue el framework "4+1" presentando el [KRUTCHEN], este
framework define cuatro vistas para la arquitectura en conjunto con los escenarios

Página 8 de 10
3. Vista Física

[Es la distribución física de la aplicación, una descripción del sistema y su interacción] [Vista Obligatoria]

Diagrama de despliegue
El diagrama de despliegue muestra las relaciones físicas entre los componentes software y
hardware del sistema. En el diagrama de despliegue siguiente se muestran # nodos: la persona
y el servidor, aunque en la práctica pueden existir más de un persona opcional ustedes verán.
Estos nodos se comunican a través de Internet mediante http supondré.
El diagrama anterior muestra la ubicación física de cada uno de los componentes software del
sistema. Se aprecia que casi todos los componentes residen en el servidor, disposición típica de
una arquitectura cliente ligero supongo.

4. Vista Funcional o Lógica

[Se describe la descomposición del sistema dentro de procesos y grupos de procesos. Se debe organizar la sección
por grupos de procesos donde se reflejen sus comunicaciones o interacciones. Describa primero los principales
modos de comunicación entre procesos, tales como: pases de mensajes, etc. Para cada red de procesos se debe
incluir una subsección con la siguiente información:
Su nombre.
Los procesos involucrados.
Las interacciones entre los procesos en la forma de diagramas de colaboración, en los cuales los objetos son los
procesos reales que completan su propio vínculo de control. Para cada proceso, describa brevemente su
comportamiento, su ciclo de vida y sus características de comunicación.]

Aunque tradicionalmente se utilizan diagramas de secuencia o de colaboración para esta representación, también
puede representarse de manera genérica mediante un diagrama de manifestación el cual cumple como objetivo
mostrar la relación de dependencia entre los distintos componentes del sistema sin llegar a mostrar la vista completa
de despliegue. ] [Vista opcional dependiendo de las necesidades a resolver y la perspectiva del cliente]

se incluye el diagrama de secuencia que describe la interacción ente los componentes para
realizar el caso de uso en cuestión

5. Vista de Despliegue

[Se describe una o más configuraciones de redes físicas (hardware) sobre las cuales el software será desarrollado.
Para cada configuración, se debe indicar los nodos físicos (computadores, CPUs) que ejecutan el software, y sus
interconexiones (bus, LAN, punto a punto, etc.). También se incluye un mapa de los procesos de la vista de
procesos, dentro de los nodos físicos. Para cada configuración física de red incluya una subsección con la siguiente
información:
Su nombre.
Un diagrama de entrega que ilustre la configuración, seguida por un mapa de procesos para cada procesador.]

Puede representarse mediante el siguiente artefacto: Diagrama de despliegue.

[Vista opcional dependiendo de las necesidades a resolver y la perspectiva del cliente]

El diagrama de Componentes muestra los módulos en los que estará dividida la

Funcionalidad del sistema. Los conectores identifican la relación entre los mismos.

Página 9 de 10
La aplicación cuenta con módulos claramente definidos los cuales acceden al modelo de datos
único de la solución. Los módulos se dividen en

Página 10 de 10