Arquitectura de SW

Sis stemade d Adm ministra acinySoport tedeAtenci A naEm mergenc cias
Do ocument todeAr rquitectu ura de elSistem ma (SAD)
F Fenna arioSoftwar So re
JosephAndrsGuevaraUmaa U
ja.gu uevara@un niandes.e edu.co
Rafa aelHumbe ertoClavijoOrtiz

rh.cla avijo24@u uniandes. .edu.co
Ja avierDaroOrjuelaKo oop
jd.orj juela73@u uniandes. .edu.co
SistemadeAdministracinySoportede AtencinaEmergencias
Tabladecontenido
Seccin1.DescripcindelDocumento..........................2 Seccin2.GeneralidadesdelProyecto..........................5 Seccin3.MotivadoresArquitecturales......................11 Seccin4.Contexto......................................................23 Escenarios Operacionales ......................................23 Escenario01.................................................................23 Escenario02.................................................................23 Seccin5.PuntosdeVistayModelosArquitecturales 25

ArquitecturayDiseodeSoftwareMayode2011
Seccin1. DescripcindelDocumento
1.1. Propsito y Audiencia
El presente documento expone la arquitectura propuesta para un sistema de atencin de emergencias en un contexto urbano de varios millones de habitantes, tomando como referencia a la ciudad de Bogot. El documento recoge el diseo de una solucin tecnolgica pensada para optimizar la eficiencia de la atencin a emergencias, proveyendo mecanismos para la recepcin de solicitudes, centralizacin de informacin relevante e intercomunicacin y coordinacin de los organismos que brindan atencin (e.g.CruzRoja,DefensaCivil,bomberos,polica).Estdestinadoatodoslos actores directamente involucrados en el despliegue, operacin y mantenimiento de tal sistema, bien sea operacionalmente o financieramente. En particular, se dirige a la administracin distrital, a los organismos de atencin a emergencias previamente mencionados, al equipodesarrolladorqueimplementarelsoftware,yaqullosencargados de operar el sistema y proveerle mantenimiento. Se pretende ilustrar las decisiones ms relevantes de arquitectura que responden a los intereses y necesidades de cada actor involucrado en el proyecto mediante vistas especiales para cada uno de ellos que ilustren slo los aspectos que les seanrelevantes.
1.2. Organizacin del Documento
El presente documento se organiza por secciones. En la primera seccin se comienza por introducir las generalidades del proyecto, describiendo el propsito del documento, al igual que las convenciones, trminos y referencias bibliogrficas del mismo. Posteriormente, la segunda seccin aborda la problemtica de inters y describe brevemente el sistema que desea disear, los objetivos de su arquitectura y los stakeholdersdel proyecto. En la tercera seccin se documentan los motivadores arquitecturales: motivadores de negocio que dan forma al proyecto, junto conlasrestriccionesdedesarrollo,losatributosdecalidadfavorecidosylos escenariosparadichosatributos.
1.3. Terminologa y Definiciones

Se consideran relevantes los siguientes trminos en el presente documento. Bajo ninguna circunstancia se considera lasiguiente lista como unarelacinexhaustivadelostrminosrelevantes. TCP: Transmission Control Protocol. Protocolo de la capa de transporte de la pila TCP/IP. Entre sus particularidades ms notables est el hecho de ser orientado a conexin y de proveer servicios de transporteconfiables(i.e.nopierdeinformacinenlatransferencia). Informacin GeoReferenciada: Tipo de informacin utilizada en los sistemas de ubicacin geogrfica para proveer la localizacin de objetossobrelaproyeccindeespaciosgeogrficos.
1.4. Documentos Relevantes

