documento de arquitectura de software versión 1.1
TRANSCRIPT
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 1 of 15
< Sistema de control de pasajes y tiempos en sistema de transporte > Documento de Arquitectura de Software
Versión <1.1>
[Nota: La siguiente plantilla se proporciona para su uso con el Proceso Racional Unificado.]
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 2 of 15
Table of Contents
1. Introduction
1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview
2. Architectural Representation
3. Architecture In Use
4. Use-Case View
5. Logical View
6. components View
7. Implementation View
8. Data View (optional)
9. Size and Performance
10. Quality
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 3 of 15
Documento de Arquitectura de Software 1. Introducción
1.1 Purpose
El objetivo de la definición de la arquitectura, es generar la guía para el desarrollo de la aplicación, que
busca ejemplificar y hallar una solución al sistema propuesto. Manejara diferentes vistas de arquitectura
para así encontrar un punto medio para definir la estructura, organización y posterior implementación del
proyecto. Este documento está orientado al grupo de desarrollo y al grupo de gestión de cambios, asi como
para cualquiera de los interesados que desee leerlo.
Este documento de arquitectura de software tiene como propósito brindar una visión comprensible de la
arquitectura general del software planificación y control de pasajes y tiempos del sistema de transporte
utilizando diferentes vistas de la arquitectura para ilustrar diferentes aspectos del mismo
1.2 Scope
Se Delimitara el Alcance del Sistema hasta donde se involucra el Ambiente externo y personas que con el
interactúan, tanto usuarios finales como los interesados, se verán afectados por los resultados obtenidos al
implementar la arquitectura de software, aquí planteada. El sistema de Control de Pasajes y tiempos en sistema de transporte es una aplicación que sirve para el
proceso de control de registros de pasajes y tiempo, asignación de recursos, evaluación de labores y
seguimiento de labores internas del sistema entre otras.
1.3 Definitions, Acronyms, and Abbreviations
1.4 Se proveen algunas de las definiciones o términos, acrónimos y abreviaturas requeridas para interpretar
apropiadamente el Documento de Arquitectura de Software.
Recargar Tarjeta: Método que se emplea para cargar pasajes a un medio físico.
Sensor: Antena o Aparato físico que transmite y recibe datos.
Estación: Punto de parada de buses donde se recogen y se dejan pasajeros.
Torniquete: Medio físico que representa una registradora de usuarios del sistema.
Tiempo Promedio: Es la duración en tiempo que transcurre el bus en cada ruta o trayecto.
Caja o Taquilla: Medio en el cual se realiza una transacción de pago por cantidad de pasajes.
1.5 Overview
[En esta sección se describe el Documento de Arquitectura de Software su contenido y explica cómo el
Documento de Arquitectura de Software está organizado.]
Abstract:
This paper offers a brief description of the subsystems are there in the control system of passages and times
in the transport system, describing the different diagrams for modeling using this system and the integration
of requirements engineering.
Resumen:
Este documento cuenta con una breve descripción de los subsistemas con los que cuenta el Sistema de
control de pasajes y tiempos en sistema de transporte, describiendo los diferentes diagramas utilizando
para el modelado de este sistema y la integracion de la ingeniería de requisitos.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 4 of 15
2. Representación de la Arquitectura
Se describe lo que es la arquitectura de software para el sistema actual y la forma en que se representa.
En él se muestran los casos de uso, vista lógica, Vistas al proceso, implementación y ejecución, enumera
los puntos de vista que son necesarios, y para cada punto de vista, se explica qué tipos de elementos del
modelo que contiene.
A través de este subsistema se podrán registrar las actividades que se realizan así como la planificación de
las mismas y los componentes que interactúan en el sistema. También se podrá dar de baja a actividades
que ya no sean necesarias.
Objetivos Arquitectónicos y Restricciones
Se describe los requisitos de software y los objetivos que tienen un impacto significativo en la arquitectura
y el tipo de restricciones que presenta el sistema.
Requisitos de Software:
Que nuestra Arquitectura de software a implementar, preste óptimos atributos de calidad al sistema y los
muestre en funcionamiento mejorando los procesos tales como:
(Disponibilidad, Modificabilidad, Rendimiento, Seguridad, Testeabilidad y Facilidad de Uso.)
Restricciones del Sistema:
Son todos aquellos factores que no podemos manejar, que salen del alcance del sistema (Ambiente Externo
no manipulable) y además delimitan los requisitos específicos al implementar la arquitectura del sistema.
3. Arquitectura A Utilizar:
Para el caso del sistema Transporte, utilizaremos la arquitectura: N_CAPAS, N_NIVELES.
Utilizaremos una arquitectura de 4 capas (capa de presentación, capa de lógica del negocio, capa de acceso
a BD, capa de datos) y 2 niveles (aplicación, y datos).
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 5 of 15
Arquitectura a Utilizar:
4. Vista de Casos de Uso
A través de la vista de los casos de uso se realiza una definición del alcance funcional del producto
software en cada uno de los subsistemas funcionales que lo constituyen. De acuerdo a lo mostrado
anteriormente, este producto se encuentra organizado al más alto nivel en dos subsistemas funcionales.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 6 of 15
Casos de Uso del Usuario
REF Caso de Uso – Usuario Impacto en la Arquitectura
CS-US.1
Ingresar Estación Este caso de uso es realizado por el usuario el
cual ingresa al sistema de transporte masivo.
CS-US.2
Compra/ Recarga Tarjeta Este caso de uso es realizado por el usuario el
cual se dirige a la taquilla o caja a realizar la
acción de cargar pasajes.
CS-US.3
Pasar Tarjeta Por Torniquete Este caso de uso se ejecutara cuando el usuario
tenga la tarjeta ya cargada y se realice el ingreso
a la estación interactuando así con este medio
físico registrando su pasaje.
CS-US.4
Pasar a Zona de Transborde
Este caso de uso permitirá a los usuarios del
sistema de transporte poder escoger la ruta o
trayecto especifico.
CS-US.5
Ingresar al Bus Deseado
Este caso de uso permitirá al usuario abordar el
bus y llegar al lugar destino .
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 7 of 15
Casos de Uso del Torniquete
El propósito u objetivo de cada caso de uso y la importancia por su impacto en la arquitectura del software
se presenta a continuación.
REF Caso de Uso – Torniquete Impacto en la Arquitectura
CS-US.1
Validar que la Tarjeta tenga Pasajes Este caso de uso es realizado por torniquete o
medio físico el cual valida el # de pasajes
contenidos en la tarjeta.
CS-US.2
Permitir acceso Este caso de uso es realizado por el torniquete el
cual permite al usuario el acceso interactuando
así con este medio físico.
CS-US.3
Restar pasaje Este caso de uso se ejecutara en el torniquete
cuando el usuario tenga la tarjeta ya cargada y se
realice el ingreso a la estación descontando un
pasaje de la tarjeta.
CS-US.4
Guardar registro de ingreso
Este caso de uso se ejecuta en el torniquete cada
vez que un usuario culmine el proceso de pasar
tarjeta por torniquete y validando el pasaje a
descontar se guarda el registro de entrada del
usuario.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 8 of 15
Casos de Uso del Cajero
El propósito u objetivo de cada caso de uso y la importancia por su impacto en la arquitectura del software
se presenta a continuación.
REF Caso de Uso – Cajero Impacto en la Arquitectura
CS-US.1
Registrar Venta/Recarga Este caso de uso es realizado por el cajero el cual
registra el # de pasajes que se venden por día
según estación.
CS-US.2
Manejar Caja en horario establecido Este caso de uso es realizado por el cajero el cual
cobra los pasajes de precio diferente según
horario pico o valle.
CS-US.3
Recargar / vender pasajes Este caso de uso es realizado por el cajero el cual
registra el # de pasajes que van ir contenidos en
la tarjeta del usuario.
Casos de Uso Sensor Estación
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 9 of 15
El propósito u objetivo de cada caso de uso y la importancia por su impacto en la arquitectura del software
se presenta a continuación.
REF Caso de Uso – Sensor Estación Impacto en la Arquitectura
CS-US.1
Recibir Señal de los buses Este caso de uso es realizado por el sensor de la
estación el cual registra la señal y calcula el
tiempo que transcurre el bus en el trayecto de
ruta por cada estación existente.
CS-US.2
Generar Señal a los buses Este caso de uso es realizado por el sensor el
cual emite una señal al sensor de los buses para
triangular la posición del bus e informar el
tiempo que tarda el bus en llegar a la estación.
CS-US.3
Enviar Señal Este caso de uso es realizado por el sensor de la
Estación el cual envía respuesta a los portales
para dar salida a los buses con sus rutas
específicas.
Casos de Uso Bus
El propósito u objetivo de cada caso de uso y la importancia por su impacto en la arquitectura del software
se presenta a continuación.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 10 of 15
REF Caso de Uso – Sensor Bus Impacto en la Arquitectura
CS-US.1
Recibir Señal de la estación Este caso de uso es realizado por el sensor del
bus el cual captura la señal que emite las
estaciones del sistema.
CS-US.2
Generar Señal de ubicación Este caso de uso es realizado por el sensor del
bus el cual emite una señal al sensor de las
estaciones para triangular la posición del bus e
informar el tiempo que tarda el bus en llegar a la
estación.
CS-US.3
Enviar Señal Este caso de uso es realizado por el sensor del
bus el cual envía datos de respuesta a las
estaciones para dar respuesta de su llegada a
cada estación.
Casos de Uso Administrador del Sistema
REF Caso de Uso – Bus Impacto en la Arquitectura
CS-US.1
Para en estaciones según ruta Este caso de uso es realizado por el bus el cual
para en cada estación del trayecto de la ruta
específica.
CS-US.2
Recoger Pasajeros Este caso de uso es realizado por el bus el cual se
dirige a cada estación y realiza la acción de
cargar pasajeros abordar el bus.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 11 of 15
El propósito u objetivo de cada caso de uso y la importancia por su impacto en la arquitectura del software
se presenta a continuación.
5. Vista Lógica
La información correspondiente al diagrama de clases por el cual a través de él se realizará la
implementación del sistema software se organiza en torno a los módulos indicados en el diagrama de clases
que se muestra a continuación.
REF Caso de Uso – Administrador del Sistema Impacto en la Arquitectura
CS-US.1
Administrar Reportes
Este caso de uso es efectuado por el
Administrador del sistema de transporte por
estación el cual se encarga de validar, gestionar
e imprimir los reportes requeridos del sistema de
transporte.
REF Caso de Uso – Administrador del Sistema Impacto en la Arquitectura
CS-US.2
Administración de la Información de Rutas Este caso de uso es determinante en la creación
modificación o actualización de las rutas
existentes.
CS-US.3
Ingresar Información de Rutas En este caso de uso se ingresa la relación por día
de los buses con sus rutas correspondiente y su
trayecto por cada una de las estaciones.
CS-US.4
Eliminar Información de Rutas Este caso de uso se encarga de la depuración de
rutas que no son habilitadas por cambios o
modificaciones en el sistema de transporte.
CS-US.5
Administrar Información de Rutas Este caso de uso está facultado para registrar
todas las posibles gestiones que se realizan cada
día en cada estación existente.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 12 of 15
Diagrama de Clases del Sistema
6. Vista de Componentes
Diagrama de Componentes del Sistema
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 13 of 15
7. Vista de Implementación
[En esta sección se describe la estructura completa del Modelo de Implementación, la descomposición del
software en capas y subsistemas en el Modelo de Implementación, y cualquier componente
arquitectónicamente significativo.]
7.1 Generalidades
[Nombre y defina las diferentes capas y sus contenidos, las reglas que definen la inclusion de una capa deda
y la fronteras entre las diferentes capas (interfaces de integración) entre componentes de capas adyacentes.
Esta información será cubierta a través del Diagrama de Componentes. ]
7.2 Capas
[Se deberá proveer para cada capa una sección con su nombre y la enumeración de los subsistemas
asignados a la capa, así como un diagrama de componentes donde se muestren los componentes que
conforman la capa, las dependencias entre ellos. Las interfaces requeridas y proporcionadas por cada
componente, a fin de describir con suma precisión la integración.]
Diagrama de Implementación del Sistema
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 14 of 15
8. Vista de Datos
Modelo Entidad Relación del Sistema
Vista de los flujos de Información del Sistema de Transporte
Perspectiva del flujo de datos persistentes en el sistema.
<Project Name> Versión: <1.1>
Software Architecture Documento de Arquitectura de Software Date: <18/Noviembre/2012>
Elaborado por: Diego Alejandro Sánchez cód.: 10490522939
Publico <Company Name>, 2012 Page 15 of 15
9. Tamaño y Rendimiento
[Una descripción de las características principales de dimensionamiento del software que afectan la
arquitectura, así como las restricciones de rendimiento objetivo.]
Se ilustra la explotación de los requerimientos específicos y el refinamiento de estos requisitos.
El rendimiento se muestra en la obtención de los datos y la efectividad en la lógica de negocios.
El Sistema de transporte masivo se caracteriza por ser robusto en sus dimensiones además puede ser
flexible al momento de gestión de cambios en el software y puede ser actualizable según su
comportamiento.
10. Calidad
En este documento se describe la calidad del software como la satisfacción del cliente o los interesados del
proyecto a demás contribuye con las capacidades del sistema: extensibilidad, confiabilidad, portabilidad
para los operarios del sistema la flexibilidad al momento en que surge el control de cambios del sistema y
el eficiente manejo de la seguridad para evitar el filtrado de la información y la privacidad de los datos
más relevantes.
Historial de Revisión
Fecha: Versión Descripción Autor
<26/Septiembre/2012> <1.0> <Elaboración del Documento de Arquitectura.>
<Grupo de Ingenieria De Software II>
<17/Noviembre/2012> <1.1> <Corrección del Documento de Arquitectura.>
<Grupo de Ingenieria De Software II>