documento de arquitectura de software versión 1.1

<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 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.]





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





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.





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).





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.





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 .





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.





Casos de Uso del Cajero



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







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







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.







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.





Diagrama de Clases del Sistema

6. Vista de Componentes

Diagrama de Componentes del Sistema





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





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.





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>

documento de arquitectura de software versión 1.1

Documents

arquitectura y

este sistema y

sistema actual y

software para

desarrollo y

pasajes y tiempos en

que nuestra arquitectura

que es