Paralaelaboracindelpresentedocumentodearquitecturaseconsultaron lassiguientesfuentes. SisiZlatanova.AProposedSystemArchitectureforEmergency ResponseinUrbanAreas.PublicadoenOctubre18de2005en DirectionsMagazine.
Disponibleen: http://www.directionsmag.com/articles/a%C2%AD%E2%80%90proposed-%C2%AD%E2%80%90system%C2%AD%E2%80%90architecture-%C2%AD%E2%80%90for%C2%AD%E2%80%90emergency%C2%AD%E2%80%90response-%C2%AD%E2%80%90in%C2%AD%E2%80%90urban%C2%AD%E2%80%90areas/123317 SADInFlightEntertainmentexenIFEGrupoEXEN ProyectodeArquitecturadeSoftware20101(Universidaddelos Andes) Autores:CarolGalvis,DianaFernndez,GilbertoGarca. Disponibleen: http://sistemas.uniandes.edu.co/~isis2603/dokuw iki/lib/exe/fetch.php?media=proyectos:documento _arquitectura_-_grupo_exen.pdf RepblicadeColombia,MinisteriodeDefensa.DecretoNmero 4222de2006(23deNoviembrede2006).Disponibleen http://www.policia.gov.co/portal/page/portal/HO ME/20_operaciones_semanales/FUNCIONES.pdf CuerpoOficialdeBomberosdeBogot.Servicios.Disponible enhttp://www.bomberosbogota.gov.co/content/view /45/75/ CruzRojaColombiana.SeccionaldeBogotyCundinamarca. Disponible enhttp://www.cruzrojabogota.org.co/contenidos.p hp?id_contenido=1&id_categoria=1&PHPSESSID=651d 1e5860ac0d6444934b0288066a0b DefensaCivilColombiana.Funciones.Disponibleen http://www.defensacivil.gov.co/portal/apps/php/ index.kwe
Seccin2. GeneralidadesdelProyecto
2.1. Problema a Resolver
Las ciudades actuales, en particular las latinoamericanas, son cada vez ms grandesycomplejas,provistasdetodasuertedeinfraestructura,mediosde transporte y edificaciones para acomodar y prestar servicios a una poblacin que va en aumento. Sin embargo, tal complejidad no evita que sucedan accidentes, desastres naturales, o desastres causados por el hombre; por el contrario, prestar servicios de atencin de emergencias en contextos urbanos altamente poblados implica enfrentar una serie de retos complejos, de los cuales destacamos tres en particular. En primer lugar, las emergenciasdebenseratendidasporequiposmultidisciplinariosintegrados por varios organismos, como los bomberos, la cruz roja, la polica, entre otros. Para que el servicio prestado sea eficiente y pertinente, todos los organismos de rescate deben estar adecuadamente coordinados. En segundolugar,sedebedisponerdeinformacinprecisaysuficientesobrela emergenciayelsitioenqueocurriparapoderresponderadecuadamente. En particular, es de especial inters poder recolectar y proveer informacin georeferenciada sobre la locacin de la emergencia y los caminos de accesoalsitioencuestin.Sinembargo,esnecesarioprocurarmantenertal informacin actualizada en todo momento, lo cual implica necesariamente el monitoreo de cada emergencia reportada. Un reto particular asociado con el manejo de informacin y su actualizacin es el hecho de que existen muchos formatos diferentes de tal informacin (e.g. video, audio, fotos) y muchos canales heterogneos para su recepcin (e.g. celulares, llamadas telefnicas, SMS). Finalmente, no basta con disponer de informacin relevante y actualizada si sta no se puede hacer llegar eficientemente y a tiempo a los organismos que la necesitan. Para ejecutar esta labor es
necesario poder integrar toda la informacin heterognea y no estructuradaqueserecibe,locualesunretoconsiderable. Finalmente, en una emergencia es necesario procurar que el pnico no se apodere de la gente. Una manera de lograr este objetivo es proveer informacin oficial y exacta a los medios de comunicacin y a la poblacin en general para evitar la propagacin de rumores malintencionados o falsos.Esclaroqueproveertalinformacindemaneraexactayatiempoes unretoqueenfrentanlossistemasdeatencindeemergencias,sobretodo cuandosemanejangrandesvolmenesdeinformacinydepoblacin.
2.2. Descripcin General del Sistema a Desarrollar
En este documento se presenta, bajo diversas vistas, la arquitectura de un sistema de informacin para la atencin de emergencias urbanas. El sistema, cuya arquitectura se presenta a continuacin, estar en capacidad de (1) atender concurrentemente grandes volmenes de reportes de emergencias sin degradar el desempeo del sistema, (2) acopiar grandes volmenes de informacin heterognea y no estructurada relativa a una emergencia particular para procesarla, integrarla y generar informacin estructurada que pueda ser manipulada fcilmente, (3) mantener canales de comunicacin constante con los grupos de rescate (e.g. bomberos, cruz roja) y utilizar la informacin recolectada para coordinar los grupos de rescate relevantes a una emergencia concreta y proveer los datos que necesitanparaejercersulabordeformaeficaz,(4)actualizarentiemporeal la informacin relativa a una emergencia para llevar a cabo un monitoreo eficiente y responder oportunamente a las nuevas exigencias (e.g. despacho de ms ambulancias) que se presenten, y (5) generar reportes actualizados de carcter oficial para mantener informados a los medios de comunicacinyalaciudadanaengeneral. El diseo de la arquitectura del sistema se basar en los atributos de calidad seleccionados, entre los cuales se destaca el desempeo (que
comprendeconcurrenciayescalabilidad)comoelatributoclavequeprovee valoragregadoalaaplicacin,dentrodeunaslimitacionesimpuestasporla tecnologaylosrequerimientosfuncionalesynofuncionalesdelsistema.
2.3. Objetivos
Desarrollar un documento de arquitectura claro que pueda ser utilizado por un equipo de desarrollo de SW para implementar la aplicacinsiguiendounciclodevidaencascada. Responder a los motivadores de negocio con una arquitectura que favorezcaeldesempeocomoatributodecalidadprincipal. Disear una arquitectura que favorezca el desempeo dentro de los lmitesimpuestosporlasrestriccionestecnolgicas. Proveer diferentes vistas de la arquitectura que sean claras y relevantesparacadastakeholderdelproyecto.
2.4. Stakeholders
Tabla1.DescripcindelosStakeholdersdelProblema
Stakeholder
AdministracinDistrital
Descripcin
Este stakeholderhace referencia al alcalde y a las secretaras distritales involucradas en la atencin de emergencias en la ciudad. En particular, hacemos referencia a la Secretara de Salud, de Gobierno, de Movilidad y de Planeacin. La polica es una dependencia del Ministerio de Defensa Nacional, que ejerce mltiples funciones entre las cuales destacamos la seguridad ciudadana, investigacin criminal, inteligencia policial, control antinarcticos, servicios antisecuestro y antiextorsin, control detrnsitoytransporte. Los bomberos son una unidad administrativa
PolicaMetropolitanade Bogot
CuerpoOficialdeBomberos
especial del distrito encargada de proveer atencin a emergencias (incendios estructurales, incendios forestales, rescate acutico, incidentes que involucran materiales peligrosos, bsqueda de personas con perros, entre otras), de promover la reduccin de riesgos en la ciudad (proveer capacitacin, realizar inspecciones tcnicas, y asegurar ambientes para eventos de aglomeracin pblica), y de atender emergencias miscelneas (emergencias elctricas, accidentes areos, terremotos, inundaciones, atentadosterroristas,etc). CruzRojaColombiana Entidadprivadasinnimodelucro,compuesta [SeccionalCundinamarcay de500funcionariosy800voluntarios Bogot] trabajandoenreadesalud,educacin, programascomunitariosygestindelriesgo. Laentidadhacepartedelsistemadistritaly departamentaldeprevencinyatencinde desastres,comocuerpooperativo. DefensaCivilColombiana Organismo gubernamental encargado de la prevencin y atencin inmediata de emergencias, calamidades y desastres naturalesocausadosporelhombre. Ciudadanos Hacereferenciaatodoslosciudadanos particularesqueusanelsistemacomousuarios finalesparareportarunaemergencia,o solicitarinformacinactualizadasobreel estadodesta. OperadordelSistema[Centro Entidadacargodeoperarelsistemade deDespacho] atencindeemergencias. EquipodeDesarrollode Equipodepersonasencargadasde Software implementarelsistemasegnseespecificaen elpresentedocumento,yproveer mantenimientounavezelsistemaest desplegado.
deBogot
Tabla2.ExpectativasdelosStakeholders
Stakeholder AdministracinDistrital
Expectativas Seesperaunsistemarobustocapazdeatender concurrentemente un gran nmero de
ciudadanos reportando emergencias, sin degradar la disponibilidad del servicio. Adicionalmente, el sistema debe poder recibir informacin sobre la emergencia por medio de canales diversos y utilizar dicha informacin para dimensionar la magnitud de lo ocurrido y coordinar a los organismos de rescate segn la gravedad de la emergencia y los recursos disponibles. PolicaMetropolitanade El sistema debe mantener canales de Bogot comunicacin permanentes con el centro de despacho, y debe proveer informacin relevante y actualizada sobre la ubicacin, la situacin y los recursos que la Polica debe aportaralsitiodeldesastre. CuerpoOficialdeBomberos Elsistemadebemantenercanalesde deBogot comunicacinpermanentesconelcentrode despacho,ydebeproveerinformacin relevanteyactualizadasobrelaubicacin,la situacinylosrecursosquelosBomberos debenaportaralsitiodeldesastre. CruzRojaColombiana Elsistemadebemantenercanalesde [SeccionalCundinamarcay comunicacinpermanentesconelcentrode Bogot] despacho,ydebeproveerinformacin relevanteyactualizadasobrelaubicacin,la situacinylosrecursosquelaCruzRojadebe aportaralsitiodeldesastre. DefensaCivilColombiana Elsistemadebemantenercanalesde comunicacinpermanentesconelcentrode despacho,ydebeproveerinformacin relevanteyactualizadasobrelaubicacin,la situacinylosrecursosquelaDefensaCivil debeaportaralsitiodeldesastre. Ciudadanos Elsistemadebepresentarunainterfaz(no necesariamentegrfica)amigableyfcilde usarparareportaremergenciasdemaneragil ysincomplicaciones.Adicionalmente,el sistemadebeproveerinformacinactualizada sobreelestadodelasemergenciasrelevantes. OperadordelSistema[Centro Elsistemadebeserfcildeutilizar,demodo deDespacho] quesepuedaentrenarrpidamenteal personalencargadodesuoperacin. EquipodeDesarrollode Seesperaqueelpresentedocumentoexponga Software laarquitecturadelsistemademaneraclara
10
paraevitarerroresdeinterpretacinylatoma dedecisionesarbitrariasporpartedelos desarrolladoresalahoradela implementacin.

