CAPITULO II

MARCO TEÓRICO

No tiene número esta

18
pagina
1.1. INTRODUCCIÓN

La utilización masiva de computadoras y dispositivos de almacenamiento y procesamiento de

información se ha incrementado exponencialmente en los últimos años, llegando a convertirse
en un elemento indispensable para la sociedad actual. Consecuentemente las bases de datos
permiten el manejo y manipulación de la gran cantidad de datos que existan.

Por consiguiente en este capítulo se abordará una recopilación de textos, publicaciones sobre
definiciones, conceptos y metodologías tomados en cuenta durante todo el proceso de
elaboración de la aplicación web de este proyecto de sistema de información.

Los conceptos que a continuación se presentaran es la metodología orientada a objetos, la cual

darán la pauta sobre los estándares utilizados tanto para el análisis, diseño, implementación y
pruebas.

Es por ello que a continuación se presenta una serie de definiciones, conceptos y metodologías
que ayudaran a comprender mejor estos temas.

1.2. METODOLOGÍA APLICADA

La metodología de investigación de este proyecto informático es tanto cualitativa como

cuantitativa y se divide en cuatro partes principales. La primera fase incluye la idea a defender
sobre la accesibilidad, relevancia y usabilidad de automatizar los procesos académicos de la
institución. A continuación, en la segunda fase de la investigación se incluye toda la
información necesaria para establecer definiciones detalladas sobre el tema investigado, marco
teórico y variables que pueden afectar el análisis y la interpretación de la investigación del
problema. La tercera fase se encarga de generar y colectar datos, usando métodos tanto
cualitativos como cuantitativos, aplicando metodologías de desarrollo (RUP en nuestro caso),
métodos de problema-solución (Patrones de diseño en nuestro caso). Finalmente, la cuarta fase
derivada de la recolección de datos, que será respaldada.

De manera que se puede decir que este proyecto busca denotar una manera de elaborar una
investigación mediante exploración e integración de tecnologías disponibles para entregar un

19
sistema que se enfoque en “probar la teoría” más que en construirla, dando paso a un progreso
fluido desde el desarrollo a la evaluación.

El desarrollo de este sistema se compromete con tres pasos principales: desarrollo de

conceptos, construcción del sistema y evaluación del sistema. La metodología cualitativa se
aplica mediante constantes reuniones con el usuario final (Personal administrativo del
Departamento de Asuntos Estudiantiles), para ver el progreso cualitativo (calidad, confianza,
satisfacción) del sistema. Mientras que la metodología cuantitativa se verá plasmada en los
indicadores e informes de la documentación generada a partir del RUP.
Fuente
1.2.1. RUP - EL PROCESO UNIFICADO DE RATIONAL

Rational Unified Process (RUP) es una metodología de desarrollo de software orientado a

objeto (FIGURA Nº 6) que establece las bases, plantillas, y ejemplos para todos los aspectos y
fases de desarrollo del software. RUP es herramientas de la ingeniería de software que
combinan los aspectos del proceso de desarrollo (como fases definidas, técnicas, y prácticas)
con otros componentes de desarrollo (como documentos, modelos, manuales, código fuente,
etc.) dentro de un framework unificado. RUP establece cuatro fases de desarrollo cada una de
las cuales está organizada en varias iteraciones separadas que deben satisfacer criterios
definidos antes de emprender la próxima fase.

FIGURA Nº 6
Estructura del RUP mostrada en dos dimensiones

Tamaño 12 …
Time New Roman

Fuente: [ CITATION Yaq15 \l 3082 ]

Falta datos
20
1.2.1.1. HISTORIA

La (FIGURA Nº 7) muestra la historia de RUP. El antecedente más importante se ubica en

1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una
aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de
Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el
proceso de desarrollo Objectory (abreviación de Object Factory).

¿Para qué? FIGURA

No esNº necesario
7

HISTORIA DE PROCESO UNIFICADO RATIONAL

Fuente: [ CITATION Rat05 \l 3082 ]

Posteriormente en 1995 Rational Software Corporation adquiere entre 1995 y 1997 se

desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational
(Rational Approach) adoptando UML como lenguaje de modelado. Desde ese entonces y a la
cabeza de Grady Booch, Ivar Jacobson y Rumbaugh, Rational Software desarrolló e incorporó
diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo
conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

1.2.1.2. CARACTERÍSTICAS DE LA METODOLOGÍA

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres
características esenciales: está dirigido por los la arquitectura y es iterativo e incremental.

21
1.2.1.2.1. PROCESO DIRIGIDO A CASO DE USOS

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de
importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se
define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del
sistema; también guían su diseño, implementación y prueba. Los Casos de Uso constituyen un
elemento integrador y una guía del trabajo. No solo inician como se muestra en la (FIGURA
Nº 8).
FIGURA Nº 8
LOS CASOS DE USO INTEGRAN EL TRABAJO

Tamaño 12 …
Time New Roman
Fuente: [CITATION Los15 \l 3082 ]
Falta datos
Los Casos de Uso no sólo inician el proceso de desarrollo sino establecen la transacción entre
los distintos artefactos que son generados en las diferentes actividades del proceso de
desarrollo. Basándose en los Casos de Uso se crean los modelos de análisis y diseño,
posteriormente se genera la implementación que los lleva a cabo, ayuda a verificar la adecuada
implementación de cada caso de uso en el producto final. Fuente
1.2.1.2.2. PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo

que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios),
así como una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

22
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema,

Fuente
está relacionada con la toma de decisiones que indican la forma de construcción del sistema.
La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de
bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas
de estas restricciones constituyen requisitos no funcionales del sistema.
RUP presta especial atención al establecimiento temprano de una buena arquitectura que no se
vea fuertemente impactada ante cambios posteriores durante la construcción y el
mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar
en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos
los casos de uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura
como casos de uso deban evolucionar en paralelo durante todo el proceso de desarrollo de
software.

