Sisevp Ic

SISEVP
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

ESCUELA ACADEMICA PROFESIONAL DE INGENIERIA DE
SISTEMAS
Sistema de Estacionamiento Vehicular
Para la Playa de
San Pedro - Lurn
Curso : Ingeniera de Control
Profesor: Armando Fermn Prez
Alumnos: Alan Alvarado Barzola
Erick Chipana Ramos
John Quispe Palomino
Juan Carlos LLacza Torres
SISEVP
Versin: 2.0
Documento de la Arquitectura de Software Fecha: 02/Julio/14
Confidencial SISEVP, 2014 Pgina 2 de 23
Tabla de Contenidos
1. Introduccin 3
1.1 Propsito 3
1.2 Alcance 3
1.3 Definiciones, Siglas, y Abreviaciones 3
1.4 Referencias 3
1.5 Vista Global 3
2. Representacin Arquitectnica 3
3. Metas y Restricciones Arquitectnicas 4
4. Vista de Casos de Uso 5
5. Vista Lgica 7
5.1 Modelo Conceptual 7
5.2 Diagrama de Clases 8
6. Vista de Implantacin 16
7. Vista de Implementacin 17
8. Vista de Datos 20
8.1 Diagrama Entidad-Relacin 20
8.2 Tamao y Desempeo
9. Calidad 21
10. Aplicacin de la Computacin Autonmica 22
SISEVP
Versin: 2.0
Documento de la Arquitectura del Software
1. Introduccin
Este documento proporciona una amplia descripcin arquitectnica del sistema a ser implementado en la
Playa San Pedro de Lurn y en la municipalidad de Lurn, mediante la utilizacin de un nmero variado de
vistas arquitectnicas que permiten representar los distintos aspectos del sistema SISEVP. La intencin es
capturar y comunicar las decisiones arquitectnicas significativas que se han realizado sobre el sistema.
1.1 Propsito
Se mostrar la arquitectura del sistema empleando el modelo de las 4 + 1 vistas pertenecientes a la
metodologa RUP. En cada una de las vistas se detallarn las decisiones que se tomaron respecto a ellas.
1.2 Alcance
Automatizar los procesos de la gestin de estacionamiento vehicular en las playas de San Pedro - Lurn,
mediante un sistema de informacin.
Para poder reducir los costos de la gestin de estacionamiento y as poder incrementar los ingresos.
1.3 Definiciones, Siglas, y Abreviaciones
SISEVP : Sistema para Estacionamiento Vehicular para Playa.
1.4 Referencias
Se hace referencia al documento de visin, especificacin de casos de uso, el documento de secuencia,
diagrama de estados y el diagrama de navegabilidad.
1.5 Vista Global
Este documento se basa en la representacin de arquitectura del sistema, para lo cual se especifican cada
una de las vistas: casos de uso, lgica, de procesos, de despliegue, de implementacin y de datos.
Adicionalmente, contiene las restricciones del sistema con respecto a la arquitectura, sus metas, una breve
descripcin de las dimensiones del producto, al igual que todo lo relacionado con el desempeo y calidad
de plataformas y portabilidad, entre otros.
2. Representacin Arquitectnica
Siguiendo la metodologa RUP se va a implementar una arquitectura de 4 + 1 vistas para
el sistema de resolucin de casos. A continuacin se describe en que consiste cada una
de estas vistas.
Vista Lgica: Constituye el modelo conceptual del sistema a travs de los
subsistemas, clases e interfaces ms importantes y las relaciones entre estos
componentes.
Vista de Proceso: En esta vista se muestra la concurrencia entre los procesos e
hilos que conforman el sistema.
Vista de Implementacin: Es un resumen de la organizacin de los entregables y
de los cdigos
fuentes que se generan a partir de estos.
Vista de Implantacin: Lo constituye la distribucin del software en el hardware,
as como los requisitos funcionales a nivel de escalabilidad, confiabilidad y
respuesta.
Vista de Casos de Uso: Est constituida por los casos de uso o escenarios del
sistema. Se basa en las 4 vistas anteriores.
SISEVP
Versin: 2.0
3. Metas y Restricciones Arquitectnicas
Plataforma Tcnica: El sistema de resolucin de casos es desarrollado con PHP como lenguaje
de programacin y se encuentra en un servidor web Apache Tomcat, as como un manejador de
bases de datos MySQL Server. El servidor debe tener en consideracin posibles fallas de
electricidad, con el fin que la aplicacin no cese su funcionamiento por culpa de stas.
La comunicacin entre los equipos de la playa y los equipos de la municipalidad se realizarn a
travs de una conexin LAN Inalmbrica conformada por una antena emisora para la
transmisin en la playa y una antena receptora ubicada en la municipalidad.
Seguridad: Dado que distintos tipos de usuarios pueden acceder al sistema, es necesario
establecer niveles de privilegios, y por tanto establecer un sistema de acceso a sesiones mediante
un login para cada usuario con su respectivo password.
Persistencia de Datos: Una de las principales metas del sistema es garantizar que la
informacin registrada por los encargados de registro en los registros de ingreso, perdure en el
tiempo. Para ello es importante contar con un buen manejo de la base de datos, y respaldos de
los mismos.
Las restricciones halladas durante el desarrollo del proyecto son:
Restricciones de tiempo: existe una fecha de entrega fijada que apresura los procesos de
desarrollo.
Restricciones de interfaz: el desarrollo de la misma estar regido por las normas que imponga
la Municipalidad de Lurn.
Restricciones en la metodologa: SISEVP utiliza la metodologa de RUP para el desarrollo de
los documentos y diagramas.
Sistema de Estacionamiento Vehicular para la Playa de San Pedro - Lurn
Versin: 1.0
Documento de la Arquitectura de Software Fecha: 02/07/14
SISEVP_Doc_Architec.doc
Confidencial SISEVP, 2014 Pgina5 de 23
4. Vista de Casos de Uso
Descripcin del
negocio
Actores Modelo del
dominio
Casos de Uso
4.1. Descripcin del Negocio
El negocio se basa en el funcionamiento de una playa de estacionamiento vehicular en este caso de la playa de San Pedro-Lurn.
Los clientes se dirigen con sus vehculos a la playa de estacionamiento con el fin de que les deje ingresar a la playa. El encargado de cobro
toma los datos del vehculo y en especial la hora de ingreso y entrega ticket al cliente. El ayudante del encargado de cobro levanta la
cuerda y deja pasar al vehculo. Cuando un cliente se quiere retirar se dirige hacia salida y entrega el ticket al encargado de cobro el
calcula el tiempo y cobra lo que corresponde. Al final del da los encargados de cobro llevan todo el importe recaudado en el da y los
tickets registrados al liquidador. El liquidador verifica el importe recibido con los tickets recibidos. El liquidador ni bien calculado el
importe entrega todo al subgerente quien lo verifica ltimo y lo registra con esto se obtendra los ingresos diarios en la playa.
Versin: 1.0
Ver el documento Especificacin de Casos de Uso en la seccin 1.4 Referencias
Versin: 1.0
5. Vista Lgica
5.1 Modelo Conceptual
Versin: 1.0
5.2 Diagrama de Clases
Versin: 1.0
5.3. Interfaz de Usuario
REGISTRAR INGRESO
Versin: 1.0
REGISTRAR COBRO
Versin: 1.0
Versin: 1.0
VERIFICAR MONTO DE COBRADOR
Versin: 1.0
Versin: 1.0
VERIFICAR MONTO DE LIQUIDADOR
Versin: 1.0
Versin: 1.0
6. Vista de Implantacin
La vista de implantacin presenta la infraestructura necesaria para la utilizacin de nuestro
sistema.
Considerando la distribucin de la aplicacin, es posible identificar tres tipos de nodos: Pc Cliente,
Servidor Web, Servidor Bases de datos.
El nodo de Pc Cliente representa a las estaciones de trabajo de los usuarios finales de la
aplicacin, estos son en total 4 equipos (2 para el Encargado Cobro y 2 para el Encargado de
Registro).
El nodo Servidor Web representa aquel equipo donde correr el servidor Web y las aplicaciones
de nuestro sistema.
El ltimo nodo, Servidor Bases de Datos, representa el sistema donde se encuentra nuestro
manejador de base de datos y todas las tablas que la conforman.
Figura 7.1: Vista de Despliegue.
Las estaciones de trabajo de los usuarios (Pc Cliente) deben contar con un browser.
Hay solo una instancia del nodo Servidor la cual centraliza todos los requerimientos de los
clientes, debe ser servidor de aplicaciones PHP.
Dentro de la instancia Servidor de Bases de Datos el cual se encarga de la distribucin de los datos segn las
peticiones que vallan llegando del servidor.
Versin: 1.0
7. Vista de Implementacin
En esta vista se plantea la organizacin de cada uno de los componentes de nuestro sistema. Estos
son organizados en jerarqua de capas, en donde cada capa provee una interfaz o fachada bien definida para
las capas superiores. En nuestro sistema podemos distinguir tres diferentes procesos que interactan entre si
a travs del sistema.
1. Interfaz grfica
Aqu encontramos todas nuestras diferentes paginas Web que son las encargadas en de la
comunicacin con los diferentes usuarios de nuestro sistema. Dentro de esta capa tambin encontramos una
fachada encargada de comunicarse con los diferentes paquetes de la capa de negocios, facilitando as el
entendimiento entre capas y la comunicacin con el usuario.
Nuestro sistema es una aplicacin basada principalmente en la Web. A nivel de usuario final,
existe una interaccin continua con el browser el cual se encargar de presentar al usuario, la interfaz de la
aplicacin y de enviarle al servidor las diversas solicitudes que el usuario realiza.
Por el lado del servidor, para poder ejecutar las pginas PHP, es necesario un servidor Web con un
contenedor Web que cumpla con las especificaciones de PHP y del Controlador. Para puntualizar, se
requiere algn servidor de aplicaciones PHP. Un servidor de aplicaciones es un software que ayuda al
servidor Web a procesar las pginas que contienen scripts etiquetas del lado del servidor. Cuando un
navegador solicita una pgina de este tipo, el servidor Web remite la pgina al servidor de aplicaciones para
su procesamiento antes de enviarla al navegador.
El servidor Web recibe las solicitudes del usuario y las redirige a las pginas dinmicas ubicadas
en la capa de Interfaz. El servidor web asocia a cada usuario con la informacin de sesin y es el quien se
encarga de gestionar la atencin a mltiples clientes en forma simultnea.
2. Lgica de negocio
Dentro de nuestra capa de negocios tenemos las diferentes clases que nos permiten manejar el
recibimiento y tratamiento de las distintas peticiones y realizar eficazmente las diferentes acciones que
ejecutan nuestro sistema, incluyendo en ellas todos los mtodos que cumplan nuestros ya establecidos
contratos.
Dado que nuestro sistema se desarrolla bajo un ambiente Cliente-Servidor sobre tecnologa Web,
usando pginas de servidor Apache (PHP). Para la realizacin de las tareas todas estas clases se encuentran
desarrolladas bajo el ambiente PHP.
Para un mejor manejo de nuestro programa, estas clases se encuentran agrupadas en diferentes
paquetes segn las distintas funciones que realiza nuestro sistema.
3. Acceso de datos
Para ejecutar los diferentes paquetes que conforman nuestro sistema es necesario interactuar con
una base de datos a cada momento. Para todo el desarrollo de la base de datos usamos un manejador de
Base de Datos como lo es MySQL.
Una aplicacin Web no puede conectarse directamente con una base de datos. Hace falta una
interfaz de software entre la aplicacin Web y la base de datos que haga posible el dilogo entre ambas.
Una aplicacin PHP puede conectarse con una base de datos mediante una interfaz. Esta interfaz acta
como un intrprete o traductor que permite a la aplicacin PHP comunicarse con una base de datos
utilizando el lenguaje SQL.
Versin: 1.0
Dentro de esta capa se encuentra una de las principales clases de nuestro sistema como lo es el
manejador de base de datos, el cual ser el encargado de crear una comunicacin entre los objetos de la
capa de negocios y los de la capa de datos.
Figura de las 3 capas o paquetes que conforman nuestro programa
Versin: 1.0
Versin: 1.0
8. Vista de Datos
8.1 Diagrama Entidad-Relacin
Versin: 1.0
8.2 Tamao y Desempeo
Tamao: Considerando que el sistema va a ser utilizado principalmente por el personal de
la Municipalidad de Lurn, el volumen de conexiones simultneas al sistema que se esperan
no es tan grande, incluso durante las horas pico, es probable que este nmero no exceda
las 10 conexiones simultneas.
Desempeo: El sistema debe presentar los resultados de las consultas en un tiempo
razonable, digamos no ms de 0.5 seg.
9. Calidad
Escalabilidad: El sistema debe poder soportar varias conexiones simultneamente, esto se
logra mediante el soporte de concurrencia del servidor web.
Confiabilidad y disponibilidad: Es importante que el sistema se mantenga en
funcionamiento las 24 horas, todos los das, para ello hay que garantizar que no caiga ante
fallas de electricidad, etc. Esto se logra mediante instalaciones en la planta fsica en donde se
van ubicar los servidores, as como mediante equipos (UPS, etc) que aseguren que el
servicio se mantenga arriba incluso durante una falla elctrica.
Portabilidad: Debido al uso de PHP, MySQL, el sistema puede ser migrado fcilmente a
cualquier otro servidor en caso de ser necesario, ya que estas herramientas funcionan bajo
cualquier sistema operativo.
Seguridad: PHP provee libreras para implementar los requisitos de seguridad del sistema,
tales como creacin de certificados, cifrado de datos, entre otros.
Modificable y mejor manejo de fallas: El sistema SISEVP cuenta con una arquitectura
basada en componentes, la cual es una de las prcticas de desarrollo de software ms
recomendadas hoy en da. Dicha arquitectura basada en componentes permite un mejor
manejo y correccin de fallas en el sistema sin modificar o afectar gran parte del mismo.
Es decir, podemos modificar solo aquellos componentes que produzcan la falla sin tener que
modificar otros componentes del sistema.
Expandible: La arquitectura basada en componentes tambin permite que el sistema sea
expandible. A la hora de ser necesaria la inclusin de una nueva funcionalidad al sistema, se
puede implementar un nuevo componente e integrarlo a la arquitectura sistema.
Versin: 1.0
10. Aplicacin de la Computacin Autonmica
Los sistemas de computacin autonmica son aquellos que tienen la capacidad de gestionarse por s
mismos y adaptarse de forma dinmica a los cambios, de acuerdo con las reglas de negocio y
los objetivos existentes. Los sistemas autogestionados pueden llevar a cabo actividades de
gestin basadas en situaciones que ellos mismos perciben u observan dentro del entorno IT. En
vez de ser los profesionales del IT quienes inicien las actividades de gestin, es el sistema el
que se observa a si mismo y acta consecuentemente.
Esto le permite al profesional IT centrarse en otras tareas de alto valor mientras que la tecnologa es
la que gestiona las operaciones ms mundanas.
10.1. Auto-proteccin
El objetivo de la auto-proteccin es la de permitir que el entorno IT proporcione
la informacin exacta a los usuarios correctos en el momento oportuno, a travs
de acciones que garanticen un acceso a la informacin en funcin del rol del usuario y
de las polticas de seguridad preestablecidas con anterioridad. Un entorno IT dotado
de auto-proteccin puede detectar comportamientos hostiles o intrusivos dentro del sistema
y ejecutar las acciones necesarias para protegerse de los intentos no autorizados de
acceso, de los virus, de los ataques de denegacin de servicio, y de los fallos en general.
La capacidad de auto-proteccin permite a las empresas ejecutar de forma consistente
polticas de seguridad y privacidad, reducir los costes de administracin de seguridad La
auto-proteccin tambin se encarga de tareas relacionadas con la prevencin de
condiciones que puedan sobrecargar el sistema y poner en peligro la integridad del mismo.
Caso 1:
En caso que nuestro sistema detecte que un usuario est intentando acceder AL
SISTEMA y no lo consigue en 3 intentos, entonces se proceder a bloquear a ese usuario
y luego se realizar un reporte al administrador del sistema que corresponda.
Solucin planteada:
Uso de los componentes DOCTRINE o PHPILLOW para PHP adems de la seguridad
reforzada proporcionada por DB2.
Caso 2:
En caso que nuestro sistema detecte que existen demasiadas peticiones desde una
misma IP en un corto periodo de tiempo, entonces dicha IP ser bloqueada.
Solucin planteada:
Uso de un componente sensor que se encargue de monitorear el log del servidor, se
utilizar modelos matemticos para realizar acciones de proteccin.
Caso 3:
En caso que nuestro sistema detecte que un usuario del sistema est intentando hacer
sql injection en la base de datos, se proceder a cerrar la sesin de dicho usuario y
bloquearlo, luego esto se reportar al Administrador del Sistema.
Versin: 1.0
Solucin planteada:
Aplicacin de las propiedades autonmicas de la base datos DB2.
10.2. Auto-reparacin
Los entornos IT dotados de auto-recuperacin pueden detectar operaciones incorrectas
(bien proactivamente a travs de predicciones o bien de otras formas) e iniciar a
continuacin las acciones correctivas oportunas sin afectar al correcto funcionamiento de
las aplicaciones del sistema. Una accin correctiva podra significar que un elemento
altere su propio estado o influya sobre otros elementos del entorno provocando cambios
en ellos. Las operaciones del da a da de la empresa no deben tambalearse o fallar
por culpa de diversos eventos a nivel de componentes. El entorno IT debe hacerse ms
resistente y fiable gracias a que los cambios llevados a cabo reducen o ayudan a
eliminar el impacto sobre el negocio tras un fallo de un componente.
Caso 1:
En caso que nuestro sistema detecte que se perdi la conexin a la base de datos, se
proceder a reconectarlo automticamente hasta conseguir xito, mientras tanto los datos
de la transaccin se guardarn en sesin, una vez restaurada la conexin se continuar
con la ejecucin de la transaccin, de esta manera aseguramos que no se pierda la
informacin de la transaccin en proceso.
Solucin planteada:
Uso de componentes de DB2 Touchpoint Simulator y HADR.
10.3. Auto-Configuracin
Gracias a la capacidad de auto-configuracin al vuelo de un sistema, un
entorno IT puede adaptarse inmediatamente, y con la mnima intervencin humana
posible, al despliegue de nuevos componentes o cambios en el propio entorno. La
adaptacin dinmica ayuda a verificar de forma continua la fortaleza y la productividad de
la infraestructura e-business, a menudo el nico factor determinante entre
el crecimiento del negocio o el caos.
Caso 1:
En caso de que la variable que almacena la cantidad de usuarios registrados en la playa
llega a su nivel mximo (460), el sistema se autoconfigurar para no permitir ms registros
de ingreso.
Solucin planteada:
Creacin de un Componente el manejo de la variable.

Sisevp Ic

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sisevp Ic

Uploaded by

Copyright:

Available Formats

SISEVP

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

You might also like