11
Seccin3. MotivadoresArquitecturales
3.1. Motivadores de Negocio

Tabla3.MotivadordeNegocioNo.01
NombredelMotivadorde Negocio
DescripcindelMotivadordeNegocio
Disminuirlostiemposderespuesta Disminuireltiempodelanzamientodelarespuestaauna aemergenciasdentrodelreade emergenciaamenosdetresminutosmediantela cobertura. sistematizacinydigitalizacindeloscanalesde comunicacinentrelasentidadesquerespondenalas emergencias. MedidadelImpacto Eltiempotranscurridodesdeeliniciodelacomunicacinentrequienreportalaemergenciay lacentraldeemergenciashastalaconfirmacindelarespuestadetodoslosorganismosde respuestarelevantes,medidoensegundos.
Rangos Ninguno Bajo Moderado Fuerte MuyFuerte AsociacindelMotivador conelNegocio
CotaMnima 1800segundos 1200segundos 600segundos 180segundos 60segundos DefinidoPor EjecutadoPor Ubicacinenel Portafoliode Negocios
CotaMxima
Ninguna 1799segundos 1199segundos 599segundos 179segundos AdministracinDistrital OperadordelSistema[Centrode Despacho] SeguridadCiudadana
Aumentarelnmerodevctimas nofallecidasnilisiadasdeporvida arazdeunaemergencia.
Lograrqueparaunasituacindeemergenciadada,las muertesyheridasdelargoplazodisminuya,atravsde unamejorcoordinacinentreorganismosderescateyde salud. MedidadelImpacto Latasademuertesylesionesdeporvidaentreeltotaldelaspersonasenelsitiodela emergencia.

