SISEVP

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

ESCUELA ACADEMICA PROFESIONAL DE INGENIERIA DE
SISTEMAS
Sistema de Estacionamiento Vehic!a"
Pa"a !a P!a#a de
San Ped"o $ L"%n&
C"so ' In(enie"%a de Cont"o!
P"o)eso"' A"mando Fe"m%n P*"e+
A!mnos' A!an A!,a"ado -a"+o!a
E"ic. Chi/ana Ramos

0ohn 1is/e Pa!omino

0an Ca"!os LLac+a To""es

SISEVP
Versin: 2.0
Documento de la Arquitectura de Software Fecha: 02!ulio"#
Tabla de Contenidos
". Introduccin
"." Pro$sito
".2 Alcance
".% Definiciones& Si'las& ( A)re*iaciones
".# +eferencias
"., Vista -lo)al
2. +e$resentacin Arquitectnica
%. .etas ( +estricciones Arquitectnicas
#. Vista de /asos de 0so
,. Vista 1'ica
,." .odelo /once$tual
,.2 Dia'rama de /lases
2. Vista de Im$lantacin
3. Vista de Im$lementacin
4. Vista de Datos
4." Diagrama Entidad-Relacin
4.2 5ama6o ( Desem$e6o
7. /alidad
"0. A$licacin de la /om$utacin Autonmica 22
/onfidencial SISEVP& 20"# P8'ina 2 de 2,
SISEVP
Versin: 2.0
Documento de la Arquitectura de Software Fecha: 02!ulio"#
Docmento de !a A"2itect"a de! So)t3a"e
1. Introduccin
Este documento $ro$orciona una am$lia descri$cin arquitectnica del sistema a ser im$lementado en la
Pla(a San Pedro de 1ur9n ( en la munici$alidad de 1ur9n& mediante la utili:acin de un n;mero *ariado de
*istas arquitectnicas que $ermiten re$resentar los distintos as$ectos del sistema SISEVP. 1a intencin es
ca$turar ( comunicar las decisiones arquitectnicas si'nificati*as que se han reali:ado so)re el sistema.
1.1 Propsito
Se mostrar8 la arquitectura del sistema em$leando el modelo de las # < " *istas $ertenecientes a la
metodolo'9a +0P. En cada una de las *istas se detallar8n las decisiones que se tomaron res$ecto a ellas.
1.2 Alcance
Automati:ar los $rocesos de la 'estin de estacionamiento *ehicular en las $la(as de San Pedro = 1ur9n&
mediante un sistema de informacin.
Para $oder reducir los costos de la 'estin de estacionamiento ( as9 $oder incrementar los in'resos.
1.3 Definiciones, Silas, ! Abre"iaciones
SISEVP : Sistema $ara Estacionamiento Vehicular $ara Pla(a.
1.# $eferencias
Se hace referencia al documento de *isin& es$ecificacin de casos de uso& el documento de secuencia&
dia'rama de estados ( el dia'rama de na*e'a)ilidad.
1.% Vista &lobal
Este documento se )asa en la re$resentacin de arquitectura del sistema& $ara lo cual se es$ecifican cada
una de las *istas: casos de uso& l'ica& de $rocesos& de des$lie'ue& de im$lementacin ( de datos.
Adicionalmente& contiene las restricciones del sistema con res$ecto a la arquitectura& sus metas& una )re*e
descri$cin de las dimensiones del $roducto& al i'ual que todo lo relacionado con el desem$e6o ( calidad
de $lataformas ( $orta)ilidad& entre otros.
2. $epresentacin Ar'uitectnica
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 (ica) onstitu!e el modelo conceptual del sistema a trav"s de los
subsistemas# clases e inter$aces m%s importantes ! las relaciones entre estos
componentes.
Vista de Proceso) &n esta vista se muestra la concurrencia entre los procesos e
'ilos que con$orman el sistema.
Vista de I*ple*entacin) &s un resumen de la organi(acin de los entregables !
de los cdigos
$uentes que se generan a partir de estos.
Vista de I*plantacin) )o constitu!e la distribucin del so$t*are en el 'ard*are#
as como los requisitos $uncionales a nivel de escalabilidad# con$iabilidad !
respuesta.
Vista de Casos de +so) &st% constituida por los casos de uso o escenarios del
sistema. Se basa en las 4 vistas anteriores.
/onfidencial SISEVP& 20"# P8'ina % de 2,
SISEVP
Versin: 2.0
Documento de la Arquitectura de Software Fecha: 02!ulio"#
3. ,etas ! $estricciones Ar'uitectnicas
> P!ata)o"ma T*cnica' El sistema de resolucin de casos es desarrollado con P?P como len'ua@e
de $ro'ramacin ( se encuentra en un ser*idor we) A$ache 5omcat& as9 como un mane@ador de
)ases de datos .(SA1 Ser*er. El ser*idor de)e tener en consideracin $osi)les fallas de
electricidad& con el fin que la a$licacin no cese su funcionamiento $or cul$a de Bstas.
1a comunicacin entre los equi$os de la $la(a ( los equi$os de la munici$alidad se reali:ar8n a
tra*Bs de una coneCin 1AD Inal8m)rica conformada $or una antena emisora $ara la
transmisin en la $la(a ( una antena rece$tora u)icada en la munici$alidad.
> Se("idad' Dado que distintos ti$os de usuarios $ueden acceder al sistema& es necesario
esta)lecer ni*eles de $ri*ile'ios& ( $or tanto esta)lecer un sistema de acceso a sesiones mediante
un lo'in $ara cada usuario con su res$ecti*o $assword.
> Pe"sistencia de Datos' 0na de las $rinci$ales metas del sistema es 'aranti:ar que la
informacin re'istrada $or los encar'ados de re'istro en los re'istros de in'reso& $erdure en el
tiem$o. Para ello es im$ortante contar con un )uen mane@o de la )ase de datos& ( res$aldos de
los mismos.
1as restricciones halladas durante el desarrollo del $ro(ecto son:
> Rest"icciones de tiem/o' eCiste una fecha de entre'a fi@ada que a$resura los $rocesos de
desarrollo.
> Rest"icciones de inte")a+' el desarrollo de la misma estar8 re'ido $or las normas que im$on'a
la .unici$alidad de 1ur9n.
> Rest"icciones en !a metodo!o(%a' SISEVP utili:a la metodolo'9a de RUP $ara el desarrollo de
los documentos ( dia'ramas.
/onfidencial SISEVP& 20"# P8'ina # de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
#. Vista de Casos de +so
+escripcin del
negocio
Actores ,odelo del
dominio
asos de Uso
#.1. Descripcin del -eocio
El ne'ocio se )asa en el funcionamiento de una $la(a de estacionamiento *ehicular en este caso de la $la(a de San Pedro=1ur9n.
1os clientes se diri'en con sus *eh9culos a la $la(a de estacionamiento con el fin de que les de@e in'resar a la $la(a. El encar'ado de co)ro
toma los datos del *eh9culo ( en es$ecial la hora de in'reso ( entre'a ticFet al cliente. El a(udante del encar'ado de co)ro le*anta la
cuerda ( de@a $asar al *eh9culo. /uando un cliente se quiere retirar se diri'e hacia salida ( entre'a el ticFet al encar'ado de co)ro el
calcula el tiem$o ( co)ra lo que corres$onde. Al final del d9a los encar'ados de co)ro lle*an todo el im$orte recaudado en el d9a ( los
ticFets re'istrados al liquidador. El liquidador *erifica el im$orte reci)ido con los ticFets reci)idos. El liquidador ni )ien calculado el
im$orte entre'a todo al su)'erente quien lo *erifica ;ltimo ( lo re'istra con esto se o)tendr9a los in'resos diarios en la $la(a.
/onfidencial SISEVP& 20"# P8'ina, de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
Ver el documento Es$ecificacin de /asos de 0so en la seccin ".# +eferencias
/onfidencial SISEVP& 20"# P8'ina2 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
/onfidencial SISEVP& 20"# P8'ina3 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
%. Vista (ica
%.1 ,odelo Conceptual
/onfidencial SISEVP& 20"# P8'ina4 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
%.2 Diara*a de Clases
/onfidencial SISEVP& 20"# P8'ina7 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
%.3. Interfa. de +suario
REGISTRAR INGRESO

/onfidencial SISEVP& 20"# P8'ina"0 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
$E&IST$A$ C/0$/
/onfidencial SISEVP& 20"# P8'ina"" de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc

/onfidencial SISEVP& 20"# P8'ina"2 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
VERIFICAR MONTO DE CO-RADOR
/onfidencial SISEVP& 20"# P8'ina"% de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
/onfidencial SISEVP& 20"# P8'ina"# de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
VERIFICAR MONTO DE LI1UIDADOR
/onfidencial SISEVP& 20"# P8'ina", de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
/onfidencial SISEVP& 20"# P8'ina"2 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
1. Vista de I*plantacin
1a *ista de im$lantacin $resenta la infraestructura necesaria $ara la utili:acin de nuestro
sistema.
/onsiderando la distri)ucin de la a$licacin& es $osi)le identificar tres ti$os de nodos: Pc /liente&
Ser*idor Ge)& Ser*idor Hases de datos.
El nodo de Pc /liente re$resenta a las estaciones de tra)a@o de los usuarios finales de la
a$licacin& estos son en total # equi$os I2 $ara el Encar'ado /o)ro ( 2 $ara el Encar'ado de
+e'istroJ.
El nodo Ser*idor Ge) re$resenta aquel equi$o donde correr8 el ser*idor Ge) ( las a$licaciones
de nuestro sistema.
El ;ltimo nodo& Ser*idor Hases de Datos& re$resenta el sistema donde se encuentra nuestro
mane@ador de )ase de datos ( todas las ta)las que la conforman.
Fi("a 456' Vista de Des$lie'ue.
1as estaciones de tra)a@o de los usuarios IPc /lienteJ de)en contar con un )rowser.
?a( solo una instancia del nodo Ser*idor la cual centrali:a todos los requerimientos de los
clientes& de)e ser ser*idor de a$licaciones P?P.
Dentro de la instancia Ser*idor de Hases de Datos el cual se encar'a de la distri)ucin de los datos se';n las
$eticiones que *allan lle'ando del ser*idor.
/onfidencial SISEVP& 20"# P8'ina"3 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
2. Vista de I*ple*entacin
En esta *ista se $lantea la or'ani:acin de cada uno de los com$onentes de nuestro sistema. Estos
son or'ani:ados en @erarqu9a de ca$as& en donde cada ca$a $ro*ee una interfa: o fachada )ien definida $ara
las ca$as su$eriores. En nuestro sistema $odemos distin'uir tres diferentes $rocesos que interact;an entre si
a tra*Bs del sistema.
1. Interfa. r3fica
Aqu9 encontramos todas nuestras diferentes $a'inas Ge) que son las encar'adas en de la
comunicacin con los diferentes usuarios de nuestro sistema. Dentro de esta ca$a tam)iBn encontramos una
fachada encar'ada de comunicarse con los diferentes $aquetes de la ca$a de ne'ocios& facilitando as9 el
entendimiento entre ca$as ( la comunicacin con el usuario.
Duestro sistema es una a$licacin )asada $rinci$almente en la Ge). A ni*el de usuario final&
eCiste una interaccin continua con el )rowser el cual se encar'ar8 de $resentar al usuario& la interfa: de la
a$licacin ( de en*iarle al ser*idor las di*ersas solicitudes que el usuario reali:a.
Por el lado del ser*idor& $ara $oder e@ecutar las $8'inas P?P& es necesario un ser*idor Ge) con un
contenedor Ge) que cum$la con las es$ecificaciones de P?P ( del /ontrolador. Para $untuali:ar& se
requiere al';n ser*idor de a$licaciones P?P. 0n ser*idor de a$licaciones es un software que a(uda al
ser*idor Ge) a $rocesar las $8'inas que contienen scri$ts etiquetas del lado del ser*idor. /uando un
na*e'ador solicita una $8'ina de este ti$o& el ser*idor Ge) remite la $8'ina al ser*idor de a$licaciones $ara
su $rocesamiento antes de en*iarla al na*e'ador.
El ser*idor Ge) reci)e las solicitudes del usuario ( las rediri'e a las $8'inas din8micas u)icadas
en la ca$a de Interfa:. El ser*idor we) asocia a cada usuario con la informacin de sesin ( es el quien se
encar'a de 'estionar la atencin a m;lti$les clientes en forma simult8nea.
2. (ica de neocio
Dentro de nuestra ca$a de ne'ocios tenemos las diferentes clases que nos $ermiten mane@ar el
reci)imiento ( tratamiento de las distintas $eticiones ( reali:ar efica:mente las diferentes acciones que
e@ecutan nuestro sistema& inclu(endo en ellas todos los mBtodos que cum$lan nuestros (a esta)lecidos
contratos.
Dado que nuestro sistema se desarrolla )a@o un am)iente /liente=Ser*idor so)re tecnolo'9a Ge)&
usando $8'inas de ser*idor A$ache IP?PJ. Para la reali:acin de las tareas todas estas clases se encuentran
desarrolladas )a@o el am)iente P?P.
Para un me@or mane@o de nuestro $ro'rama& estas clases se encuentran a'ru$adas en diferentes
$aquetes se';n las distintas funciones que reali:a nuestro sistema.
3. Acceso de datos
Para e@ecutar los diferentes $aquetes que conforman nuestro sistema es necesario interactuar con
una )ase de datos a cada momento. Para todo el desarrollo de la )ase de datos usamos un mane@ador de
Hase de Datos como lo es .(SA1.
0na a$licacin Ge) no $uede conectarse directamente con una )ase de datos. ?ace falta una
interfa: de software entre la a$licacin Ge) ( la )ase de datos que ha'a $osi)le el di8lo'o entre am)as.
0na a$licacin P?P $uede conectarse con una )ase de datos mediante una interfa:. Esta interfa: act;a
como un intBr$rete o traductor que $ermite a la a$licacin P?P comunicarse con una )ase de datos
utili:ando el len'ua@e SA1.
/onfidencial SISEVP& 20"# P8'ina"4 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
Dentro de esta ca$a se encuentra una de las $rinci$ales clases de nuestro sistema como lo es el
mane@ador de )ase de datos& el cual ser8 el encar'ado de crear una comunicacin entre los o)@etos de la
ca$a de ne'ocios ( los de la ca$a de datos.
Fi("a de !as 7 ca/as o /a2etes 2e con)o"man nest"o /"o("ama
/onfidencial SISEVP& 20"# P8'ina"7 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
/onfidencial SISEVP& 20"# P8'ina20 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
4. Vista de Datos
4.1 Diara*a Entidad5$elacin
/onfidencial SISEVP& 20"# P8'ina2" de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
4.2 Ta*a6o ! Dese*pe6o
Ta*a6o) onsiderando que el sistema va a ser utili(ado principalmente por el personal de
la ,unicipalidad de )urn# el volumen de cone-iones simult%neas al sistema que se
esperan no es tan grande# incluso durante las 'oras pico# es probable que este n.mero no
e-ceda las 1/ cone-iones simult%neas.
Dese*pe6o) &l sistema debe presentar los resultados de las consultas en un tiempo
ra(onable# digamos no m%s de /.0 seg.
7. Calidad
Escalabilidad) &l sistema debe poder soportar varias cone-iones simult%neamente# esto se
logra mediante el soporte de concurrencia del servidor *eb.
Confiabilidad ! disponibilidad) &s importante que el sistema se mantenga en
$uncionamiento las 14 'oras# todos los das# para ello 'a! que garanti(ar que no caiga ante
$allas de electricidad# etc. &sto se logra mediante instalaciones en la planta $sica en donde se
van ubicar los servidores# as como mediante equipos 2UPS# etc3 que aseguren que el
servicio se mantenga arriba incluso durante una $alla el"ctrica.
Portabilidad) +ebido al uso de P4P# ,!S5)# el sistema puede ser migrado $%cilmente a
cualquier otro servidor en caso de ser necesario# !a que estas 'erramientas $uncionan ba6o
cualquier sistema operativo.
Seuridad) P4P provee libreras para implementar los requisitos de seguridad del sistema#
tales como creacin de certi$icados# ci$rado de datos# entre otros.
,odificable ! *e8or *ane8o de fallas) &l sistema S7S&8P cuenta con una arquitectura
basada en componentes# la cual es una de las pr%cticas de desarrollo de so$t*are m%s
recomendadas 'o! en da. +ic'a arquitectura basada en componentes permite un *e8or
*ane8o ! correccin de fallas en el sistema sin modi$icar o a$ectar gran parte del mismo.
&s decir# podemos modi$icar solo aquellos componentes que produ(can la $alla sin tener que
modi$icar otros componentes del sistema.
E9pandible) )a arquitectura basada en componentes tambi"n permite que el sistema sea
e-pandible. A la 'ora de ser necesaria la inclusin de una nueva $uncionalidad al sistema# se
puede implementar un nuevo componente e integrarlo a la arquitectura sistema.
/onfidencial SISEVP& 20"# P8'ina22 de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
1:. Aplicacin de la Co*putacin Auton*ica
)os sistemas de computacin autonmica son aquellos que tienen la capacidad de gestionarse por s
mismos ! adaptarse de $orma din%mica a los cambios# de acuerdo con las reglas de negocio !
los ob6etivos e-istentes. )os sistemas autogestionados pueden llevar a cabo actividades de
gestin basadas en situaciones que ellos mismos perciben u observan dentro del entorno 79. &n
ve( de ser los pro$esionales del 79 quienes inicien las actividades de gestin# es el sistema el
que se observa a si mismo ! act.a consecuentemente.
&sto le permite al pro$esional 79 centrarse en otras tareas de alto valor mientras que la tecnologa es
la que gestiona las operaciones m%s mundanas.
1:.1. Auto5proteccin
&l ob6etivo de la auto:proteccin es la de permitir que el entorno 79 proporcione
la in$ormacin e-acta a los usuarios correctos en el momento oportuno# a trav"s
de acciones que garanticen un acceso a la in$ormacin en $uncin del rol del usuario !
de las polticas de seguridad preestablecidas con anterioridad. Un entorno 79 dotado
de auto:proteccin puede detectar comportamientos 'ostiles o intrusivos dentro del sistema
! e6ecutar las acciones necesarias para protegerse de los intentos no autori(ados de
acceso# de los virus# de los ataques de denegacin de servicio# ! de los $allos en general.
)a capacidad de auto:proteccin permite a las empresas e6ecutar de $orma consistente
polticas de seguridad ! privacidad# reducir los costes de administracin de seguridad; )a
auto:proteccin tambi"n se encarga de tareas relacionadas con la prevencin de
condiciones que puedan sobrecargar el sistema ! poner en peligro la integridad del mismo.
Caso 1)
&n caso que nuestro sistema detecte que un usuario est% intentando acceder A) S7S9&,A
! no lo consigue en < intentos# entonces se proceder% a bloquear a ese usuario ! luego se
reali(ar% un reporte al administrador del sistema que corresponda.
Solucin planteada)
Uso de los componentes +=9R7>& o P4P7))=? para P4P adem%s de la @seguridad
re$or(adaA proporcionada por +B1.
Caso 2)
&n caso que nuestro sistema detecte que e-isten demasiadas peticiones desde una
misma 7P en un corto periodo de tiempo# entonces dic'a 7P ser% bloqueada.
Solucin planteada)
Uso de un componente sensor que se encargue de monitorear el log del servidor# se
utili(ar% modelos matem%ticos para reali(ar acciones de proteccin.
Caso 3)
/onfidencial SISEVP& 20"# P8'ina2% de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
&n caso que nuestro sistema detecte que un usuario del sistema est% intentando 'acer
@sql in6ectionA en la base de datos# se proceder% a cerrar la sesin de dic'o usuario !
bloquearlo# luego esto se reportar% al Administrador del Sistema.
Solucin planteada)
Aplicacin de las propiedades autonmicas de la base datos +B1.
1:.2. Auto5reparacin
)os entornos 79 dotados de auto:recuperacin pueden detectar operaciones incorrectas
2bien proactivamente a trav"s de predicciones o bien de otras $ormas3 e iniciar a
continuacin las acciones correctivas oportunas sin a$ectar al correcto $uncionamiento de
las aplicaciones del sistema. Una accin correctiva podra signi$icar que un elemento
altere su propio estado o in$lu!a sobre otros elementos del entorno provocando cambios
en ellos. )as operaciones del da a da de la empresa no deben tambalearse o $allar
por culpa de diversos eventos a nivel de componentes. &l entorno 79 debe 'acerse m%s
resistente ! $iable gracias a que los cambios llevados a cabo reducen o a!udan a
eliminar el impacto sobre el negocio tras un $allo de un componente.
Caso 1)

