Infante Kevin

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 Información Web

Centralizado para la CANTV del Estado Mérida

Por

Br. Kevin J. Infante O.

Tutor: Prof. Pablo Guillén

Asesor Industrial: Ing. José Velázquez

Junio 2009

c2009 Universidad de Los Andes, Mérida, Venezuela


2/100

Desarrollo de un Sistema de Información Web Centralizado

para la CANTV del Estado Mérida

Br. Kevin J. Infante O.

Proyecto de Grado — Investigación de Operaciones, 89 páginas

Escuela de Ingenieŕıa de Sistemas, Universidad de Los Andes, 2009

Resumen: En el presente proyecto se realizó el diseño, desarrollo e implementación de

un Sistema de Información Web para la Red de CANTV Mérida, que incluye una base

de datos y los diferentes mapas que describen las redes secundaria, fibra óptica, urbana

e interurbana. Se utilizó el UML (Unified Modeling Language ) el cual es un lenguaje

grá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 permitió establecer con mayor facilidad las conexiones entre

las diferentes tablas y elementos de la base de datos. Para el desarrollo se utilizó el

manejador de base de datos MySQL.

Palabras claves: Sistema de Información Web, Bases de Datos, MySQL, Telefońıa,

Redes telefónicas.

Este trabajo fue procesado en LATEX.


3/100

A mis padres por ser lo mejor

de mi vida y mi mayor ejemplo, gracias.


4/100


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 gestión de bases de datos MySQL . . . . . . . . . 17

2.3.4 Algunas caracteŕı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 programación PHP . . . . . . . . . . . . . . . . . . . . . 25

3 Modelado de Negocios del Sistema de Información Centralizado

(SIC) 27

3.1 Modelado de negocios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Delimitación del sistema de negocios . . . . . . . . . . . . . . . 28

3.2 Ingenieŕıa de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Definición de los requisitos de software . . . . . . . . . . . . . . 29

3.2.2 Definición de requisitos según actores . . . . . . . . . . . . . . . 30

3.2.3 Clasificacíon de los requisitos y definición de prioridades . . . . 34

3.2.4 Definición de casos de uso . . . . . . . . . . . . . . . . . . . . . 36

3.2.5 Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . . 42

4 Diseño del Sistema de Información Centralizado (SIC) 44

4.1 Metas de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Definición del estilo arquitectónico . . . . . . . . . . . . . . . . . . . . 45

4.3 Diagrama de clases del sistema . . . . . . . . . . . . . . . . . . . . . . 49


6/100

4.4 Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.5 Diagramas de secuencias . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.6 Diseño de la interfaz del usuario . . . . . . . . . . . . . . . . . . . . . . 54

4.7 Fase de implementación y pruebas . . . . . . . . . . . . . . . . . . . . . 56

4.7.1 Implementació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


7/100


8/100

Índice de Figuras

1.1 Estructura de CANTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Estructura de CANTV Mérida . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Etapas del método watch . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Arquitectura orientada a servicios . . . . . . . . . . . . . . . . . . . . . 20

3.1 Delimitación del sistema de negocios . . . . . . . . . . . . . . . . . . . 28

3.2 Diagrama de actores del SIC . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Diagrama de caso de uso centralizar información . . . . . . . . . . . . . 37

3.4 Diagrama de caso de uso identificación . . . . . . . . . . . . . . . . . . 37

3.5 Diagrama de caso de uso mostrar informació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


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 dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.13 Filtro de consulta dinámico . . . . . . . . . . . . . . . . . . . . . . . . 58

4.14 Formulario dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.15 Modelo de la base de datos del SIC . . . . . . . . . . . . . . . . . . . . 61

4.16 Mensaje obtenido al ingresar usuario inválido . . . . . . . . . . . . . . 63

4.17 Mensaje obtenido al ingresar contraseñ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 Información exportada a una hoja de cálculo . . . . . . . . . . . . . . . 65

4.23 Valores erró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 sesió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 sesión . . . . . . . . . . . . . . . . . . 80


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 óptica . . . . . . . . . . . . . . . . 87

C.6 Pantalla de lista de mapas o diagramas . . . . . . . . . . . . . . . . . . 88

C.7 Pantalla de insertar enlace de fibra óptica . . . . . . . . . . . . . . . . 88

C.8 Pantalla de historial de acciones . . . . . . . . . . . . . . . . . . . . . . 89

C.9 Pantalla de diagrama de la red de fibra óptica . . . . . . . . . . . . . . 89

C.10 Pantalla de salida del sistema . . . . . . . . . . . . . . . . . . . . . . . 89


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 algún momento sobre el

proyecto, y que gracias a su experiencia, interés, dedicación, apoyo y confianza hicieron

posible su realización. Por ello tengo que agradecerles:

A la ilustre Universidad de Los Andes, particularmente a la Escuela de Ingenieŕıa

de Sistemas, por contribuir en mi formación profesional.

Al profesor Pablo Guilĺen, por ser un excelente gúıa y un gran apoyo desde el

comienzo hasta el final del proyecto.

Al ingeniero José Velá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 Conmutación, Transmisión y Datos de

CANTV del estado Mérida, su consejo y apoyo fueron fundamentales en la realización

de este proyecto.

A CANTV Mé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 compañeros, que de alguna forma intervinieron en la

realización de este trabajo, Gracias.

xi


12/100

Caṕıtulo 1

Introducción

El 22 de Mayo de 2007, luego de un proceso de compra de acciones, el Estado

Venezolano concretó la nacionalización de la Compañı́a Anónima Nacional Telé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 llevará los servicios de

telecomunicaciones a todos los rincones del territorio nacional.

La CANTV ofrecerá servicios de telefonı́a básica a todo centro poblado con más de

500 personas, pondrá a disposición de los clientes de menores recursos una tarifa social a

comienzos del 2008 y reinvertirá el 60% de las ganancias de la empresa en función de las

necesidades de telecomunicaciones del pueblo venezolano. Como empresa del Estado,

CANTV impulsará también la construcción de una nueva estructura social en Venezuela

en la que priven valores de igualdad, solidaridad, participación y corresponsabilidad.

La CANTV alineada con la visión de páıs, se planteó los siguientes objetivos

estratégicos:

• Democratizar el servicio con justicia social: Ampliando la cobertura geográfica,

incluyendo a todos los segmentos de la población, ofreciendo tarifas justas y

solidarias para promover una competencia más equitativa, con atención particular

para cada segmento de la población para facilitar la integración al uso de las

telecomunicaciones.

• Potenciar la participación y el Poder Popular: Las comunidades se convierten


13/100

1 Introducción 2

en aliadas en la prestación del servicio. En esta etapa, CANTV promueve la

participación protagónica de las comunidades organizadas, al tiempo que potencia

la labor de los Consejos Comunales.

• Garantizar autosostenibilidad de la empresa: La CANTV será eficiente en

sus operaciones, de manera de generar los recursos requeridos para acometer

proyectos con rentabilidad social, pero siempre asegurando la viabilidad

económica de la empresa.

• Convertirnos en empresa socialista del Estado: La empresa se ajustará al marco

legal de empresa pública e implantará el modelo laboral socialista, impulsando

la participación protagónica de los trabajadores como servidores públicos, bajoun esṕıritu de solidaridad y abriendo espacios para los Esquemas Asociativos

Solidarios con el fin de desarrollar el modelo de econoḿıa social.

• Avanzar hacia la soberańıa tecnológica: La CANTV apoyará la implantación del

software libre cumpliendo con el decreto 3.390 del Ministerio del Poder Popular

para la Ciencia y Tecnoloǵıa. Además, impulsará la apropiación tecnológica

por parte de los ciudadanos y ciudadanas, promoverá el desarrollo endógeno,

respaldará la formación de talentos nacionales y promoverá la sustitución de las

importaciones.

• Apalancar la transformación del Estado: La CANTV jugará un papel protagónico

en la transformación del Estado apalancando con el potencial que ofrecen las

tecnoloǵıas de información y comunicación para acercarse al ciudadano y servirlo

de manera más eficiente, ágil y confiable, facilitando a su vez su participación en

el diseño de las polı́ticas públicas que gúıan la acción del Estado.

• Apoyar la integración Nacional e Internacional: CANTV cobra una dimensióninternacional, expandiendo las fronteras tecnoĺogicas de la nacíon, bajo el

lineamiento del acuerdo ALBA, el proyecto satelital VENESAT-1, que servir á

para brindar apoyo a los programas sociales y del Estado y facilitar la

transferencia tecnológica. Asimismo, se apoyará la seguridad y la defensa

integral del Estado proveyendo una red de comunicaciones segura y de alcance


14/100

1 Introducción 3

nacional. La CANTV asume el reto de crear la concepcíon socialista del

servicio de telecomunicaciones, abrir espacios reales para la participación de

las comunidades, colocar las innovaciones tecnológicas al servicio del pueblo,

convertirse en un motor de integración para los pueblos de la región, contribuir

a definir el perfil del Servidor Público Socialista y coadyuvar en el desarrollo del

modelo de econoḿıa social sustentable y endógeno.

“Misión”:

Somos la empresa estrat́egica del Estado venezolano operadora y proveedora

de soluciones integrales de telecomunicaciones e informática, corresponsable de la

soberanı́a y transformación de la nación, que potencia el poder popular y la integración

de la regíon, capaz de servir con calidad, eficiencia y eficacia, y con la participaciónprotagónica del pueblo, contribuyendo a la suprema felicidad social.

“Visión”:

Ser una empresa socialista operadora y proveedora de soluciones integrales de

telecomunicaciones e informática, reconocida por su capacidad innovadora, habilitadora

del desarrollo sustentable y de la integración nacional y regional, comprometida con la

democratizació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


15/100

1.1 Estructura del documento 4

De manera más espećıfica se tiene la estructura organizativa del Estado Mérida,

que se muestra en la figura 1.2.

Figura 1.2: Estructura de CANTV Mé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, además de ofrecer los objetivos generales y espećıficos planteados.

El Caṕıtulo 2, muestra la metodologı́a usada durante el desarrollo, además muestra

los procesos y procedimientos necesarios para la elaboración de este sistema de

informació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 utilización para el

desarrollo del mismo. Se habla acerca de los sistemas de informacíon, clasificación

y se hace mención del lenguaje de modelado unificado UML, las bases de datos y el

manejador de base de datos MySQL, entre otros.En el Caṕı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 álisis de

requisitos, hasta llegar a la fase de implementación y pruebas del sistema.

En el Caṕıtulo 5, se incluyen las conclusiones y recomendaciones del proyecto.


16/100

1.2 Antecedentes 5

1.2 Antecedentes

La CANTV cuenta con muchas redes cableadas e inalámbricas, que deben ser

gestionadas por diferentes departamentos. La gestión operativa de la compañ́ıa en

las redes debe hacerse de manera rápida, organizada y con la mayor informacíon

actualizada a disposición. En la gestión operativa de las redes de CANTV cada

departamento tiene información correspondiente a la red en su área de acción. La

Gerencia Operativa de Mérida cree que la gestíon operativa no puede ser algo de

una sola persona o de un solo departamento. Cuando se genera un problema, aveŕıa,

chequeo o simplemente una revisión de rutina se debe acudir a la persona encargada

del área para que sea el o ella quien solvente el inconveniente. Para resolver problemas

se necesita información, información que posee el departamento al cual pertenece el

problema o necesidad, por lo tanto, si algún otro departamento necesita algún tipo de

información para resolver un problema, aveŕıa o necesidad, debe necesariamente acudir

a ese departamento y solicitar esa información, trámite que retarda la efectividad de

la empresa, además de resultar engorroso para su personal no tener la informaci ón a

la mano.

Describiendo un poco más a fondo este proceso, cada departamento tiene la

información de sus equipos y cada miembro de ese departamento tiene a su vez dicha

informació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 información nunca esta actualizada a tiempo para todos los que la necesitan.

La CANTV cuenta con sistemas de información como el TAS (Trouble Administra-

tion System , por sus siglas en inglés) y ASAP (Automatización de Servicios de Atención

al Público) que poseen información de las capacidades de los elementos, ĺıneas, puertos

ABA (Acceso a Banda Ancha), clientes, aveŕıas de los clientes, entre otros. Pero no