12
Rangos Ninguno Bajo Moderado Fuerte MuyFuerte AsociacindelMotivador conelNegocio
CotaMnima 95%rangoantiguo 90%rangoantiguo 85%rangoantiguo 80%rangoantiguo 75%rangoantiguo DefinidoPor EjecutadoPor Ubicacinenel Portafoliode Negocios
CotaMxima
100%+rangoantiguo 95%rangoantiguo 90%rangoantiguo 85%rangoantiguo 80%rangoantiguo AdministracinDistrital OrganismosdeRescate[e.g.polica, bomberos,etc.] SeguridadCiudadana
Disminuirelcostodelosdaos materialesdelasemergencias.
Enlasemergenciasquesignificanundaoafsicoalos alrededores,seesperadisminuirelcostodelareparacin almanejarlaemergenciaatiempoyalprevenirquela emergenciaseextienda. MedidadelImpacto Costoporcentualdereparacindelosdaosmaterialesocasionadosporlaemergenciacon respectoacostosocasionadosensiniestropreviosdeigualesoparecidasmagnitudes.
Rangos CotaMnima Ninguno 96% 92% Bajo 88% Moderado 84% Fuerte 80% MuyFuerte AsociacindelMotivador DefinidoPor conelNegocio EjecutadoPor Ubicacinenel Portafoliode Negocios
CotaMxima
100%+ 96% 92% 88% 84% AdministracinDistrital OrganismosdeRescate[e.g.polica, bomberos,etc.] PresupuestoDistrital
Generarculturaciudadanaparael reporteoportunodeemergencias urbanas.
DescripcindelMotivadorde Negocio
Muchasemergenciasnosereportanatiempo,o simplementenorecibenatencinadecuadaporque muchaspersonasnosabencmoniaquinreportarlas. Tenerunsistemacentralizadodeatencinfacilitaesta
13
tarea,garantizandounamayorproporcinde emergenciasatendidasoportunamente. MedidadelImpacto Proporcindeemergenciasnoatendidasoportunamenteenlaciudad.
Rangos CotaMnima Ninguno 20% 14% Bajo 9% Moderado 6% Fuerte 3% MuyFuerte AsociacindelMotivador DefinidoPor conelNegocio EjecutadoPor Ubicacinenel Portafoliode Negocios

CotaMxima
15% 10% 7% 4% 1% AdministracinDistrital Ciudadanos CulturaCiudadana
3.2. Restricciones de Tecnologa

Tabla7.RestriccindeTecnologaT01
IDRestriccin
T01
Tipo
Nombre
Descripcin EstablecidaPor Alternativas Observaciones
Tecnologa Canalesdeatencinalpblico Losciudadanosslopodrncomunicarlaexistenciade emergenciasporvatelefnica. AdministracinDistrital Lallamadapuedeserhechaportelefonaconvencionalo celular. Seexcluyenlosdemsmtodosdecomunicacinporserno sincrnicos(e.g.email)oporqueproveenmuypoca informacin(e.g.SMS).Sinembargo,sepodrrecibirtoda clasedeinformacinrelativaaleventoporotrosmedios.
IDRestriccin
T02
Tipo
Tecnologa
Nombre
Manejodeinformacingeo referenciada Elsistemadebesercapazdegestionarinformacingeo referenciada. AdministracinDistrital Ninguna Elsistemadebeposeermodelos(informacingeo referenciada)delreadecoberturacargadosdesdeantesde

14
iniciaroperacin. Tabla9.RestriccindeTecnologaT03
IDRestriccin
T03
Tipo
Nombre
Tecnologa AplicacindesarrolladaenJEE Partedelaaplicacindebeestardesarrolladousandola tecnologaJEE. ArquitectodeSoftware Ninguna LatecnologaJEEseasociaconunaarquitecturadetres niveles.Sinembargo,talarquitecturapuedeentraren conflictoconaquellaqueseproponeenestedocumento.Por lotanto,quedaadiscrecindeldesarrolladorusarJEEsloen laspartesdondesejuzgueposible.
IDRestriccin
T04
Tipo
Tecnologa
Nombre
AmbientedeDesarrolloy Ejecucin Elsistemadebeserdesarrolladoconelambientededesarrollo NetBeans6.5.1.,ydebecorrersobreGlassFishv2.1.1. ArquitectodeSoftware Ninguna Ninguna
IDRestriccin
T05
Tipo
Tecnologa
Nombre

Interfazdeautenticaciny autorizacin Elsistemadeberealizartodoelmanejodeautenticaciny autorizacinutilizandoJAAS. ArquitectodeSoftware Ninguna Ninguna
15
3.3. Restricciones de Negocio

Tabla12.RestriccindeNegocioN01
IDRestriccin
N01
Tipo
Negocio
Nombre
Comunicacinconequiposde rescate Elsistemadebemantenercanalesdecomunicacin permanentescontodoslosorganismosderescate,tantoen perodosdeemergenciacomodecalma. AdministracinDistrital Ninguna Esimportantequeloscuerposderescatepuedanser contactadosinmediatamentealreportaseunaemergencia. Asimismo,esfundamentalgarantizarunacomunicacin ininterrumpidaconcadagrupoderescateenlazonadela emergenciaparapodercoordinaresfuerzosyrecursos.
IDRestriccin
N02
Tipo
Nombre
Negocio readecoberturadelsistema Elsistemadebegarantizarunacoberturantegra(posibilidad dereportaremergenciasyrecibiratencin)enlas20 localidadesdeBogot. AdministracinDistrital Ninguna Nodebehaberzonaalgunaenlaciudaddesdedondenose puedareportarunaemergenciayadondenopuedanllegar cuadrillasderescate.
IDRestriccin
N03
Tipo
Negocio
Nombre
Horariodeoperacindel sistema Elsistemadebeestaroperandoylistoparaatendercualquier emergencialas24horas,sietedasalasemana. AdministracinDistrital Ninguna Estemotivadordeningunamaneraexigedisponibilidaddel 100%,yaqueestonosepuedelogrartcnicamente.Sin embargo,sexigedisponibilidaddel99.99%repartida uniformementealolargodelao.
16
IDRestriccin
N04
Tipo
Negocio
Nombre
Autenticacinyautorizacin enelsistema. Elsistemadebeasegurarqueningncomponentedenegocio puedaserusadosinpreviaautenticacindelusuarioy verificacindesuniveldeautorizacin. AdministracinDistrital Ninguna El100%delosaccesosaloscomponentesdenegociodeben serrealizadosporusuariosautenticadosenelsistemay autorizadosparatalfin.
3.4. Atributos de Calidad

