Upload
wilson-donis
View
223
Download
0
Embed Size (px)
Citation preview
8/16/2019 Infante Kevin
1/100
Proyecto de Grado
Presentado ante la ilustre Universidad de Los Andes como requisito parcial para
obtener el T́ıtulo de Ingeniero de Sistemas
Desarrollo de un Sistema de Información Web
Centralizado para la CANTV del Estado Mérida
Por
Br. Kevin J. Infante O.
Tutor: Prof. Pablo Guillén
Asesor Industrial: Ing. José Velázquez
Junio 2009
c2009 Universidad de Los Andes, Mérida, Venezuela
8/16/2019 Infante Kevin
2/100
Desarrollo de un Sistema de Información Web Centralizado
para la CANTV del Estado Mérida
Br. Kevin J. Infante O.
Proyecto de Grado — Investigación de Operaciones, 89 páginas
Escuela de Ingenieŕıa de Sistemas, Universidad de Los Andes, 2009
Resumen: En el presente proyecto se realizó el diseño, desarrollo e implementación de
un Sistema de Información Web para la Red de CANTV Mérida, que incluye una base
de datos y los diferentes mapas que describen las redes secundaria, fibra óptica, urbana
e interurbana. Se utilizó el UML (Unified Modeling Language ) el cual es un lenguaje
gráfico para modelar, visualizar, especificar, construir y documentar un sistema de
software, como herramienta para el modelado de la base de datos con la que cuenta el
sistema. Dicho modelado permitió establecer con mayor facilidad las conexiones entre
las diferentes tablas y elementos de la base de datos. Para el desarrollo se utilizó el
manejador de base de datos MySQL.
Palabras claves: Sistema de Información Web, Bases de Datos, MySQL, Telefońıa,
Redes telefónicas.
Este trabajo fue procesado en LATEX.
8/16/2019 Infante Kevin
3/100
A mis padres por ser lo mejor
de mi vida y mi mayor ejemplo, gracias.
8/16/2019 Infante Kevin
4/100
8/16/2019 Infante Kevin
5/100
2.3.1 Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Lenguaje estructurado de consulta (SQL) . . . . . . . . . . . . . 17
2.3.3 El sistema de gestión de bases de datos MySQL . . . . . . . . . 17
2.3.4 Algunas caracteŕısticas de MySQL . . . . . . . . . . . . . . . . 18
2.4 Arquitectura orientada a servicios (SOA) . . . . . . . . . . . . . . . . . 19
2.5 Protocolo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Lenguaje de modelado unificado (UML) . . . . . . . . . . . . . . . . . 22
2.6.1 Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.2 Diagramas de componentes . . . . . . . . . . . . . . . . . . . . 23
2.6.3 Diagramas de objetos . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.4 Diagramas de despliegue . . . . . . . . . . . . . . . . . . . . . . 24
2.6.5 Diagramas de paquetes . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.6 Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . 24
2.6.7 Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . 25
2.6.8 Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . 25
2.7 El lenguaje de programación PHP . . . . . . . . . . . . . . . . . . . . . 25
3 Modelado de Negocios del Sistema de Información Centralizado
(SIC) 27
3.1 Modelado de negocios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Delimitación del sistema de negocios . . . . . . . . . . . . . . . 28
3.2 Ingenieŕıa de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Definición de los requisitos de software . . . . . . . . . . . . . . 29
3.2.2 Definición de requisitos según actores . . . . . . . . . . . . . . . 30
3.2.3 Clasificacíon de los requisitos y definición de prioridades . . . . 34
3.2.4 Definición de casos de uso . . . . . . . . . . . . . . . . . . . . . 36
3.2.5 Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . . 42
4 Diseño del Sistema de Información Centralizado (SIC) 44
4.1 Metas de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Definición del estilo arquitectónico . . . . . . . . . . . . . . . . . . . . 45
4.3 Diagrama de clases del sistema . . . . . . . . . . . . . . . . . . . . . . 49
8/16/2019 Infante Kevin
6/100
4.4 Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Diagramas de secuencias . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6 Diseño de la interfaz del usuario . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Fase de implementación y pruebas . . . . . . . . . . . . . . . . . . . . . 56
4.7.1 Implementación del sistema . . . . . . . . . . . . . . . . . . . . 56
4.7.2 Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.8 Entrega final del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Conclusiones y Recomendaciones 71
5.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Bibliograf́ıa 75
A 77
B 83
C 86
8/16/2019 Infante Kevin
7/100
8/16/2019 Infante Kevin
8/100
Índice de Figuras
1.1 Estructura de CANTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Estructura de CANTV Mérida . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Etapas del método watch . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Arquitectura orientada a servicios . . . . . . . . . . . . . . . . . . . . . 20
3.1 Delimitación del sistema de negocios . . . . . . . . . . . . . . . . . . . 28
3.2 Diagrama de actores del SIC . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Diagrama de caso de uso centralizar información . . . . . . . . . . . . . 37
3.4 Diagrama de caso de uso identificación . . . . . . . . . . . . . . . . . . 37
3.5 Diagrama de caso de uso mostrar información . . . . . . . . . . . . . . 38
3.6 Digrama de caso de uso modificar elemento . . . . . . . . . . . . . . . . 38
3.7 Diagrama de caso de uso reporte lista . . . . . . . . . . . . . . . . . . . 39
3.8 Diagrama de caso de uso eliminar elemento . . . . . . . . . . . . . . . . 39
3.9 Diagrama de caso de uso crear usuario . . . . . . . . . . . . . . . . . . 39
3.10 Diagrama de caso de uso modificar usuario . . . . . . . . . . . . . . . . 40
3.11 Diagrama de caso de uso insertar elemento . . . . . . . . . . . . . . . . 40
3.12 Diagrama de caso de uso subir mapa o diagrama . . . . . . . . . . . . . 40
4.1 Diagrama de despliegue del sistema . . . . . . . . . . . . . . . . . . . . 48
4.2 Diagrama de clases del SIC . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Diagrama de actividad de autenticar usuario . . . . . . . . . . . . . . . 51
4.4 Diagrama de actividad de consultar equipo . . . . . . . . . . . . . . . . 51
4.5 Diagrama de actividad de modificar equipo . . . . . . . . . . . . . . . . 52
4.6 Diagrama de secuencia de consultar equipo . . . . . . . . . . . . . . . . 52
viii
8/16/2019 Infante Kevin
9/100
4.7 Diagrama de secuencia de modificar equipo . . . . . . . . . . . . . . . . 53
4.8 Diagrama de secuencia de autenticar usuario . . . . . . . . . . . . . . . 53
4.9 Pantalla de inicio del sistema . . . . . . . . . . . . . . . . . . . . . . . 54
4.10 Pantalla principal de usuario . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11 Diagrama de flujo de pantallas . . . . . . . . . . . . . . . . . . . . . . . 56
4.12 Formulario dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.13 Filtro de consulta dinámico . . . . . . . . . . . . . . . . . . . . . . . . 58
4.14 Formulario dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.15 Modelo de la base de datos del SIC . . . . . . . . . . . . . . . . . . . . 61
4.16 Mensaje obtenido al ingresar usuario inválido . . . . . . . . . . . . . . 63
4.17 Mensaje obtenido al ingresar contraseña incorrecta . . . . . . . . . . . 63
4.18 Mensaje obtenido al intentar ingresar equipo con campos faltantes . . . 64
4.19 Lista de centrales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.20 Registro de acciones en SIC . . . . . . . . . . . . . . . . . . . . . . . . 64
4.21 Exportar archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.22 Información exportada a una hoja de cálculo . . . . . . . . . . . . . . . 65
4.23 Valores erróneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.24 Valores correctos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.1 Diagrama de estado de equipo . . . . . . . . . . . . . . . . . . . . . . . 77
A.2 Diagrama de estado de mapa o diagrama . . . . . . . . . . . . . . . . . 77
A.3 Diagrama de estado de usuario autenticado . . . . . . . . . . . . . . . . 77
A.4 Diagrama de estado de usuario . . . . . . . . . . . . . . . . . . . . . . 78
A.5 Diagrama de actividad de crear usuario . . . . . . . . . . . . . . . . . . 78
A.6 Diagrama de actividad de modificar usuario . . . . . . . . . . . . . . . 78
A.7 Diagrama de actividad de cerrar sesión . . . . . . . . . . . . . . . . . . 78
A.8 Diagrama de actividad de insertar equipo . . . . . . . . . . . . . . . . . 79A.9 Diagrama de actividad de eliminar equipo . . . . . . . . . . . . . . . . 79
A.10 Diagrama de actividad de listar reporte . . . . . . . . . . . . . . . . . . 79
A.11 Diagrama de actividad de subir mapa o diagrama . . . . . . . . . . . . 80
A.12 Diagrama de secuencia de crear usuario . . . . . . . . . . . . . . . . . . 80
A.13 Diagrama de secuencia de cerrar sesión . . . . . . . . . . . . . . . . . . 80
8/16/2019 Infante Kevin
10/100
A.14 Diagrama de secuencia de modificar usuario . . . . . . . . . . . . . . . 81
A.15 Diagrama de secuencia de insertar equipo . . . . . . . . . . . . . . . . . 81
A.16 Diagrama de secuencia de eliminar equipo . . . . . . . . . . . . . . . . 82
A.17 Diagrama de secuencia de listar reporte . . . . . . . . . . . . . . . . . . 82
A.18 Diagrama de secuencia de subir mapa o diagrama . . . . . . . . . . . . 82
C.1 Pantalla de crear usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 86
C.2 Pantalla de usuario buscado . . . . . . . . . . . . . . . . . . . . . . . . 86
C.3 Pantalla de buscar equipo . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.4 Pantalla de lista de equipos . . . . . . . . . . . . . . . . . . . . . . . . 87
C.5 Pantalla de lista de enlaces de fibra óptica . . . . . . . . . . . . . . . . 87
C.6 Pantalla de lista de mapas o diagramas . . . . . . . . . . . . . . . . . . 88
C.7 Pantalla de insertar enlace de fibra óptica . . . . . . . . . . . . . . . . 88
C.8 Pantalla de historial de acciones . . . . . . . . . . . . . . . . . . . . . . 89
C.9 Pantalla de diagrama de la red de fibra óptica . . . . . . . . . . . . . . 89
C.10 Pantalla de salida del sistema . . . . . . . . . . . . . . . . . . . . . . . 89
8/16/2019 Infante Kevin
11/100
Agradecimientos
Este documento no hubiera podido realizarse sin el aporte de todas las personas
e instituciones que intervinieron su tiempo y esfuerzo en algún momento sobre el
proyecto, y que gracias a su experiencia, interés, dedicación, apoyo y confianza hicieron
posible su realización. Por ello tengo que agradecerles:
A la ilustre Universidad de Los Andes, particularmente a la Escuela de Ingenieŕıa
de Sistemas, por contribuir en mi formación profesional.
Al profesor Pablo Guilĺen, por ser un excelente gúıa y un gran apoyo desde el
comienzo hasta el final del proyecto.
Al ingeniero José Velázquez por ser un buen mentor, guı́a y apoyo dentro de la
empresa, sin su ayuda no hubiera sido posible.
A todos los miembros del departamento de Conmutación, Transmisión y Datos de
CANTV del estado Mérida, su consejo y apoyo fueron fundamentales en la realización
de este proyecto.
A CANTV Mérida, por brindarme esta inigualable oportunidad de iniciar mi
desarrollo profesional.
A mis padres, por brindarme su apoyo incondicional y darme fuerza durante todo
el transcurso de mi carrera.
A todos aquellos amigos y compañeros, que de alguna forma intervinieron en la
realización de este trabajo, Gracias.
xi
8/16/2019 Infante Kevin
12/100
Caṕıtulo 1
Introducción
El 22 de Mayo de 2007, luego de un proceso de compra de acciones, el Estado
Venezolano concretó la nacionalización de la Compañı́a Anónima Nacional Teléfonos
de Venezuela (CANTV).
La CANTV declara como principio irrenunciable, que el acceso a las telecomuni-
caciones es un derecho humano fundamental. Por ese motivo llevará los servicios de
telecomunicaciones a todos los rincones del territorio nacional.
La CANTV ofrecerá servicios de telefonı́a básica a todo centro poblado con más de
500 personas, pondrá a disposición de los clientes de menores recursos una tarifa social a
comienzos del 2008 y reinvertirá el 60% de las ganancias de la empresa en función de las
necesidades de telecomunicaciones del pueblo venezolano. Como empresa del Estado,
CANTV impulsará también la construcción de una nueva estructura social en Venezuela
en la que priven valores de igualdad, solidaridad, participación y corresponsabilidad.
La CANTV alineada con la visión de páıs, se planteó los siguientes objetivos
estratégicos:
• Democratizar el servicio con justicia social: Ampliando la cobertura geográfica,
incluyendo a todos los segmentos de la población, ofreciendo tarifas justas y
solidarias para promover una competencia más equitativa, con atención particular
para cada segmento de la población para facilitar la integración al uso de las
telecomunicaciones.
• Potenciar la participación y el Poder Popular: Las comunidades se convierten
8/16/2019 Infante Kevin
13/100
1 Introducción 2
en aliadas en la prestación del servicio. En esta etapa, CANTV promueve la
participación protagónica de las comunidades organizadas, al tiempo que potencia
la labor de los Consejos Comunales.
• Garantizar autosostenibilidad de la empresa: La CANTV será eficiente en
sus operaciones, de manera de generar los recursos requeridos para acometer
proyectos con rentabilidad social, pero siempre asegurando la viabilidad
económica de la empresa.
• Convertirnos en empresa socialista del Estado: La empresa se ajustará al marco
legal de empresa pública e implantará el modelo laboral socialista, impulsando
la participación protagónica de los trabajadores como servidores públicos, bajoun esṕıritu de solidaridad y abriendo espacios para los Esquemas Asociativos
Solidarios con el fin de desarrollar el modelo de econoḿıa social.
• Avanzar hacia la soberańıa tecnológica: La CANTV apoyará la implantación del
software libre cumpliendo con el decreto 3.390 del Ministerio del Poder Popular
para la Ciencia y Tecnoloǵıa. Además, impulsará la apropiación tecnológica
por parte de los ciudadanos y ciudadanas, promoverá el desarrollo endógeno,
respaldará la formación de talentos nacionales y promoverá la sustitución de las
importaciones.
• Apalancar la transformación del Estado: La CANTV jugará un papel protagónico
en la transformación del Estado apalancando con el potencial que ofrecen las
tecnoloǵıas de información y comunicación para acercarse al ciudadano y servirlo
de manera más eficiente, ágil y confiable, facilitando a su vez su participación en
el diseño de las polı́ticas públicas que gúıan la acción del Estado.
• Apoyar la integración Nacional e Internacional: CANTV cobra una dimensióninternacional, expandiendo las fronteras tecnoĺogicas de la nacíon, bajo el
lineamiento del acuerdo ALBA, el proyecto satelital VENESAT-1, que servir á
para brindar apoyo a los programas sociales y del Estado y facilitar la
transferencia tecnológica. Asimismo, se apoyará la seguridad y la defensa
integral del Estado proveyendo una red de comunicaciones segura y de alcance
8/16/2019 Infante Kevin
14/100
1 Introducción 3
nacional. La CANTV asume el reto de crear la concepcíon socialista del
servicio de telecomunicaciones, abrir espacios reales para la participación de
las comunidades, colocar las innovaciones tecnológicas al servicio del pueblo,
convertirse en un motor de integración para los pueblos de la región, contribuir
a definir el perfil del Servidor Público Socialista y coadyuvar en el desarrollo del
modelo de econoḿıa social sustentable y endógeno.
“Misión”:
Somos la empresa estrat́egica del Estado venezolano operadora y proveedora
de soluciones integrales de telecomunicaciones e informática, corresponsable de la
soberanı́a y transformación de la nación, que potencia el poder popular y la integración
de la regíon, capaz de servir con calidad, eficiencia y eficacia, y con la participaciónprotagónica del pueblo, contribuyendo a la suprema felicidad social.
“Visión”:
Ser una empresa socialista operadora y proveedora de soluciones integrales de
telecomunicaciones e informática, reconocida por su capacidad innovadora, habilitadora
del desarrollo sustentable y de la integración nacional y regional, comprometida con la
democratización del conocimiento, el bienestar colectivo, la eficiencia del estado y la
soberanı́a nacional.
La estructura organizativa de la empresa se muestra en la figura 1.1.
Figura 1.1: Estructura de CANTV
8/16/2019 Infante Kevin
15/100
1.1 Estructura del documento 4
De manera más espećıfica se tiene la estructura organizativa del Estado Mérida,
que se muestra en la figura 1.2.
Figura 1.2: Estructura de CANTV Mérida
1.1 Estructura del documento
El presente proyecto se estructura de la siguiente manera:
El Capı́tulo 1, expone el planteamiento del problema, las metas a cumplir, en que se
justifica el proyecto, además de ofrecer los objetivos generales y espećıficos planteados.
El Caṕıtulo 2, muestra la metodologı́a usada durante el desarrollo, además muestra
los procesos y procedimientos necesarios para la elaboración de este sistema de
información Web.
El Capı́tulo 3, ofrece un breve resumen de los conceptos y herramientas ı́ntimamente
vinculados con el proyecto y que es necesario su conocimiento y utilización para el
desarrollo del mismo. Se habla acerca de los sistemas de informacíon, clasificación
y se hace mención del lenguaje de modelado unificado UML, las bases de datos y el
manejador de base de datos MySQL, entre otros.En el Caṕıtulo 4, se desarrolla el sistema enmarcado en el modelo de procesos
Watch, se comienza con la fase de modelado de negocios, pasando por el an álisis de
requisitos, hasta llegar a la fase de implementación y pruebas del sistema.
En el Caṕıtulo 5, se incluyen las conclusiones y recomendaciones del proyecto.
8/16/2019 Infante Kevin
16/100
1.2 Antecedentes 5
1.2 Antecedentes
La CANTV cuenta con muchas redes cableadas e inalámbricas, que deben ser
gestionadas por diferentes departamentos. La gestión operativa de la compañ́ıa en
las redes debe hacerse de manera rápida, organizada y con la mayor informacíon
actualizada a disposición. En la gestión operativa de las redes de CANTV cada
departamento tiene información correspondiente a la red en su área de acción. La
Gerencia Operativa de Mérida cree que la gestíon operativa no puede ser algo de
una sola persona o de un solo departamento. Cuando se genera un problema, aveŕıa,
chequeo o simplemente una revisión de rutina se debe acudir a la persona encargada
del área para que sea el o ella quien solvente el inconveniente. Para resolver problemas
se necesita información, información que posee el departamento al cual pertenece el
problema o necesidad, por lo tanto, si algún otro departamento necesita algún tipo de
información para resolver un problema, aveŕıa o necesidad, debe necesariamente acudir
a ese departamento y solicitar esa información, trámite que retarda la efectividad de
la empresa, además de resultar engorroso para su personal no tener la informaci ón a
la mano.
Describiendo un poco más a fondo este proceso, cada departamento tiene la
información de sus equipos y cada miembro de ese departamento tiene a su vez dicha
información, pero cuando uno de sus miembros realiza un cambio lo refleja en su base de
datos que no es compartida inmediatamente para el resto de las personas. De manera
que la información nunca esta actualizada a tiempo para todos los que la necesitan.
La CANTV cuenta con sistemas de información como el TAS (Trouble Administra-
tion System , por sus siglas en inglés) y ASAP (Automatización de Servicios de Atención
al Público) que poseen información de las capacidades de los elementos, ĺıneas, puertos
ABA (Acceso a Banda Ancha), clientes, aveŕıas de los clientes, entre otros. Pero no
posee información de los equipos de la red, marcas, ubicación, tecnologı́a, coordenadasy otras propiedades.
Al respecto, CANTV también cuenta con el SIR (Sistema Integral de la Red), el cual
es un sistema de inventarios masivo de la red de CANTV a nivel nacional desarrollado
durante los años 1999-2001 por personal de CANTV. El SIR es una herramienta muy
poderosa que nos servirá para buscar información en este sistema.
8/16/2019 Infante Kevin
17/100
8/16/2019 Infante Kevin
18/100
1.5 Objetivos 7
información y visualización de los mapas de la red.
1.5.2 Objetivos Espećıficos
1. Definir y analizar el dominio de aplicación, alcance e información.
2. Diseñar, identificar y especificar los requisitos del sistema que cumplan con
los requerimientos exigidos por CANTV, bajo un ambiente amigable y de fácil
manejo.
3. Construir, implementar y realizar pruebas del sistema de informacíon que
cumplan con la normativa de la empresa.
4. Presentar una visualización de la información de la red:
• Centrales Fijas
• Centrales Móviles
• URL
• Nodos outdoor
• ADS
• DLC
Aśı como los datos de los enlaces entre elementos:
• Estaciones
• Repetidoras
• Enlaces de radio
• Enlaces de fibra óptica
Y las propiedades de los elementos:
• Equipos
• Marcas
• Capacidades
8/16/2019 Infante Kevin
19/100
1.6 Metodoloǵıa 8
• Número de ĺıneas
• Frecuencias de transmisión y recepción
• Ubicación
• Coordenadas
• Dirección
Y además de otro tipo de información espećıfica de los diferentes componentes
de la red tales como: IP, bastidores, sub-bastidores, ranuras, puertos, posiciones,
tarjetas entre otros.
1.6 Metodoloǵıa
En este caṕıtulo de describen los procedimientos, procesos y métodos para realizar
el diseño e implementación del Sistema de Información Web.
Para el modelado del sistema se hizo uso del Lenguaje Unificado de Modelado
(UML, por sus siglas en inglés, Unified Modeling Language ), el cual es un lenguaje
de modelado de sistemas de software más conocido y utilizado en la actualidad,
está respaldado por el OMG (Object Management Group) y es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema de software. El UML
ofrece un estándar para describir un “plano” del sistema (modelo) incluyendo aspectos
conceptuales tales como: procesos de negocios y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, esquemas de bases de datos
y componentes de software reutilizables (Schmuller, 1997).
1.6.1 Revisión bibliográfica
En primer lugar se busca información bibliográfica de los conceptos y basamentos
teóricos sobre telefonı́a y redes telefónicas, igualmente se recopilará la documentación
acerca de algunas de las herramientas para el desarrollo de este tipo de proyecto.
Luego, se ofrece la investigación acerca del manejador de base de datos MySQL, el
cual es herramienta de desarrollo de este sistema.
8/16/2019 Infante Kevin
20/100
1.6 Metodoloǵıa 9
Posteriormente, se procede a investigar y recopilar informacíon sobre la im-
plantación de dicho sistema.
1.6.2 Proceso de desarrollo
Para el proceso de desarrollo de este proyecto se siguen las etapas propuestas en
el método Watch, el cual se expone muy bien en (Montilva and Barrios, 2003). Este
método consta de los siguientes modelos:
• Modelo del producto: Describe el tipo de producto que el método Watch
ayuda a generar. Se establecen las caracteŕısticas arquitectónicas generales de
una aplicación empresarial. En este caso las caracteŕısticas del sistema.
• Modelo del proceso: Es una descripcíon estructurada del conjunto de
actividades que el desarrollador debe seguir para generar una aplicación
empresarial y comprende las siguientes fases:
– Análisis del dominio de la aplicación: En esta fase se estudia el sistema
organizacional, es decir, las actividades y los procesos que son llevados por la
organización para lograr sus objetivos, se definen los actores que intervienen
en el desarrollo de las actividades del sistema, el dominio de aplicaciones
de dichas actividades y se modela la estructura funcional, describiendo las
funciones, procesos y tareas que se ejecutan.
– Definición y especificación de requerimientos: Los requerimientos
son las necesidades que deben ser satisfechas por el sistema programado
a partir de la manipulación y consulta de las bases de datos en el sistema
de información Web.
– Diseño del sistema: En esta fase se representa el diseño de la arquitecturadel sistema, el diseño del esquema conceptual de la base de datos y el diseño
de la interfaz Usuario/Sistema.
– Implantación del sistema: Es el proceso de convertir el esquema
modelado a uno que pueda ser directamente implementado con el uso de
8/16/2019 Infante Kevin
21/100
1.6 Metodoloǵıa 10
un manejador de base de datos, es decir, se lleva el modelo a un lenguaje de
programación.
• Modelo del desarrollador: Este modelo describe cómo el desarrollador debe
estar organizado cuáles son sus roles y tareas.
La figura 1.3 muestra las diferentes etapas comprendidas en el método Watch.1
Figura 1.3: Etapas del método watch
1Fuente (Montilva and Barrios, 2003).
8/16/2019 Infante Kevin
22/100
Caṕıtulo 2
Marco teórico
Para el desarrollo de este proyecto se hace necesario conocer un conjunto de
conceptos y herramientas. Al respecto, en este caṕıtulo se ofrece un breve resumen de
los conceptos y herramientas ı́ntimamente vinculados con el proyecto. Se comenzará
desarrollando el concepto de sistema de información, su clasificación y se define el tipo
de sistema de información que se considera este proyecto. Se hará mención a algunos
conceptos relacionados y se mencionan brevemente los aspectos mas resaltantes de las
bases de datos relacionales y del manejador de bases de datos MySQL. En cuanto a otras
herramientas utilizadas, se definirán algunos conceptos relacionados con el lenguaje demodelado unificado (UML) y se explicará la estructura y utilidad de los diagramas
utilizados en el proyecto; por último se hará mención del lenguaje de programación
PHP (Hypertext Preprocessor).
2.1 Sistemas de información
Un Sistema de Informacíon es un conjunto de componentes interrelacionados
que operan de manera sistemática para capturar, procesar, almacenar y distribuirinformación que sirva de apoyo a la toma de decisiones, la coordinación, el control y el
análisis dentro de una organización (Schmal and Cisternas, 2000). En ese sentido, de
acuerdo con Muñoz (2003) algunas de las caracteŕısticas que resultan necesarias para
cualquier Sistema de Información son:
8/16/2019 Infante Kevin
23/100
8/16/2019 Infante Kevin
24/100
2.1 Sistemas de información 13
de los datos y la información generada por el sistema, las personas encargadas de
analizar e interpretar la información pueden llevar a cabo la toma de decisiones.
Almacenamiento de la información: Permite que la información generada en
el proceso anterior pueda ser guardada para ser recuperada y utilizada más adelante.
Por lo general, la información es almacenada utilizando archivos y bases de datos que
utilizan como medio de almacenamiento los discos magnéticos o discos duros, los discos
compactos, los DVDs, entre otros.
Salida de la información: Es la capacidad que tiene un sistema de información
para mostrar la información procesada al exterior. La salida de un sistema puede ser la
entrada de otro sistema de información o módulo, o puede ser mostrada directamente
al usuario en el formato que éste desee.
2.1.2 Tipos de sistemas de información
En Barrios (2000) se clasifican los sistemas de informacíon basándose en tres
criterios: el grado de cobertura de las actividades organizacionales, el grado de apoyo
a la ejecución de las actividades en la organización y las tecnoloǵıas en las que se basa
su desarrollo 1. En este orden de ideas los sistemas se describen de acuerdo al grado
de cobertura de las actividades organizacionales:
Sistemas independientes (Sind): Surgen como resultado de requisitos
individuales de los miembros de una organización, apoyando las actividades del usuario
en forma completa y sujetos a las necesidades de éstos.
Sistemas integrados (SII): Están conformados por la conjunción y colaboración
de los sistemas de información ya existentes en la organización.
Sistemas organizacionales (SIO): Proporcionan un grado de cobertura e
integración total de las actividades y procesos organizacionales, aportando ası́ un grado
de apoyo máximo a la toma de decisiones.De acuerdo al apoyo brindado a la ejecución de las actividades organizacionales los
sistemas de información pueden ser:
Sistemas operacionales (SIOp): Son sistemas de bajo nivel que apoyan la
automatización de tareas y operaciones básicas dentro de una organización, tales como
1No obstante un sistema puede ser clasificado en m ás de uno de estos criterios.
8/16/2019 Infante Kevin
25/100
2.1 Sistemas de información 14
las actividades administrativas y de producción.
Sistemas gerenciales (SIGe): Están orientados a brindar apoyo a las actividades
de nivel gerencial y de coordinación dentro de una organización.
Sistemas de apoyo a la toma de decisiones (SATD): Son sistemas que
contribuyen de forma directa y expĺıcita al proceso de toma de decisiones dentro de
una organización, permitiendo visualizar el panorama organizacional desde el punto de
vista de los resultados y/o consecuencias de tomar alguna acción en un momento dado.
De acuerdo a las tecnoloǵıas en las que se basan, los sistemas de información pueden
ser:
• Sistemas cliente/servidor
• Sistemas basados en tecnoloǵıas Web
• Sistemas basados en agentes
• Sistemas basados orientados a servicios
Existe una cuarta clasificación de los sistemas de información en base al apoyo
de actividades organizacionales muy especializadas. Dentro de este grupo, se
encuentran los ya mencionados SATD, los Sistemas Expertos (SE) que incorporan
la automatización de “experticia humana” en la realización de determinada actividad
y Sistemas de Información Geográfica (SIG) que están relacionados con el manejo de
información geográfica o georeferenciados.
2.1.3 Sistemas de información Web
En Muñoz (2003) se define un Sistema de Información Web (SIW) como: Un sistema
de información que utiliza una arquitectura web para proporcionar información (datos)
y funcionalidad (servicios) a usuarios finales, a través de una interfaz de usuario basada
en presentación e interacción sobre dispositivos con capacidad de trabajar en la Web.
En este orden de ideas los SIW vaŕıan ampliamente en su ámbito, desde sistemas
de información, hasta sistemas de transacciones, incluso sistemas de servicios Web
distribuidos. En virtud de la definición anterior los SIW se clasifican como sigue:
8/16/2019 Infante Kevin
26/100
2.2 Servidor Web Apache 15
• Las Intranets, (las cuales dan apoyo al trabajo interno dentro de la Empresa)
• Los sitios de presencia en la Web, (los cuales son herramientas utilizadas para
alcanzar consumidores fuera de la empresa)
• Los sistemas de Comercio Electrónico, (los cuales dan apoyo a la interacción con
el consumidor)
• Las Extranets, (las cuales son un conjunto de sistemas internos y externos que
apoyan las comunicaciones entre la empresa y otras empresas)
Por lo general, los SIW manejan un gran volumen de datos que se encuentran en
fuentes heterogéneas, se maneja en distintos formatos, y en un conjunto de componentesque están por lo general codificados en diferentes lenguajes de programación y a su vez
distribuidos en diferentes plataformas. Al igual que los SI tradicionales, más allá que
una infraestructura para la entrega de información (en tiempo de ejecución), los SIW
deben proporcionar una infraestructura de desarrollo y mantenimiento que permita
manejar e interpretar los datos y que proporcione funcionalidades a los usuarios finales
para capturar, almacenar, procesar y mostrar la informacíon dando solución a sus
requerimientos.
Los SIW son diseñados, desarrollados y mantenidos con el propósito de alcanzar
objetivos espećıficos de los usuarios finales. Éstos objetivos deben constituir la base
del proyecto de desarrollo de todo SIW.
2.2 Servidor Web Apache
Apache es el servidor de Web por excelencia. Ha sido uno de los mayores éxitos
del software libre y su supremaćıa entre los servidores de Web no se ve amenazada
y hacen que cada vez millones de servidores reiteren su confianza en este programa
(Linux, 2009).
Una de las principales caracteŕısticas de Apache es su extensibilidad basada en una
gran modularidad de su código fuente lo que han facilitado la aparición de módulos
de extensión como PHP el cual evitará el uso de cgi-bins por completo, facilitando
8/16/2019 Infante Kevin
27/100
2.3 Bases de datos 16
ampliamente la programación de aplicaciones en el lado del servidor, especialmente en
el ámbito de uso de bases de datos.
2.3 Bases de datos
Una base de datos es una colección de datos relacionados, es decir, un conjunto
de hechos que pueden registrarse y que tienen un significado impĺıcito. Por lo general,
las bases de datos representan aspectos del mundo real y son diseñadas, construidas y
pobladas con datos que tienen un propósito especı́fico, se caracterizan por la coherencia
de los datos que la integran (Elmasri and Navathe, 2002). Hay cinco modelos principales
de bases de datos: el modelo jerárquico, el modelo en red, el modelo relacional, elmodelo de bases de datos deductivas y el modelo de bases de datos orientado a objetos.
Para el desarrollo del proyecto fue necesario manejar el concepto de bases de datos
relacionales que se menciona a continuación.
2.3.1 Bases de datos relacionales
Constituye el modelo más utilizado en la actualidad para el modelado de problemas
reales y la administración de datos de manera dinámica. Almacena la información en
varias tablas (filas y columnas de datos) o ficheros independientes y realiza búsquedas
que permiten relacionar datos que han sido almacenados en más de una tabla. Se basa
en el uso de relaciones, donde cada relación es una tabla compuesta por registros (las
filas de una tabla) y campos (las columnas de una tabla). En el modelo relacional
cada fila representa un hecho que normalmente se corresponde con un v́ınculo o una
entidad del mundo real. El nombre de la tabla y de las columnas ayuda a interpretar
el significado de los valores que están en cada fila. En el modelo relacional una fila
se denomina “tupla”, una cabecera de columnas se denomina “atributo” y la tabla sedenomina “relación”. En este modelo, el lugar y la forma en que se almacenen los datos
no tienen relevancia. Esto tiene la considerable ventaja de que es más fácil de entender
y de utilizar para un usuario esporádico de la base de datos. La información puede ser
recuperada o almacenada mediante “consultas” que ofrecen una amplia flexibilidad y
poder para administrar la información (Elmasri and Navathe, 2002).
8/16/2019 Infante Kevin
28/100
2.3 Bases de datos 17
2.3.2 Lenguaje estructurado de consulta (SQL)
Es un lenguaje de base de datos normalizado, utilizado por los diferentes manejadores
de bases de datos para realizar determinadas operaciones sobre los datos o sobrela estructura de los mismos. Está diseñado como un lenguaje amplio que incluye
instrucciones para definir, consultar y actualizar las bases de datos. Las funcionalidades
que proporciona el SQL van más allá de la simple consulta o recuperación de datos.
Esta a su vez permite definir los tipos de datos y manipular los datos. Además, el SQL
permite la concesión y denegación de permisos, la implementación de restricciones de
integridad, controles de transacción y la alteración de esquemas. El lenguaje SQL está
compuesto por comandos, cláusulas, operadores y funciones agregadas. Estos elementos
se combinan en las instrucciones para crear, actualizar y manipular las bases de datos
(Elmasri and Navathe, 2002).
2.3.3 El sistema de gestión de bases de datos MySQL
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario
con más de seis millones de instalaciones. Desde Enero de 2008 una subsidiaria de
SUN MICROSYSTEMS desarrolla MySQL como software libre en un esquema de
licenciamiento dual.Por un lado, se ofrece para cualquier uso compatible con la licencia GNU GPL,
pero para aquellas empresas que quieran incorporarlo en productos privativos deben
comprar a la empresa una licencia espećıfica que les permita este uso. Está desarrollado
en su mayor parte en ANSI C (Wikipedia, 2008c).
MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no
transaccional MyISAM, pero puede provocar problemas de integridad en entornos de
alta concurrencia en la modificación. En aplicaciones Web hay baja concurrencia en la
modificación de datos, y en cambio el entorno es intensivo en lectura de datos lo que
hace a MySQL ideal para este tipo de aplicaciones.
MySQL fue desarrollado bajo los lenguajes C y C++ y se destaca por su gran
adaptación a diferentes entornos de desarrollo, permitiendo su interacción con los
lenguajes de programación más utilizados como: PHP, Perl y Java y su integración
8/16/2019 Infante Kevin
29/100
2.3 Bases de datos 18
en distintos sistemas operativos.
Wikipedia (2008c) dice que MySQL es muy utilizado en aplicaciones Web, como
Drupal o phpBB, en diversas plataformas como Unix y por herramientas de seguimiento
de errores como Bugzilla. Su popularidad como aplicacíon web está muy ligada a PHP
que a menudo aparece en combinación con MySQL lo cual no es una excepción en este
proyecto.
Inicialmente MySQL carećıa de elementos considerados esenciales en las bases de
datos relacionales tales como: integridad referencial y transacciones. Estos elementos
atrajeron a los desarrolladores de páginas Web con contenido dinámico, justamente
por su simplicidad; aquellos elementos faltantes fueron llenados a medida que las
aplicaciones lo utilizaban.Poco a poco los elementos faltantes en MySQL están siendo incorporados tanto por
desarrollos internos como por desarrolladores de software libre.
2.3.4 Algunas caracteŕısticas de MySQL
Entre las caracteŕısticas disponibles en las últimas versiones de MySQL se pueden
destacar:
• Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidasigualmente
• Disponibilidad en gran cantidad de plataformas y sistemas
• Diferentes opciones de almacenamiento según si se desea velocidad en las
operaciones o el mayor número de operaciones disponibles
• Transacciones y claves foráneas
• Conectividad segura
• Replicación, búsqueda e indexación de campos de texto
8/16/2019 Infante Kevin
30/100
2.4 Arquitectura orientada a servicios (SOA) 19
2.4 Arquitectura orientada a servicios (SOA)
La SOA es vista como un marco para el desarrollo de productos de software. La
arquitectura orientada a servicios es un paradigma para utilizar y organizar servicios
distribuidos que pueden encontrarse bajo varios dominios y estar implementados
utilizando diferentes tecnoloǵıas. Esta arquitectura se basa en los conceptos de
escalabilidad y reutilización del software.
Por lo general, las organizaciones desarrollan funciones y aplicaciones que son útiles
para automatizar ciertas tareas dentro de los procesos de negocio. Sin embargo, muchas
veces una solución puede ser útil a nivel intermedio para varios procesos o unidades
dentro de la organización con fines diferentes.
El concepto de arquitectura orientada a servicios implica que los desarrolladores
creen un conjunto de funciones independientes entre śı llamadas servicios, que aceptan
llamadas y generan respuestas mediante interfaces bien definidas y que son puestas
a disposición de los clientes como utilidades que pueden ser reutilizadas por diversas
aplicaciones dentro de la organización.
La implementación de los servicios es transparente para los usuarios, ya que a éstos
no le interesa conocer más que el tipo y formato de las entradas admitidas y de las
salidas generadas por el servicio (Nickul, 2007).
En un ambiente SOA los nodos de la red hacen disponibles sus recursos a otros
participantes de la red como servicios independientes a los que tienen acceso de un
modo estandarizado. La mayoŕıa de las definiciones de SOA identifican la utilización
de Servicios Web en su implementación. No obstante se puede implementar SOA
utilizando cualquier tecnologı́a basada en servicios (Wikipedia, 2008a).
Las arquitecturas orientadas a servicios difieren de las arquitecturas orientadas a
objetos en que se encuentran formadas por servicios débilmente acoplados y altamente
interoperables. Estos servicios definen una estructura para comunicarse entre śı, quees independiente del lenguaje en que se encuentran implementados y el lenguaje de
programación. Todo ello buscando maximizar la reutilizacíon de los componentes
desarrollados en un sistema (Wikipedia, 2008a).
La arquitectura SOA es muy utilizada por las grandes organizaciones en la
8/16/2019 Infante Kevin
31/100
2.4 Arquitectura orientada a servicios (SOA) 20
actualidad, entre tantas cosas, por el hecho de permitir la creación o cambios en los
procesos de negocios automatizados de forma ágil, a través de una composición de
nuevos procesos utilizando las funcionalidades del negocio contenidas en las aplicaciones
actuales o futuras consumidas por medio de servicios Web. Una arquitectura de este
tipo es como la que se muestra en la figura 2.1. En esta figura se observa cómo los
componentes se distribuyen en tres capas:
• La capa de presentación es la que le da el formato a los datos recibidos desde el
bus de integración con el fin de que el usuario visualice la información en una
página Web
• El bus de integración, comprende la segunda capa en la que se encuentran losservicios Web del negocio; aśı como los objetos manipulados por esos servicios
y todos los servicios comunes para todas las funciones de negocio. Esta capa
implementa la lógica de negocios de la aplicación
• La capa de datos es la que mantiene la implementaci ón de las estructuras que
almacenan los datos de la aplicación (bases de datos).
Figura 2.1: Arquitectura orientada a servicios
8/16/2019 Infante Kevin
32/100
2.5 Protocolo SOAP 21
2.5 Protocolo SOAP
El SOAP es un protocolo de comunicación definido para el intercambio de
datos mediante el paso de mensajes en formato XML. Define los estándares para la
comunicación entre dos objetos de diferentes procesos a través de una conexión de
Internet. Este protocolo es utilizado para el acceso a servicios Web. El mismo permite
la llamada de procedimientos remotos mediante HTTP entre aplicaciones distribuidas
en distintos servidores.
Existen varios protocolos parecidos, como por ejemplo RMI de Java y ORPC de
CORBA. Sin embargo, DesarrolloWeb (2009b) dice que SOAP es uno de los más
utilizados y aceptados por las grandes compañ́ıas del mundo y las principales razones
de su éxito son:
• No esta asociado con ningún lenguaje: SOAP no especifica una API, por lo que
la implementación de la API se deja al lenguaje de programación y la plataforma
• No se encuentra fuertemente asociado a ningún protocolo de transporte: Un
mensaje de SOAP no es más que un documento XML, por lo que puede
transportarse utilizando cualquier protocolo capaz de transmitir texto
• No está atado a ninguna infraestructura de objeto distribuido: La mayoŕıa de
los sistemas de objetos distribuidos se pueden extender, y muchos de ellos ya lo
están para que admitan SOAP
• Aprovecha los est́andares existentes en la industria: Por ejemplo, SOAP
aprovecha XML para la codificación de mensajes, en lugar de utilizar su propio
sistema de tipo que ya están definidas en la especificación esquema de XML,
y como ya se ha mencionado, SOAP no define un medio de transporte para los
mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte
existentes como HTTP y SMTP
• Permite la interoperabilidad entre múltiples entornos: SOAP se desarrolló sobre
los estándares existentes de la industria por lo que las aplicaciones que se ejecuten
en plataformas con dichos estándares, pueden comunicarse mediante mensaje
8/16/2019 Infante Kevin
33/100
2.6 Lenguaje de modelado unificado (UML) 22
SOAP, con aplicaciones que se ejecuten en otras plataformas Existen varias
implementaciones de SOAP que proporcionan la estructura para definir servicios
Web bajo un lenguaje particular entre estas implementaciones.
2.6 Lenguaje de modelado unificado (UML)
El UML es un lenguaje gráfico para el modelado de sistemas de software que
permite representar gráficamente la estructura de un sistema, haciendo posible que
cualquier persona ajena o no al proceso de diseño lo pueda entender. Mediante UML
se pueden especificar, visualizar y documentar de manera expĺıcita las caracteŕısticas
de un sistema de software antes y durante su construcción. UML es sólo un lenguajepara el modelado por lo que su utilización es independiente del proceso de desarrollo,
aunque para su uso óptimo debe aplicarse en un proceso centrado en arquitectura,
dirigido a casos de uso, iterativo e incremental (Object Management Group, 2007).
El UML es lo suficientemente expresivo como para modelar pruebas del sistema,
sistemas de hardware, sistemas de negocios, el flujo de trabajo en una empresa, dise ño
de estructura de una organización, actividades de planificación de proyectos y sistemas
no informáticos.
El UML se deriva de la unificación de tres metodoloǵıas de análisis y diseño
orientada a objeto, tales como: la metodoloǵıa de Grady Booch (para la descripción
de conjuntos de objetos y sus relaciones), la técnica de modelado orientada a objetos
de James Rumbaugh OMT (Object-Modeling Technique) y la aproximación de Ivar
Jacobson OOSE (Object Oriented Software Engineering) mediante la metodologı́a de
casos de uso.
De estas tres metodoloǵıas, las de Rumbaugh y Booch se pueden clasificar como
metodoloǵıas directamente orientadas a objetos, mientras que la metodoloǵıa de
Jacobson está orientada al usuario, ya que todo su método se deriva de los escenarios
de uso del sistema.
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim
Rumbaugh de Rational Software Corporation que comenzaron a unificar sus métodos.
A finales de 1995, Ivar Jacobson y su compañ́ıa Objectory se incorporaron,
8/16/2019 Infante Kevin
34/100
2.6 Lenguaje de modelado unificado (UML) 23
aportando el método OOSE.
Los anteproyectos de UML empezaron a circular en la industria de software y
las reacciones resultantes trajeron modificaciones considerables. Conforme diversas
organizaciones vieron que el UML les resultaba útil a sus propósitos, estas fueron
agregando nuevos aportes.
En 1997 se produjo la versión 1.0 del UML y se puso a consideración del OMG
(Object Management Group), propuesto como un lenguaje de modelado estándar.
Desde entonces, UML ha atravesado una serie de revisiones y refinamientos hasta llegar
a su versión actual: UML 2.3 (Wikipedia, 2008b). Al respecto el UML está compuesto
por diversos elementos gráficos que se combinan para conformar diagramas. Como
se trata de un lenguaje, UML aporta las reglas para combinar tales elementos. Losdiagramas de UML permiten representar diversas perspectivas de un sistema, indicando
lo que supuestamente hará, pero no la forma como se implementará. En la versión 2.0
del UML, se define un total de 13 diagramas para representar la estructura y din ámica
del sistema. Sin embargo, para efectos del proyecto solo se utilizaron ciertos diagramas.
2.6.1 Diagramas de clases
Son estructuras estáticas que dan una visión general del conjunto de clases existentes
en el sistema modelado y las relaciones existentes entre cada una de ellas. Los
diagramas de clases constan de diagramas estáticos pues muestran las relaciones entre
las clases pero no especifican sus interacciones de manera dinámica. Los diagramas de
clases colaboran en lo referente al análisis y permiten al analista hablarle en su propia
terminoloǵıa, lo cual hace posible que los clientes indiquen importantes detalles de los
problemas que deben ser resueltos.
2.6.2 Diagramas de componentesLos diagramas de componentes son utilizados para modelar la estructura del software
y las dependencias entre sus componentes. Estos diagramas modelan y agrupan los
componentes del sistema en forma de paquetes, y a su vez muestran las interfaces de
los componentes, sus dependencias, relaciones e interacciones.
8/16/2019 Infante Kevin
35/100
2.6 Lenguaje de modelado unificado (UML) 24
2.6.3 Diagramas de objetos
Un objeto es una instancia de clase (una entidad que tiene valores espećıficos de
los atributos y acciones). Son parte de la vista estática del sistema. Los diagramasde objetos permiten modelar las instancias de las clases que fueron representadas en
el diagrama de clases. Estos diagramas muestran en un momento concreto del sistema
los objetos y sus relaciones. Pueden incorporar clases para mostrar la clase a la que
pertenece un objeto representado.
2.6.4 Diagramas de despliegue
Los diagramas de despliegue muestran la distribución f́ısica de los distintos nodos
que componen el sistema, la comunicación entre los nodos y la disposici ón de los
componentes sobre ellos. Un nodo es un recurso de ejecucíon tal como un computador,
un dispositivo o memoria. Permiten precisar la naturaleza del equipo. Los elementos
utilizados en la representación gráfica de estos diagramas son los mismos que son
utilizados en los diagramas de componentes.
2.6.5 Diagramas de paquetes
Los diagramas de paquetes permiten visualizar la distribución de los componentes
del sistema en paquetes y las dependencias entre los mismos.
2.6.6 Diagramas de actividades
Un diagrama de actividades ha sido diseñado para mostrar una visión simplificada
de lo que ocurre durante una operación o un proceso. Los diagramas de actividades
son utilizados para modelar el flujo de control de las actividades que tienen lugar a lo
largo del tiempo junto a las tareas concurrentes que pueden realizarse a la vez. Estos
diagramas muestra las interacciones entre las clases mediante el flujo de control de
actividades ordenadas cronológicamente con el fin de lograr la ejecución de un proceso
más complejo.
8/16/2019 Infante Kevin
36/100
2.7 El lenguaje de programación PHP 25
2.6.7 Diagramas de casos de uso
Los diagramas de casos de uso representan la forma como un usuario opera con el
sistema en desarrollo y la forma, tipo y orden en la que interactúan sus elementos. Loselementos implicados en un diagrama de casos de uso son:
Actores: Son entidades con un comportamiento definido y que realizan alguna
interacción con el sistema. Pueden representar usuarios, organizaciones u otros sistemas
informáticos.
Casos de uso: Son descripciones de las secuencias de acciones que se producen de
la interacción entre un actor y el sistema.
Relaciones entre casos de uso: Las relaciones entre los casos de uso pueden
ser de inclusión y extensión. Un caso de uso puede incluir a otro caso de uso como
parte de su procesamiento. Generalmente se asume que los casos de uso incluidos se
llamarán cada vez que se ejecute el camino base. Un caso de uso puede ser incluido
por uno o más casos de uso, ayudando ası́ a reducir la duplicación de funcionalidad al
factorizar el comportamiento común en los casos de uso que se reutilizan. Un caso de
uso puede extender el comportamiento de otro caso de uso t́ıpicamente cuando ocurren
situaciones excepcionales o cuando depende de ciertos criterios. Entonces el caso de uso
que “extiende” extend describe un comportamiento opcional del sistema a diferencia
de la relación “incluye” include que se da siempre que se realiza la interacción descrita.
2.6.8 Diagramas de secuencia
Representan la interacción ordenada entre los objetos de un sistema de acuerdo a
una secuencia temporal de eventos. En particular muestran los objetos que participan
en la interacción y los mensajes que intercambian en orden temporal (Schmuller, 1997).
2.7 El lenguaje de programación PHP
PHP: “Hypertext Preprocessor” es un lenguaje de programación del lado del servidor
diseñado originalmente para la generación de páginas Web dinámicas. Es un lenguaje
de programación interpretado o de script que permite insertar fragmentos de código
8/16/2019 Infante Kevin
37/100
2.7 El lenguaje de programación PHP 26
dentro de una página HTML y realizar determinadas acciones de una forma fácil y
eficiente sin tener que generar programas en un lenguaje distinto al HTML.
Por otra parte, PHP ofrece un sinf́ın de funciones para el aprovechamiento de las
potencialidades de bases de datos de una manera llana y sin complicaciones. PHP
generalmente se ejecuta en un servidor Web, tomando el código en PHP como su
entrada y creando páginas Web como salida.
PHP puede ser desplegado en la mayoŕıa de los servidores web y en casi todos los
sistemas operativos y plataformas sin costo alguno. PHP se encuentra instalado en
más de 20 millones de sitios web y en un millón de servidores (Wikipedia, 2008d).
Una de sus mayores ventajas es el parecido que posee con otros lenguajes
de programación estructurada como Perl y C que permiten a la mayoŕıa de losprogramadores crear aplicaciones complejas de manera muy sencilla, pues no se requiere
mucho tiempo para su aprendizaje.
Cuando un cliente hace una petición al servidor para que le env́ıe una página Web,
el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado y genera de
manera dinámica un contenido. El resultado es enviado por el int́erprete al servidor,
quien a su vez env́ıa la página HTML al cliente. Mediante extensiones es también
posible la generación de archivos de tipo PDF, Flash; aśı como imágenes en diferentes
formatos (Wikipedia, 2008d).Si bien, PHP no es un lenguaje completamente orientado a objetos, en su última
versión (versión 5.0) se incorporan varios constructores de programación orientada a
objetos. Su creación y desarrollo se da en el ámbito de los sistemas libres, bajo la
licencia GNU. Existen muchos editores y entornos integrados de desarrollo disponibles
en el mercado para desarrollar aplicaciones en PHP. Para el desarrollo del sistema se
utilizó el editor Quanta Plus en su versión 3.5.
8/16/2019 Infante Kevin
38/100
Caṕıtulo 3
Modelado de Negocios del Sistema
de Información Centralizado (SIC)
El presente caṕıtulo describe las fases de modelado del SIC. Como se mencionó
en los caṕıtulos anteriores para el desarrollo del sistema se utiliza el método watch en
su versión 2004. A continuación se describe cada una de las fases contempladas en
este método y que son aplicadas para obtener el sistema. Se comenzará explicando el
modelado de negocios realizado para la unidad organizativa de la CANTV en estudio
especı́ficamente la gerencia operativa del estado Mérida. Aśı mismo se presentan losrequisitos de la aplicación y los casos de uso modelados.
3.1 Modelado de negocios
En la fase de modelado de negocios resulta de vital importancia dentro del proceso
de desarrollo de un sistema de software, pues permite obtener un conocimiento más
a fondo del sistema de negocios u organización bajo la cual se enmarca el proyecto.
Para determinar de la mejor manera posible los requisitos del sistema es necesario y
esencial un conocimiento a profundidad del dominio de la aplicación. En el contexto
de aplicaciones empresariales, el dominio de aplicación se refiere a la organización o
sistema de negocios que será apoyada por la aplicación o SI, obteniendo como producto
final el modelo de negocios de la organización.
8/16/2019 Infante Kevin
39/100
3.2 Ingenieŕıa de requisitos 28
Un modelo de negocios es una representación que captura la estructura y dinámica
de la organización objetivo bajo la cual se incorporará el SI. Mediante el modelo de
negocios es posible obtener un conocimiento a profundidad de la organización, sus
problemas de información y los requisitos funcionales que deben ser satisfechos por el
SI (Montilva et al., 2000).
3.1.1 Delimitación del sistema de negocios
Dentro de la CANTV, la gerencia operativa del estado Mérida se encarga de
coordinar los diferentes departamentos que hacen posible el buen funcionamiento y
mantenimiento de su plataforma tecnológica. La ejecución de una buena coordinación
tiene como objetivo maximizar la productividad de sus trabajadores, minimizar el
tiempo de respuesta de las aveŕıas y de mejorar el servicio a los usuarios. Los diferentes
departamentos involucrados en el SIW poseen información importante referente a cada
una de sus áreas y la cual será manejada por el SIW. Los departamentos involucrados
en la gerencia operativa del estado Mérida se muestran en la figura 3.1.
Figura 3.1: Delimitación del sistema de negocios
3.2 Ingenieŕıa de requisitos
Dentro del método Watch , la fase de ingenieŕıa de requisitos comprende dos fases
primordiales: una de ellas es la definición y la otra es la especificación del conjunto de
requisitos funcionales y no funcionales del producto de software. En la fase de definición
8/16/2019 Infante Kevin
40/100
3.2 Ingenieŕıa de requisitos 29
se clasifican los requisitos y se les asigna prioridades de acuerdo con las necesidades del
cliente. También se lleva a cabo la negociación de los requisitos, siendo posible que el
equipo encargado del desarrollo proponga nuevos requisitos y modifique algunos de los
previamente establecidos, a fin de que exista compatibilidad entre los mismos.
La fase de especificación de requisitos deriva un conjunto de modelos en los que
se obtiene lo que será la arquitectura del sistema. Para la ingenieŕıa de requisitos del
SIC se comenzará realizando una descripción en lenguaje natural de los necesidades
expresadas por el cliente durante las reuniones y entrevistas. A partir de esta
descripción se realiza una clasificación de los requisitos en funcionales y no funcionales,
y a partir de los funcionales se generan los casos de uso del sistema.
3.2.1 Definición de los requisitos de software
Durante las diferentes reuniones y entrevistas realizadas a lo largo del desarrollo
del SIC y espećıficamente en la fase del modelado de negocios para el entendimiento
de la organización surgieron diferentes actores. En esta fase se enuncian los principales
actores dentro del proceso de desarrollo:
Cliente: Es el que tiene una necesidad y desea que ésta sea satisfecha. El cliente
solicita el desarrollo de un determinado sistema de software de acuerdo a sus problemas
y necesidades. Él aporta sus ideas y requerimientos al proceso de diseño del sistema.
En el caso del SIW a implementar, el cliente es la gerencia operativa de Mérida de
CANTV, particularmente el departamento de Conmutación, Transmisión y Datos.
Desarrolladores/Analistas: Los miembros del equipo de desarrolladores de-
sempeñan diferentes roles como por ejemplo: coordinador, analista de sistemas, pro-
motor de software, instructor y consejero o guı́a informático. Para satisfacer las necesi-
dades del cliente y la resolución de su problema, los desarrolladores intentaran cumplir
con sus requerimientos en caracterı́sticas especı́ficas de calidad.Usuarios finales del sistema: La experiencia y aportes brindados por las
personas a las cuales está dirigido el SIW son esenciales para el proceso de diseño y
desarrollo. En este caso, el grupo de usuarios finales del SIW hasta los momentos, está
constituido por el área de conmutación, transmisión, datos, operaciones centralizadas
que comprende los diferentes distribuidores y el personal que trabaja en las diferentes
8/16/2019 Infante Kevin
41/100
3.2 Ingenieŕıa de requisitos 30
centrales foráneas; además de personal de otras áreas como las de planta externa,
que necesita de la información contenida en el SIC. Sin embargo, se deben permitir
diferentes niveles de acceso a los usuarios del sistema con miras a que éste pueda ser
utilizado por miembros de otras unidades o gerencias. Por lo tanto, el sistema debe
manejar al menos los siguientes perfiles de usuario:
• Visitante: El visitante podrá realizar consultas a la base de datos del sistema.
• Usuario: Además de las acciones de visitante, el usuario podrá realizar consultas
sobre la base de datos del sistema y realizar modificaciones de registros sin poder
eliminar ningún tipo de información.
• Administrador: El perfil de administrador debe permitir tanto la consulta
sobre la base de datos del sistema como la modificación y eliminación de registros
erróneos o que carezcan de interés para el sistema de negocios y para los cuales
no tengan permiso los usuarios de perfil inferior.
• Super administrador: El super administrador debe ser capaz de acceder al
sistema para la corrección de fallas, la inserción de datos, consultas a la base de
datos, restablecer datos borrados erróneamente, crear nuevos usuarios, modificar
y eliminar usuarios, ingresar y eliminar gráficos (mapas o diagramas). Ademásde realizar todas las acciones sobre la bitácora o historial de uso del sistema.
En la figura 3.2 se muestra el diagrama de actores de SIC.
3.2.2 Definición de requisitos según actores
• Requisitos del cliente
1. El sistema debe contener la información más importante para cadadepartamento, mostrar la información de las propiedades de los elementos
para la gestión operativa, aśı como, el igual acceso por parte de cada uno
de ellos.
2. El sistema debe contener los diferentes mapas y diagramas de la red de
CANTV del estado Mérida.
8/16/2019 Infante Kevin
42/100
3.2 Ingenieŕıa de requisitos 31
Figura 3.2: Diagrama de actores del SIC
3. El sistema debe permitir el manejo de usuarios (creaci ón, modificación y
eliminación), además de manejar los perfiles de actores ya mencionados.
(Ver Figura 3.2).
4. El manejo de información debe permitir la inserción, modificación y
eliminación según los perfiles de actores ya mencionados. (Ver Figura 3.2).
5. La informacíon eliminada no debe ser borrada de manera definitiva, sino
pasar a un estado de “inactivo” y permanecer “oculta” para los usuarios a
excepción del Super Administrador.
6. El sistema debe contar con un manejo de histórico (bitácora) donde se
8/16/2019 Infante Kevin
43/100
3.2 Ingenieŕıa de requisitos 32
registren todas las acciones realizadas, bien sea de inserción, modificación
y/o eliminación de información.
7. Los estilos de letras de las páginas Web y los colores deben ser los
establecidos por CANTV.
8. Poseer una interfaz amigable, entendible y de fácil manejo para el usuario.
9. Todas las respuestas a las consultas al servidor de base de datos deben
ser lo más rápidas y eficientes posible, es por esto, que se ha definido el
tiempo máximo a 60 seg. Este tiempo solo se podrá exceder con una clara
justificación.
• Requisitos de los usuarios
1. El sistema debe permitir la inserción, modificación y eliminación individual
de los elementos y además debe contener la siguiente información básica:
a. Número del elemento o equipo.
b. Código del inventario.
c. Nombre del equipo.
d. Ubicación geográfica con coordenadas.
e. Capacidades de sus diferentes propiedades. Además de otros
mucho atributos espećıficos de cada uno de los equipos tales como: IP,
bastidores, sub-bastidores, ranuras, puertos, marcas entre otros.
2. El sistema debe mostrar al usuario la información para la gestión de
los registros, tales como: campos de observaciones, última modificación
realizada al registro, usuario que realizó la modificación y cuando lo hizo.
3. Para la búsqueda de información en áreas como operaciones centralizadas, el
sistema debe contar con campos de consulta directa, por ejemplo el númerotelefónico.
4. El sistema deberá poseer un buzón de actualizaciones pendientes, el cual
tiene como función notificar a los administradores que deben realizar
modificaciones o actualizaciones para las cuales los usuarios de bajo nivel
no poseen permiso.
8/16/2019 Infante Kevin
44/100
3.2 Ingenieŕıa de requisitos 33
5. El sistema debe permitir cerrar la sesión al usuario actual.
6. La sesión se cerrará automáticamente luego de determinado tiempo. Al
respecto la sesión de PHP es de 24 minutos, por tal motivo este ser á eltiempo de sesión del SIC.
7. Los errores en la inserción de información por parte del usuario deben ser
notificados.
8. Los usuarios se crearán con una contraseña por defecto y ésta puede y debe
ser cambiada por cada usuario.
9. El sistema debe incorporar filtros de búsqueda, es decir, consultas a la base
de datos por todos los campos.
10. El sistema debe permitir la extracción de información en hojas de cálculo
para que puedan servir de apoyo en la toma de decisiones.
• Requisitos del desarrollador
1. El software se deberá implantar con el lenguaje de programación PHP en el
lado del servidor y contenidos en HTML y Javascript en el lado del cliente.
2. El sistema gestor de bases de datos debe ser MySQL.
3. El equipo donde se ejecute el sistema debe tener las siguientes caracterı́sticas:
a. Memoria principal de al menos 512 MB.
b. Procesador mayor a 1.0 Ghz.
c. Disco duro de al menos 40 GB.
d. Un monitor.
e. Un ratón.
f. Un Teclado.
g. Una tarjeta de video de 32 MB.
h. Una tarjeta de red con capacidad de conexión a la intranet de
CANTV.
i. El sistema operativo Windows XP, Vista o Linux en cualquier
distribución.
8/16/2019 Infante Kevin
45/100
3.2 Ingenieŕıa de requisitos 34
j. Navegador Mozilla Firefox 3.0.
3.2.3 Clasificación de los requisitos y definición de prioridades
Requisitos funcionales: Describen las funciones y servicios que el sistema debe
hacer. Están dirigidos a cómo el sistema hace las cosas.
Requisitos no funcionales: Describen las diferentes respuestas que debe dar el
sistema ante los distintos tipos de errores los cuales imponen restricciones y atributos.
Además de clasificarse, los requisitos son priorizados dependiendo de su importancia
para el desarrollo del producto de software y el resultado que se desea obtener. Es por
esto que los requisitos se clasifican con números del 1 al 10, siendo el 1 la prioridad más
alta (requisito obligatorio) y el 10 la prioridad más baja (requisito casi prescindible).
La Tabla 3.1 muestra la clasificación de los requisitos.
Tabla 3.1: Especificación de los requisitos
N◦ de Nombre del Requisito Clasificación Prioridad Tipo de
Requisito Requisito
R1 Centralizar la información No Funcional 1 Aseguramiento
importante para cada de la calidad
departamento (Igual acceso).
R2 Mostrar la información de las Funcional 2 Funcionalidad
propiedades de los elementos
para la gestión operativa.
R3 Contener los diferentes mapas Funcional 1 Funcionalidad
de Mérida, red secundaria,
fibra óptica y diagramas.
R4 Permitir la gestión de usuarios Funcional 4 Funcionalidad
R5 Capacidad para insertar, Funcional 2 Funcionalidad
modificar y eliminar información
según los niveles de seguridad.
R6 La información eliminada no Funcional 2 Funcionalidad
debe ser borrada, solo ocultada.
8/16/2019 Infante Kevin
46/100
3.2 Ingenieŕıa de requisitos 35
N◦ de Nombre del Requisito Clasificación Prioridad Tipo de
Requisito Requisito
R7 Registrar cuando se inserta, Funcional 5 Funcionalidad
modifica y/o elimina un elemento
existente en el sistema, quien y
cuando.
R8 Generar reportes o listados de Funcional 6 Funcionalidad
los elementos almacenados en
el sistema.
R9 Identificar los diferentes Funcional 5 Seguridad
usuarios con sus diferentes
perfiles.R10 Permitir insertar o eliminar un Funcional 5 Funcionalidad
mapa o diagrama en el sistema.
R11 Desarrollado bajo la plataforma No Funcional 1 Restricción
de software libre.
R12 Varios niveles de usuario. 1 Funcional 5 Seguridad
super administrador, varios
administradores, varios usuarios.
Con sus diferentes niveles de
acceso.
R13 Permitir cerrar sesión Funcional 3 Funcionalidad
R14 El software se debe implantar No Funcional 3 Restricción
con el lenguaje de programación
PHP en el lado del servidor y
contenidos en HTML y
Javascript en el lado del cliente.
R15 El gestor manejador de base de No Funcional 3 Restricción
datos debe ser MySQL.R16 El equipo donde se ejecute el No Funcional 4 Restricción
sistema debe tener ciertas
caracterı́sticas.
R17 El acceso al sistema debe ser a No Funcional 3 Restricción
través de la intranet de CANTV.
8/16/2019 Infante Kevin
47/100
3.2 Ingenieŕıa de requisitos 36
N◦ de Nombre del Requisito Clasificación Prioridad Tipo de
Requisito Requisito
R18 La interfaz debe ser amigable y No Funcional 4 Aseguramiento
de fácil manejo. de la calidad
R19 La respuesta a las consultas al No Funcional 5 Aseguramiento
servidor de base de datos deben de la calidad
ser lo más rápidas y eficientes
posible.
R20 El estilo de letra y colores No Funcional 5 Aseguramiento
deben ser los usados por CANTV. de la calidad
R21 El sistema debe manejar un Funcional 1 Funcionalidad
histórico o bitácora.
Vale la pena mencionar que a pesar de que el producto aqúı mostrado es resultado
de un proceso de refinamiento y validación junto al cliente, en la medida que se sigue
avanzando en el desarrollo del sistema los requisitos de los actores involucrados y sus
expectativas respecto al sistema cambian constantemente. Por ello se trata de mantener
la recopilación inicial de requisitos, negociando con el cliente aquellos que surgieran
sobre la marcha. De ese modo se trata de abarcar todos los requisitos enunciados.
3.2.4 Definición de casos de uso
La elaboración de los casos de uso se realiza clasificando las funciones según los
diferentes actores del sistema. La jerarqúıa de actores se mostró en la figura 3.2.
En la figura 3.3 se muestra el caso de uso para ejemplificar la centralizaci ón de
información, es decir, la implementación de un servidor para almacenar la información.
Por su parte la figura 3.4 explica el caso de uso para la identificación de un usuario
cualquiera y dar acceso al sistema.
8/16/2019 Infante Kevin
48/100
3.2 Ingenieŕıa de requisitos 37
Figura 3.3: Diagrama de caso de uso centralizar información
Figura 3.4: Diagrama de caso de uso identificación
8/16/2019 Infante Kevin
49/100
3.2 Ingenieŕıa de requisitos 38
A continuación se muestran los diagramas de casos de uso más importantes del
sistema:
Figura 3.5: Diagrama de caso de uso mostrar información
Figura 3.6: Digrama de caso de uso modificar elemento
8/16/2019 Infante Kevin
50/100
3.2 Ingenieŕıa de requisitos 39
Figura 3.7: Diagrama de caso de uso reporte lista
Figura 3.8: Diagrama de caso de uso eliminar elemento
Figura 3.9: Diagrama de caso de uso crear usuario
8/16/2019 Infante Kevin
51/100
3.2 Ingenieŕıa de requisitos 40
Figura 3.10: Diagrama de caso de uso modificar usuario
Figura 3.11: Diagrama de caso de uso insertar elemento
Figura 3.12: Diagrama de caso de uso subir mapa o diagrama
8/16/2019 Infante Kevin
52/100
3.2 Ingenieŕıa de requisitos 41
Descripción de los casos de uso:
Para una mayor comprensión de la secuencia de tareas asociadas a los casos de uso,
se hace una breve descripción de cada uno de ellos en la tabla 3.2.
Tabla 3.2: Casos de uso del sistemaCaso Nombre del Caso Descripción
de Uso de Uso
CU1 Ingresar al sistema. El usuario introduce su indicador (nombre de usuario de la red
de CANTV) y su contraseña en la ventana de inicio del sistema.
CU2 Identificar perfil de El sistema verifica el nombre del usuario y la contraseña, dándole
usuario. acceso a un conjunto de funcionalidades de acuerdo a su perfil.
CU3 Consultar Centrales. El usuario introduce el estado, municipio y tipo de central. El sis-
tema generará una lista de las centrales.
CU4 Consultar ADS. El usuario introduce el estado, municipio y central a la que perte-
nece el ADS. El sistema generará una lista de los ADS.
CU5 Consultar Estaciones. El usuario introduce el estado y el municipio de la estacíon. El
sistema generará una lista de las estaciones.
CU6 Consultar Repetidoras. El usuario introduce el estado y el municipio de la repetidora. El
sistema generará una lista de las repetidoras.
CU7 Consultar Enlaces de El usuario introduce el estado, municipio y central o la estacíon,
Fibra Óptica. repetidora tanto del origen como del destino. El sistema generará
una lista de enlaces entre estos dos puntos.
CU8 Consultar Enlaces de El usuario introduce el estado, municipio y central o la estacíon,
Radio. repetidora tanto del origen como del destino. El sistema generaŕa
una lista de los enlaces entre estos dos puntos.
CU9 Consultar TCP-IP El usuario introduce el estado, municipio y central en donde se
RAS. encuentra el bastidor TCP-IP. El sistema generará una lista con
la información de cada ranura del bastidor.
CU10 Consultar Elementos El usuario introduce el estado, municipio, central y tipo de
de Datos. elemento de datos. El sistema generará una lista de los elementos
de datos.
CU11 Consultar Mapas o El usuario introduce el estado de donde quiera ver los mapas o
Diagramas. diagramas. El sistema generará una lista de los mapas o diagra-
mas para que el usuario posteriormente los visualice.
CU12 Consultar hist́orico o El usuario introduce la fecha o rango de fechas y el sistema
bitácora del sistema. generará una lista de acciones realizadas.
8/16/2019 Infante Kevin
53/100
3.2 Ingenieŕıa de requisitos 42
Caso Nombre del Caso Descripción
de Uso de Uso
CU13 Modificar Elementos Una vez consultado el equipo o elemento del sistema se edita o
del sistema. actualiza la información. El sistema notificará de la modificación.
CU14 Eliminar un Elemento Luego de la consulta del elemento de elimina (marcar como
del sistema. eliminado). El sistema notificaŕa de la eliminación.
CU15 Insertar un Elemento El usuario elige el tipo de elemento para introducir la información
en el sistema. correspondiente e inserta el elemento. El sistema notificará de
la inserción.
CU16 Reporte Lista. Luego de la consulta del elemento en el sistema el usuario
selecciona exportar lista. El sistema generará una hoja de cálculo
con la lista de elementos buscados anteriormente.
CU17 Crear Usuario. El usuario con el perfil para crearlo introduce los datos y crea el
usuario. El sistema notificará la creación.
CU18 Modificar Usuario. El usuario consulta el usuario deseado, edita o actualiza la
información. El sistema notificará de la modificación.
CU19 Cerrar Sesíon. El usuario cierra la sesión actual en el sistema.
CU20 Registrar Accíon. La acción realizada por el usuario es almacenada en la base de datos.
3.2.5 Matriz de casos de uso vs. requisitos
Parte fundamental y esencial del proceso de ingenieŕıa de requisitos es la validación
y verificación de los requisitos del sistema. Mediante la matriz de Casos de Uso vs.
Requisitos es posible determinar si los requisitos del cliente fueron satisfechos con los
casos de uso especificados. En la matriz de la tabla 3.3 se observa como cada requisito
se ve incluido en por lo menos un caso de uso, por lo que se han cubierto todos los
requisitos funcionales del SIC.
8/16/2019 Infante Kevin
54/100
3.2 Ingenieŕıa de requisitos 43
Tabla 3.3: Matriz de casos de uso vs. requisitos
R
CUC U1 CU 2 CU 3 CU 4 C U5 C U6 CU 7 CU 8 CU 9 CU1 0 CU 11 CU 12 C U1 3 CU 14 CU1 5 C U1 6 CU 17 C U1 8 CU 19 CU2 0
R2 ok ok ok ok ok ok ok ok
R3 ok
R4 ok ok
R5 ok ok ok
R6 ok
R7 ok
R8 ok
R9 ok ok
R10 ok
R13 ok
R21 ok
8/16/2019 Infante Kevin
55/100
Caṕıtulo 4
Diseño del Sistema de Información
Centralizado (SIC)
Una vez terminada la tarea de especificación y definición de los requisitos, se
procede a diseñar el sistema. La fase de diseño pretende determinar la estructura de
la aplicación a fin de satisfacer los requisitos obtenidos en el procedimiento anterior,
estableciendo la interconexión de los distintos subsistemas que la conforman, junto
con los parámetros que regulan que el sistema apoye los procesos de la organización
y cumpla con los objetivos que fueron prefijados. Dentro de esta fase se estableceel conjunto de metas con las que debe cumplir el diseño, se determina cuáles de los
requerimientos se encuentran relacionados con la arquitectura del sistema, se describe
la arquitectura, se diseña la interfaz usuario/sistema y se diseña la base de datos.
4.1 Metas de diseño
Buscando que el desarrollo de la aplicación realmente satisfaga las necesidades de
los actores involucrados en él y que además cumpla con los estándares de rendimiento
esperados, se hace necesario fijar ciertas metas en esta fase de diseño. Las metas
propuestas para el diseño se enuncian a continuación:
• La arquitectura del sistema estará basada en el uso de servicios Web que estarán
claramente especificados y que podrán ser reutilizados por cualquier componente
8/16/2019 Infante Kevin
56/100
4.2 Definición del estilo arquitectónico 45
que los necesite.
• Los componentes diseñados van a buscar cumplir los requisitos de los actores
involucrados de la manera más eficiente posible.
• La arquitectura estará basada en la utilización de componentes modulares bien
estructurados y con entradas y salidas claramente definidas.
• El diseño será fácil de entender, manejar y modificar, permitiendo probar y
detectar fallas rápidamente.
• El diseño se caracterizará por una alta cohesión de los componentes dentro
de cada subsistema y un bajo acopl