En la (FIGURA Nº 9) se muestra la evolución de la arquitectura durante las fases de RUP. Se

tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo
que se hace es ir consolidando la arquitectura por medio de base lines y se va modificando
dependiendo de las necesidades del proyecto.
Mal redactado
FIGURA Nº 9
EVOLUCIÓN DE LA ARQUITECTURA DEL SISTEMA

Fuente: [ CITATION Tol15 \l 3082 ]

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño
Nada que ver la bibliografía…
por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos
concretos del sistema, abstrayéndose de los libro
demás. Para RUP, todas las vistas juntas forman el

23
llamado modelo 4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas
lógica, de implementación, de proceso y de despliegue, más la de casos de uso que es la que
da cohesión a todas.
Durante la construcción, los diversos modelos van desarrollándose hasta completarse. La
descripción de la arquitectura sin embargo, no debería cambiar significativamente debido
a que la mayor parte de la arquitectura se decidió durante la elaboración, incorporando pocos
cambios a la arquitectura, (FIGURA Nº 10).
FIGURA Nº 10
PROCESO DE MADUREZ DE LA ARQUITECTURA
Fuente: [ CITATION Tol151 \l 3082 ]

1.2.1.2.3. PROCESO ITERATIVO E INCREMENTAL

RUP propone tener un proceso iterativo e incremental en donde el trabajo se divide en partes
más pequeñas o mini proyectos, permitiendo generar un equilibrio entre casos de uso y
arquitectura. Cada mini proyecto se puede ver como una iteración (un recorrido más o
menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se
obtiene un incremento que produce un crecimiento en el producto.

24
Una iteración puede realizarse por medio de una cascada como se muestra en (FIGURA Nº
11) la cual pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y
Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas
actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados
con lo obtenido de las iteraciones anteriores.

FIGURA Nº 11
ITERACIÓN DE RUP

Incluye además:
La planificación de la
Iteración.
REQUISITOS El análisis de la iteración.
Actividades especifica.
ANÁLISIS
DISEÑO
IMPLEMENTACIÓN
PRUEBA E INTEGRACIÓN

UNA ITERACIÓN

Fuente: [ CITATION Pro151 \l 3082 ]

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración

aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo
relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede
determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a
las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración,
el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso.
Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las
siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por
completo con la versión actual del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en los

25
 distintas actividades. En la (FIGURA Nº6) se muestra cómo varía el esfuerzo asociado a
las disciplinas según la fase en la que se encuentre el proyecto RUP.

Fases de Inicio y Elaboración: Se enfocan hacia la comprensión del problema y la

tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y
al establecimiento de una base line de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades modelado del
negocio y de requisitos.

Fase de elaboración: Las iteraciones se orientan al desarrollo de la base line de la

arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la base line de la
arquitectura.

Fase de construcción: Se lleva a cabo la construcción del producto por medio de una serie
de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se
procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se
realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del
producto.

Fase de transición: Se pretende garantizar que se tiene un producto preparado para su

entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero que
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

1.2.1.3. MEJORAS PRÁCTICAS PARA EL DESARROLLO DE SOFTWARE

RUP identifica las seis mejores prácticas con las que define una forma efectiva de trabajar
para los equipos de desarrollo de software (FIGURA Nº 6).

- La administración de requerimientos

- El desarrollo iterativo

26
 - La arquitectura basada en componentes
- El modelo visual
- La verificación continua de la calidad
- La administración del cambio.

Estas seis prácticas orientan el modelo y con ellas se pretende solucionar muchos de los
problemas asociados al software. Adicionalmente hay muchos aspectos de diseño que son
bien conocidos, pero que en realidad han sido muy poco implementados en los proyectos
de software; estos son: facilidad de uso, modularidad, encapsulamiento y facilidad de
mantenimiento. Es necesario entonces definir una arquitectura sólida basada en
componentes, para construir mejores y más flexibles soluciones de software para las
necesidades organizacionales.

Los cambios en un proyecto no pueden ser detenidos dado que la evolución del entorno de
cada organización es continua, pero sí pueden ser administrados de manera que su impacto
pueda ser estimado para determinar si dicho cambio se incluye o no y si el proyecto debe
ser reajustado.

Cada cambio en el proyecto debe tener especificado cuándo y cómo se va a realizar, quién
lo va a hacer y qué productos se ven involucrados en ese cambio. En ese punto es donde el
control de cambios y la trazabilidad de los componentes a través de los diversos modelos
adquieren una gran importancia.

1.2.1.3.1. GESTIÓN DE REQUISITOS

RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los
requisitos funcionales y restricciones (FIGURA Nº 12). Utiliza una notación de Caso de
Uso para representar los requisitos. Con la finalidad de especificar el comportamiento
deseado del sistema (objetivos del usuario), así como describir qué debe de hacer, pero no
especifica cómo lo hace y da lugar a un conjunto de posibles escenarios.

La gestión de requisitos debe de asegurarse de resolver el problema correcto y construir

el sistema correcto. Es necesario evaluar el impacto del cambio en cuestión a las
necesidades del negocio y las características del producto (casos de uso). Todos los
27
participantes del proyecto requieren tener acceso a los requisitos.

FIGURA Nº 12

DEPÓSITO DE REQUERIMIENTOS

Fuente:[ CITATION Pro15 \l 3082 ]

1.2.1.3.2. DESARROLLO DE SOFTWARE ITERATIVO

Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se
repiten las actividades pero con distinto énfasis, según la fase del proyecto, (FIGURA Nº6)

- Cada iteración produce una versión ejecutable del sistema.

- Las primeras iteraciones atacan los riesgos mayores.

- Define y robustece la arquitectura de la aplicación en forma temprana.

- Cada iteración permite la retroalimentación del usuario.

- Prueba desde el principio, verificando desempeño y escalabilidad.

- Entregables bien definidos y delimitados permiten tener metas a corto plazo y no una
sola meta a largo plazo.
- El progreso se mide mediante la evaluación de las implementaciones (mediciones
reales).
Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de

28
 esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

1.2.1.3.3. LA ARQUITECTURA BASADA EN COMPONENTES

La clave del éxito es crear arquitecturas duraderas, flexibles al cambio y basadas en componentes
(FIGURA Nº 13).

Reuso de todo “Artefacto”:

- Arquitectura.

- Casos de Uso, Análisis, Diseño, Implementación y Pruebas

- Modelos de interfaces, modelos de negocio, patrones arquitectónicos, etc.

Reuso de tecnología

- Proceso y automatización

- Proyectos

- Guías

FIGURA Nº 13

ARQUITECTURA BASADA EN COMPONENTES

29
Fuente: [ CITATION Pro152 \l 3082 ]

1.2.1.3.4. MODELO VISUAL (USANDO UML)

El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema:
requisitos, diseños e implementaciones (FIGURA Nº 14). El modelado visual ayuda a
mejorar la capacidad del equipo para gestionar la complejidad del software a modelar el
sistema independientemente del lenguaje de implementación y promover la reutilización.

FIGURA Nº 14

VISTA DE LA ARQUITECTURA CON UML

Fuente: [ CITATION Pro153 \l 3082 ]

1.2.1.3.5. VERIFICACIÓN CONTINUA DE LA CALIDAD

Es importante que la calidad de todos los artefactos se evalúe en varios puntos durante el
proceso de desarrollo, especialmente al final de cada iteración. En esta verificación las
pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos
los artefactos no ejecutables las revisiones e inspecciones también deben ser continuas (es
de 100 a 1000 veces más costoso encontrar y reparar los problemas del software después

30
 del desarrollo).

Se hace una evaluación objetiva del estatus del proyecto, se detecta inconsistencias entre
análisis, diseño e implementación. Las pruebas se concentran en los aspectos de mayor
riesgo, los defectos se identifican claramente:
- Verificar y probar todo continuamente desde el inicio.

- Toda actividad es verificada: los casos de prueba se definen a partir de:

requerimientos, análisis, diseño y codificación.
- Automatizar la verificación de la calidad con herramientas.
Cada actividad incluye su verificación es decir “Todo aquello que hagas, no lo habrás
terminado, hasta que hayas verificado que hiciste lo que debías de hacer“(FIGURA Nº15).

FIGURA Nº 15
PLAN DE ACTIVIDADES DE ASEGURAMIENTO DE LA CALIDAD.

Fuente: [ CITATION Pro153 \l 3082 ]

1.2.1.3.6. GESTIÓN DE LOS CAMBIOS

El cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos

software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del
producto, sino que durante el proceso de desarrollo, especialmente importantes por su
posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafío que
debe abordarse es la construcción de software con la participación de múltiples
desarrolladores, posiblemente distribuidos geográficamente, trabajando a la vez en una

31
 release, y quizás en distintas plataformas. La ausencia de disciplina rápidamente conduciría
al caos.

La administración de Configuración y Cambios es:

- Permitir, controlar y monitorear cambios para habilitar un desarrollo iterativo.

- Controlar todos los artefactos de software modelos, código, documentos, etc.

- Administrar todas las versiones, con integración automática a los cambios

realizados al software.
- Establecer espacios de trabajos seguros y aislados para cada desarrollador.

- Contar con métricas de estado y avance.

1.2.1.4. ESTRUCTURA DEL PROCESO

El proceso puede ser descrito en dos dimensiones o ejes:

- Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos

dinámicos del proceso. Indica las características del ciclo de vida del proceso
expresado en términos de fases, iteraciones e hitos. Se puede observar en la
(FIGURA Nº6) que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y
Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en
iteraciones.

- Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en
términos de componentes de proceso, disciplinas, flujos de trabajo, actividades,
artefactos y roles.

1.2.2. AUP- PROCESO UNIFICADO ÁGIL

El Proceso Unificado Ágil (AUP, del inglés Agile Unified Process) es una versión

simplificada del Proceso Unificado de Rational (Rational Unified Process, RUP) desarrollada
por Scott Ambler, que describe una aproximación al desarrollo de aplicaciones que combina

32
conceptos propios del proceso unificado tradicional con técnicas ágiles, con el objetivo de
mejorar la productividad.
En general, el Proceso Unificado Ágil supone un enfoque intermedio entre XP (Extreme
Programming) y el Proceso Unificado de Rational, y tiene la ventaja de ser un proceso ágil
que incluye explícitamente actividades y artefactos a los que la mayoría de desarrolladores ya
están, de alguna manera, acostumbrados.

1.2.2.1. CICLO DE VIDA DEL PROCESO UNIFICADO AGIL (AUP)

El Proceso Unificado Ágil consta de cuatro fases (FIGURA Nº 16) que el proyecto atraviesa
de forma secuencial. Dichas fases son:
FIGURA Nº 16
CICLO DE VIDA DEL PROCESO UNIFICADO AGIL

Fuente:[CITATION Ing20 \l 3082 ]

1. Iniciación. El objetivo de esta fase es identificar el alcance inicial del proyecto, una
arquitectura potencial para el sistema y obtener, si procede, financiación para el proyecto y la
aceptación por parte de los promotores del sistema.

2. Elaboración. Mediante esta fase se pretende identificar y validar la arquitectura del

sistema.

33
3. Construcción. El objetivo de esta fase consiste en construir software desde un punto de
vista incremental basado en las prioridades de los participantes.

4. Transición. En esta fase se valida y despliega el sistema en el entorno de producción.

La siguiente (FIGURA Nº 7) muestra un esquema de estas cuatro fases incluyendo, además,

los objetivos y tareas fundamentales de cada una, así como los diferentes hitos por los que
pasa el proyecto como; Objeticos del ciclo de vida, Arquitectura del ciclo de vida, Capacidad
de Operación Inicial y Lanzamiento del producto.

FIGURA Nº1 7
OBJETIVOS Y TAREAS FUNDAMENTALES

Fuente: [ CITATION Pab12 \l 3082 ]

A lo largo de las cuatro fases, se desarrollan actividades relativas a siete disciplinas de manera
iterativa:

1. Modelado. Su objeto es entender la lógica de negocio de la aplicación, el dominio del

problema del proyecto e identificar una solución viable para el dominio del problema.

2. Implementación. Transformar los modelos en código ejecutable y realizar pruebas

básicas, en particular pruebas unitarias.

3. Pruebas. Realizar una evaluación de los objetivos para asegurar la calidad. Esto incluye
encontrar defectos, validar que el sistema funciona como fue diseñado y verificar que los
requisitos se cumplen.

34
4. Despliegue. Planear la entrega del sistema y ejecutar el plan para hacer que el sistema
quede disponible para los usuarios finales.

5. Gestión de la configuración. Gestionar el acceso a los artefactos del proyecto. Esto

incluye, además de la traza de versiones de los artefactos, el control de cambios y la gestión de
los mismos.

6. Gestión del proyecto. Dirige las actividades que tienen lugar dentro del proyecto,
incluyendo gestión de riesgos, dirección del personal y coordinación.
7. Entorno. Apoyar el resto del esfuerzo asegurando que los procesos, métodos y
herramientas están disponibles para el equipo cuando los necesitan.

En la próxima entrega veremos cómo se tratan en el Proceso Unificado Ágil los modelos y la
documentación. [ CITATION Pab121 \l 3082 ]

1.3. UML – LENGUAJE DE MODELADO UNIFICADO

UML es un lenguaje de modelado para visualizar, especificar, construir y documentar partes

de un sistema software desde distintos puntos de vista. Puede usarse con cualquier proceso de
desarrollo, a lo largo de todo el ciclo de vida y puede aplicarse a todos los dominios de
aplicación y plataformas de implementación.

También puede usarse en tres áreas, como la ingeniería de negocio y modelado de procesos
gracias a los mecanismos de adaptación/extensión mediante perfiles.

1.3.1. UML COMO LENGUAJE PARA ESPECIFICAR

Especificar es construir modelos precisos, no ambiguos y completos. UML cubre la

especificación de todas las decisiones de análisis, diseño e implementación que deben
realizarse al desarrollar y desplegar un sistema con gran cantidad de software. [ CITATION
Ale16 \l 3082 ]

1.3.2. UML COMO LENGUAJE PARA VISUALIZAR

La distancia entre pensar en una implementación y transformarla en código es casi cero. En

algunos casos: Lo que piensas lo codificas. Algunas cosas se modelan mejor textualmente;

35
otras se modelas mejor de forma gráfica UML es algo más que un simple montón de símbolos
gráficos. [ CITATION Nor17 \l 3082 ]

1.3.3. UML COMO LENGUAJE PARA CONSTRUIR

No es un lenguaje de programación visual, pero sus modelos pueden conectarse de forma

directa a una gran variedad de lenguajes de programación. Java, C++, HTML, tablas en
una base de datos relacional. Las cosas que se expresan mejor se gráficamente se expresan en
UML mientras que las que se expresan mejor textualmente se plasman en el
lenguaje de programación. Esto permite la ingeniería directa, es decir la generación de código
a partir de un modelo UML como también la ingeniería inversa que consiste en escribir código
a partir de una implementación, ésta requiere de herramientas que la soporten y de la
intervención humana. UML es lo suficientemente expresivo y no ambiguo para permitir la
ejecución directa de modelos, la simulación de sistemas y la coordinación de sistemas de
ejecución.

1.3.4. UML COMO LENGUAJE PARA DOCUMENTAR

Una organización de software, además de código ejecutable, debe producir toda clase de
artefactos como:

- Requisitos.
- Arquitectura.
- Diseño.
- Código fuente.
- Planificación de proyectos.
- Pruebas.
- Prototipos.
- Versiones.

Estos son críticos para el control, la medición y comunicación que requiere un sistema durante

su desarrollo y después de su despliegue. UML cubre la documentación de la arquitectura y
todos sus detalles. UML proporciona un lenguaje para expresar requisitos y pruebas y para
modelar las actividades de planificación de proyectos y gestión de versiones.[ CITATION
Ale18 \l 3082 ]

36
1.3.5. VISTAS DEL MODELO DE UN SISTEMA

Modelado de la arquitectura de un sistema software (FIGURA Nº 18) vista de diseño, vista de

implementación, vista de procesos, vista de despliegue, vista de casos de uso, vocabulario,
funcionalidad ensamblado y gestión configuración. Topología entrega distribución instalación
Funcionamiento escalabilidad rendimiento comportamiento.

FIGURA Nº 18

MODELADO DE LA ARQUITECTURA DE UN SISTEMA

Fuente: [ CITATION Car17 \l 3082 ]

La vista de casos de uso de un sistema comprende los casos de uso que describen el
comportamiento del sistema tal y como es percibido por los usuarios finales, analistas, y
encargados de las pruebas.

- La vista de diseño de un sistema comprende las clases, interfaces y colaboraciones que

forman el vocabulario del problema y la solución.
- La vista de procesos de un sistema comprende los hilos y procesos que forman los
mecanismos de sincronización y concurrencia del sistema.
- La vista de implementación de un sistema comprende los componentes y archivos que
se utilizan para ensamblar y hacer disponible el sistema físico.
- La vista de despliegue de un sistema contiene los nodos que forman la topología

37
 hardware sobre la que se ejecuta el sistema.

Cada una de estas cinco vistas puede existir por sí misma, de forma que diferentes usuarios
pueden centrarse en las cuestiones de la arquitectura del sistema que más le interese.

1.3.6. ELEMENTOS UML

Un elemento es considerado como una abstracción y dichos elementos (FIGURA Nº 19), se

clasifican en estructurales, de comportamiento, de agrupación y de anotación. En esta lección
daremos una descripción general, ya que a medida que se profundice en el contenido del
módulo se dará respuesta a cada uno de los términos de relaciones a este espacio.

FIGURA Nº 19

ELEMENTOS UML

Fuente: [ CITATION Uni161 \l 3082 ]

1.3.6.1. ELEMENTOS DE AGRUPAMIENTO

Se realiza mediante el elemento de agrupación denominado paquete, es presentada por una

caja que dentro de esta se puede se descompuesto un modelo. También aparecen los
Frameworks, modelos y subsistemas como a variaciones o tipos de paquetes.

38
1.3.6.2. ELEMENTOS ESTRUCTURALES

Es hace referencia a la parte estética de un modelo, representando elementos conceptuales o

físicos. Son siete los tipos de elementos estructurales que son: Clase, Interfaz, Colaboración,
Caso de uso, clase activa, componente, y nodo. Es importante tener muy claro que los nodos y
componentes representan elementos físicos.

Al igual que los elementos de agrupación en estos elementos tampoco encontramos con
variaciones a los siete elementos mencionados que se identifican como:

Tipos de clase: actores, señales, utilidades, Tipos de clases activas: procesos e hilos y Tipos
de Componentes: aplicaciones, documentos, archivos, bibliotecas, páginas y tablas.

1.3.6.3. ELEMENTOS DE COMPORTAMIENTO

Es la parte dinámica de un modelo y se ve representada por los verbos que representan una
función sobre tiempo y espacio. Se identifican dos tipos de elementos de comportamiento: la
interacción y la máquina de estado.

1.3.6.4. ELEMENTOS ANOTACIÓN

Son los comentarios explícitos o muy detallados de un modelo UML y se aplican para
describir, iluminar y remarcar algunos elementos del modelo. Solo presenta un tipo de
elemento de anotación que es denominado Nota y este re registraran los comentarios y
limitaciones asociados a un elemento o una colección de datos. [ CITATION Uni16 \l 3082 ]

1.3.7. RELACIONES EN UML

Las relaciones entre clasificadores son asociación, generalización y varios tipos de

dependencia, entre los que se incluyen la realización y el uso (véase TABLA Nº 2).

TABLA Nº 2

TIPOS DE RELACIONES

39
 Fuente: [ CITATION Jam14 \l 3082 ]

1.3.7.1. ASOCIACIONES
Una asociación es una relación estructural que describe una conexión entre objetos.

FIGURA Nº 20
RELACIÓN DE ASOCIACIÓN

Fuente: [ CITATION Art19 \l 3082 ]

En la (FIGURA Nº 20) e1 podemos observar una relación entre la clase Cliente y la clase
Dirección.

1.3.7.2. DEPENDENCIA

Es una relación más débil que una asociación que muestra la relación entre un cliente y el
proveedor de un servicio usado por el cliente. Los conceptos que hacen parte una relación de
dependencia son Cliente y Servidor.

- Cliente: Es el objeto que solicita un servicio.

40
 - Servidor: Es el objeto que provee el servicio.

FIGURA Nº 21
DEPENDENCIA

Fuente: [ CITATION Art191 \l 3082 ]

En la (FIGURA Nº 21) podemos observar que la clase Ecuación necesita las operaciones de la
clase Math para poder operar. Este tipo de relación es muy importante porque muchos
patrones de diseño usan este tipo de relación.

1.3.7.3. GENERALIZACIÓN / ESPECIALIZACIÓN

Son relaciones de herencia entre una superclase y sus subclases. Podemos usarlas cuando
objetos de distintas clases pueden tener atributos similares y exhibir comportamientos
parecidos véase en (FIGURA Nº 22).
FIGURA Nº 22

GENERALIZACIÓN

Fuente: [ CITATION Art192 \l 3082 ]

41
Las subclases heredan características de las clases de las que se derivan y añaden
características específicas que las diferencian.

1.3.7.4. REALIZACIÓN

Es una relación semántica entre clasificadores donde este especifica unas normas o un
reglamento con otro clasificador que garantiza que se cumplirá.

Se encuentran relaciones de realización (FIGURA Nº 23): entre interfaces, clases y

componentes que las realizan y entre los casos de uso y las colaboraciones que los realizan.

Si confrontamos las relaciones de la dependencia, la generalización y la asociación notamos

que la realización es diferente a las otras relaciones mencionadas y así poderla trabajar como
un tipo aparte de relación. Pero semánticamente la realización es una mezcla entre
dependencia y generalización.

FIGURA Nº 23
REALIZACIÓN

Fuente: [ CITATION Art193 \l 3082 ]

1.3.8. DIAGRAMAS UML

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de
diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.

42
UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para
generar código en diversos lenguajes usando los diagramas. UML guarda una relación directa
con el análisis y el diseño orientados a objetos.

1.3.8.1. TIPOS DE DIAGRAMAS UML

UML usa elementos y los asocia de diferentes formas para formar diagramas que representan
aspectos estáticos o estructurales de un sistema, y diagramas de comportamiento, que captan
los aspectos dinámicos de un sistema.

1.3.8.1.1. DIAGRAMAS UML ESTRUCTURALES

- Diagrama de clases: El diagrama UML más comúnmente usado, y la base principal de

toda solución orientada a objetos. Las clases dentro de un sistema, atributos y
operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas
de clases al crear diagramas de sistemas grandes.

- Diagrama de componentes: Muestra la relación estructural de los elementos del

sistema de software, muy frecuentemente empleados al trabajar con sistemas
complejos con componentes múltiples. Los componentes se comunican por medio de
interfaces.

- Diagrama de estructura compuesta: Los diagramas de estructura compuesta se usan

para mostrar la estructura interna de una clase.

- Diagrama de implementación: Ilustra el hardware del sistema y su software. Útil

cuando se implementa una solución de software en múltiples máquinas con
configuraciones únicas.

- Diagrama de objetos: Muestra la relación entre objetos por medio de ejemplos del

mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos
están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones

43
 entre objetos.

- Diagrama de paquetes: Hay dos tipos especiales de dependencias que se definen

entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes
pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se
pueden marcar las dependencias de paquetes para mostrar el mecanismo de
comunicación entre niveles.

1.3.8.1.2. DIAGRAMAS UML DE COMPORTAMIENTO

- Diagramas de actividades: Flujos de trabajo de negocios u operativos representados

gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los
diagramas de actividades se usan como una alternativa a los diagramas de máquina de
estados.

- Diagrama de comunicación: Similar a los diagramas de secuencia, pero el enfoque

está en los mensajes que se pasan entre objetos. La misma información se puede
representar usando un diagrama de secuencia y objetos diferentes.

- Diagrama de panorama de interacciones: Hay siete tipos de diagramas de

interacciones. Este diagrama muestra la secuencia en la cual actúan.

- Diagrama de secuencia: Muestra cómo los objetos interactúan entre sí y el orden de la

ocurrencia. Representan interacciones para un escenario concreto.

- Diagrama de estados: Similar a los diagramas de actividades, describen el

comportamiento de objetos que se comportan de diversas formas en su estado actual.

- Diagrama de temporización: Al igual que en los diagramas de secuencia, se

representa el comportamiento de los objetos en un período de tiempo dado. Si hay un
solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los
objetos se muestran durante ese período de tiempo particular.

- Diagrama de caso de uso: Representa una funcionalidad particular de un sistema. Se

44
 crea para ilustrar cómo se relacionan las funcionalidades con sus controladores
(actores) internos/externos. [ CITATION Ant18 \l
3082 ]

1.3.9. TÉCNICAS Y MÉTRICAS PARA LA EVALUACIÓN DE LA USABILIDAD

El éxito de un programa depende directamente de la calidad de su interfaz. Al usuario final

poco o nada le importa el tipo de tecnología que se utiliza detrás de la interfaz, él no entiende
de protocolos, paquetes o enrutamiento, el solo juzga lo que ve y cómo se comporta frente a
sus necesidades. Pero lo que sorprende de este asunto, es la poca motivación que presentan las
empresas en invertir dinero y tiempo para la evaluación y mejoramiento de sus interfaces, aun
sabiendo las altas tasas de retorno de dicha inversión. A esta situación se le atribuyen
diferentes causas, entre ellas: el simple desconocimiento de técnicas o herramientas para
ejecutar esta labor, pero en otros, consecuencia de una cultura de desarrollo anticuado
centrado en la tecnología y no en el usuario y sus tareas.

1.3.9.1. EVALUACIÓN DE LA USABILIDAD

En términos generales, se define la evaluación como el proceso sistemático, continuo e

integrador de todos los aspectos de un proceso; que recolecta y analiza información para
describir la realidad y emitir juicios de valor sobre su adecuación a un patrón o criterio de
referencia establecido como base para la toma de decisiones.

La evaluación de la usabilidad es un proceso que busca establecer una medida confiable de la

facilidad con que los usuarios interactúan con un sistema. La evaluación de usabilidad para
algunos autores como Mayhew, es un estudio empírico con usuarios reales del sistema
propuesto, con el propósito de proporcionar retroalimentación en el desarrollo de software
durante el ciclo de vida de desarrollo iterativo.

El propósito más importante de la evaluación no es demostrar, sino perfeccionar el proceso o

producto evaluado. Por tanto, la finalidad perseguida en la elaboración de una guía de
evaluación es brindar herramientas para facilitar el desarrollo de una cultura de evaluación de
la usabilidad software. Es pertinente en el desarrollo software, y en general de todo proceso,

45
una cultura que evalúe; incorporando a la evaluación como una práctica cotidiana de todos los
integrantes del proceso de desarrollo. Como consecuencias directas de la evaluación se tiene:

- Mejoramiento en la calidad de los procesos: derivada de una cultura de desarrollo

organizada y consciente de la importancia de la evaluación.

- Mejoramiento en la calidad en los productos: validación consciente y temprana de los

diferentes módulos que conforman el sistema.

- Manejo eficiencia de los recursos tiempo y dinero: consecuencia derivada de la

corrección temprana de fallas.

- Posibilidad de reproducir éxitos en otros proyectos: cada módulo desarrollado se

convierte en una fuente confiable de código reutilizable, además de evolucionar a
procedimientos ágiles y óptimos para la evaluación del sistema.

- Dominación de los riesgos del proceso: entre más rápido se detecten fallas, las estrategias
de contingencia de riesgos serán más efectivas.

- Confianza y satisfacción del cliente: la validación conjunta con el usuario, evita

sorpresas desagradables en etapas críticas del desarrollo.

La propuesta metodológica definida en este trabajo de grado, toma conceptos de ambos

enfoques y comienza por modelar la usabilidad de un sitio en términos de Criterios, Métricas y
Atributos; esquema denominado Modelo de Medición de Usabilidad basada en Jerarquía de
tres Niveles. En la Ilustración (FIGURA Nº24), se muestra dicho modelo. Capa uno de los
niveles o capas definidos por el modelo pretende acerca la definición de usabilidad con los
elementos tangibles del sitio.

FIGURA Nº 24
MODELO DE MEDICIÓN DE USABILIDAD BASADA EN
JERARQUÍA DE TRES NIVELES.

46
 Fuente: [ CITATION Ivá16 \l 3082 ]

Por otro lado, el clásico proceso de evaluación de productos software puede ser descrito de
acuerdo al modelo mostrado en la (FIGURA Nº 25) . Dicho modelo ha sido interpretado de la
siguiente forma: para pasar de la fase de desarrollo Fase N a Fase N+1  es necesario un
proceso de evaluación: un procedimiento que controle, mejore y permita hacer seguimiento de
la calidad tanto del producto como del proceso. Dicho proceso se construye con base en dos
entradas fundamentales: los requerimientos, criterios o métricas a evaluar, y las técnicas o
métodos que permitan recolectar y procesar datos de la evaluación.
FIGURA Nº25

MODELO BÁSICO DE EVALUACIÓN SOFTWARE

47
Fuente: [ CITATION Ivá161 \l 3082 ]

Es oportuno agregar como consideraciones importantes durante la selección de herramientas

de evaluación a los recursos disponibles (tiempo y dinero); perfiles de los evaluadores y
usuarios del sistema (características físicas, cognitivas, culturales); experiencias y aportes que
el equipo de evaluadores tenga sobre el método y la teoría; y finalmente, expectativa frente al
grado de exactitud con el cual la evaluación describe las características de calidad expuestas
por el sistema (modelos cuantitativos o cualitativos).

Apropiándose del modelo anterior, el conjunto de requerimientos o criterios para la valoración

de la usabilidad estará dado por un Modelo de Medición de Usabilidad para la Web, que
combinado con las técnicas o métodos apropiados, podrá establecer una herramienta de
evaluación de la usabilidad. Ya se dieron algunas pautas para generar el modelo y por tanto el
siguiente apartado tiene por objetivo definir dicho modelo.

1.3.9.2. MODELO DE MEDICIÓN DE LA USABILIDAD PARA LA WEB

Bajo una definición formal, una métrica es un valor numérico o nominal asignado a
características o atributos de un ente y se calcula a partir de un conjunto de datos observables
y consistentes con la intuición. Es una correspondencia entre un dominio empírico y un mundo

48
formal o matemático. La métrica puede ser directa o indirecta, interna o externa, objetiva o
subjetiva.

La métrica debe ser en todo momento una medida válida, la medida debe ser una
caracterización numérica apropiada del atributo, mostrando que se satisfaga la condición de
representación, esto es, que la correspondencia entre el dominio empírico y el nuevo dominio
numérico o simbólico preserve la relación de manera que estudiando y analizando a los
números podamos explicar y conjeturar sobre el ente del mundo real. Cualquier medida que
satisfaga la condición de representación es una métrica válida.

Kitchenham afirma que para decir si una métrica es válida es necesario al menos confirmar:

- La validez del atributo: si el atributo en cuestión es realmente exhibido por el ente que
se desea evaluar.
- La validez de la unidad: si la unidad de medición a ser usada es apropiada para medir el
atributo.

Para este trabajo, siguiendo con el modelo de evaluación planteado, las métricas de usabilidad
Web se han agrupado dentro de seis grandes criterios: Aprendizaje, Operatividad,
Satisfacción, Contenido, Eficiencia y Eficacia. Esta división obedece principalmente a la
combinación entre las diferentes definiciones de usabilidad que se han apropiado para este
trabajo de grado. Dentro de cada criterio se dispone de un conjunto de métricas que creemos,
según resultados de nuestro trabajo de investigación y juicios propios, se han dispuesto como
las más adecuadas para cada criterio.

Desde este enfoque, las Métricas de usabilidad para la Web pueden verse como requisitos
deseables para una aplicación Web. El cálculo de dichas métricas no se realiza directamente,
para ello se define un conjunto de atributos e indicadores por cada métrica. Los Atributos son
elementos más prácticos y claros que cualifican o cuantifican las métricas (preferiblemente
cuantitativo para facilitar su análisis a través de métodos estadísticos). Los Indicadores, se han
postulado como estrategias para la medida de los atributos; en muchos casos, estas estrategias
resultan igual de abstractas que los mismos atributos, para tal caso se espera que una vez

49
definidas las métricas particulares a utilizar en el contexto de la evaluación, se precise de
argumentos numéricos que permitan estimar una medida.

1.3.9.3. VALIDACIÓN Y ACERCAMIENTO AL CONTEXTO DEL MODELO DE

MEDICIÓN PLANTEADO

Una vez definido el Modelo de Medición de la Usabilidad para la Web, se procede a

comprobar si éste tiene validez y coherencia con las teorías y conceptos de usabilidad. Para
ello, se diseña y presenta a un conjunto de expertos en el área de la usabilidad unas encuestas
en la cual se piden dos cosas: primero, ponderar los elementos componentes del modelo
planteado, teniendo como base el contexto para el cual se va a utilizar (la aplicación Web del
Departamento de Asuntos Estudiantiles) y segundo expresar, en forma de comentario, la
opinión que el modelo le merece. [ CITATION Ivá162 \l 3082 ]

1.3.10. PHP

PHP es un lenguaje interpretado del lado del servidor que surge dentro de la corriente
denominada código abierto (open source). Se caracteriza por su potencia, versatilidad,
robustez y modularidad. Al igual que ocurre con tecnologías similares, los programas son
integrados directamente dentro del código HTML. En este libro se explicará en detalle la
sintaxis y el funcionamiento de este lenguaje, de momento se realiza a continuación una breve
comparativa con las otras tecnologías del lado del servidor descritas previamente.

1.3.10.1. CARACTERÍSTICAS DE PHP

PHP presenta cuatro grandes características:

1) Velocidad: PHP no solo es rápido al ser ejecutado sino que no genera retrasos en la
máquina, por esto no requiere grandes recursos del sistema. PHP se integra muy bien
junto a otras aplicaciones, especialmente bajo ambientes Unix.
2) Estabilidad: PHP utiliza su propio sistema de administración de recursos y posee de un
sofisticado método de manejo de variables, conformando un sistema robusto y estable.
3) Seguridad: PHP maneja distintos niveles de seguridad, estos pueden ser configurados
desde el archivo .ini