La seccin anterior muestra los motivadores que orientan la arquitectura delsistemaadesarrollar.Elmotivadormsimportantedelaadministracin distrital para hacer la inversin y desarrollar el sistema es contar con una herramienta que permita reducir los daos humanos y materiales que resultandesituacionescatastrficas. Es claro que las situaciones de emergencia no pueden ser previstas. Por lo tanto, surge la disponibilidad como primer atributo de calidad relevante. Sin embargo, no se debe asegurar simplemente que el sistema est disponible: en un contexto urbano de varios millones de habitantes es fundamental que el sistema no deteriore la calidad del servicio prestado al recibir un gran nmero de llamadas en una situacin de emergencia. Sin embargo, para asegurar que el sistema sea adoptado verdaderamente por la poblacin, es necesario que se pueda utilizar fcilmente. De lo contrario, habremos construido un sistema en extremo costoso tanto en tiempo como endinero quenadieusar.Tenemos,entoncesla escalabilidadcomo atributo fundamental de calidad, seguido de la usabilidad, que responde directamentealmotivadordenegocioNo.4. Ahora bien, como el objetivo fundamental de la administracin distrital es reducir los daos humanos y materiales por medio de una pronta accin frente a situaciones de desastre, concluimos que el sistema debe presentar bajos tiempos de respuesta (i.e. latencia). En conjuncin con el atributo de
17
calidad anterior, tenemos que el buen desempeo del sistema debe ser garantizado. Garantizar el buen desempeo del sistema implica, necesariamente, conocer algo ms del funcionamiento interno del mismo. En particular, nos interesasaber qu factores y requerimientos tcnicos representan una alta cargacomputacionalqueafecteeldesempeo.Paratalpropsito,hacemos referencia a las restricciones de negocio y de tecnologa. En particular, nos interesalarestriccindenegocioN01,dondeseindicaqueelsistemadebe mantener comunicacin constante con todos los organismos de rescate. Necesariamente esto implica la interconexin y operacin con sistemas legados de la ms diversa ndole. Por lo tanto, como un atributo de calidad quesoportaalosdems,sesealalainteroperabilidad. Finalmente, la restriccin de negocio N03, que en principio habla de disponibilidad, tambin exige directamente que una falla en el sistema no puede sacarlo de lnea por perodos prolongados que entren en conflicto con el atributo de disponibilidad. Por lo tanto, se identifica la recuperacin ante fallas (recuperabilidad) como el ltimo atributo de calidad relevante enestaiteracindelSAD.
3.4.1. Escenarios de Calidad

EscenariodeCalidad# AtributodeCalidad Justificacin
001
Stakeholder
Administracin Distrital
Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta
Disponibilidad Esdegranimportanciahacerevidentelacapacidaddel sistemaparamantenerseenoperacinlamayorcantidadde tiempoposible,paraestardisponibleencasodecualquier emergencia. Ciudadano. Registrarunanuevaemergencia. Mduloderecepcindeemergencias. Ejecucinnormal. Seharegistradoexitosamenteunanuevaemergenciay persisteenelsistema. 99.99%deltiempoenunaoelsistemaesfuncional,con respectoalcomponentederecepcindeemergencias.
18
EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta
002
Stakeholder
Disponibilidad Enunmomentodeemergenciasialgnservidorllegaraa verseafectadofsicamenteelsistemadebegarantizarquese puedaseguirregistrandoinformacin. Desastrelocal. Sedestruyeunservidorderecepcin. Sistema. Estrs. Elsistemadistribuyelaspeticionesentrelosservidoresaun funcionales. 99.99%delasveceselsistemacontinuaenfuncionamiento.
003
Stakeholder
Escalabilidad Elsistemaespropensoatenerunaaltaconcurrenciade usuariosensituacionesdeemergencia. Ciudadano Ocurrenciadeunaemergencia. Mduloderecepcindeemergencias. Estrs.Uneventodegrandesmagnitudeshaocurrido. Laemergenciahasidoregistradaexitosamenteypersisteenel sistema. 100.000peticionesrecibidasypersistentescada30segundos.