posee información de los equipos de la red, marcas, ubicación, tecnologı́a, coordenadasy otras propiedades.

Al respecto, CANTV tambié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 años 1999-2001 por personal de CANTV. El SIR es una herramienta muy

poderosa que nos servirá para buscar información en este sistema.


17/100


18/100

1.5 Objetivos 7

información y visualización de los mapas de la red.

1.5.2 Objetivos Espećıficos

1. Definir y analizar el dominio de aplicación, alcance e información.

2. Diseñar, identificar y especificar los requisitos del sistema que cumplan con

los requerimientos exigidos por CANTV, bajo un ambiente amigable y de fácil

manejo.

3. Construir, implementar y realizar pruebas del sistema de informacíon que

cumplan con la normativa de la empresa.

4. Presentar una visualización de la información de la red:

• Centrales Fijas

• Centrales Móviles

• URL

• Nodos outdoor

• ADS

• DLC

Aśı como los datos de los enlaces entre elementos:

• Estaciones

• Repetidoras

• Enlaces de radio

• Enlaces de fibra óptica

Y las propiedades de los elementos:

• Equipos

• Marcas

• Capacidades


19/100

1.6 Metodoloǵıa 8

• Número de ĺıneas

• Frecuencias de transmisión y recepción

• Ubicación

• Coordenadas

• Dirección

Y además de otro tipo de información espećıfica de los diferentes componentes

de la red tales como: IP, bastidores, sub-bastidores, ranuras, puertos, posiciones,

tarjetas entre otros.

1.6 Metodoloǵıa

En este caṕıtulo de describen los procedimientos, procesos y métodos para realizar

el diseño e implementación del Sistema de Información Web.

Para el modelado del sistema se hizo uso del Lenguaje Unificado de Modelado

(UML, por sus siglas en inglés, Unified Modeling Language ), el cual es un lenguaje

de modelado de sistemas de software más conocido y utilizado en la actualidad,

está respaldado por el OMG (Object Management Group) y es un lenguaje gráfico

para visualizar, especificar, construir y documentar un sistema de software. El UML

ofrece un está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 programación, esquemas de bases de datos

y componentes de software reutilizables (Schmuller, 1997).

1.6.1 Revisión bibliográfica

En primer lugar se busca información bibliográfica de los conceptos y basamentos

teóricos sobre telefonı́a y redes telefónicas, igualmente se recopilará la documentación

acerca de algunas de las herramientas para el desarrollo de este tipo de proyecto.

Luego, se ofrece la investigación acerca del manejador de base de datos MySQL, el

cual es herramienta de desarrollo de este sistema.


20/100


Posteriormente, se procede a investigar y recopilar informacíon sobre la im-

plantació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 método Watch, el cual se expone muy bien en (Montilva and Barrios, 2003). Este

método consta de los siguientes modelos:

• Modelo del producto: Describe el tipo de producto que el método Watch

ayuda a generar. Se establecen las caracteŕısticas arquitectónicas generales de

una aplicación empresarial. En este caso las caracteŕısticas del sistema.

• Modelo del proceso: Es una descripcíon estructurada del conjunto de

actividades que el desarrollador debe seguir para generar una aplicación

empresarial y comprende las siguientes fases:

– Análisis del dominio de la aplicación: En esta fase se estudia el sistema

organizacional, es decir, las actividades y los procesos que son llevados por la

organizació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.

– Definición y especificación de requerimientos: Los requerimientos

son las necesidades que deben ser satisfechas por el sistema programado

a partir de la manipulación y consulta de las bases de datos en el sistema

de información Web.

– Diseño del sistema: En esta fase se representa el diseño de la arquitecturadel sistema, el diseño del esquema conceptual de la base de datos y el diseño

de la interfaz Usuario/Sistema.

– Implantación del sistema: Es el proceso de convertir el esquema

modelado a uno que pueda ser directamente implementado con el uso de


21/100


un manejador de base de datos, es decir, se lleva el modelo a un lenguaje de

programación.

• Modelo del desarrollador: Este modelo describe cómo el desarrollador debe

estar organizado cuáles son sus roles y tareas.

La figura 1.3 muestra las diferentes etapas comprendidas en el método Watch.1

Figura 1.3: Etapas del método watch

1Fuente (Montilva and Barrios, 2003).


22/100

Caṕıtulo 2

Marco teórico

Para el desarrollo de este proyecto se hace necesario conocer un conjunto de

conceptos y herramientas. Al respecto, en este caṕıtulo se ofrece un breve resumen de

los conceptos y herramientas ı́ntimamente vinculados con el proyecto. Se comenzará

desarrollando el concepto de sistema de información, su clasificación y se define el tipo

de sistema de información que se considera este proyecto. Se hará menció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 definirán algunos conceptos relacionados con el lenguaje demodelado unificado (UML) y se explicará la estructura y utilidad de los diagramas

utilizados en el proyecto; por último se hará mención del lenguaje de programación

PHP (Hypertext Preprocessor).

2.1 Sistemas de información

Un Sistema de Informacíon es un conjunto de componentes interrelacionados

que operan de manera sistemática para capturar, procesar, almacenar y distribuirinformación que sirva de apoyo a la toma de decisiones, la coordinación, el control y el

análisis dentro de una organización (Schmal and Cisternas, 2000). En ese sentido, de

acuerdo con Muñoz (2003) algunas de las caracteŕısticas que resultan necesarias para

cualquier Sistema de Información son:


23/100


24/100

2.1 Sistemas de información 13

de los datos y la información generada por el sistema, las personas encargadas de

analizar e interpretar la información pueden llevar a cabo la toma de decisiones.

Almacenamiento de la información: Permite que la información generada en

el proceso anterior pueda ser guardada para ser recuperada y utilizada más adelante.

Por lo general, la información es almacenada utilizando archivos y bases de datos que

utilizan como medio de almacenamiento los discos magnéticos o discos duros, los discos

compactos, los DVDs, entre otros.

Salida de la información: Es la capacidad que tiene un sistema de información

para mostrar la información procesada al exterior. La salida de un sistema puede ser la

entrada de otro sistema de información o módulo, o puede ser mostrada directamente

al usuario en el formato que éste desee.

2.1.2 Tipos de sistemas de información