50
 4) Simplicidad: Usuarios con experiencia en C y C++ podrán utilizar PHP rápidamente.
Además PHP dispone de una amplia gama de librerías, y permite la posibilidad de
agregarle extensiones. Esto le permite su aplicación en múltiples áreas, tales como
encriptado, gráficos, XML y otras.

1.3.10.2. Ventajas Y Desventajas De PHP

a) Ventajas: Es un lenguaje multiplataforma.

- Completamente orientado al desarrollo de aplicaciones web dinámicas con acceso a
información almacenada en una Base de Datos.

- El código fuente escrito en PHP es invisible al navegador y al cliente ya que es el

servidor el que se encarga de ejecutar el código y enviar su resultado HTML al
navegador. Esto hace que la programación en PHP sea segura y confiable.

- Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan
en la actualidad, destaca su conectividad con MySQL y PostgreSQL.

- Capacidad de expandir su potencial utilizando la enorme cantidad de módulos

(llamados ext's o extensiones).

b) Desventajas:

- Como es un lenguaje que se interpreta en ejecución para ciertos usos puede resultar un
inconveniente que el código fuente no pueda ser ocultado. La ofuscación es una técnica
que puede dificultar la lectura del código pero no la impide y, en ciertos casos,
representa un costo en tiempos de ejecución. [ CITATION Jes16 \l 3082 ]