004 OperadordelSistema Stakeholder Desempeo Enunmomentocrticodurantelaocurrenciadeuna emergencia,esfundamentalhacerunregistrorpidodeella; delocontrario,sedemoraramuchocoordinarlaatencin. Cualquierusuariofinal(e.g.ciudadano,equipoderescate) Reportarunemergenciaparticular. Sistema. Estrs.Duranteeltranscursodeunaemergenciadegrandes magnitudes. Seregistralaemergenciaenelsistema. 0.5a2segundos.
19
005 OperadordelSistema Stakeholder Desempeo Enunmomentocrticoduranteeltranscursodeunasituacin dealerta,eltiempoderespuestadelassolicitudesde informacin(nogeoreferenciada)relevanteesfundamental paralograrelobjetivodelproyecto.Sinembargo,estedebe variarconrespectoalcomportamientoenunambientede ejecucinnormal. Cualquierusuariofinal(e.g.ciudadano,equipoderescate) Solicitarinformacinnogeoreferenciadasobreuna emergenciaparticular. Mdulodesolicituddeinformacin. Estrs.Duranteeltranscursodeunaemergenciadegrandes magnitudes. Seentregaalusuariofinallainformacinrelevante,segnsu perfil,sobrelaemergenciaencurso. 3080segs

006 OperadordelSistema Stakeholder Desempeo Enunmomentocrticoduranteeltranscursodeunasituacin dealerta,eltiempoderespuestadelassolicitudesde informacingeoreferenciadarelevanteesfundamentalpara lograrelobjetivodelproyecto.Sinembargo,estedebevariar conrespectoalcomportamientoenunambientedeejecucin normalyconrespectoaltiempoderespuestadeentregar informacinconvencional(i.e.nogeoreferenciada). Cualquierusuariofinal(e.g.ciudadano,equipoderescate) Solicitarinformacingeoreferenciadasobreunaemergencia particular. Sistema. Estrs.Duranteeltranscursodeunaemergenciadegrandes magnitudes. Seentregaalusuariofinallainformacingeoreferenciada relevante,segnsuperfil,sobrelaemergenciaencurso. 310minutos,segnlocalizacinfsicadelusuariofinal.
20

007 OperadordelSistema Stakeholder Interoperabilidad Serequiereevaluarlacapacidaddelsistemadeinteractuar consistemasyaexistentes,desarrolladosydesplegadossobre plataformaspotencialmentedistintasalapropia. Sistemaexterno. Intercambiodeinformacin. Mdulodeinterconexin. Ejecucinnormalodeestrs. Elsistemabrindainformacinrelevantealsistemaquela solicita. 100%delossistemasfronterizosdelasunidadesderescate sonoperablesconelsistema.

008 Ciudadanos Stakeholder Usabilidad Lainteraccindelciudadanoconelsistemadebeserloms naturalposibleparaevitarobstculosydificultadesenel procesodereportarunaemergencia. Ciudadano. Registrarunanuevaemergencia. Mduloderecepcindeemergencias. Ejecucinnormal. Seharegistradoexitosamenteunanuevaemergenciay persisteenelsistema. 500ms10000ms
009 Ciudadanos Stakeholder Usabilidad Lainteraccindelciudadanoconelsistemadebeserloms naturalposibleparaevitarobstculosydificultadesenel procesodereportarunaemergencia,sobretodoenperodos deemergencia. Ciudadano. Registrarunanuevaemergencia. Mduloderecepcindeemergencias. Estrs. Seharegistradoexitosamenteunanuevaemergenciay persisteenelsistema. 110segundos.
21

010 OperadordelSistema Stakeholder Recuperabilidad Encasodepresentarseunafallaquedejealsistemaporfuera delnea,estedebepoderserrestauradoypuestoen funcionamientorpidamenteparacumplirconlasexigencias dedisponibilidad. Cualquierusuariodelsistema. Falladelsistema. Sistema. Ejecucinnormal. Elsistemaespuestootravezenfuncionamientonormal. Entre10minutosy2horas,dependiendodeltipodefalla.

011
Stakeholder
Seguridad Lainformacincaptadayanalizadaporelsistemaessensibley debeserprotegidaysolousuariosautenticadosyautorizados debenpoderaccederaesta. Cualquierusuario.(normalomalintencionado) Intentaaccederauncomponentedenegocio Sistema. Ejecucinnormal. Elsistemasolicitacredencialesyverificaautorizacindel usuarioparapermitirusarelcomponentesolicitado. 100%delasvecesloscomponentesdenegociosonusadospor usuariosquesehanautenticadoyautorizadopreviamenteen elsistema.
22

012
Stakeholder
Seguridad Anteunataquededenegacindeservicioelsistemadebeser capazdemantenersefuncional. Usuariomalintencionado Serealizan500.000omssolicitudesenmenosde30 segundos. Sistema. Ejecucinnormal. Elsistemadesechatodaslassolicitudesquesuperenlas 500.000. Despusdelapeticin500.000enunrangode30segundosse descartanel100%delassolicitudes,yaqueseconsideraun ataquededenegacindeservicio.
23
Seccin4. Contexto
Escenarios Operacionales
Escenario01
TtulodelEscenarioOperacional Registrodeemergencia StakeholderAsociado Ciudadano ID
RespuestadelStakeholder la Despusdequeelusuarioseharegistradoenelsistema,esteproporcionapor mediodeunformulariowebalgunosdatossobrelaemergencia(ej.Lugar,tipo, etc.),elsistemalaclasificayfinalmentereportaunplandeaccinalasunidades derescate.
EO01
ConsideracinOperacional Descripcin general funcionalidad de
Descripcin del estado actual e Elciudadanoactualmentellamaal123sideseareportaralgunaemergencia,debe intencindelStakeholder esperaraquelecontesten,sistematicenycomuniquenlaemergencia.Loquese deseaesqueesteprocesoseaautomticoymseficiente. Descripcin de algunas entradas Seesperandatosrelacionadosalaemergenciacomo:lugar,tipo,hora,etc.Y provistas o disponibles al datosrelacionadosalapersonaquereportacomo:celularynombre. momentodelinicio Descripcindel contexto de la Haocurridoalgunaemergenciaenlaciudadyunciudadanorecurrealsistemade operacin manejodeemergencias. Descripcinde la respuesta del Elsistemadebefiltrarlaemergencia(siyahasidoreportadasolobusca sistema. informacinadicional),clasificarlaemergencia(determinarsegnlascategoras delsistemaquetipodeemergenciaes),generarunplandeaccinycomunicarlo alasunidadesderescate. Descripcin del resultado de la Lainformacindelaemergenciaestenlossistemasdeinformacindelas accin del sistema en trminos unidadesderescateypersistelocalmenteenelsistema. desalidas Descripcin deluso delas salidas Lainformacindelaemergenciaademsdealertaralosgruposderescatedebe delsistema ayudaraestosamejorarlosplanesdeaccinintentandoreducirlasvctimas humanasylosdaosmateriales
Escenario02
TtulodelEscenarioOperacional Consultadeinformacinconsolidada
SistemadeAdministracinySoportede AtencinaEmergencias StakeholderAsociado Administracindistrital ID