&n caso que nuestro sistema detecte que se perdi la cone-in a la base de datos# se
proceder% a reconectarlo autom%ticamente 'asta conseguir "-ito# mientras tanto los datos
de la transaccin se guardar%n en sesin# una ve( restaurada la cone-in se continuar%
con la e6ecucin de la transaccin# de esta manera aseguramos que no se pierda la
in$ormacin de la transaccin en proceso.
Solucin planteada)
Uso de componentes de +B1 9ouc'point Simulator ! 4A+R.
1:.3. Auto5Confiuracin
Cracias a la capacidad de auto:con$iguracin @al vueloA de un sistema# un
entorno 79 puede adaptarse inmediatamente# ! con la mnima intervencin 'umana
posible# al despliegue de nuevos componentes o cambios en el propio entorno. )a
adaptacin din%mica a!uda a veri$icar de $orma continua la $ortale(a ! la productividad de
la in$raestructura e:business# a menudo el .nico $actor determinante entre
el crecimiento del negocio o el caos.
Caso 1)
&n caso de que la variable que almacena la cantidad de usuarios registrados en la pla!a
llega a su nivel m%-imo 24D/3# el sistema se autocon$igurar% para no permitir m%s registros
de ingreso.
Solucin planteada)
reacin de un omponente el mane6o de la variable.
/onfidencial SISEVP& 20"# P8'ina2# de 2,
Sistema de Estacionamiento Vehicular $ara la Pla(a de San Pedro = 1ur9n
Versin: ".0
Documento de la Arquitectura de Software Fecha: 0203"#
SISEVPEDocEArchitec.doc
/onfidencial SISEVP& 20"# P8'ina2, de 2,