En Barrios (2000) se clasifican los sistemas de informacíon basándose en tres

criterios: el grado de cobertura de las actividades organizacionales, el grado de apoyo

a la ejecución de las actividades en la organización y las tecnoloǵı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 organización, apoyando las actividades del usuario

en forma completa y sujetos a las necesidades de éstos.

Sistemas integrados (SII): Están conformados por la conjunción y colaboración

de los sistemas de información ya existentes en la organización.

Sistemas organizacionales (SIO): Proporcionan un grado de cobertura e

integración total de las actividades y procesos organizacionales, aportando ası́ un grado

de apoyo máximo a la toma de decisiones.De acuerdo al apoyo brindado a la ejecución de las actividades organizacionales los

sistemas de información pueden ser:

Sistemas operacionales (SIOp): Son sistemas de bajo nivel que apoyan la

automatización de tareas y operaciones básicas dentro de una organización, tales como

1No obstante un sistema puede ser clasificado en m ás de uno de estos criterios.


25/100

2.1 Sistemas de información 14

las actividades administrativas y de producción.

Sistemas gerenciales (SIGe): Están orientados a brindar apoyo a las actividades

de nivel gerencial y de coordinación dentro de una organización.

Sistemas de apoyo a la toma de decisiones (SATD): Son sistemas que

contribuyen de forma directa y expĺıcita al proceso de toma de decisiones dentro de

una organización, permitiendo visualizar el panorama organizacional desde el punto de

vista de los resultados y/o consecuencias de tomar alguna acción en un momento dado.

De acuerdo a las tecnoloǵıas en las que se basan, los sistemas de información pueden

ser:

• Sistemas cliente/servidor

• Sistemas basados en tecnoloǵıas Web

• Sistemas basados en agentes

• Sistemas basados orientados a servicios

Existe una cuarta clasificación de los sistemas de informació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 automatización de “experticia humana” en la realización de determinada actividad

y Sistemas de Información Geográfica (SIG) que están relacionados con el manejo de

información geográfica o georeferenciados.

2.1.3 Sistemas de información Web

En Muñoz (2003) se define un Sistema de Información Web (SIW) como: Un sistema

de información que utiliza una arquitectura web para proporcionar información (datos)

y funcionalidad (servicios) a usuarios finales, a través de una interfaz de usuario basada

en presentación e interacción sobre dispositivos con capacidad de trabajar en la Web.

En este orden de ideas los SIW vaŕıan ampliamente en su ámbito, desde sistemas

de información, hasta sistemas de transacciones, incluso sistemas de servicios Web