RespuestadelStakeholder la Despusdequeelusuarioseharegistradoenelsistemaysehaverificadoque estetienelaautorizacinparagenerarunreporte,segeneraunconsolidadoque muestraelnmerodeemergenciasregistradas(ordenadasportipode emergenciaporunidaddetiempo(hora,da,mes,ao)),elnmeroytipode unidadesqueasistieronalaemergencia,eltipoyelnmerodevctimas,elestado actualdelaemergenciayelmedioporelquefuereportadalaemergencia.Todo elreporteestarordenadoyagrupadoporlocalidad.
24
EO02
ConsideracinOperacional Descripcin general funcionalidad de
Descripcin del estado actual e Actualmentegenerarestetipodereportepuedetardardasoinclusosemanasya intencindelStakeholder quetocaconsolidarfsicamentelainformacindelosdiferentessistemasdelas unidadesderescate.Loquequierelaadministracindistritalesqueelreporte puedasergeneradoymostradoenpantallaenmenosde60segundos. Descripcin de algunas entradas Nohayentradas. provistas o disponibles al momentodelinicio Descripcindel contexto de la Algnusuarioadministrativorequierelainformacinconsolidadadelas operacin emergenciasdelaciudad. Descripcinde la respuesta del Elsistemamuestraporpantallalainformacinconsolidadadeemergenciasenel sistema. sistema,haciendousodelainformacinlocal. Descripcin del resultado de la Lainformacindelaemergenciaestenlossistemasdeinformacindelas accin del sistema en trminos unidadesderescateypersistelocalmenteenelsistema.Elreportemuestrael desalidas nmerodeemergenciasregistradas(ordenadasportipodeemergenciapor unidaddetiempo(hora,da,mes,ao)),elnmeroytipodeunidadesque asistieronalaemergencia,eltipoyelnmerodevctimas,elestadoactualdela emergenciayelmedioporelquefuereportadalaemergencia;ordenadoy agrupadoporlocalidad. Descripcin deluso delas salidas Losreportesconsolidadoslousanentidadesadministrativasyorganismosde delsistema rescateamaneradeevaluacinymonitoreodelasemergencias.Deestamanera sepuedenenterardelestadoactualdeemergenciasactivasyelresultadosegn planesdeaccinenemergenciasyasucedidas,todoconelfindemejorar progresivamentelosplanesdeaccinyasreducirelnmerodevctimasydaos enemergenciasfuturas.
25
Seccin5. PuntosdeVistayModelos Arquitecturales
Enestaseccinpresentamoslaarquitecturaescogidaparaelsistema.Ensu nivelmsgrueso,consisteenunaestructurahub&spoke,dondeelhubesun componente centralizador que administra sus spokes de manera asincrnica. Cada spokerepresenta una unidad funcional independiente dentro del sistema. En ese orden de ideas, reconocemos tres funcionalidades independientes como la recepcin de informacin, la comunicacin con los equipos de rescate y el procesamiento. Esta modelo general de arquitectura garantiza, en un primera instancia, los atributos de calidad ms importantes sealados en la seccin anterior, a saber la escalabilidad, la disponibilidad y el desempeo. La clave reside en la independenciarelativadecadacomponenteparaactuarydecidir,haciendo uso del hub central slo cuando se requiera coordinacin entre funcionalidadesdelsistema. Si bien la estructura general es hub&spoke, cada componente independientetienesupropiaestructurainterna.Esascomotenemosque el sistema de recepcin de informacin y reportes de emergencia tiene tambin una estructura hub&spoke, donde cada spoke est distribuido geogrficamente en la ciudad, pudiendo despachar atencin de manera inmediata para responder a la emergencia de manera rpida. A su vez, el componente encargado de repartir informacin tiene una estructura P2P dedistribucindecontenidoparaaliviarlacargacomputacionalydetrfico de red que implica una estructura convencional de clientes servidor, sobre todo cuando la informacin provista es tan estructuralmente compleja comolainformacingeoreferenciada.
26
4.1.Diagrama de Contexto
27
4.2. Punto de Vista Funcional

Diagrama de Componentes del Sistema a Nivel Cero
Hub&Spoke
002
28
Diagrama de Componentes del Sistema a Nivel Uno
003
29
Diagrama de Componentes del Sistema de Comunicacin
P2P
004
30
Flujo de Control para el Reporte de una Emergencia