1.3.11. GESTOR DE BASE DE DATOS MYSQL

MySQL es un gestor de bases de datos relacional de licencia. Una base de datos relacional
desde un punto de vista lógico usa tablas para guardar los datos. Internamente un mecanismo
de almacenamiento (storage engine) es el encargado de almacenar en último término los datos
de las tablas en dispositivos físicos, para que estos tengan durabilidad. El mecanismo es
totalmente clave a la hora de evaluar la rapidez y las funcionalidades que puede ofrecer el

51
SGBD. MySQL tiene la opción de incluir dinámicamente desde MySQL los distintos
mecanismos para soportar el almacenamiento de las tablas.  [ CITATION Wii16 \l
3082 ]

1.3.11.1. CARACTERÍSTICAS DE MYSQL

MySQL presenta algunas ventajas que lo hacen muy interesante para los desarrolladores. La más
evidente es que trabaja con bases de datos relacionales, es decir, utiliza tablas múltiples que se
interconectan entre sí para almacenar la información y organizarla correctamente.

Al ser basada en código abierto es fácilmente accesible y la inmensa mayoría de programadores

que trabajan en desarrollo web han pasado usar MySQL en alguno de sus proyectos porque al
estar ampliamente extendido cuenta además con una ingente comunidad que ofrece soporte a
otros usuarios. Pero estas no son las únicas características como veremos a continuación:

1)  Arquitectura Cliente y Servidor: MySQL basa su funcionamiento en un modelo cliente y

servidor. Es decir, clientes y servidores se comunican entre sí de manera diferenciada para un
mejor rendimiento. Cada cliente puede hacer consultas a través del sistema de registro para
obtener datos, modificarlos, guardar estos cambios o establecer nuevas tablas de registros, por
ejemplo.
2)  Compatibilidad con SQL: SQL es un lenguaje generalizado dentro de la industria. Al ser
un estándar MySQL ofrece plena compatibilidad por lo que si has trabajado en otro motor de
bases de datos no tendrás problemas en migrar a MySQL.

3)  Vistas: Desde la versión 5.0 de MySQL se ofrece compatibilidad para poder configurar
No emplear niveles de
vistas personalizadas del mismo modo que podemos hacerlo en otras bases de datos SQL. En

números…
bases de datos de gran tamaño las vistas se hacen un recurso imprescindible.
4)  Procedimientos almacenados. MySQL posee la característica de no procesar las tablas
Viñetas o niveles del
directamente sino que a través de procedimientos almacenados es posible incrementar la

abecedario
eficacia de nuestra implementación.

52
  Fuente bibliográfica, todas están
incompletas
5)  Siga
 Desencadenantes. MySQL laspermite