distribuidos. En virtud de la definición anterior los SIW se clasifican como sigue:


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 Electrónico, (los cuales dan apoyo a la interacció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 heterogéneas, se maneja en distintos formatos, y en un conjunto de componentesque están por lo general codificados en diferentes lenguajes de programación y a su vez

distribuidos en diferentes plataformas. Al igual que los SI tradicionales, más allá que

una infraestructura para la entrega de información (en tiempo de ejecució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 informacíon dando solución a sus

requerimientos.

Los SIW son diseñados, desarrollados y mantenidos con el propósito de alcanzar

objetivos espećıficos de los usuarios finales. É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 éxitos

del software libre y su supremaćı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 caracteŕısticas de Apache es su extensibilidad basada en una

gran modularidad de su código fuente lo que han facilitado la aparición de módulos

de extensión como PHP el cual evitará el uso de cgi-bins por completo, facilitando


27/100

2.3 Bases de datos 16

ampliamente la programación de aplicaciones en el lado del servidor, especialmente en

el ámbito de uso de bases de datos.

2.3 Bases de datos

Una base de datos es una colección de datos relacionados, es decir, un conjunto

de hechos que pueden registrarse y que tienen un significado impĺıcito. Por lo general,

las bases de datos representan aspectos del mundo real y son diseñadas, construidas y

pobladas con datos que tienen un propó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 jerá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 continuación.

2.3.1 Bases de datos relacionales

Constituye el modelo más utilizado en la actualidad para el modelado de problemas

reales y la administración de datos de manera dinámica. Almacena la información en

varias tablas (filas y columnas de datos) o ficheros independientes y realiza búsquedas

que permiten relacionar datos que han sido almacenados en más de una tabla. Se basa

en el uso de relaciones, donde cada relació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 están en cada fila. En el modelo relacional una fila

se denomina “tupla”, una cabecera de columnas se denomina “atributo” y la tabla sedenomina “relació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 más fácil de entender

y de utilizar para un usuario esporádico de la base de datos. La información puede ser

recuperada o almacenada mediante “consultas” que ofrecen una amplia flexibilidad y

poder para administrar la información (Elmasri and Navathe, 2002).


28/100


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. Está diseñado como un lenguaje amplio que incluye

instrucciones para definir, consultar y actualizar las bases de datos. Las funcionalidades

que proporciona el SQL van más allá de la simple consulta o recuperación de datos.

Esta a su vez permite definir los tipos de datos y manipular los datos. Además, el SQL

permite la concesión y denegación de permisos, la implementación de restricciones de

integridad, controles de transacción y la alteración de esquemas. El lenguaje SQL está

compuesto por comandos, clá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 gestión de bases de datos MySQL

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario

con má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 espećıfica que les permita este uso. Está desarrollado

en su mayor parte en ANSI C (Wikipedia, 2008c).

MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no

transaccional MyISAM, pero puede provocar problemas de integridad en entornos de

alta concurrencia en la modificación. En aplicaciones Web hay baja concurrencia en la

modificació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

adaptación a diferentes entornos de desarrollo, permitiendo su interacción con los

lenguajes de programación más utilizados como: PHP, Perl y Java y su integración


29/100


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 aplicacíon web está muy ligada a PHP

que a menudo aparece en combinación con MySQL lo cual no es una excepción en este

proyecto.

Inicialmente MySQL carećıa de elementos considerados esenciales en las bases de

datos relacionales tales como: integridad referencial y transacciones. Estos elementos

atrajeron a los desarrolladores de páginas Web con contenido diná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 están siendo incorporados tanto por

desarrollos internos como por desarrolladores de software libre.

2.3.4 Algunas caracteŕısticas de MySQL

Entre las caracteŕısticas disponibles en las ú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 según si se desea velocidad en las

operaciones o el mayor número de operaciones disponibles

• Transacciones y claves foráneas

• Conectividad segura

• Replicación, búsqueda e indexación de campos de texto


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 tecnoloǵıas. Esta arquitectura se basa en los conceptos de

escalabilidad y reutilización del software.

Por lo general, las organizaciones desarrollan funciones y aplicaciones que son útiles

para automatizar ciertas tareas dentro de los procesos de negocio. Sin embargo, muchas

veces una solución puede ser útil a nivel intermedio para varios procesos o unidades

dentro de la organización con fines diferentes.

El concepto de arquitectura orientada a servicios implica que los desarrolladores

creen un conjunto de funciones independientes entre śı llamadas servicios, que aceptan

llamadas y generan respuestas mediante interfaces bien definidas y que son puestas

a disposición de los clientes como utilidades que pueden ser reutilizadas por diversas

aplicaciones dentro de la organización.

La implementación de los servicios es transparente para los usuarios, ya que a éstos

no le interesa conocer má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 mayoŕıa de las definiciones de SOA identifican la utilización

de Servicios Web en su implementació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 débilmente acoplados y altamente

interoperables. Estos servicios definen una estructura para comunicarse entre śı, quees independiente del lenguaje en que se encuentran implementados y el lenguaje de

programación. Todo ello buscando maximizar la reutilizacíon de los componentes

desarrollados en un sistema (Wikipedia, 2008a).

La arquitectura SOA es muy utilizada por las grandes organizaciones en la


31/100

2.4 Arquitectura orientada a servicios (SOA) 20

actualidad, entre tantas cosas, por el hecho de permitir la creación o cambios en los

procesos de negocios automatizados de forma ágil, a través de una composició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 cómo los

componentes se distribuyen en tres capas:

• La capa de presentación es la que le da el formato a los datos recibidos desde el

bus de integración con el fin de que el usuario visualice la información en una

página Web

• El bus de integración, comprende la segunda capa en la que se encuentran losservicios Web del negocio; aśı como los objetos manipulados por esos servicios

y todos los servicios comunes para todas las funciones de negocio. Esta capa

implementa la lógica de negocios de la aplicación

• La capa de datos es la que mantiene la implementaci ón de las estructuras que

almacenan los datos de la aplicación (bases de datos).

Figura 2.1: Arquitectura orientada a servicios


32/100

2.5 Protocolo SOAP 21

2.5 Protocolo SOAP

El SOAP es un protocolo de comunicación definido para el intercambio de

datos mediante el paso de mensajes en formato XML. Define los estándares para la

comunicación entre dos objetos de diferentes procesos a través de una conexió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 más

utilizados y aceptados por las grandes compañ́ıas del mundo y las principales razones

de su éxito son:

• No esta asociado con ningún lenguaje: SOAP no especifica una API, por lo que

la implementación de la API se deja al lenguaje de programación y la plataforma

• No se encuentra fuertemente asociado a ningún protocolo de transporte: Un

mensaje de SOAP no es más que un documento XML, por lo que puede

transportarse utilizando cualquier protocolo capaz de transmitir texto

• No está atado a ninguna infraestructura de objeto distribuido: La mayoŕıa de

los sistemas de objetos distribuidos se pueden extender, y muchos de ellos ya lo

están para que admitan SOAP

• Aprovecha los est́andares existentes en la industria: Por ejemplo, SOAP

aprovecha XML para la codificación de mensajes, en lugar de utilizar su propio

sistema de tipo que ya están definidas en la especificació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 múltiples entornos: SOAP se desarrolló sobre

los estándares existentes de la industria por lo que las aplicaciones que se ejecuten

en plataformas con dichos estándares, pueden comunicarse mediante mensaje


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 gráfico para el modelado de sistemas de software que

permite representar gráficamente la estructura de un sistema, haciendo posible que

cualquier persona ajena o no al proceso de diseño lo pueda entender. Mediante UML

se pueden especificar, visualizar y documentar de manera expĺıcita las caracteŕısticas

de un sistema de software antes y durante su construcción. UML es sólo un lenguajepara el modelado por lo que su utilización es independiente del proceso de desarrollo,

aunque para su uso ó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 ño

de estructura de una organización, actividades de planificación de proyectos y sistemas

no informáticos.

El UML se deriva de la unificación de tres metodoloǵıas de análisis y diseño

orientada a objeto, tales como: la metodoloǵıa de Grady Booch (para la descripción

de conjuntos de objetos y sus relaciones), la técnica de modelado orientada a objetos

de James Rumbaugh OMT (Object-Modeling Technique) y la aproximación de Ivar

Jacobson OOSE (Object Oriented Software Engineering) mediante la metodologı́a de

casos de uso.

De estas tres metodoloǵıas, las de Rumbaugh y Booch se pueden clasificar como

metodoloǵıas directamente orientadas a objetos, mientras que la metodoloǵıa de

Jacobson está orientada al usuario, ya que todo su método se deriva de los escenarios

de uso del sistema.

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim

Rumbaugh de Rational Software Corporation que comenzaron a unificar sus métodos.

A finales de 1995, Ivar Jacobson y su compañ́ıa Objectory se incorporaron,


34/100


aportando el mé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 útil a sus propósitos, estas fueron

agregando nuevos aportes.

En 1997 se produjo la versión 1.0 del UML y se puso a consideración del OMG

(Object Management Group), propuesto como un lenguaje de modelado estándar.

Desde entonces, UML ha atravesado una serie de revisiones y refinamientos hasta llegar

a su versión actual: UML 2.3 (Wikipedia, 2008b). Al respecto el UML está compuesto

por diversos elementos grá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 hará, pero no la forma como se implementará. En la versión 2.0

del UML, se define un total de 13 diagramas para representar la estructura y din ámica

del sistema. Sin embargo, para efectos del proyecto solo se utilizaron ciertos diagramas.

2.6.1 Diagramas de clases

Son estructuras estáticas que dan una visió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 estáticos pues muestran las relaciones entre

las clases pero no especifican sus interacciones de manera dinámica. Los diagramas de

clases colaboran en lo referente al análisis y permiten al analista hablarle en su propia

terminoloǵı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.


35/100


2.6.3 Diagramas de objetos

Un objeto es una instancia de clase (una entidad que tiene valores espećıficos de

los atributos y acciones). Son parte de la vista está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 distribución f́ısica de los distintos nodos

que componen el sistema, la comunicación entre los nodos y la disposici ón de los

componentes sobre ellos. Un nodo es un recurso de ejecucíon tal como un computador,

un dispositivo o memoria. Permiten precisar la naturaleza del equipo. Los elementos

utilizados en la representación grá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 distribució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 diseñado para mostrar una visión simplificada

de lo que ocurre durante una operació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 cronológicamente con el fin de lograr la ejecución de un proceso

más complejo.


36/100

2.7 El lenguaje de programació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 interactúan sus elementos. Loselementos implicados en un diagrama de casos de uso son:

Actores: Son entidades con un comportamiento definido y que realizan alguna

interacción con el sistema. Pueden representar usuarios, organizaciones u otros sistemas

informáticos.

Casos de uso: Son descripciones de las secuencias de acciones que se producen de

la interacción entre un actor y el sistema.

Relaciones entre casos de uso: Las relaciones entre los casos de uso pueden

ser de inclusión y extensió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

llamarán cada vez que se ejecute el camino base. Un caso de uso puede ser incluido

por uno o más casos de uso, ayudando ası́ a reducir la duplicación de funcionalidad al

factorizar el comportamiento comú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 relación “incluye” include que se da siempre que se realiza la interacción descrita.

2.6.8 Diagramas de secuencia

Representan la interacció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 interacción y los mensajes que intercambian en orden temporal (Schmuller, 1997).

2.7 El lenguaje de programación PHP

PHP: “Hypertext Preprocessor” es un lenguaje de programación del lado del servidor

diseñado originalmente para la generación de páginas Web dinámicas. Es un lenguaje

de programación interpretado o de script que permite insertar fragmentos de código


37/100

2.7 El lenguaje de programación PHP 26

dentro de una página HTML y realizar determinadas acciones de una forma fá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 código en PHP como su

entrada y creando páginas Web como salida.

PHP puede ser desplegado en la mayoŕıa de los servidores web y en casi todos los

sistemas operativos y plataformas sin costo alguno. PHP se encuentra instalado en

más de 20 millones de sitios web y en un millón de servidores (Wikipedia, 2008d).

Una de sus mayores ventajas es el parecido que posee con otros lenguajes

de programación estructurada como Perl y C que permiten a la mayoŕıa de losprogramadores crear aplicaciones complejas de manera muy sencilla, pues no se requiere

mucho tiempo para su aprendizaje.

Cuando un cliente hace una petición al servidor para que le env́ıe una página Web,

el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado y genera de

manera dinámica un contenido. El resultado es enviado por el int́erprete al servidor,

quien a su vez env́ıa la página HTML al cliente. Mediante extensiones es también

posible la generación de archivos de tipo PDF, Flash; aśı como imágenes en diferentes

formatos (Wikipedia, 2008d).Si bien, PHP no es un lenguaje completamente orientado a objetos, en su última

versión (versión 5.0) se incorporan varios constructores de programación orientada a

objetos. Su creación y desarrollo se da en el á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

utilizó el editor Quanta Plus en su versión 3.5.


38/100

Caṕıtulo 3

Modelado de Negocios del Sistema

de Información Centralizado (SIC)

El presente caṕıtulo describe las fases de modelado del SIC. Como se mencionó

en los caṕıtulos anteriores para el desarrollo del sistema se utiliza el método watch en

su versión 2004. A continuación se describe cada una de las fases contempladas en

este método y que son aplicadas para obtener el sistema. Se comenzará explicando el

modelado de negocios realizado para la unidad organizativa de la CANTV en estudio

especı́ficamente la gerencia operativa del estado Mérida. Aśı mismo se presentan losrequisitos de la aplicació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 más

a fondo del sistema de negocios u organizació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 aplicación. En el contexto

de aplicaciones empresariales, el dominio de aplicación se refiere a la organización o

sistema de negocios que será apoyada por la aplicación o SI, obteniendo como producto

final el modelo de negocios de la organización.


39/100

3.2 Ingenieŕıa de requisitos 28

Un modelo de negocios es una representación que captura la estructura y dinámica

de la organización objetivo bajo la cual se incorporará el SI. Mediante el modelo de

negocios es posible obtener un conocimiento a profundidad de la organización, sus

problemas de información y los requisitos funcionales que deben ser satisfechos por el

SI (Montilva et al., 2000).

3.1.1 Delimitación del sistema de negocios

Dentro de la CANTV, la gerencia operativa del estado Mérida se encarga de

coordinar los diferentes departamentos que hacen posible el buen funcionamiento y

mantenimiento de su plataforma tecnológica. La ejecución de una buena coordinación

tiene como objetivo maximizar la productividad de sus trabajadores, minimizar el

tiempo de respuesta de las aveŕıas y de mejorar el servicio a los usuarios. Los diferentes

departamentos involucrados en el SIW poseen información importante referente a cada

una de sus áreas y la cual será manejada por el SIW. Los departamentos involucrados

en la gerencia operativa del estado Mérida se muestran en la figura 3.1.

Figura 3.1: Delimitación del sistema de negocios

3.2 Ingenieŕıa de requisitos

Dentro del método Watch , la fase de ingenieŕıa de requisitos comprende dos fases

primordiales: una de ellas es la definición y la otra es la especificación del conjunto de

requisitos funcionales y no funcionales del producto de software. En la fase de definición


40/100


se clasifican los requisitos y se les asigna prioridades de acuerdo con las necesidades del

cliente. También se lleva a cabo la negociació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 especificación de requisitos deriva un conjunto de modelos en los que

se obtiene lo que será la arquitectura del sistema. Para la ingenieŕıa de requisitos del

SIC se comenzará realizando una descripción en lenguaje natural de los necesidades

expresadas por el cliente durante las reuniones y entrevistas. A partir de esta

descripción se realiza una clasificació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 Definición de los requisitos de software

Durante las diferentes reuniones y entrevistas realizadas a lo largo del desarrollo

del SIC y espećıficamente en la fase del modelado de negocios para el entendimiento

de la organizació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 ésta sea satisfecha. El cliente

solicita el desarrollo de un determinado sistema de software de acuerdo a sus problemas

y necesidades. Él aporta sus ideas y requerimientos al proceso de diseño del sistema.

En el caso del SIW a implementar, el cliente es la gerencia operativa de Mérida de

CANTV, particularmente el departamento de Conmutación, Transmisión y Datos.

Desarrolladores/Analistas: Los miembros del equipo de desarrolladores de-

sempeñan diferentes roles como por ejemplo: coordinador, analista de sistemas, pro-

motor de software, instructor y consejero o guı́a informático. Para satisfacer las necesi-

dades del cliente y la resolució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 está dirigido el SIW son esenciales para el proceso de diseño y

desarrollo. En este caso, el grupo de usuarios finales del SIW hasta los momentos, está

constituido por el área de conmutación, transmisión, datos, operaciones centralizadas

que comprende los diferentes distribuidores y el personal que trabaja en las diferentes


41/100


centrales foráneas; además de personal de otras áreas como las de planta externa,

que necesita de la información contenida en el SIC. Sin embargo, se deben permitir

diferentes niveles de acceso a los usuarios del sistema con miras a que é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 podrá realizar consultas a la base de datos del sistema.

• Usuario: Además de las acciones de visitante, el usuario podrá realizar consultas

sobre la base de datos del sistema y realizar modificaciones de registros sin poder

eliminar ningún tipo de información.

• Administrador: El perfil de administrador debe permitir tanto la consulta

sobre la base de datos del sistema como la modificación y eliminación de registros

erróneos o que carezcan de interé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 corrección de fallas, la inserción de datos, consultas a la base de

datos, restablecer datos borrados erróneamente, crear nuevos usuarios, modificar

y eliminar usuarios, ingresar y eliminar gráficos (mapas o diagramas). Ademásde realizar todas las acciones sobre la bitácora o historial de uso del sistema.

En la figura 3.2 se muestra el diagrama de actores de SIC.

3.2.2 Definición de requisitos según actores

• Requisitos del cliente

1. El sistema debe contener la información más importante para cadadepartamento, mostrar la información de las propiedades de los elementos

para la gestión operativa, aśı 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 Mérida.


42/100


Figura 3.2: Diagrama de actores del SIC

3. El sistema debe permitir el manejo de usuarios (creaci ón, modificación y

eliminación), además de manejar los perfiles de actores ya mencionados.

(Ver Figura 3.2).

4. El manejo de información debe permitir la inserción, modificación y

eliminación según los perfiles de actores ya mencionados. (Ver Figura 3.2).

5. La informacíon eliminada no debe ser borrada de manera definitiva, sino

pasar a un estado de “inactivo” y permanecer “oculta” para los usuarios a

excepción del Super Administrador.

6. El sistema debe contar con un manejo de histórico (bitácora) donde se


43/100


registren todas las acciones realizadas, bien sea de inserción, modificación

y/o eliminación de información.

7. Los estilos de letras de las páginas Web y los colores deben ser los

establecidos por CANTV.

8. Poseer una interfaz amigable, entendible y de fácil manejo para el usuario.

9. Todas las respuestas a las consultas al servidor de base de datos deben

ser lo más rápidas y eficientes posible, es por esto, que se ha definido el

tiempo máximo a 60 seg. Este tiempo solo se podrá exceder con una clara

justificación.

• Requisitos de los usuarios

1. El sistema debe permitir la inserción, modificación y eliminación individual

de los elementos y además debe contener la siguiente información básica:

a. Número del elemento o equipo.

b. Código del inventario.

c. Nombre del equipo.

d. Ubicación geográfica con coordenadas.

e. Capacidades de sus diferentes propiedades. Además de otros

mucho atributos espećı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 información para la gestión de

los registros, tales como: campos de observaciones, última modificación

realizada al registro, usuario que realizó la modificación y cuando lo hizo.

3. Para la búsqueda de información en áreas como operaciones centralizadas, el

sistema debe contar con campos de consulta directa, por ejemplo el númerotelefónico.

4. El sistema deberá poseer un buzón de actualizaciones pendientes, el cual

tiene como función notificar a los administradores que deben realizar

modificaciones o actualizaciones para las cuales los usuarios de bajo nivel

no poseen permiso.


44/100


5. El sistema debe permitir cerrar la sesión al usuario actual.

6. La sesión se cerrará automáticamente luego de determinado tiempo. Al

respecto la sesión de PHP es de 24 minutos, por tal motivo este ser á eltiempo de sesión del SIC.

7. Los errores en la inserción de información por parte del usuario deben ser

notificados.

8. Los usuarios se crearán con una contraseña por defecto y ésta puede y debe

ser cambiada por cada usuario.

9. El sistema debe incorporar filtros de búsqueda, es decir, consultas a la base

de datos por todos los campos.

10. El sistema debe permitir la extracción de información en hojas de cálculo

para que puedan servir de apoyo en la toma de decisiones.

• Requisitos del desarrollador

1. El software se deberá implantar con el lenguaje de programació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 ratón.

f. Un Teclado.

g. Una tarjeta de video de 32 MB.

h. Una tarjeta de red con capacidad de conexión a la intranet de

CANTV.

i. El sistema operativo Windows XP, Vista o Linux en cualquier

distribución.


45/100


j. Navegador Mozilla Firefox 3.0.

3.2.3 Clasificación de los requisitos y definición de prioridades

Requisitos funcionales: Describen las funciones y servicios que el sistema debe

hacer. Están dirigidos a có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.

Ademá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 números del 1 al 10, siendo el 1 la prioridad más

alta (requisito obligatorio) y el 10 la prioridad más baja (requisito casi prescindible).

La Tabla 3.1 muestra la clasificación de los requisitos.

Tabla 3.1: Especificación de los requisitos

N◦ de Nombre del Requisito Clasificación Prioridad Tipo de

Requisito Requisito

R1 Centralizar la información No Funcional 1 Aseguramiento

importante para cada de la calidad

departamento (Igual acceso).

R2 Mostrar la información de las Funcional 2 Funcionalidad

propiedades de los elementos

para la gestión operativa.

R3 Contener los diferentes mapas Funcional 1 Funcionalidad

de Mérida, red secundaria,

fibra óptica y diagramas.

R4 Permitir la gestión de usuarios Funcional 4 Funcionalidad

R5 Capacidad para insertar, Funcional 2 Funcionalidad

modificar y eliminar información

según los niveles de seguridad.

R6 La información eliminada no Funcional 2 Funcionalidad

debe ser borrada, solo ocultada.


46/100



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 Restricció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 sesión Funcional 3 Funcionalidad

R14 El software se debe implantar No Funcional 3 Restricción

con el lenguaje de programació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 Restricción

datos debe ser MySQL.R16 El equipo donde se ejecute el No Funcional 4 Restricción

sistema debe tener ciertas

caracterı́sticas.

R17 El acceso al sistema debe ser a No Funcional 3 Restricción

través de la intranet de CANTV.


47/100



Requisito Requisito

R18 La interfaz debe ser amigable y No Funcional 4 Aseguramiento

de fá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 más rá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

histórico o bitácora.

Vale la pena mencionar que a pesar de que el producto aqúı mostrado es resultado

de un proceso de refinamiento y validació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 recopilació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 Definición de casos de uso

La elaboración de los casos de uso se realiza clasificando las funciones según los

diferentes actores del sistema. La jerarqúıa de actores se mostró en la figura 3.2.

En la figura 3.3 se muestra el caso de uso para ejemplificar la centralizaci ón de

información, es decir, la implementación de un servidor para almacenar la información.

Por su parte la figura 3.4 explica el caso de uso para la identificación de un usuario

cualquiera y dar acceso al sistema.


48/100


Figura 3.3: Diagrama de caso de uso centralizar información

Figura 3.4: Diagrama de caso de uso identificación


49/100


A continuación se muestran los diagramas de casos de uso más importantes del

sistema:

Figura 3.5: Diagrama de caso de uso mostrar información

Figura 3.6: Digrama de caso de uso modificar elemento


50/100


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


51/100


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


52/100


Descripción de los casos de uso:

Para una mayor comprensión de la secuencia de tareas asociadas a los casos de uso,

se hace una breve descripción de cada uno de ellos en la tabla 3.2.

Tabla 3.2: Casos de uso del sistemaCaso Nombre del Caso Descripción

de Uso de Uso

CU1 Ingresar al sistema. El usuario introduce su indicador (nombre de usuario de la red

de CANTV) y su contraseña en la ventana de inicio del sistema.

CU2 Identificar perfil de El sistema verifica el nombre del usuario y la contraseña, dá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 generará 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 generará una lista de los ADS.

CU5 Consultar Estaciones. El usuario introduce el estado y el municipio de la estacíon. El

sistema generará una lista de las estaciones.

CU6 Consultar Repetidoras. El usuario introduce el estado y el municipio de la repetidora. El

sistema generará una lista de las repetidoras.

CU7 Consultar Enlaces de El usuario introduce el estado, municipio y central o la estacíon,

Fibra Óptica. repetidora tanto del origen como del destino. El sistema generará

una lista de enlaces entre estos dos puntos.

CU8 Consultar Enlaces de El usuario introduce el estado, municipio y central o la estacíon,

Radio. repetidora tanto del origen como del destino. El sistema generaŕ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 generará una lista con

la informació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 generará 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 generará 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

bitácora del sistema. generará una lista de acciones realizadas.


53/100


Caso Nombre del Caso Descripción

de Uso de Uso

CU13 Modificar Elementos Una vez consultado el equipo o elemento del sistema se edita o

del sistema. actualiza la información. El sistema notificará de la modificación.

CU14 Eliminar un Elemento Luego de la consulta del elemento de elimina (marcar como

del sistema. eliminado). El sistema notificaŕa de la eliminación.

CU15 Insertar un Elemento El usuario elige el tipo de elemento para introducir la información

en el sistema. correspondiente e inserta el elemento. El sistema notificará de

la inserción.

CU16 Reporte Lista. Luego de la consulta del elemento en el sistema el usuario

selecciona exportar lista. El sistema generará una hoja de cá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 notificará la creación.

CU18 Modificar Usuario. El usuario consulta el usuario deseado, edita o actualiza la

información. El sistema notificará de la modificación.

CU19 Cerrar Sesíon. El usuario cierra la sesión actual en el sistema.

CU20 Registrar Accíon. La acció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 ingenieŕıa de requisitos es la validación

y verificació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.


54/100


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


55/100

Caṕıtulo 4

Diseño del Sistema de Información

Centralizado (SIC)

Una vez terminada la tarea de especificación y definición de los requisitos, se

procede a diseñar el sistema. La fase de diseño pretende determinar la estructura de

la aplicación a fin de satisfacer los requisitos obtenidos en el procedimiento anterior,

estableciendo la interconexión de los distintos subsistemas que la conforman, junto

con los parámetros que regulan que el sistema apoye los procesos de la organización

y cumpla con los objetivos que fueron prefijados. Dentro de esta fase se estableceel conjunto de metas con las que debe cumplir el diseño, se determina cuáles de los

requerimientos se encuentran relacionados con la arquitectura del sistema, se describe

la arquitectura, se diseña la interfaz usuario/sistema y se diseña la base de datos.

4.1 Metas de diseño

Buscando que el desarrollo de la aplicación realmente satisfaga las necesidades de

los actores involucrados en él y que además cumpla con los estándares de rendimiento

esperados, se hace necesario fijar ciertas metas en esta fase de diseño. Las metas

propuestas para el diseño se enuncian a continuación:

• La arquitectura del sistema estará basada en el uso de servicios Web que estarán

claramente especificados y que podrán ser reutilizados por cualquier componente


56/100

4.2 Definición del estilo arquitectónico 45

que los necesite.

• Los componentes diseñados van a buscar cumplir los requisitos de los actores

involucrados de la manera más eficiente posible.

• La arquitectura estará basada en la utilización de componentes modulares bien

estructurados y con entradas y salidas claramente definidas.

• El diseño será fácil de entender, manejar y modificar, permitiendo probar y

detectar fallas rápidamente.

• El diseño se caracterizará por una alta cohesión de los componentes dentro

de cada subsistema y un bajo acopl

Infante Kevin

Documents

Transcript of Infante Kevin