31
4.3. Punto de Vista de Despliegue

Despliegue Fsico del Sistema en la Ciudad
Hub&Spoke
005
32
Diagrama de Despliegue de Red del Sistema de Distribucin de Contenidos
P2P
Sis.Distribucindecontenidos
006
33
Diagrama de Red del Sistema de Distribucin de Contenidos
34
Modelo de Plataforma de Ejecucin
Modelo de Dependencia Tecnolgica

Componente ServidordeAplicaciones Plataforma SeguridadyAutenticacin Persistencia WebServer
Requiere GlassFishv2.1.1 JavaEE6 JAAS Oracle10g SunJavaSystemWebServer7
35
4.4. Punto de Vista de Informacin

Diagrama Esttico de Informacin(Clases)
36
Diagrama de Flujo de Informacin de Alto Nivel
37

38
4.5. Punto de Vista de Concurrencia

Manejo de Concurrencia a Alto Nivel
Componentede concurrencia (Proceso, threadoPool dethreads

39
Manejo de Concurrencia a Bajo Nivel

Arquitectura de SW

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Arquitectura de SW

Diunggah oleh

Hak Cipta:

Format Tersedia

Sis stemade d Adm ministra acinySoport tedeAtenci A naEm mergenc cias

Do ocument todeAr rquitectu ura de elSistem ma (SAD)

Rafa aelHumbe ertoClavijoOrtiz

1.1. Propsito y Audiencia

1.2. Organizacin del Documento

1.3. Terminologa y Definiciones

1.4. Documentos Relevantes

2.1. Problema a Resolver

2.2. Descripcin General del Sistema a Desarrollar

comprendeconcurrenciayescalabilidad)comoelatributoclavequeprovee valoragregadoalaaplicacin,dentrodeunaslimitacionesimpuestasporla tecnologaylosrequerimientosfuncionalesynofuncionalesdelsistema.

Expectativas Seesperaunsistemarobustocapazdeatender concurrentemente un gran nmero de

paraevitarerroresdeinterpretacinylatoma dedecisionesarbitrariasporpartedelos desarrolladoresalahoradela implementacin.

3.1. Motivadores de Negocio

Rangos Ninguno Bajo Moderado Fuerte MuyFuerte AsociacindelMotivador conelNegocio

Lograrqueparaunasituacindeemergenciadada,las muertesyheridasdelargoplazodisminuya,atravsde unamejorcoordinacinentreorganismosderescateyde salud. MedidadelImpacto Latasademuertesylesionesdeporvidaentreeltotaldelaspersonasenelsitiodela emergencia.

Rangos Ninguno Bajo Moderado Fuerte MuyFuerte AsociacindelMotivador conelNegocio

tarea,garantizandounamayorproporcinde emergenciasatendidasoportunamente. MedidadelImpacto Proporcindeemergenciasnoatendidasoportunamenteenlaciudad.

3.2. Restricciones de Tecnologa

Descripcin EstablecidaPor Alternativas Observaciones

Descripcin EstablecidaPor Alternativas Observaciones

Manejodeinformacingeo referenciada Elsistemadebesercapazdegestionarinformacingeo referenciada. AdministracinDistrital Ninguna Elsistemadebeposeermodelos(informacingeo referenciada)delreadecoberturacargadosdesdeantesde

Descripcin EstablecidaPor Alternativas Observaciones

Descripcin EstablecidaPor Alternativas Observaciones

AmbientedeDesarrolloy Ejecucin Elsistemadebeserdesarrolladoconelambientededesarrollo NetBeans6.5.1.,ydebecorrersobreGlassFishv2.1.1. ArquitectodeSoftware Ninguna Ninguna

Descripcin EstablecidaPor Alternativas Observaciones

Interfazdeautenticaciny autorizacin Elsistemadeberealizartodoelmanejodeautenticaciny autorizacinutilizandoJAAS. ArquitectodeSoftware Ninguna Ninguna

3.3. Restricciones de Negocio

Descripcin EstablecidaPor Alternativas Observaciones

Descripcin EstablecidaPor Alternativas Observaciones

Descripcin EstablecidaPor Alternativas Observaciones

Descripcin EstablecidaPor Alternativas Observaciones

3.4. Atributos de Calidad

3.4.1. Escenarios de Calidad

Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin

Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin

Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin

Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin

Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

EscenariodeCalidad# AtributodeCalidad Justificacin Fuente Estmulo Artefacto Ambiente Respuesta MedidadelaRespuesta

ConsideracinOperacional Descripcin general funcionalidad de

SistemadeAdministracinySoportede AtencinaEmergencias StakeholderAsociado Administracindistrital ID

ConsideracinOperacional Descripcin general funcionalidad de

Seccin5. PuntosdeVistayModelos Arquitecturales

4.2. Punto de Vista Funcional

Diagrama de Componentes del Sistema a Nivel Uno

Diagrama de Componentes del Sistema de Comunicacin

Flujo de Control para el Reporte de una Emergencia

4.3. Punto de Vista de Despliegue

Diagrama de Despliegue de Red del Sistema de Distribucin de Contenidos

Diagrama de Red del Sistema de Distribucin de Contenidos

Modelo de Plataforma de Ejecucin

Modelo de Dependencia Tecnolgica

Requiere GlassFishv2.1.1 JavaEE6 JAAS Oracle10g SunJavaSystemWebServer7

4.4. Punto de Vista de Informacin