recomendaciones hechas
además poder automatizar ciertas tareas dentro de
nuestra base deen datos.clase…
En el momento que se produce un evento otro es lanzado para

 Leer el material de clases

actualizar registros u optimizar su funcionalidad.
6)  Transacciones. Una transacción representa la actuación de diversas operaciones en la base
 Debes mejorar todo el
de datos como un dispositivo. El sistema de base de registros avala que todos los
documento …
procedimientos se establezcan correctamente o ninguna de ellas. En caso por ejemplo de una
falla de energía, cuando el monitor falla u ocurre algún otro inconveniente, el sistema opta
por preservar la integridad de la base de datos resguardando la información.

1.3.11.2. VENTAJAS DE USAR MYSQL

Descritas las principales características de MySQL es fácil ver sus ventajas. MySQL es una
opción razonable para ser usado en ámbito empresarial. Al estar basado en código abierto permite
a pequeñas empresas y desarrolladores disponer de una solución fiable y estandarizada para sus
aplicaciones. Por ejemplo, si se cuenta con un listado de clientes, una tienda online con un
catálogo de productos o incluso una gran selección de contenidos multimedia disponible, MySQL
ayuda a gestionarlo todo debida y ordenadamente.

Todo lo que esta con fondo de color rosado

debe revisar
Leer en vos alta para no cometer errores

53