desarrollo de un framework en php para desarrollo de ... web view... y que es el módulo de...
TRANSCRIPT
CFT ANDRÉS BELLO
DEPARTAMENTO DE TECNOLOGÍA
DESARROLLO DE UN FRAMEWORK EN PHP PARA DESARROLLO DE APLICACIONES EN ENTORNOS WEBS
JAVIER CARVAJAL OBREQUE.
VINICIUS HERNÁNDEZ SCHIFFERLI.
ENRIQUE OSVALDO MONTERO SAN JUAN.
JUAN CARLOS MARCHANT HERNANDEZ
2017
CFT ANDRÉS BELLO
DEPARTAMENTO DE TECNOLOGÍA
DESARROLLO DE UN FRAMEWORK EN PHP PARA DESARROLLO DE
APLICACIONES EN ENTORNOS WEBS.
TRABAJO DE TÍTULO PARA OPTAR AL TÍTULO DE TECNICO DE NIVEL SUPERIOR EN COMPUTACIÓN E INFORMÁTICA
PROFESOR GUÍA: SRTA. SARA NAMINAO
JAVIER CARVAJAL OBREQUE.
VINICIUS HERNÁNDEZ SCHIFFERLI
ENRIQUE OSVALDO MONTERO SAN JUAN
JUAN CARLOS MARCHANT HERNANDEZ
2017
I
Agradecimientos
Dedico esta tesis a todas esas personas que hicieron posible el que yo siga adelante con su apoyo y cariño incondicional a mis profesores del centro de formación técnica Andrés Bello de la ciudad de Temuco, a mis compañeros por su apoyo, a mis padres, tíos y tías y por darme fuerzas para salir adelante por estar siempre dispuestos a ayudarme cuando yo los necesite, a dios por hacer posible mis estudios. Gracias infinitas a todos.
Javier Carvajal
Un paso, una meta está siendo concluida. Agradezco en primera instancia a Luis Miranda y Sara Naminao mis profesores, quienes además de enseñar el conocimiento adquirido, siempre aportaban entusiasmo y simpatía, cuando muchas veces el cansancio físico y psicológico a esas horas vencía.
A mi familia, que siempre ha estado al tanto de mis situaciones académicas, en especial a mi hermano mayor Hamal, quien ha demostrado y tomado preocupación constante en mis labores académicas y situaciones personales.
Esencialmente a Paulina, por haberme impulsado en todo mi proceso académico, ayudándome en cada momento, entregando calma, dedicación e impulsando cuando muchas veces la frustración ante algunas situaciones académicas me invadía, haciendo cada proceso más llevadero, a ti, muchas gracias.
A mi grupo de Tesis, por el conocimiento compartido durante todo este tiempo.
Todo lo que he recibido y todo lo que está por llegar se lo agradezco a Dios.
Vinicius Hernández
Primero a mi Madre Gloria, por brindarme toda su ayuda y apoyo… gracias por todo lo que me has dado, gracias por amarme tanto, le doy gracias a Dios por tenerte y pedirle que sean por muchos años más.
A mis suegros, Ramon y Leticia, por aceptarme tal cual como soy, por considerarme un hijo más y darme todo su apoyo. Gracias por todo eso.
A mis tíos, Daniel, Héctor y José, porque siempre me han apoyado de una u otra forma. Gracias.
A mis profesores del Instituto, gracias por compartir todas sus enseñanzas.
II
A mis 2 amores chicos, mis hijos, Ramon y José, por entregarme todo su amor y apoyo. Alegrarme la vida con sus tonteras. No cambien nunca. Los amo con todo el corazón.
Por último, agradecer a la persona que a estado conmigo desde que salimos junto del liceo; a mi esposa, compañera fiel y amiga, Rossana, por aguantarme y apoyarme en todo, por estar siempre ahí cuando más lo necesite, por amarme con todo su corazón a pesar de mis errores y mañas que me dan, por confiar en mis capacidades de estar trabajando y estudiando al mismo tiempo, por darme 2 hermosos hijos que han sido mis ojos, y por su amor condicional que nos a mantenido junto más de 20 años. Por todo eso…. Gracias…. Y te Amo Mucho.
Osvaldo Montero
Nah … ¡A todos los quiero por igual hasta que me joden!
Juan Carlos Marchant
III
CONTENIDO
Capítulo 1 INTRODUCCION.........................................................................1
1.1 Descripción del Problema..................................................................2
1.2 Objetivo General................................................................................3
1.3 Objetivos Específicos........................................................................4
Capítulo 2 MARCO TEÓRICO......................................................................5
2.1 Introducción.......................................................................................6
2.2 Lenguajes de Programación...............................................................7
2.2.1 Historia del Desarrollo Web.......................................................7
2.2.2 Evolución de los Lenguajes de Programación............................9
2.2.3 PHP...........................................................................................11
2.2.4 MySQL.....................................................................................13
2.2.5 JavaScript, AJAX y JQuery......................................................14
2.2.6 HTML5, CSS3 y Bootstrap......................................................16
2.3 Programación Orientada a Objetos. POO........................................19
2.3.1 Introducción..............................................................................19
2.3.2 Elementos de la POO................................................................23
2.3.3 Características conceptuales de la POO...................................25
2.4 Patrones de Diseño...........................................................................35
2.5 Principios SOLID............................................................................38
2.7.1 Single Responsibility Principle....................................................39
IV
2.7.2 Open Closed Principle..................................................................39
2.7.3 Liskov Substitution Principle.......................................................40
2.7.4 Interface Segregation Principle....................................................40
2.7.5 Dependency Inversion Principle..................................................41
2.6 MVC................................................................................................42
2.7 Calidad del Software........................................................................44
Capítulo 3 Diseño del Framework.................................................................49
3.1 Introducción.....................................................................................50
3.2 Estructura Básica.............................................................................51
3.3 Configuración Inicial.......................................................................54
3.4 Controladores...................................................................................57
3.5 Modelos...........................................................................................58
3.6 Vistas...............................................................................................59
3.7 Archivos de Configuración..............................................................60
3.8 Librerías y Módulos.........................................................................61
3.9 Dependencias...................................................................................62
3.10 Funcionamiento............................................................................64
3.11 Observaciones:.............................................................................69
Capítulo 4 Aplicaciones modulares...............................................................71
4.1 Introducción.....................................................................................72
4.2 Modulo de Usuarios.........................................................................73
4.2.1 Introducción..............................................................................73
V
4.2.2 Base de Datos...........................................................................75
4.2.3 Diagramas.................................................................................78
4.2.4 Interfaces..................................................................................87
4.3 Modulo de Blog...............................................................................95
4.3.1 Introducción..................................................................................95
4.3.2 Base de Datos...............................................................................96
4.3.3 Interfaces......................................................................................99
4.4 Modulo Bodega..............................................................................101
4.4.1 Introducción................................................................................101
4.4.2 Base de Datos.............................................................................103
4.4.3 Diagramas...................................................................................106
4.4.4 Interfaces....................................................................................110
4.5 Modulo Tienda Online...................................................................114
4.5.1 Introducción................................................................................114
4.5.2 Base de Datos.............................................................................116
4.5.3 Diagramas...................................................................................120
4.5.4 Interfaces....................................................................................126
Capítulo 5 Mejoras a futuro.........................................................................132
Capítulo 6 Conclusiones..............................................................................136
Capítulo 7 Bibliografía................................................................................138
Capítulo 8 Anexos.......................................................................................139
Anexo A. Siglas.......................................................................................140
VI
Anexo B. Sobre Frameworks y CMS......................................................141
B.1 Sobre los Frameworks..................................................................141
B.2 Sobre los CMS..............................................................................142
VII
ÍNDICE DE TABLAS
Tabla 3-1 Estructura Inicial framework PHP................................................52
Tabla 3-2 Configuración Inicial....................................................................55
Tabla 3-3 Ejemplo URL petición sin modulo...............................................67
Tabla 3-4 Ejemplo URL petición con modulo..............................................68
Tabla 4-1 Caso de Uso. Registro de Usuario................................................78
Tabla 4-2 Caso de Uso. Login de Usuario....................................................79
Tabla 4-3 Caso de Uso. Modificación de Usuario........................................79
Tabla 4-4 Caso de Uso. Eliminación de Usuario..........................................80
Tabla 4-5 Caso de Uso. Creación de Permiso de Usuario.............................80
Tabla 4-6 Caso de Uso. Modificación de Permiso de Usuario.....................81
Tabla 4-7 Caso de Uso. Eliminación de Permiso de Usuario.......................81
Tabla 4-8 Caso de Uso. Creación de Nuevo Rol...........................................82
Tabla 4-9 Caso de Uso. Modificación de Rol...............................................82
Tabla 4-10 Caso de Uso. Eliminación de Rol...............................................83
Tabla 4-11 Generación de Reportes..............................................................83
Tabla 4-12 Caso de Uso. Creación de Orden de Compra...........................106
Tabla 4-13 Caso de Uso. Creación de Producto..........................................107
Tabla 4-14 Caso de Uso. Creación de Proveedor........................................107
Tabla 4-15 Caso de Uso. Entrada de Producto............................................108
Tabla 4-16 Caso de Uso. Salida de Producto..............................................108
Tabla 4-17 Generación de Reportes............................................................109
Tabla 4-18 Registro de usuarios..................................................................121
Tabla 4-19 Confirmar Compra....................................................................121
VIII
Tabla 4-20 Exhibición de Productos...........................................................122
Tabla 4-21 Editar Perfil de Usuario............................................................122
Tabla 4-22 Añadir Producto Carro..............................................................123
Tabla 4-23 Eliminar Producto Carro...........................................................123
Tabla 4-24 Modificar Producto Catalogo....................................................124
Tabla 4-25 Validez de la cuenta registrada.................................................124
IX
ÍNDICE DE IMAGENES
Imagen 2.1. Eventos y Mensajes de los objetos............................................24
Imagen 2.2. Abstracción................................................................................25
Imagen 3.1. Estructura Básica.......................................................................51
Imagen 3.2. Configuración Inicial.................................................................54
Imagen 3.3. Diagrama Patrón MVC..............................................................64
Imagen 3.4. Core del Framework..................................................................69
Imagen 4.1. Diseño Conceptual Modulo Usuarios........................................75
Imagen 4.2. Diseño Lógico Modulo Usuarios..............................................76
Imagen 4.3. Diseño Físico Modulo Usuarios................................................77
Imagen 4.4. Casos de Uso Generales............................................................84
Imagen 4.5. Casos de Uso Administrador.....................................................84
Imagen 4.6. Secuencia de Registro...............................................................85
Imagen 4.7. Secuencia de Login...................................................................85
Imagen 4.8. Diagrama de Nuevo Role.........................................................86
Imagen 4.9. Registro de Usuarios.................................................................87
Imagen 4.10. Login de Usuarios...................................................................88
Imagen 4.11. Perfil de Usuario......................................................................88
Imagen 4.12. Permisos de Usuario................................................................89
Imagen 4.13. Listado y Reportes de Usuarios...............................................89
Imagen 4.14. Permisos de Rol.......................................................................90
Imagen 4.15. Nuevo Usuario.........................................................................90
Imagen 4.16. Control de Permisos...............................................................91
Imagen 4.17. Editar Permiso.........................................................................91
Imagen 4.18. Eliminar permiso.....................................................................92
X
Imagen 4.19. Nuevo Permiso........................................................................92
Imagen 4.20. Control de Roles......................................................................93
Imagen 4.21. Editar Role...............................................................................93
Imagen 4.22. Eliminar Role..........................................................................94
Imagen 4.23. Nuevo Role..............................................................................94
Imagen 4.24. Diseño Conceptual Modulo Blog............................................96
Imagen 4.25. Diseño Lógico Modulo Blog...................................................97
Imagen 4.26. Diseño Físico Modulo Blog....................................................98
Imagen 4.27. Interface Blog 1.......................................................................99
Imagen 4.28. Interface Blog 2.......................................................................99
Imagen 4.29. Interface Blog 3.....................................................................100
Imagen 4.30. Diseño Fisico Modulo Bodega..............................................105
Imagen 4.31. Listado de Órdenes de Compra.............................................110
Imagen 4.32. Nueva Orden de Compra.......................................................110
Imagen 4.33. Eliminar Orden de Compra...................................................111
Imagen 4.34. Listado de Productos.............................................................111
Imagen 4.35. Agregar Nuevo Producto.......................................................112
Imagen 4.36. Eliminar Producto..................................................................112
Imagen 4.37. Listar Proveedores.................................................................113
Imagen 4.38. Nuevo Proveedor...................................................................113
Imagen 4.39. Diseño Conceptual Modulo Tienda.......................................117
Imagen 4.40. Diseño Lógico Modulo Tienda..............................................118
Imagen 4.41. Diseño Físico Modulo Tienda...............................................119
Imagen 4.42. Casos de Usos generales........................................................125
Imagen 4.43. Listar Productos.....................................................................126
Imagen 4.44. Nuevo Producto.....................................................................126
Imagen 4.45. Editar Producto......................................................................127
XI
Imagen 4.46. Eliminar producto..................................................................127
Imagen 4.47. Listado Marcas......................................................................128
Imagen 4.48. Nueva Marca.........................................................................128
Imagen 4.49. Editar Marca..........................................................................129
Imagen 4.50. Eliminar Marca......................................................................129
Imagen 4.51. Listado de Categorías............................................................130
Imagen 4.52. Nueva categoría.....................................................................130
Imagen 4.53. Editar Categoría.....................................................................131
Imagen 4.54. Eliminar Categoría................................................................131
XII
RESUMEN
Entendamos el concepto de Desarrollo de Aplicaciones Web, como la
implementación de una solución a una necesidad especifica de un usuario, con
la creación de un proyecto determinado que cumpla con los requerimientos del
usuario y de calidad de software por medio del uso de tecnologías web y
lenguajes de programación.
Por otro lado, podemos definir un proyecto como un conjunto de modos y
medios necesarios para llevar a cabo la implementación de una solución a un
problema específico. En el entorno de la informática estos proyectos están
encargados principalmente a desarrolladores o programadores de aplicaciones.
Estos proyectos se desarrollan bajo un entorno de trabajo específico y adecuado
para el fin que los crea.
Para poder determinar la solución más idónea para un proyecto web
determinado es necesario tomar bastantes decisiones y una de las cuales se basa
en saber determinar que entorno de trabajo es el más apropiado para ese
proyecto. Si se usa un gestor de contenidos, conocidos son los CMS, o se usa
un Framework específico y se empieza el desarrollo desde cero.
La presente Tesis trata sobre la creación de un Framework, o entorno de
trabajo, basado en el lenguaje de programación PHP, como lenguaje nativo,
para el desarrollo de Aplicaciones Web. El Framework gestionara
principalmente el acceso a datos a través de la librería PDO, nativa de PHP que
tiene soporte para gestores de base de datos como MySQL, SQL, ODBC, entre
otros. Incluirá soporte para JQuery, librería basada en el lenguaje JavaScript y
para HTML5 y CSS3, estos últimos dos lenguajes se ven reflejados en el uso de
XIII
la librería de código abierto Bootstrap. Implementara composer como gestor de
dependencias para tratar librerías de terceros.
Al finalizar el desarrollo del Framework, este se aplicará en la construcción
de tres desarrollos habituales en el mundo de la Web, como son la creación de
un Blog, el desarrollo de un control de bodega y la implementación de una
tienda online. Estas soluciones implican el desarrollo de un módulo que se hace
común a cualquiera de estos desarrollos y que es el módulo de control de
usuarios y sus permisos
.
XIV
CAPÍTULO 1
INTRODUCCION
1
Capítulo 1. Introducción
1.1 Descripción del Problema
Ante la presencia de un nuevo proyecto de desarrollo web, una de las
primeras decisiones que el desarrollador o grupo de desarrolladores debe tomar
es que entorno de trabajo usar para el desarrollo. Ante esta cuestión las
opciones son principalmente dos, o usar un CMS que cumpla con los
requerimientos mínimos o usar un Framework que les permita escalar, desde
una estructura nueva, el desarrollo para lograr una solución ideal.
Cualquier decisión que se tome respecto a las soluciones vistas antes va a
depender principalmente de factores como el económico, el tiempo de
desarrollo, la curva de aprendizaje, la escalabilidad del proyecto, la
optimización del proyecto final y sobre todo del fin último del proyecto.
Debemos hacer notar que a día de hoy tanto los CMS como Frameworks más
conocidos también cuentan con una gran comunidad de soporte y que algunos
son de código abierto, lo que hace más o menos difícil la elección de estos para
el desarrollo del proyecto.
Para motivos de esta Tesis, daremos por supuesto que la decisión tomada es
optar por un Framework. Este será uno personalizado y se iniciará desde cero.
Más adelante hablaremos de los Frameworks más conocidos sin entrar en
mayores detalles de estos (puede consultar el Anexo B para más detalles sobre
este tema).
2
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 1. Introducción
1.2 Objetivo General.
Desarrollar un framework para el desarrollo de aplicaciones basadas en
entono web construido bajo PHP y que implemente el patrón arquitectónico
MVC. El framework debe desarrollar aplicaciones optimizadas, garantizar
seguridad y permitir la escalabilidad.
3
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 1. Introducción
1.3 Objetivos Específicos.
Desarrollar un framework en PHP desde cero.
Potenciar el conocimiento en tecnologías y lenguajes informáticos.
Comprender el paradigma de la programación orientada a objetos.
Comprender el concepto de patrones de diseño y del patrón
arquitectónico MVC (Modelo-Vista-Controlador)
Hacer uso del framework creado para desarrollar aplicaciones web de
uso habitual como lo es un Blog, una Tienda Online y un Control de
Bodega.
Analizar el framework y la aplicación según parámetros de calidad del
software.
4
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
CAPÍTULO 2
MARCO TEÓRICO
5
Capítulo 2. Marco Teórico
2.1 Introducción.
En el mundo de la programación, así como existen lenguajes de
programación (Y sí que hay muchos) existen frameworks de desarrollos para
cada uno de ellos, algunos están diseñados para proyectos grandes y pesados y
otros son más sencillos y livianos. Sin embargo, el conocer el uso de cualquiera
de estos, implica el conocimiento previo del lenguaje en el cual se ha construido
(esto último puede ser excluyente en algunos casos) para así poder entender,
manejar y construir un buen proyecto.
Ahora ¿Cómo definir un framework? Podría definirlo como un entorno de
trabajo incompleto (sin ninguna funcionalidad aparente, por sí solo no hace
nada) y que posee cierto grado de configuración (u orden) en cómo se agregan
las demás estructuras o componentes para llevar a cabo el desarrollo de un
proyecto.
En esta Tesis se construirá un Framework desde cero, revisando desde la
estructura de archivos a la configuración básica que debe tener para un correcto
funcionamiento. Se revisarán conceptos básicos sobre Programación Orientada
a Objetos y Patrones de Diseño, ambos necesarios para aplicar el patrón MVC
sobre el cual se desarrollará el Framework. Luego se analizarán los conceptos
sobre Calidad de Software y como se aplican tanto en el Framework como en
una aplicación desarrollada bajo esta.
6
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.2 Lenguajes de Programación.
En este capítulo se hará un breve recorrido solo la evolución del desarrollo
web y de los lenguajes de programación. También se describirán los lenguajes
que van a hacer partícipes en la creación del Framework con sus características
principales.
2.2.1 Historia del Desarrollo Web.
La aparición de Internet y el protocolo HTTP, junto a la primera
estandarización de HMTL marcaron los inicios del Desarrollo Web. Los
cambios en la tecnología, el hardware y el software nos permiten diferenciar
cuatro generaciones en el Desarrollo Web.
La primera generación, entre los años 1992 y 1994 hace referencia a páginas
web estáticas, donde la tecnología era muy limitada con módems de 2.4 kbps y
monitores monocromáticos. El sitio web era una sola página, lo que la hacía
muy larga, no tenía una estructura cohesionada, casi no tenían imágenes y su
función era más educativa e informativa. Netscape se impone como navegador
web.
La aparición de la tecnología CGI permite la creación de páginas webs
dinámicas y desde el año 1995 la segunda generación permite la incorporación
de imágenes, iconos y banners. La aparición de los primeros libros de visitas y
pequeños formularios son implementados con CGI. El tiempo de carga es lenta
y siguen siendo sitios, en su mayoría, de una sola página y largas. Aparece la
navegación jerárquica y el uso de tablas para mostrar datos e información más
estructurada. Aparecen monitores y tarjetas gráficas de mayor resolución y esto
permitió la mejora en la calidad del diseño de sitios web. Un punto a mencionar
es la notada separación de estándares entre los dos principales navegadores de
la época, Internet Explorer y Netscape Navigator. Nace la W3C un consorcio
7
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
internacional que genera recomendaciones y estándares que aseguran el
crecimiento de la World Wide Web a largo plazo.
La consolidación de la web dinámica llega en 1996 y con eso la tercera
generación en el desarrollo web. Microsoft crea nuevas tecnologías como
Internet Database Connector (IDC), posteriormente Active Server Pages (ASP).
Aparece Coldfusion, PHP y las Java Server Pages (JSP) basadas en Java. La
aparición de FLASH marca la tendencia en sitios webs hacia el diseño más que
a la experiencia del usuario y según el objetivo de la página, acercar más al
usuario a la página ya sea para vender producto, servicios o información.
La evolución de la tecnología permitió la aparición de la cuarta generación,
la llegada del elemento multimedia, ahora se puede transmitir audio y video en
tiempo real. Las Bases de Datos tienen un papel importante en esta generación,
pues los sitios web se van construyendo en base a la información que se puede
obtener desde las bases de datos. La evolución de HTML y la aparición de
AJAX cambia la forma en cómo se manejan los sitios webs dinámicos.
Aparecen los primeros equipos multidisciplinarios en el desarrollo de sitios
webs. La experiencia del usuario es el enfoque principal, desde que llega a la
página hasta que la abandona.
El desarrollo Web hoy en día a cambiado para bien, tanto así que incluso los
viejos navegadores se han tenido que actualizar y así sobrellevar el nuevo
estándar que implementa HTML5 y CSS3. Las aplicaciones webs ya dejan de
ser simples páginas webs sino más bien pasan a ser una aplicación que cumple
una función específica. Estas ya permiten la escalabilidad, ser multi-usuario y
multi-lenguaje. La seguridad en la información tiene un papel relevante. Todo
esto hace que la aplicación gire en torno al usuario y que este pueda acceder a la
aplicación en cualquier momento y desde cualquier dispositivo haciendo del
cliente (navegador) una herramienta más.
8
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Aparece el termino Responsivo que alude a la capacidad de un sitio web de
adaptarse a diferentes tamaños de pantalla. Estas webs responsivas son
producto de la evolución en la telefonía celular y viene a ser una condición casi
obligatoria para cualquier sitio web a día de hoy.
Se habla de una quinta generación en el desarrollo web y es la que se inicia
con el creciente auge de las páginas de streaming en línea, ya sea emitiendo
video o audio, como las páginas de televisión. Se suma a esto la navegación
desde la nube (Cloud Computing) y los sistemas operativos en la nube y hasta
editores de texto.
El desarrollo web esta implícitamente relacionado con el desarrollo de
HTML y podemos relacionar las generaciones antes mencionadas con su
evolución. A día de hoy el estándar en HTML5 y es con este lenguaje que se
trabajara en el desarrollo del framework.
Hacemos hincapié a la “nivelación hacia arriba”, a desarrollar con los
nuevos estándares y hacer uso de los navegadores más actualizados
2.2.2 Evolución de los Lenguajes de Programación.
Si definimos como programa al conjunto de ordenes e instrucciones que se le
dan a un computador para que resuelva un problema o ejecute alguna
instrucción. Un lenguaje de Programación es un conjunto de ordenes e
instrucciones ya programadas que facilitan la creación de los programas.
Un lenguaje de bajo nivel es aquel que entiende el computador y que para el
ser humano es muy difícil de interpretar. Un lenguaje de alto nivel es aquel en
que el humano puede escribir e interpretar y que, a través de un compilador que
reside en el computador, se puede traducir a lenguaje maquina o de bajo nivel.
En los inicios de la Programación solo existía el lenguaje máquina,
lenguaje que relaciona directamente al programa con la máquina, estaban
9
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
escrito en código binario, eran lento en construcción y propenso a errores, a este
lenguaje se le conoce con el nombre de ASSEMBLY.
Junto al lenguaje maquina aparece también el primer traductor de código o
compilador llamado ASSEMBLER que se encargaba de traducir el lenguaje de
“alto nivel” escrito por los seres humanos en lenguaje maquina o de “bajo
nivel”.
Los primeros lenguajes de “alto nivel” utilizaban una programación no
estructurada, una serie de líneas con instrucciones de salto (GOTO) y en un
único bloque. No existían subrutinas. Entre estos lenguajes podemos encontrar
a BASIC y FORTRAN.
La aparición de PASCAL posibilito el empleo de subrutinas (funciones o
procedimientos). A estos lenguajes se les ubica dentro de la programación
procedimental.
Ante la necesidad de claridad y legibilidad en la escritura de programas,
aparecen las primeras reglas y estructuras en torno a la codificación. Surge así
la programación estructurada que hacía énfasis en una estructura jerárquica
top-down, diseño modular, salidas y entradas claramente definidas,
constructores de programación como: secuencia, selección, iteración y llamadas
a procedimientos.
La programación modular llevo a la división de aquellos programas de
ciento o miles de líneas de código a separar estos en módulos y con esto la
separación de tareas entre diferentes programadores. El problema de esta
programación residía en que no permitía la instanciación ni la exportación de
datos. Si bien los programas se podían separar en módulos aún estaban
intrínsecamente unidos.
Como consecuencia a lo anterior aparecieron los TADs (Tipos Abstractos de
Datos) permitiendo la exportación e instanciación de datos. Este tipo de
10
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
programación da paso al siguiente nivel y que hasta el día de hoy perdura, la
programación orientada a objetos.
La programación orientada a objetos (POO) trae consigo tres nuevos
conceptos, las clases, los objetos y la herencia. Podemos relacionar la POO con
los TADs de manera que una clase es el tipo, el objeto un dato y que la POO es
equivalente a un TAD más la característica de la herencia.
La POO permite un nuevo paradigma de programación, en el cual se permite
diferentes tipos de jerarquías, habilitando las subclases y superclases y con
ellos una nueva característica en la programación, el polimorfismo.
Las clases en la POO manejan objetos que se relacionan entre si a través de
mensajes.
La programación orientada al flujo de datos, usada hasta antes de la POO no
favorecía la reutilización de código. Con esta última, las clases más generales
pueden ser usadas en nuevas aplicaciones.
Así mismo, la POO ya no es top-down, sino más bien, bottom-up, de lo
especifico a lo general, de aquí la importancia de identificar bien los objetos
que participaran en el proyecto.
El primer lenguaje orientado a objetos fue Smalltalk, que sentó las bases para
lenguajes como C++, Eiffel, Perl, entre otros. Los lenguajes orientados a
objetos de hoy en día tienen sus raíces en los ya mencionados, ya sea heredando
características o bien combinando la sintaxis propia de estos lenguajes. En este
grupo tenemos lenguajes como por ejemplo PHP, Ruby, Python, Java, C#, Go.
2.2.3 PHP.
PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) Es un lenguaje
de código abierto y orientado a objetos desde la versión 5 que trabaja de lado
del servidor y es independiente de la plataforma (es soportado por Windows,
11
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
MAC, Linux), ideado para el desarrollo web y que puede ser incrustado en el
HTML. PHP ejecuta código de lado del servidor que transforma a HTML y que
puede ser leído en cualquier navegador web.
Creado originalmente en 1994 por Rasmus Lerdorf, quien se basa en C, Java
y Perl para crear un lenguaje que permita el desarrollo dinámico de contenido
web. Su política de código abierto a permitido que muchos desarrolladores
contribuyan en su código fuente. Actualmente se encuentra en su versión 7.1 y
cuyo motor es Zend Engine.
El acceso a datos en PHP se hace a través de librerías como mysql_*,
mysqli_* o PDO, la primera esta descontinuada y el soporte a la segunda deja
de ser en la última versión de PHP. PDO es una librería, existe desde la versión
5, que permite la conexión a diferentes gestores de Bases de Datos SQL como
MySQL, Oracle, SQL Server, Informix, PostgreSQL, etcétera.
Esta capacidad de PDO permite que el código para administrar la Base de
datos pueda reutilizarse entre diferentes aplicaciones con distintos gestores de
datos, tal vez solo tengas que reformular la sintaxis de las consultas para el
nuevo gestor. También permite escribir código más limpio y seguro además de
permitir un aumento de rendimiento al llamar a la misma consulta SQL muchas
veces con parámetros ligeramente diferentes. Posee un buen manejo de errores.
La librería PDO viene, en su mayoría, instalado por defecto al instalar PHP.
Si no es el caso, solo falta ingresar al archivo de configuración de PHP para
poder habilitar la librería y el driver necesario para el gestor de datos que se
usara.
Con lo antes explicado podemos decir que algunas de las ventajas de PHP
son:
Lenguaje Multiplataforma.
Orientado al desarrollo de webs dinámicas y al acceso de datos.
12
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Soporte para diferentes gestores de datos.
Lenguaje de tipado dinámico.
Buen control de excepciones.
La integración con librerías externas.
¿Desventajas? Desde la versión 5.0 las desventajas al usar PHP se han ido
minimizando, tanto que PHP 7 ofrece una versión del motor que acelera la
carga de la aplicación de hasta un 70% o más en algunos frameworks. También
con la versión nueva se tiene soporte a sistemas Windows de 64 bits, ya que de
forma nativa PHP estaba hecho para funcionar en un entorno LAMP.
Para nuestro propósito, la construcción de un framework, se usa PHP en su
versión 5.6. Sin embargo, actualizar el código del framework a la versión 7.0 o
7.1 es ya una necesidad, no solo por una cuestión de mantener el software
actualizado, sino que para aprovechar las ventajas de las nuevas versiones de
PHP.
2.2.4 MySQL.
MySQL es un sistema gestor de Bases de Datos desarrollada en sus inicios
por MySQL AB la cual fue adquirida por Sun Microsystems en 2008 y está por
Oracle en el 2010. Cuenta con licencia dual GPL/Comercial.
Esta desarrollado en ANSI C y C++, es multiplataforma y es uno de los
componentes de desarrollo en los sistemas LAMP y WAMP. Actualmente va
en la Versión 5.7. Trabaja de fondo con el lenguaje SQL para gestionar las
Bases de Datos
Desde un principio MySQL utiliza el motor no transaccional MyISAM el
cual es bien rápido para Bases de Datos de poca concurrencia, pero carece de
soporte sobre integridad referencial y alto tráfico de transacciones. Con la
13
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
llegada a manos de Oracle, MySQL agrego el motor InnoDB el que si
soportaba las carencias de MyISAM y a partir de la versión 5.1 aparece el
soporte nativo para otros motores como Falcon, Merge. CSV, Blackhole, entre
otros. Estos se pueden ir añadiendo en tiempo de ejecución.
Entre sus características más importantes podemos decir que MySQL
soporta hasta 50 millones de registros y hasta 64 índices por tabla.
MySQL sirve fundamentalmente en desarrollos pequeños a medianos, en
donde la cantidad de datos y transacciones no sea elevada (teniendo en cuenta
los datos anteriores)
Con la compra de MySQL por parte de Sun Microsystems, uno de sus
fundadores, Michael Widenius, desarrollo a la par el gestor MariaDB, con
licencia GPL y que proporciona dos motores de almacenamiento como Aria
(por MyISAM) y XtraDB (por InnoDB).
MariaDB es totalmente compatible con MySQL ya que posee las mismas
órdenes, interfaces, APIs y bibliotecas, siendo su objetivo poder cambiar un
servidor por otro directamente. En la práctica, por ejemplo, las versiones 5.2 de
ambos gestores se pueden intercambiar sin problemas.
Para el desarrollo del framework, se comenzó usando el gestor MySQL que
venía integrado en versiones anteriores de XAMPP y que la aplicación web
phpMyAdmin utilizaba. En las nuevas versiones del paquete XAMPP viene
incluido el gestor MariaDB y no se han visto problemas en cuanto al respaldo,
exportación e importación de los datos entre ambos gestores.
2.2.5 JavaScript, AJAX y JQuery.
En los años 90s, la conexión a internet se realizaba mediante módems a 28
kbps lo que conllevaba a velocidades muy lentas y junto al rápido desarrollo de
las aplicaciones webs, hacía falta un lenguaje que facilitara el nexo entre el
14
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
servidor y el navegador para disimular la tardanza entre la entrada de datos y la
salida. Brendan Eich, programador de Netscape desarrollo JavaScript,
adoptando la sintaxis de C y Java, con este propósito y que luego derivo en el
estándar ECMAScript. Microsoft, a su vez, saco una copia de este lenguaje
llamado JScript y que funcionaba en el navegador Internet Explorer.
Hoy en día, JavaScript se considera una implementación del lenguaje
ECMAScript, aunque hablar de uno equivale a hablar del otro en el ámbito
cotidiano.
ECMAScript va actualmente en la versión 7 de su desarrollo, aunque no es
mayormente soportada por los navegadores y los programadores utilizan la
versión 5 para tener mayor compatibilidad con los navegadores más
actualizados.
JavaScript es un lenguaje interpretado, ejecutado del lado del cliente
(navegador), orientado a objetos (casi todo es un objeto), sensible a mayúsculas
u minúsculas y de tipado dinámico.
Este lenguaje es utilizado principalmente para escribir funciones incluidas en
páginas HTML y que interactúan con el DOM de esta. Algunas utilidades
serian, entre otras:
Cargar contenido en la página o enviar datos al servidor a través de
AJAX
Animar elementos de la página.
Validar formularios
Transmitir información de los hábitos del usuario y las actividades de
navegación.
AJAX es definido como un conjunto de tecnologías que se unen para dar
forma al desarrollo web asíncrono, es decir, el intercambio de información entre
15
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
el servidor y el usuario se realiza en segundo plano lo que ayuda a la
interacción con el usuario y la visualización de la página.
Aparece por primera vez el 2005 y une tecnologías como:
XHTML y CSS, para crear una presentación basada en estándares.
DOM, para la interacción y manipulación dinámica de la presentación.
XML, XSLT y JSON, para el intercambio y la manipulación de
información.
XMLHttpRequest, para el intercambio asíncrono de información.
JavaScript, para unir todas las demás tecnologías.
Esta tecnología es bastante útil en desarrollos web con PHP u otros lenguajes
de programación que se manejen de lado del servidor.
JQuery es una librería o biblioteca basada en JavaScript cuyo fin es hacer de
la programación en script (entiéndase JavaScript) más simple, fácil y rápida del
lado del cliente.
JQuery aparece en enero del 2006, su creador fue John Resign, al mes
siguiente tuvo soporte para AJAX y posee licencia MIT de código abierto.
Además, cuenta con una gran comunidad de soporte.
En el desarrollo del framework se promueve el uso tanto de JavaScript como
de AJAX y JQuery. Su uso es opcional y está claramente ligado a las
necesidades y experiencia del programador y requerimientos del proyecto.
2.2.6 HTML5, CSS3 y Bootstrap.
HTML5 es el nombre que recibe la última versión del lenguaje HTML y
cuyo estándar es mantenido por la W3C. El origen de HTML se remonta a 1991
siendo la versión 2.0 la primera estandarizada en 1995. La versión 3.0 llega en
1996 bajo el estándar de la W3C y junto a la versión 4.0 en 1998 aparecen las
16
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
hojas de estilos CSS. La versión actual es presentada en el 2008 pero es
publicada oficialmente el 2014.
HTML es un lenguaje de marcado, no de programación, que nos permite
crear páginas webs mediante etiquetas o elementos. Los navegadores webs
interpretan el contenido de la página web (lenguaje HTML) y lo presenta de
forma visual.
La versión actual del lenguaje provee características únicas como son el
almacenamiento offline y la tecnología de Storage, el acceso a diferentes
dispositivos, la amplia conectividad y capacidad multimedia, características 3D
y gráficas, el nivel de rendimiento y por supuesto la incorporación de CSS3.
Las hojas de estilo, CSS, se crearon ante la necesidad de definir un
mecanismo que permitiera de forma consistente aplicar diferentes estilos a los
documentos electrónicos. Si bien no es un lenguaje de programación, se define
muy bien como un lenguaje de diseño. En 1970 aparecieron las primeras hojas
de estilo. Fue en 1995 cuando la W3C definió el primer estándar conocido
como CSS nivel 1, la segunda revisión fue en 1998 y se estandarizo como CSS
nivel 2. Hubo una revisión más, en el 2004, conocida como CSS2.1.
La versión actual y aun en desarrollo, en realidad no está completamente
estandarizada pues está en continua revisión, es la CSS3, que fue publicada en
el 2011. Esta revisión ya soportada por la mayoría de los navegadores fue
separada en módulos lo que influyo e influye en que los navegadores soporten o
no algunas etiquetas. Se espera para el año 2019 la versión 4.0 de este estándar.
En agosto del 2011, Mark Otto y Jacob Thorton, que en ese tiempo
trabajaban como ingenieros de twitter, lanzan Bootstrap como una solución a la
gran cantidad de librerías que se manejaban dentro del equipo de ingenieros de
la plataforma causando inconsistencias y una gran carga en el mantenimiento de
los proyectos. Fue lanzado como proyecto Open Source y desde ese momento y
17
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
gracias al aporte de cientos de desarrolladores se ha constituido en uno de los
frameworks de presentación web más populares para proyectos responsives y
dispositivos mobiles.
Bootstrap es una colección de elementos y funciones personalizables
empaquetadas en una sola herramienta. Este paquete o framework es el
resultado de combinar HTML, CSS y JavaScript y es perfectamente adaptable a
cualquier desarrollo web. Para trabajar con Bootstrap solo es necesario enlazar
la hoja de estilos en el header del HTML Para poder utilizar los elementos de
JavaScript que trae Bootstrap, es necesario incluir la librería JQuery a la página
web (documento HTML).
A día de hoy, encontramos la versión 3.3.7 como las más estable y se espera
muy pronto la versión 4.0.
En nuestra tesis hemos adoptado Bootstrap como solución al diseño para
proyectos lo que no implica que siempre sea así. El uso de cualquier otra
librería. Como JQuery UI, para diseño u hoja de estilo personal está habilitado
como se verá más adelante.
18
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.3 Programación Orientada a Objetos. POO.
2.3.1 Introducción.
La POO es un paradigma de programación (algunos lo llaman filosofía, otros
lo denominan modelo) que utiliza objetos que interactúan entre si dentro de un
sistema que proporciona una solución para un problema particular.
Antes de esta filosofía, la programación estructurada trataba un problema de
lo general a lo particular, dividiendo el sistema solución en subsistemas o
sistemas más pequeños, estos últimos más fáciles de entender y de codificar. Se
podría agregar que la estructura básica de este tipo de programación son las
funciones o métodos, las cuales asignan valores a nuestros datos.
Si queríamos saber la información de una persona, como sus nombres y
fecha de nacimiento, se solía hacer de la siguiente manera.
1. $nombre = 'John';2. $apellido = 'Doe';3. $fechaNacimiento = '1980-12-01';4. 5. function nombreCompleto($nombre, $apellido)6. {7. return "{$nombre} {$apellido}";8. }9. function edad($fechaNacimiento) 10. {11. // Calcular edad...12. return $edad;13. }
Tenemos varios problemas con este tipo de programación. A saber:
No hay forma de agrupar la información y las acciones.
No se puede prevenir el cambio de valor de alguna variable sin que
cambie la información de la persona.
19
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Si quisiéramos tener los datos de otra persona tendríamos que crear tres
variables nuevas. $firstName2, $lastName2, $dateOfBirth2
Se podría pensar en asignar los datos de las personas a un arreglo.
1. <?php2.3. $persona = array(4. 'nombre' => 'John',5. 'apellido' => 'Doe',6. 'fechaNacimiento' => '1980-12-01',7. );8. ?>
Pero tampoco evitamos que se pueda cambiar, por ejemplo, la fecha de
nacimiento sin cambiar los datos de la persona.
En la POO la estructura más básica es el objeto, que posee propiedades y
comportamientos propios y que depende de una clase o entidad superior, que
los agrupa según propiedades y comportamientos comunes. Así POO trabaja de
lo particular a lo general, agrupando objetos en común en entidades
denominadas clases.
En nuestro ejemplo. Un objeto (una persona, en singular) pertenece a una
clase que llamaremos Personas (en plural pues agrupa varios objetos) con
características y funciones en común.
1. <?php2.3. class Personas4. {5. public $nombre = 'John';6. public $apellido = 'Doe';7. private $fechaNacimiento = '1980-12-01';8.
20
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
9. public function __construct($nombre, $apellido, $fechaNacimiento)
10. {11. $this->nombre = $nombre;12. $this->apellido = $apellido;13. $this->fechaNacimiento = $fechaNacimiento;14. }15. 16. public function nombreCompleto()17. {18. return "{$this->nombre} {$this->apellido}";19. }20. 21. public function edad()22. {23. # Calcular $edad con 24. # $this->fechaNacimiento25. # ...26. return $edad;27. }28. }29. ?>
Como se puede observar, la clase Personas agrupa las propiedades necesarias
para que cada objeto persona sea independiente. Así para tener más objetos
personas ahora solo nos basta con crear nuevos objetos de la clase.
1. <?php2. $persona1 = new Personas("Juan", "Perez", "1970-01-01");3. $persona2 = new Personas("Maria", "Rozas", "1990-05-06");4. $persona3 = new Personas("Luis", "Riquelme", "1985-11-
15");5. // ...6. ?>
Y si queremos obtener la edad de estas personas, solo tenemos que llamar al
método de clase que sea necesario.
21
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
1. <?php2. $persona1->edad(); # Devuelve la edad de $persona13. $persona2->edad(); # Devuelve la edad de $persona24. $persona3->edad(); # Devuelve la edad de $persona35. // ...6. ?>
En este punto tenemos que decir que las variables
$persona1, $persona2, $persona3 son denominadas instancias de clase y
pertenecen a una única clase, la clase Personas.
Si quisiéramos cambiar el nombre de una persona, tendríamos que crear un
método de clase, en el ejemplo el método ya está creado, que nos permita el
cambio y luego asignar ese método al objeto (o instancia) al cual queremos
cambiarle el nombre.
1. <?php2. 3. class Personas4. {5. # [El resto del codigo iria aqui]6. 7. public function setNombre($nuevoNombre)8. {9. $this->nombre = $nuevoNombre;10. }11. }12. 13. # Asignamos 'Manuel' como nombre al objeto $persona114. $persona1->setNombre('Manuel');15. 16. # Obtenemos el nombre completo 17. # del objeto ya cambiado18. $persona1->nombreCompleto();19. ?>
22
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Como se puede notar, el cambio solo afecta al objeto referenciado y no a los
demás objetos. Esto nos permite tener un mayor control sobre los datos que
manejamos.
2.3.2 Elementos de la POO.
Los principales elementos de la POO serian: clases, objetos, métodos,
propiedades y mensajes y eventos.
Clase: Es un modelo que se utiliza para crear objetos que comparten
propiedades y comportamientos en común,
1. <?php2. class Personas3. {4. // propiedades5. // métodos6. }7. ?>
Objeto: Es una entidad provista de métodos o mensajes a los cuales
responde (comportamiento); atributos con valores concretos (estado); y
propiedades (identidad).
1. <?php2. $persona = new Personas();3. /*4. El objeto, ahora, es $persona,5. que se ha creado siguiendo el modelo de la clase Personas6. */7. ?>
23
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Método: Es una función asociada a un objeto que indica la capacidad de que
este puede hacer.
1. <?php2. function caminar() {3. # Algoritmo que hace caminar a una persona4. }5. ?>
Propiedades: Son variables que contienen datos asociados a un objeto y que
determinan su identidad
1. <?php2. public $nombre = 'John';3. public $apellido = 'Doe';4. private $fechaNacimiento = '1980-12-01';5. ?>
Evento y Mensaje: Mientras el evento es un suceso del sistema, el mensaje
es la comunicación del suceso dirigido a un objeto.
Imagen 2.1. Eventos y Mensajes de los objetos
24
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.3.3 Características conceptuales de la POO.
La POO posee ciertas características que la identifican y diferencian de otros
paradigmas. Estas características son: Abstracción, Encapsulamiento,
Modularidad, Ocultación, Polimorfismo, Herencia y Recolector de basura.
Abstracción: Aislación de un elemento de su contexto. Define las
características esenciales de un objeto y su comportamiento. La abstracción
permite ocultar el cómo se implementa el comportamiento de un objeto en
relación con otros en el mismo sistema. Se hace más énfasis en el ¿Qué hace?
Que en ¿Cómo se hace?
Imagen 2.2. Abstracción
En la figura observamos 3 clases diferentes, Figura, Cuadrado y Circulo,
todas implementan un método para calcular el área. La Abstracción impide
conocer la lógica del método.
25
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Encapsulamiento: Reúne al mismo nivel de abstracción, a todos los
elementos que puedan considerarse pertenecientes a una misma entidad.
Básicamente protege las propiedades y métodos de los objetos ante posibles
cambios desde fuera de la clase a la que pertenecen. Se suele confundir con la
Ocultación, debido a que ambas características van de la mano.
Un ejemplo claro suele ser lo que sucede con las librerías externas que se
implementan en un sistema. Una vez instanciado un objeto, este tiene acceso
solo a los métodos que la librería permite y no deja interactuar al programador
con el funcionamiento interno de esta.
Modularidad: Característica que permite dividir una aplicación en varias
partes más pequeñas (denominadas módulos), independientes unas de otras.
Esta característica es la que hace de la POO y en general de cualquier sistema
construido bajo esta filosofía, en términos de calidad de software, un sistema
escalable y mantenible.
Se recomienda, debido a esta característica programar usando la premisa
“Programe pensando en quien mantendrá el código”.
Ocultación: Los objetos están aislados del exterior, protegiendo a sus
propiedades para no ser modificadas por aquellos que no tengan derecho a
acceder a las mismas. A las propiedades del objeto solo se pueden acceder
desde métodos internos y si es necesario la modificación de alguna propiedad,
esta sea a través de un mensaje generado por un evento del usuario. Esta
característica también es conocida como “principio de visibilidad”
PHP define tres niveles de visibilidad para las propiedades y los métodos de
una clase, public (accesible desde cualquier parte del sistema), private
26
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
(accesible solo desde la clase que lo contiene) y protected (accesibles desde la
propia clase y desde la clase que la herede)
1. <?php2. /**3. * Definición de ClaseUno4. */5. class ClaseUno6. {7. public $public = 'Public';8. protected $protected = 'Protected';9. private $private = 'Private';10. 11. function holaMundo()12. {13. echo $this->public;14. echo $this->protected;15. echo $this->private;16. }17. }18. 19. $obj = new MyClass();20. echo $obj->public; // Funciona bien21. echo $obj->protected; // Error Fatal22. echo $obj->private; // Error Fatal23.24. // Muestra Public, Protected y Private25. $obj->holaMundo(); 26. 27. /**28. * Definición de ClaseDos29. */30. class ClaseDos extends ClaseUno31. {32. // Se pueden redeclarar las propiedades públicas 33. // y protegida, pero no la privada34. public $public = 'Public2';35. protected $protected = 'Protected2';36. 37. function holaMundo()38. {39. echo $this->public;40. echo $this->protected;41. echo $this->private;42. }43. }
27
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
44. 45. $obj2 = new MyClass2();46. echo $obj2->public; // Funciona bien47. echo $obj2->protected; // Error Fatal48. echo $obj2->private; // Undefined49.50. // Muestra Public2, Protected2, Undefined51. $obj2->HolaMundo(); 52. ?>
Polimorfismo: Es la capacidad que da a diferentes objetos, la posibilidad de
contar con métodos, propiedades y atributos de igual nombre, sin que los de un
objeto interfieran con el de otro. Si revisamos el ejemplo mencionado en la
Abstracción y le asignamos algo de código tenemos lo siguiente:
1. <?php2. abstract class Figura {3. abstract public function area();4. }5.6. class Cuadrado extends Figura {7. private $lado;8. 9. public function __construct($lado) {10. $this->lado = $lado;11. }12. public function area() {13. $area = pow($this->lado, 2);14. echo "El area del Cuadrado es {$area}<br>";15. }16. }17.18. class Circulo extends Figura {19. private $radio;20. 21. public function __construct($radio) {22. $this->radio = $radio;23. }24. public function area() {25. $area = pow($this->radio, 2) * 3.14;26. echo "El area de un Circulo es {$area}<br>";27. }
28
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
28. }29. 30. $cuadrado = new Cuadrado(3);31. # Imprime. El area del Cuadrado es 932.33. $cuadrado->area(); 34. 35. $circulo = new Circulo(3);36.37. # Imprime. El area de un Circulo es 28.2638. $circulo->area();39. ?>
Podemos ver como objetos diferentes acceden al método propio area() sin
interferir el uno con el otro. Además cada clase hereda de Figura, clase
abstracta padre, quien obliga a sus hijas a implementar el método area().
Herencia: Esta característica hace de la POO la diferencia con otros
paradigmas de programación. Es un mecanismo mediante el cual objetos
específicos incorporan la estructura y comportamientos de objetos más
generales.
Una clase hija heredara las propiedades y métodos de una clase padre
dependiendo el nivel de visibilidad de estas en la clase padre. Así las clases
hijas solo heredaran las propiedades y métodos que sean protegidos en la clase
padre y claramente por defecto tienen acceso a aquellas que tienen u visibilidad
pública.
1. <?php2. class Figura {3. private $alto;4. private $ancho;5. protected function areaFigura($figura) {6. echo "Sacando el area de un {$figura}<br>";7. }
29
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
8. }9. class Cuadrado extends Figura {10. private $lado;11. 12. public function __construct($lado) {13. $this->lado = $lado;14. }15. 16. public function area() {17. $this->areaFigura("Cuadrado");18. }19. }20. class Circulo extends Figura {21. private $radio;22. 23. public function __construct($radio) {24. $this->radio = $radio;25. }26. 27. public function area() {28. $this->areaFigura("Circulo");29. }30. }31. 32. $cuadrado = new Cuadrado(3);33. $cuadrado->area();34. # Imprime. Sacando el area de un Cuadrado35. 36. $circulo = new Circulo(3);37. $circulo->area();38. # Imprime. Sacando el area de un Circulo39. ?>
En el código anterior notamos que la clase Figura (clase padre) tiene un
método protegido areaFigura() y las clases hijas (clase Circulo y clase
Cuadrado) pueden heredar este método pero solo desde dentro de sus clases
respectivas. Un objeto de las clases hijas no pueden llamar al método
areaFigura() por el principio de encapsulación, sin embargo estas implementan
un método propio area() que hace un llamado implícito al método
areaFigura().
30
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
En PHP no existe la herencia múltiple, sin embargo, para saltarse esta
prohibición este lenguaje permite crear interfaces (clases especiales que
implementan solo la definición de métodos). Una clase en PHP puede
implementar múltiples interfaces.
En el código siguiente se crea una interface que implementa un método para
que las clases puedan calcular el perímetro de la figura que representan.
1. <?php2. class Figura {3. private $alto;4. private $ancho;5. protected function areaFigura($figura) {6. echo "Sacando el area de un {$figura}<br>";7. }8. }9. 10. interface Perimetro {11. public function getPerimetro();12. }13. 14. class Cuadrado extends Figura implements Perimetro {15. private $lado;16. public function __construct($lado) {17. $this->lado = $lado;18. }19. public function area() {20. $this->areaFigura("Cuadrado");21. $area = pow($this->lado, 2);22. echo "Area Cuadrado: {$area}<br>";23. }24. public function getPerimetro() {25. $perimetro = 4*$this->lado;26. echo "Y su perimetro es: {$perimetro}<br>";27. }28. }29. 30. class Circulo extends Figura implements Perimetro {31. private $radio;32. public function __construct($radio) {33. $this->radio = $radio;34. }35. public function area() {36. $this->areaFigura("Circulo");37. $area = pow($this->radio, 2)*3.14;
31
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
38. echo "Area Circulo: {$area}<br>";39. }40. public function getPerimetro() {41. $perimetro = 2*3.14*$this->radio;42. echo "Y su perimetro es: {$perimetro}<br>";43. }44. }45. 46. $cuadrado = new Cuadrado(3);47. $cuadrado->area();48. $cuadrado->getPerimetro();49. 50. $circulo = new Circulo(3);51. $circulo->area();52. $circulo->getPerimetro();53. ?>
Recolector de basura: El GC es una función de la POO que se encarga de
liberar la memoria que utilizan los objetos o variables dentro del lenguaje.
Cuando un objeto o variable es creada y se le asigna un valor, se crea un
puntero a la memoria que contiene esa información y cuando este puntero ya no
existe, no es referenciado, el GC se preocupa de liberar ese espacio en la
memoria.
En PHP no se crean punteros, sino una referencia a dicho objeto en una tabla
de símbolos.
1. <?php2. class Foo {3. public $var;4. function __construct() {5. $this->var = 1;6. }7. function inc() { return ++$this->var; }8. }9. 10. // $a "referencia" a un objeto Foo11. $a = new Foo();12. //b también referencia al mismo objeto Foo que a13. $b = $a; 14. // ($a) == ($b) == <id> del objeto Foo,
32
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
15. // pero a y b son entradas distintas 16. // en la tabla de símbolos17. 18. echo "\$a = ";var_dump($a);19. echo "\$b = ";var_dump($b);20. 21. $c = &$a; //$c es un alias de $a22. // ($a, $c) == <id> del objeto Foo, 23. // c es un alias de a en la tabla de símbolos24. echo "\$c = ";var_dump($c);25. 26. $a = NULL;27. /**28. * Se elimina la entrada en la tabla de símbolos29. * donde se relacionaba a "$a" con el objeto Foo30. * Al eliminarse esta entrada, 31. * $c también deja de estar relacionado con Foo32. * A todos los efectos, Foo sigue existiendo33. * en memoria, y sigue estando relacionado con $b34. **/35. echo "\$a = ";var_dump($a);36. echo "\$b = ";var_dump($b);37. echo "\$c = ";var_dump($c);38. echo "\$b->var: ".$b->inc();39. echo "\$b->var: ".$b->inc();40. 41. $b = NULL;42. /*43. * Se elimina la entrada en la tabla de símbolos44. * donde se relacionaba a "$b" con el objeto Foo45. * Ya no hay más entradas en la tabla de símbolos46. * que se relacionen con Foo,47. * Por lo que Foo ha dejado de estar referenciado48. * y puede ser eliminado por el garbage collector49. **/50. echo "\$b = ";var_dump($b);51. ?>
En PHP un objeto o variable podrá ser eliminada de la memoria cuando el
GC no tenga ninguna referencia a dicho objeto en la tabla de símbolos. Es decir,
PHP mantiene un contador de referencias a un objeto desde el momento en que
éste es creado, de forma que durante la ejecución del script PHP va
incrementando y decrementando dicho contador de referencias en función de
33
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
las variables que le van “apuntando”. Una vez ese contador de referencias llega
a 0 (es decir, nadie está relacionado con ese objeto y, por lo tanto, no se está
utilizando dicho objeto), PHP marca ese objeto como basura o eliminable, de
forma que en la siguiente pasada del GC, éste eliminará dicho objeto de
memoria y esa posición de memoria será utilizable por PHP nuevamente.
Esta función en PHP viene activada por defecto, pero también es posible
ejecutarla o desactivarla en tiempo de ejecución.
1. <?php2. gc_enabled(); # Activa el GC y devuelve true3. dc_disabled(); # Desactiva el GC y devuelve NULL4. ?>
34
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.4 Patrones de Diseño.
Desde la aparición de la Reusabilidad (o quizás antes) la programación se ha
ido desarrollando bajo este concepto, en donde librerías o bibliotecas
(independientes del lenguaje que se han escrito) ya probadas y documentadas se
pueden usar en cualquier proyecto. Sin ir más lejos, PHP y JAVA están
compuestos principalmente por librerías (de acceso a datos, de matemáticas,
para manejar arreglos, etc.) desde las que podemos llamar a sus clases y
funciones sin más que importar esa librería con una simple línea de código.
Lo anterior estaba bien, pero la Reusabilidad no solucionaba de igual manera
problemas comunes dentro de aplicaciones similares (El menú de una
aplicación no tiene que ver con el menú de otra aplicación). Pues aparecen los
patrones de diseño como soluciones a problemas recurrentes en el desarrollo de
un software. Estos patrones de diseño, denominados así por The Gang of Four,
facilitan la reutilización de diseños y arquitecturas que han tenido éxito en otras
aplicaciones.
Patrones de Diseño hay muchos y siguen apareciendo continuamente. El
desarrollo de aplicaciones, como disciplina, está en constante cambio y así
también los problemas de diseño. Así que las herramientas que usamos para
nuestros desarrollos también se van actualizando y mejorando en favor de estos
cambios. ¿Cuantos hay? Repito, muchos. es más simple clasificarlos en tres
tipos, patrones de creación, patrones de comportamiento y patrones de
estructura.
Patrones de Creación: Hace referencia a la creación de objetos
dinámicamente y algunos de estos patrones son, Singleton, Factory, Factory
Method, Abstract Factory, Builder y otros.
35
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Patrones de Comportamiento: Se preocupa de resolver problemas sobre la
estructura de clases. Tenemos a Interpreter, Iterator, Mediator, Memento,
Observer, Strategy y otros.
Patrones de Estructura: Relaciona el comportamiento entre los objetos de
la aplicación. Acá encontramos a Adapter, Bridge, Composite, Decorator,
Flyweight, Proxy.
Hay mucha información en la web y en libros sobre el tema lo que hace que
no exista una definición como tal para cada tipo y que esta sea subjetiva.
Sin embargo, debemos tener presente los siguientes elementos para entender
un patrón y sobre todo para la elección de uno: su nombre, el problema (cuando
aplicar un patrón), la solución (descripción abstracta del problema) y las
consecuencias (costos y beneficios).
The Gang Of Four decidió todo lo anterior, que cada patrón debía tener un
buen nombre, debe tener sinónimos, asociar un problema (la intención, la
motivación y la aplicabilidad) y la solución que viene dada por una estructura
(Un diagrama de clases), sus participantes (explican el rol que juegan las clases
del diagrama anterior), las colaboraciones (diagramas de secuencia que explican
las relaciones entre los objetos), la implementación (o comentarios de
variaciones según ciertos detalles), un código (que demuestra cómo se
implementa sobre un ejemplo concreto), los usos reconocidos y en donde se
implementa junto a los patrones relacionados a este.
En relación a las consecuencias, el uso de un patrón viene dada por su
eficiencia, flexibilidad, uso de memoria, tiempo de ejecución y seguridad.
36
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
En el framework se implementa el Patrón Singleton que pertenece a los
patrones de creación. Este patrón restringe la creación de objetos de clase a uno
solo. Garantiza que hay solo una instancia y proporciona un único punto de
acceso global.
37
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.5 Principios SOLID
SOLID es un acrónimo de cinco principios del diseño orientado a objetos y
que combinados ayudan al desarrollador crear proyectos fáciles de mantener y
expandir, generando un código robusto y dando como resultado un software de
calidad. Estos principios son aplicables independientes del lenguaje de
programación orientado a objetos que se esté utilizando.
Estos principios fueron definidos por Robert C. Martin por el año 2000 pero
fue más tarde cuando Michael Feathers juntando las iniciales de estos principios
como SOLID que tomaron mayor relevancia.
Para entender estos principios es necesario manejar dos conceptos
fundamentales en cualquier desarrollo de software.
Acoplamiento: Podemos definirlo como el grado en que una clase, método o
cualquier otra entidad de software, está directamente vinculado a otro. Este
grado de acoplamiento también puede ser visto como un grado de dependencia.
Cohesión: es la medida en que dos o más partes de un sistema trabajan
juntas para obtener mejores resultados que cada parte por separado.
Para obtener un buen software siempre debemos tratar de tener un
acoplamiento bajo y una alta cohesión, y los principios SOLID nos ayudan con
esta tarea. Si seguimos estas pautas, nuestro código será más robusto,
mantenible, reutilizable y extensible y evitaremos la tendencia de nuestro
código a romperse en muchos lugares cada vez que se cambia algo.
Como buenos principios, estos no tienen un orden especifico ni una
importancia mayor uno del otro. Se necesita de bastante practica para aplicarlos
38
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
pues es necesario reconocer las fallas en el código para luego refactorizar el
código.
2.7.1 Single Responsibility Principle.
El Principio de Responsabilidad Única nos dice que una clase sólo debe
tener un motivo para cambiar, lo que significa que sólo debe tener una tarea o
responsabilidad.
¿Cuándo se está rompiendo este principio?
Cuando en una clase encuentras métodos de capas diferentes.
Un excesivo número de métodos públicos.
Cuando la clase requiere en demasía de otras.
Las variables de clase tienen métodos propios.
Si agregas una funcionalidad a la clase, debes refactorizar.
Lo que realmente se busca es aislar los cambios, no las responsabilidades,
aunque normalmente las responsabilidades y las razones para hacer cambios
van estrechamente ligados.
2.7.2 Open Closed Principle.
El Principio de Abierto/Cerrado habla sobre que los objetos o entidades
deberían estar abiertas a su extensión, pero cerradas para su modificación.
La forma más sencilla de entender este principio es cuando modificamos
constantemente una clase añadiéndole nuevas funcionalidades, estas implican
modificar las que ya están escritas. Este hecho te da motivo para revisar el
código y entender que necesitas de otra clase para que la original no sufra
mayores cambios.
39
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
La solución a este principio se basa en el Polimorfismo. En vez de obligar a
la clase principal a saber cómo realizar una operación, delega esta a los objetos
que utiliza, de tal forma que no necesita saber explícitamente cómo llevarla a
cabo. Estos objetos tendrán una interfaz común que implementarán de forma
específica según sus requerimientos.
2.7.3 Liskov Substitution Principle.
El Principio de Sustitución de Liskov dice que, si S es una subclase de T,
entonces los objetos de T podrían ser substituidos por objetos del tipo S sin
alterar las propiedades del problema. Esto es, cada clase que hereda de otra
puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
El principio de Liskov nos ayuda a utilizar la herencia de forma correcta, y a
tener mucho más cuidado a la hora de extender clases.
Este principio se rompe cuando creas una clase que extiende de otra, y ves
que hay métodos que bien te sobran o están demás. Entonces no te queda otra
solución que dejarlo vacío o que te avise de un error al intentar ejecutarlo. Si un
método sobrescrito no hace nada o lanza una excepción, es muy probable que
estés violando el principio de sustitución de Liskov.
2.7.4 Interface Segregation Principle
El Principio de Segregación de Interfaces define que una clase nunca debe
ser forzada a implementar una interface que no usa, empleando métodos que no
tiene por qué usar.
40
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Las interfaces nos ayudan a desacoplar clases entre si. Una Interfaz define el
comportamiento que una clase necesita para una funcionalidad, pero es la clase
quien implementa el cómo se hará.
Cuando las interfaces definen métodos que una clase no usa, estas violando
este principio, entonces deberías construir varias interfaces e implementar
métodos más específicos.
2.7.5 Dependency Inversion Principle.
El Principio de Inversión de Dependencias se refiere a que las entidades
deben depender de abstracciones no de concreciones. Una clase de alto nivel no
debe depender de las clases de bajo nivel, pero deben depender de
abstracciones. Así mismo, las abstracciones no deben depender de detalles, sino
que los detalles deben depender de las abstracciones.
Cuando una clase instancia otras clases dentro de su ámbito, se está violando
este principio. La clase principal depende de las clases que instancia y sería
mejor abstraer esas clases fuera del ámbito actual y generar instancias para ser
pasadas, por ejemplo, en el constructor o por setters a la clase principal. Así
ningún cambio en esos objetos influye en la clase principal.
41
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.6 MVC.
En la extensa literatura sobre el tema, podemos decir que no hay un acuerdo
sobre que patrón de diseño cumple MVC. Algunos dicen, que no es un patrón
de diseño, sino un patrón arquitectónico, otros lo dan como patrón de creación,
y algunos más le meten dentro lo un estilo arquitectónico (estos organizan la
jerarquía general de todo el software de un proyecto).
Lo que si podemos asegurar es que MVC cumple con todos los elementos ya
señalados para denominarse un patrón con la salvedad de que abarca no un
problema concreto en una aplicación, sino más bien se enfoca en como
estructurar la solución al desarrollo (estilo arquitectónico).
MVC, son las siglas de Modelo-Vista-Controlador que es uno de los tantos
patrones de arquitectura de software y como buen patrón nos brinda de un
marco de desarrollo de aplicaciones a través de la construcción de tres
componentes distintos, el Modelo, la Vista y el Controlador
Este patrón separa la lógica de negocio (Modelo) de la interfaz de usuario
(Vista) y de la lógica de la aplicación (Controlador). Esta separación implica
una mejor funcionalidad, mantenibilidad, escalabilidad y reusabilidad
(Conceptos de Calidad del Software) de un sistema, de forma simple, sencilla,
en código legible, entendible, y flexible a todo programador que esté en
condiciones de desarrollar el sistema.
Su fundamento es la separación del código en tres capas diferentes, acotadas
por su responsabilidad. Modelos, Vistas y Controladores.
Modelos: Representan la lógica del negocio. Es quien hace de intermediario
con la Base de Datos, accediendo a los datos de esta. También posee reglas de
negocio, que hace referencia al manejo de datos.
42
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Vistas: Representa la Interfaz de Usuario. Es quien se encarga de presentar
los datos al usuario mediante una interfaz gráfica. Gestiona la información de
entrada (como pedirla) y la de salida (como mostrarla).
Controladores: Representa la lógica de la aplicación. Es quien hace de
intermediario entre el modelo y la vista, a través de eventos generados por el
usuario para así acceder a los datos necesarios y presentarlos en la vista.
El funcionamiento básico del patrón MVC, puede resumirse en:
El usuario realiza una petición
El controlador captura el evento (puede hacerlo mediante un
manejador de eventos o peticiones, por ejemplo)
Hace la llamada al modelo/modelos correspondientes (por
ejemplo, mediante una llamada de retorno o callback)
efectuando las modificaciones pertinentes sobre el modelo
El modelo será el encargado de interactuar con la base de datos,
ya sea en forma directa, con una capa de abstracción para ello,
un Web Service, etc. Y retornará esta información al controlador
El controlador recibe la información, la procesa y la envía a la
vista
La vista, recibe esta información y genera el diseño de la interfaz
gráfica o GUI. La lógica de la vista, una vez procesados los
datos, los acomodará en base al diseño de la GUI p plantilla, y
los entregará al usuario de forma humanamente legible.
43
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
2.7 Calidad del Software.
Si bien el concepto de software no es nuevo, la industria del software como
tal si es algo relativamente nuevo y podríamos decir que vino acompañada con
el desarrollo de los lenguajes de programación, de lo cual ya hemos hablado, y
de los avances tecnológicos. Toda esta industria está produciendo software que
cumpla con parámetros como la alta calidad, con un menor costo y que se
desarrolle en el menor tiempo posible. Motivando la competitividad frente a
clientes cada vez más exigentes.
No se puede hablar de calidad de software sin dejar de mencionar errores
comunes en el desarrollo de software.
Mala definición de requisitos.
Mala comunicación con el cliente.
Mala organización presupuesto / tiempo.
Errores lógicos de diseño.
Errores de codificación.
Incumplimiento de estándares de codificación y documentación.
Pruebas incompletas
Errores de procedimiento.
Errores de documentación.
¿Qué nos obliga a desarrollar software pensando en la calidad?
Condiciones contractuales
Relación cliente / proveedor.
Trabajo en equipo.
44
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Cooperación y coordinación.
Interfaces con otros sistemas de software.
Cambios de componentes del equipo.
Mantenimiento del producto.
La calidad del software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia. Si bien la idea no es definir conceptos,
pues ya fueron tratados en su mayoría en asignaturas de la carrera, es necesario
hacer un breve resumen que se aplique al tema de tesis.
Siguiendo esta lógica cada desarrollo de software contara con parámetros
distintos a evaluar en busca de la Calidad de Software. Entre los más
importantes y reiterativos podemos enunciar los siguientes:
Funcionalidad: Hace referencia a la precisión y seguridad de que el
software hace lo que debe hacer.
Portabilidad: Relaciona temas como la instalación y la adaptación del
software en diferentes sistemas y entornos.
Fiabilidad: habla de la madurez del software en relación a la tolerancia a
fallos y su capacidad de recuperación frente a estos.
Mantenibilidad: Capacidad del software para ser estable y mantenible en el
tiempo.
Eficiencia: Es la relación entre el comportamiento del software en el tiempo
contra el uso de los recursos.
45
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Usabilidad: Hace referencia a la facilidad de aprendizaje del software y de
uso del cliente o usuario final.
Toda aplicación Web resultante de un desarrollo de software se puede
separar en dos componentes principales, el Front-End y el Back-End.
Podríamos definir al Back-End como todo lo que se ejecuta en el servidor,
invisible al usuario, tales como las conexiones a las bases de datos y las
consultas que realizamos a estas; así también se le denomina Back-End a toda
la interfaz de administración de una aplicación web. Este componente se sirve
principalmente de PHP para realizar sus tareas.
Sobre el Front-End podemos decir que es todo lo que la aplicación web le
muestra al usuario a través de un navegador. Este componente usa
principalmente lenguajes como HTML, CSS y JavaScript.
Por otro lado, el desarrollo de una aplicación web, o de cualquier software en
general, se lleva a cabo en dos procesos o tiempos, el primero es el tiempo de
desarrollo, durante el cual se programa todo el código y se realizan las pruebas
necesarias antes de la entrega final, y el segundo es el periodo en tiempo de
ejecución, durante el cual la aplicación está abierta al público o usuario final.
Algunas veces y según los requerimientos entre ambos periodos existe un
periodo de pruebas o ‘marcha blanca’ para solucionar algún problema no
contemplado.
Tanto en el Front-End como el Back-End, se deben asegurar ciertos atributos
de Calidad de Software y estos son dependientes de cada desarrollo y sus
requerimientos.
Algunos atributos de calidad inherentes al proceso de desarrollo del
software, referidos al Framework. pueden ser:
46
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Capacidad de ser configurable. Que el desarrollador pueda realizar
cambios sin afectar al Framework.
La capacidad de integrar módulos y dependencias al framework.
Asegurar la Integridad de la información que manejara el framework.
El framework debe garantizar la capacidad de mantenibilidad. Ser
mantenible en el tiempo.
Capacidad para ser ejecutado en distintos ambientes, tanto de
software como de hardware.
Tener la capacidad de ser reusable. Usar la misma estructura en
futuros proyectos.
Permitir la escalabilidad. Que el diseño permita la ampliación del
framework.
Y sin que sea un atributo menor, pues dependerá del tipo de
desarrollo, debe ser capaz de ser sometido a pruebas.
Durante el proceso de ejecución del software, algunos atributos de calidad
pueden ser:
Disponibilidad de uso. Hace referencia a la usabilidad de la
aplicación y su relación con el usuario final
Confidencialidad, puesto que se debe evitar el acceso no autorizado a
secciones del sistema si este lo requiere.
Funcionalidad. La aplicación debe cumplir con los requerimientos
establecidos.
Desempeño. La aplicación debe dar siempre una respuesta ante una
petición.
Confiabilidad. El sistema de estar operativo y ser permanente en el
tiempo.
47
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 2. Marco Teórico
Seguridad. Tanto interna, evitando la perdida de información debido
a errores del sistema, como externa, siendo capaz de impedir ataques,
usos no autorizados, etc.
48
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
CAPÍTULO 3
DISEÑO DEL FRAMEWORK
49
Capítulo 3. Diseño del Framework
3.1 Introducción.
Como es sabido, se utilizará el patrón arquitectónico MVC para el desarrollo
del framework que estará escrito en PHP, será compatible desde la versión 5.3.
Desde la versión 7.0, la más actual y estable (la 7.1 aun esta en desarrollo), la
compatibilidad no es completa y el framework genera errores debido a nuevos
cambios en el tipificado del código.
El desarrollo se implementará en un entorno local bajo Windows 10, usando
la distribución de XAMPP, software libre, en su versión 5.6.30. Esta versión
incluye, entre otras cosas Apache 2.4.25, MariaDB 10.1.21, PHP 5.6.30,
phpMyAdmin 4.6.5.2. Todos los componentes de XAMPP tienen su propia
licencia y esta compilación permite la actualización de cada componente por
separado si es necesario.
La instalación de XAMPP sobre Windows (Linux o MAC) o la actualización
de los componentes de la distribución no es materia de esta tesis. Tanto en su
página como en Internet encontramos variada información al respecto.
Como editor de código se usó Notepad++, un editor de código libre que
soporta múltiples lenguajes de programación. Posee una buena cantidad de
plugins y plantillas que facilitan la escritura de código. Solo está disponible
para sistemas Windows.
El desarrollo del framework en PHP que tiene motivo en esta tesis se
desarrollara bajo las condiciones antes mencionadas.
En este capítulo se revisará la estructura básica y se comparará con la
estructura actual del framework, así como también el desarrollo de los archivos
iniciales y los cambios que han llevado a la configuración actual. Se hablará
sobre el desarrollo de librerías y módulos para el framework y el cómo
implementar un gestor de dependencias para este.
50
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.2 Estructura Básica.
En la siguiente imagen se muestran las carpetas con la estructura inicial a la
izquierda y a la derecha la estructura actual del framework.
Imagen 3.1. Estructura Básica
La diferencia principal entre ambas estructuras radica en dos carpetas. La
carpeta vendor y la carpeta Widgets. Debemos hacer notar que no es necesario
que las carpetas tengan su nombre con la primera letra mayúscula, pero se
recomienda seguir con el estándar para los namespaces.
51
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
La primera es generada por el gestor de dependencias composer, quien se
encarga de instalar las librerías de terceros que se utilizan en el framework. En
su estructura actual, composer instala las librerías dompdf (que maneja la
creación de archivos PDFs) y phpmailer (quien se encarga de crear, formatear
y enviar correos). Este gestor también crea los archivos composer.json y
composer.lock
La carpeta Widgets es generada durante el desarrollo y contiene los archivos
para insertar widgets propios o de terceros en el front-end del proyecto.
En la siguiente tabla se relaciona cada componente de la estructura básica y
su función o contenido dentro del framework.
Tabla 3-1 Estructura Inicial framework PHP
Estructura Inicial framework PHP
Carpeta / Archivo Función / Contenido
ArchivosContiene archivos y carpetas públicas que no son
propias del framework.
ClasesContiene los archivos necesarios para un correcto
funcionamiento del framework.
Controladores Archivos relacionados con las clases controladoras
LibreríasArchivos o carpetas de librerías externas o
internas
Modelos Archivos con las clases modelos
Módulos Carpetas relacionadas con los módulos
Vistas Archivos y carpetas necesarias para la
52
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
visualización de las vistas.
.htaccess Archivo de configuración de servidor apache.
index.html Archivo HTML
index.php Archivo PHP
El primer archivo a crear es index.php y el servidor es quien sirve este
archivo ante cualquier petición. Contiene una función para autocargar de clases
y define algunas variables necesarias para el funcionamiento del framework.
El archivo index.html se crea ante la ausencia del archivo index.php.
El archivo .htaccess es el archivo de configuración de apache. Este contiene
las reglas necesarias para trabajar con URLs amigables. Además, impide el
acceso a directorios, ficheros y enlaces simbólicos.
53
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.3 Configuración Inicial.
En la carpeta clases encontramos el motor del framework. Esta carpeta
contiene las clases necesarias para que el framework funcione y otras clases que
se han ido agregando a medida que el framework se ha ido actualizando.
En la imagen siguiente vemos la diferencia entre el estado inicial del
framework y el actual.
Imagen 3.2. Configuración Inicial
54
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
En la siguiente tabla se describe cada archivo haciendo mención al nombre,
contenido, tipo de archivo.
Tabla 3-2 Configuración Inicial
Archivo Tipo Contenido
configuracion.php Archivo PHPContiene definiciones de
constantes
controlador.phpClase abstracta
PHP
Es el controlador padre del
framework y contiene funciones
globales
database.php Clase PHP
Es quien hace la conexión con la
Base de Datos. Es la clase padre
de Modelo
error.php Clase PHPEs la que maneja los errores del
motor del framework.
index.html Archivo HTMLEvita la navegación directa por la
URL
iniciar.php Clase PHPClase que se encarga de llamar al
controlado pedido en una petición
modelo.php Clase PHP Es Modelo padre del framework.
peticion.php Clase PHP
Es la clase que recibe las
peticiones y proporciona el
controlador a la clase Iniciar
registro,php Clase PHP Clase que implementa el Patrón
55
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
Singleton
vista.php Clase PHPClase que elabora las vistas del
framework
Archivos Actuales
acl.php Clase PHP
Es la encargada de manejar y
controlar los accesos a los
métodos y vistas de framework
cargador.php Archivo PHP
Contiene funciones para la carga
automática de clases. Se puede
eliminar si se instala composer
sesion.php Clase PHP
Encargada de controlar las
variables de sesión en el
framework
56
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.4 Controladores.
Un controlador está encargado de relacionar la lógica de negocio con la capa
encargada de gestionar la interacción con el usuario.
El Controlador principal está ubicado dentro de la carpeta Clases, este
archivo obtiene la petición realizada y genera un objeto de la vista. También se
encarga de crear objetos de los modelos y de las librerías del Framework.
Cuando se realiza una petición el core del Framework rescata esa petición y
se la envía al controlador apropiado. Ese controlador (controlador hijo)
hereda del controlador principal y ejecuta las acciones necesarias según la
petición generada por el usuario en la vista.
Los controladores hijos pueden estar ubicados en dos partes, en la carpeta
controladores o bien dentro de la carpeta controlador del módulo al que
pertenezca.
La teoría del patrón MVC puede entenderse como que a cada Controlador
existente se le debe asociar un Modelo o una Vista. La existencia de un
controlador hijo no implica necesariamente que tenga un modelo o una vista
asociada. Esta abstracción permite que ese controlador pueda usarse desde la
vista para manejar por ejemplo objetos JSON vía AJAX desde una vista
cualquiera.
57
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.5 Modelos.
Al igual que los controladores, el framework trabaja con un modelo padre y
modelos hijos. Los hijos heredan del padre una variable que permite la
conexión a la base de datos e implementan los métodos para interactuar con
esta.
En la carpeta Clases encontramos dos archivos. El primero, llamado
database es la clase que hace la conexión a la base de datos mediante la librería
PDO de PHP. El segundo archivo, modelo hereda del primero la conexión y es
quien reparte esta conexión a los modelos hijos.
La existencia de un modelo hijo implica una llamada desde un controlador
hijo, Es decir, si se realiza una petición desde la vista por el usuario que implica
una llamada a la base de datos, el controlador hijo debe pedir un acceso a esta.
Los modelos hijos se encuentran en las carpetas Modelos, ya sea en el
directorio raíz (cuando un modelo no pertenece a un módulo) o bien dentro de
su modulo correspondiente.
58
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.6 Vistas.
En la carpeta Clases se encuentra la clase Vista quien es la responsable de
analizar, procesar y visualizar una página web. Básicamente una página web es
una plantilla más una vista, en donde la platilla es la que controla la inclusión
de archivos CSS y JS para darle un aspecto visual u otro y la vista es la que va
cambiando según sea el controlador hijo que llame a la clase.
En el framework es el Controlador padre quien crea un objeto de la clase
Vista y es esta clase quien debe cargar la plantilla. El controlador hijo, quien es
el que recibe una petición, es el que pide una vista determinada a la clase Vista
a través de un método heredado desde el Controlador padre.
Las vistas son archivos phtml que son requeridos por los controladores hijos
y se encuentran en el directorio raíz (cuando un modelo no pertenece a un
módulo) o bien dentro de su modulo correspondiente.
59
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.7 Archivos de Configuración.
El framework trabaja con dos archivos de configuración. El primero está
presente en la carpeta Clases y define constantes globales para el framework. El
segundo archivo se encuentra en la carpeta Vistas/plantillas y contiene
funciones que devuelven variables necesarias para elaborar la plantilla de las
páginas web.
Podríamos decir que existe un tercer archivo de configuración,
composer.json y este se crea si se va a instalar el gestor de dependencias
composer.
60
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.8 Librerías y Módulos.
Una librería es un archivo o conjunto de varios archivos que permiten la
realización de una tarea específica. Estas librerías pueden ser clases o un
archivo con funciones. En el framework se pueden cargar librerías propias y de
terceros. Nos referimos a librerías propias a las realizadas para el framework, en
este tenemos varias librerías, para subir imágenes, generar reportes desde bases
de datos, y una con funciones varias, y se pueden usar para cualquier proyecto
que utilice el framework, Las librerías de terceros se pueden incluir sin
problemas y solo teniendo al cuidado en el cómo se cargan.
Un Módulo es un conjunto de clases y archivos implementados bajo la
estructura MVC y que permiten la realización de varias tareas que en conjunto
tienen un solo fin último.
Un Módulo debe ser capaz de ser incluido en el Framework de manera que
no altere la estructura ni el funcionamiento del sistema. Así mismo si ya no se
necesita, al ser eliminado de la estructura no cause errores en el sistema.
61
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.9 Dependencias.
Cuando hablamos de dependencias nos referimos a recursos programados,
desarrollados y ya probados por terceros, es decir, otros programadores. Estos
recursos suelen ser librerías o plugins que un proyecto necesita para realizar una
determinada tarea.
Antes de PHP en su versión 5.3 el uso de estas dependencias estaba limitado
principalmente por la colisión de nombres de clases entre las de un proyecto y
las clases de la librería externa. Por ejemplo, en una carpeta de Windows no
puedes tener dos archivos con el mismo nombre, la misma lógica se puede
utilizar para visualizar el contexto. Desde la versión 5.3 y la aparición de los
namespaces este problema se solucionó, pero si el proyecto era muy grande, el
número de librerías externas aumentaba y con ello, actualizar cada una de ellas
era engorroso.
Los programadores en PHP desarrollaron composer, un programa que
trabaja de forma local en tu equipo/servidor y que permite instalar, organizar y
mantener actualizadas todas las dependencias de un proyecto. Estos procesos se
realizan vía consola de comandos.
El uso de esta herramienta en una configuración inicial no es necesario más
si se requiere en un desarrollo más avanzado del framework, pero es algo tan
útil que no mencionarlo limitaría la potencia de este o cualquier framework,
sistema o proyecto web. Si se trabaja de forma local, composer se puede
instalar mediante su ejecutable o en la carpeta del proyecto por medio de un
archivo PHP que su misma web provee. Esta herramienta ya está instalada en
todo buen servidor.
62
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
Composer crea una carpeta vendor en la raíz del proyecto y dentro de estas
están todas las librerías que has requerido en el archivo composer.json
La utilidad más importante, para el framework, de este gestor es la inclusión
de un autoload configurable desde el archivo composer.json para trabajar con
namespaces en PHP, característica que sirve para encapsular clases tal como se
hace en Windows con las carpetas para alojar archivos. Sin composer también
se puede usar esta característica, pero se tendría que escribir y registrar un
autolader para la carga automática de clases. El autoload trabaja bajo
especificación PSR-4 (creada por PHP para estandarizar procesos), para la
autocarga de clases.
63
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.10 Funcionamiento
Un framework MVC es un patrón de arquitectura de tres capas, una capa
controladora, una capa modelo y una capa vista. La primera es la encargada de
relacionar las otras dos.
En la imagen siguiente se puede observar el funcionamiento del framework
en un proyecto o página web en seis pasos.
Imagen 3.3. Diagrama Patrón MVC
Paso 1: El usuario envía una petición al controlador vía URL.
Las URLs permitidas serán de dos tipos
Controlador/Método/param1/param2/param3/...
Modulo/Controlador/Método/param1/param2/param3/...
64
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
El encargado de procesar estas URLs es la clase Petición. Esta clase realiza
la tarea de separar la URL en variables, así sea en un módulo si existe, un
controlador, un método y agrupara los parámetros recibidos en un arreglo.
Asigna cada valor a variables para que puedan ser utilizadas por la clase Iniciar
que posee un único método que se encarga de hacer un llamado al controlador
que corresponde.
Cierto es que se pueden recibir variables por $_GET en el framework, pero
eso depende de quién programe cada controlador.
Paso 2: El controlador solicita los datos al modelo.
Cuando el usuario final visita la página web pueden pasar dos cosas, que
interactúe con la página ingresando algún dato que esta solicita (por ejemplo, en
un login de usuario o un formulario de registro) o bien buscando alguna
información (usando un buscador de la página), de forma que hablamos de una
página web dinámica. Por el contrario, si la página web no solicita información
ni mucho menos tiene un buscador para que el usuario interactúe con la página
hablamos de una página web estática.
En el primer caso, pagina web dinámica, el controlador solicita a la base de
datos la información que el usuario requiere o envía.
En una página web estática el controlador no solicita ninguna información a
la base de datos y este paso se omite.
Por lo explicado anteriormente, este paso es opcional según la página web y
como el usuario puede interactuar con ella.
Hay que hacer notar que, si la página web genera su contenido desde una
base de datos, esta no se definirá como web dinámica hasta que el usuario
interactúe con esta de alguna forma.
65
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
Paso 3: El Modelo devuelve los datos.
Esta acción es consecuencia del paso anterior. La base de datos solo
devolverá datos si hubo alguna interacción con el usuario.
Paso 4: El Controlador selecciona una Vista.
Desde el momento en que se accede a la página web, los pasos anteriores se
han ejecutado y ahora le toca al controlador seleccionar que vista le presenta al
usuario.
Si el usuario visita la raíz del sitio, por ejemplo www.web-ejemplo.com. La
clase Petición seleccionara al controlador por defecto que implementa el
framework y este controlador seleccionara la vista que tiene asignada. Si el
usuario ingresa a alguna sección dentro del sitio, por ejemplo www.web-
ejemplo-como/productos/ La clase Petición enviara productos como controlador
a la clase Iniciar la cual llamara al controlador productos para que presente la
vista que está programada.
Paso 5: Se devuelve la vista seleccionada al controlador.
La Vista devuelve la vista seleccionada por el controlador lista para ser
mostrada.
Paso 6: El controlador carga la Vista.
El Controlador recibe la vista ya renderizada y con la información
proporcionada luego la envía al navegador para ser interpretada.
Notas sobre el funcionamiento.
Una petición del tipo controlador-hijo/método/argumento1/argumento2/…
describe un controlador-hijo, un método y un conjunto de argumentos.
66
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
El controlador-hijo debe ser clase y existir en la carpeta Controladores. Así
el método debe de existir en la clase y debe llamar a la vista por medio de la
variable que la clase hereda del controlador padre.
Si es necesario acceder a un modelo, esto se realizará a través de un método
heredado del controlador padre que cargará un objeto del modelo que realizara
la interacción con la base de datos. El modelo debe estar en la carpeta Modelos.
Dado que el controlador-hijo hereda un objeto de la vista desde el
controlador padre, el primero puede acceder al método que crea la vista para
que así se pueda visualizar en el navegador. La vista que se pide debe estar en
la carpeta Vistas.
Tabla 3-3 Ejemplo URL petición sin modulo
URL www.ejemplo.com/producto/ver/articulo-1
Controlador Modelo Vista
Archivo ProductoControlador.php ProductoModelo.php producto.phtml
Clase ProductoControlador ProductoModelo
Ruta Controladores Modelos Vistas\producto
Si la petición es modulo/controlador-hijo/método/args1/args2/… El
procedimiento no varía, salvo que la ubicación del controlador-hijo, que en
este caso se encuentra dentro de la carpeta modulos\controlador-hijo\
controlador\. El modelo se encontraría en la carpeta modulos\controlador-hijo\
modelo y la vista en la carpeta modulos\controlador-hijo\vista.
67
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
Tabla 3-4 Ejemplo URL petición con modulo
URL www.ejemplo.com/productos/listar/articulo-1
Controlador Modelo Vista
Archivo ListarControlador.php ListarModelo.php listar.phtml
Clase ListarControlador ProductoModelo
Ruta Modulos\productos\controladorModulos\ productos \
modelo
Modulo\
productos \
vista\listar
68
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
3.11 Observaciones:
El patrón MVC como diseño especifica que es el controlador quien recibe y
administra las peticiones, esto según la teoría, pero la realidad y de acuerdo a
los principios SOLID de los que ya se habló anteriormente hace que quien
maneje las peticiones sea una clase especializada de forma que podamos
abstraerla y que si en algún momento cambia no afecte al Controlador.
En la siguiente imagen vemos como funciona el Framework desde que un
usuario realiza una petición.
Imagen 3.4. Core del Framework
69
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 3. Diseño del Framework
La Clase Registro implementa antes que todo el patrón Singleton que
permite crear una instancia de una clase y otorgar un acceso global a esta. Así
se crea un objeto de la Clase Petición
Cuando el usuario efectúa una petición, la Clase Petición recoge la URL y
se encarga de administrar la petición realizada, determinando el controlador,
método y argumentos apropiados y almacenando estos en variables.
Quien es el encargado de llamar al controlador que el usuario pidió mediante
una URL es la Clase Iniciar. Esta clase toma las variables que administra la
Clase Petición y hace un llamado al controlador que la Clase Petición estimo
correcto.
70
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
CAPÍTULO 4
APLICACIONES MODULARES
71
Capítulo 5. Mejoras a futuro
4.1 Introducción.
Cuando hablamos de aplicaciones modulares nos estamos refiriendo a un
conjunto de carpetas y scripts, que siguen el patrón MVC, reutilizables y
exportables a diferentes tipos de desarrollo web usando el framework
construido por nosotros.
La modularizarían es uno de los aspectos fundamentales de la POO y por lo
tanto se debe garantizar la reusabilidad del código. Estos aspectos implican la
escalabilidad de cualquier proyecto por medio del framework y que, a su vez,
cualquier modulo escrito para un proyecto particular pueda ser usado en otro
con mínimos cambios en el código.
Estos módulos deben seguir el estándar implementado por el framework.
Cada módulo debe estar en una carpeta que lleva el mismo nombre del módulo.
Dentro de esta deben existir las carpetas Controlador, Modelo y Vista que se
aplica en el patrón MVC. Además, este módulo debe estar incluido en el
archivo Peticion.php y que su clase pueda hacer la diferencia entre un módulo y
un controlador.
Los controladores extenderán del controlador padre y así también los
modelos extenderán del modelo padre. Los namespace tiene que ser definidos
de forma correcta módulos\nombre-modulo\controlador y módulos\nombre-
modulo\modelo respectivamente.
72
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2 Modulo de Usuarios.
4.2.1 Introducción.
Cuando un proyecto web requiere manejar datos e información privada, se
requiere un módulo de usuarios que permita el acceso a esta información o bien
restringirla.
El módulo Usuarios cuenta con los scripts necesarios para realizar las
siguientes tareas:
Registro de Usuarios.
Validación de cuenta de Usuario.
Login de Usuarios.
Control de sesión de Usuario.
Recuperación de cuenta a través de email
Creación de nuevos Usuarios desde el Administrador.
Reportes de Usuarios.
Edición de perfil de Usuario
Eliminar Usuarios
Por otro lado, el control de acceso se puede realizar por medio de dos clases
diferentes. La Clase Sesión y la Clase ACL, ambas clases se encuentran
ligadas a las mismas tablas de la Base de Datos y se puede usar indistintamente
una o la otra. Ambas manejan el sistema de roles y permisos para proporcionar
los accesos a los controladores, pero la Clase ACL es la única que puede
agregar, modificar o eliminar estos.
Ambas clases tienen métodos para controlar el acceso a los controladores,
emitiendo un error en caso de que el usuario no tenga los permisos, así como
73
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
también estos métodos se pueden aplicar en las vistas para deshabilitar alguna
sección o contenido para ciertos usuarios.
El sistema de Roles incluye tres roles básicos, el Super Administrador, el
Administrador y el Usuario. Se pueden crear más roles si es necesario. Estos
roles poseen permisos y son estos permisos los que son aplicados en los
controladores para dar acceso o no a un determinado rol.
La cantidad de roles y permisos dependerá exclusivamente del tipo de
proyecto web que se esté realizando y cuales sean los requerimientos.
74
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.2 Base de Datos.
4.2.2.1 Especificación de Requisitos.La implementación del módulo está condicionada al tipo de proyecto web
que se realiza y si se necesita algún nivel de acceso a datos o información que
requiera de un sistema de usuarios.
4.2.2.2 Diseño Conceptual.El módulo relaciona cada Usuario con un Rol definido según el proyecto.
Cada Rol puede tener una o muchas tareas o permisos.
Imagen 4.3. Diseño Conceptual Modulo Usuarios
75
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.2.3 Diseño Lógico:Usuarios (id, nombres, apellidos, clave, email, activado)
Roles (id_role, role)
Permisos (id_permiso, permiso, llave)
Tienen (id_role, id_permiso)
A la relación “tienen” le llamaremos permiso_role
Imagen 4.4. Diseño Lógico Modulo Usuarios
76
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.2.4 Diseño Físico:
Imagen 4.5. Diseño Físico Modulo Usuarios
77
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.3 Diagramas.
Siendo el framework el sistema y los usuarios sus actores, independiente del
proyecto, el módulo de Usuario contempla los siguientes casos de uso
Registro de usuario.
Login de Usuario.
Modificar un usuario.
Eliminación de usuario.
Creación, modificación y eliminación de permisos de usuario
Crear, modificar y eliminar roles de usuario.
Generación de reportes de usuarios.
4.2.3.1 Casos de Uso.
Tabla 4-5 Caso de Uso. Registro de Usuario
Descripción de Caso de Uso
Nombre Registro de Usuario
Alias Registro
Actores Usuario, Administrador
Función Validar el registro de un nuevo usuario al sistema.
Descripción
Un usuario accede al registro del sistema y rellena los datos
que el sistema le pide. El sistema valida esos datos y el
usuario recibe un correo para activar la cuenta o envía un
mensaje de error si los datos no son validados.
78
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Tabla 4-6 Caso de Uso. Login de Usuario
Descripción de Caso de Uso
Nombre Login de Usuario
Alias Login
Actores Usuario, Administrador
Función Validar el acceso de un usuario al sistema.
Descripción
Un usuario accede al Login del sistema y rellena los datos
que el sistema le pide. El sistema valida esos datos y el
usuario es dirigido a su perfil o envía un mensaje de error si
los datos no son validados.
Tabla 4-7 Caso de Uso. Modificación de Usuario
Descripción de Caso de Uso
Nombre Modificación de Usuario
Alias Modificar
Actores Usuario, Administrador
Función Editar el perfil de un usuario del sistema.
Descripción
Un usuario accede a su perfil en el sistema y modifica los
datos que el sistema le tiene almacenados. El sistema valida
esos datos y el usuario recibe un mensaje con los cambios
realizados o envía un mensaje de error si los datos no son
validados.
79
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Tabla 4-8 Caso de Uso. Eliminación de Usuario
Descripción de Caso de Uso
Nombre Eliminación de Usuario
Alias Eliminar
Actores Usuario, Administrador
Función Darse de baja del sistema.
DescripciónUn usuario accede a su perfil y se da de baja e el sistema. El
Sistema lo elimina de su Base de Datos.
Tabla 4-9 Caso de Uso. Creación de Permiso de Usuario
Descripción de Caso de Uso
Nombre Creación de Permiso de Usuario
Alias
Actores Administrador
Función Crear un nuevo permiso de usuario en el sistema.
Descripción
El Administrador ingresa los datos para crear un nuevo
permiso de usuario en el sistema. El sistema valida estos
datos y crea el permiso o envía un error.
Tabla 4-10 Caso de Uso. Modificación de Permiso de Usuario
80
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Descripción de Caso de Uso
Nombre Modificación de Permiso de Usuario
Alias
Actores Administrador
Función Modificar un permiso de usuario en el sistema.
Descripción
El Administrador modifica los datos de un permiso de
usuario ya existente en el sistema. El sistema valida estos
datos y modifica el permiso o envía un error.
Tabla 4-11 Caso de Uso. Eliminación de Permiso de Usuario
Descripción de Caso de Uso
Nombre Eliminación de Permiso de Usuario
Alias
Actores Administrador
Función Elimina un permiso de usuario en el sistema.
Descripción
El Administrador elimina un permiso de usuario ya
existente en el sistema. El sistema valida la petición y
elimina el permiso o envía un error.
Tabla 4-12 Caso de Uso. Creación de Nuevo Rol
81
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Descripción de Caso de Uso
Nombre Creación de Nuevo Rol de Usuario
Alias
Actores Administrador
Función Crear un nuevo Rol de usuario en el sistema.
Descripción
Un Administrador ingresa los datos para crear un nuevo Rol
de Usuario en el Sistema. El Sistema valida estos datos y
crea el Rol o envía un error.
Tabla 4-13 Caso de Uso. Modificación de Rol
Descripción de Caso de Uso
Nombre Modificación de Rol de Usuario
Alias
Actores Administrador
Función Modificar un Rol de usuario en el sistema.
Descripción
Un Administrador modifica los datos de un Rol de Usuario
existente en el Sistema. El Sistema valida estos datos y
modifica el Rol o envía un error.
Tabla 4-14 Caso de Uso. Eliminación de Rol
82
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Descripción de Caso de Uso
Nombre Eliminación de Rol de Usuario
Alias
Actores Administrador
Función Eliminar un Rol de usuario en el sistema.
Descripción
Un Administrador elimina un Rol de Usuario ya existente
en el Sistema. El Sistema valida la petición y elimina el Rol
o envía un error.
Tabla 4-15 Generación de Reportes
Descripción de Caso de Uso
Nombre Generación de Reportes
Alias Reportes
Actores Administrador
Función Generar un Reporte de Usuarios.
DescripciónUn Administrador le solicita al sistema generar un reporte
de usuarios existentes en el sistema.
83
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.6. Casos de Uso Generales
Imagen 4.7. Casos de Uso Administrador
84
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.3.2 Diagrama de Secuencias.
Imagen 4.8. Secuencia de Registro
Imagen 4.9. Secuencia de Login
85
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.10. Diagrama de Nuevo Role
86
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.2.4 Interfaces.
Imagen 4.11. Registro de Usuarios
87
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.12. Login de Usuarios
Imagen 4.13. Perfil de Usuario
88
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.14. Permisos de Usuario
Imagen 4.15. Listado y Reportes de Usuarios
89
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.16. Permisos de Rol
Imagen 4.17. Nuevo Usuario
90
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.18. Control de Permisos
Imagen 4.19. Editar Permiso
91
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.20. Eliminar permiso
Imagen 4.21. Nuevo Permiso
92
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.22. Control de Roles
Imagen 4.23. Editar Role
93
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.24. Eliminar Role
Imagen 4.25. Nuevo Role
94
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.3 Modulo de Blog.
4.3.1 Introducción.
‘El blog’ una simple herramienta que sirve como diario personal de uno o
mas autores los cuales pueden ser comentados por los lectores. Además de
diario personal puede servir como una red social en que los lectores charlan con
el autor o autores al comentar lo narrado.
El blog cuenta con los scripts necesarios para realizar las siguientes tareas:
95
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.3.2 Base de Datos.
4.3.2.1 Diseño Conceptual.
Imagen 4.26. Diseño Conceptual Modulo Blog.
96
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.3.2.2 Diseño Lógico.
Imagen 4.27. Diseño Lógico Modulo Blog.
97
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.3.2.3 Diseño Físico.
Imagen 4.28. Diseño Físico Modulo Blog.
98
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.3.3 Interfaces.
Imagen 4.29. Interface Blog 1.
Imagen 4.30. Interface Blog 2.
99
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.31. Interface Blog 3.
100
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4 Modulo Bodega.
4.4.1 Introducción.
La función de almacenaje es una parte fundamental del sistema de
distribución total y representa un punto de separación entre los aspectos de la
oferta y la demanda de cualquier negocio. Tradicionalmente, la naturaleza física
de la operación ha puesto énfasis en su intensivo grado de trabajo, exigiendo un
elevado nivel de gestión y control por parte del hombre. El rápido crecimiento
del soporte tecnológico ha ofrecido una oportunidad para conseguir una mayor
eficacia y eficiencia. Este soporte tecnológico va desde la introducción de
mejores equipos de manipulación y almacenaje hasta la utilización de sistemas
de control computarizados. Al igual que sucede con otros elementos de la
función de distribución, como por ejemplo el transporte y la administración de
inventarios; al almacén le conciernen dos objetivos principales: costo y
servicio. El principal objetivo es conseguir una posición óptima en relación a
estos dos factores a través de la minimización del costo total de la operación, la
provisión de los niveles de servicio deseados. Para conseguir estos objetivos, la
gestión de almacenes necesita considerar sus tres principales elementos:
recursos humanos, espacio y equipos, los cuales dan lugar al costo total de
operación del almacén. Este costo total depende del nivel de productividad de
cada uno de los elementos y de cómo éstos interactúan, y el nivel de servicio
ofrecido a los clientes viene determinado por la eficiencia y eficacia de los
procesos y procedimientos utilizados para recibir, almacenar y expedir
productos. Este módulo está diseñado para proporcionarle al usuario, un manejo
fácil y cómodo en el manejo de un control de bodega, ya sea para un almacén
pequeño o para un negocio grande.
101
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
El módulo de bodega está definido por:
Creación de Orden de Compra
Creación de un Producto
Ingresos y Salidas de Productos
Ingresos de Proveedores.
102
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4.2 Base de Datos.
4.4.2.1 Especificación de Requisitos.
La implementación del módulo de bodega depende del tipo de proyecto
y solicitud del usuario, ya que se realizará dependiendo de las necesidades
que tenga el usuario para implementarlo en su negocio.
103
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4.2.2 Diseño Lógico.
Órdenes de Compra (Id, Rut, Nombre, Producto, Cantidad, Precio, Total)
Productos (Id, Código, Nombre, Unidad, Tipo)
Proveedores (Id, Rut, Nombre, Giro, Dirección, Teléfono)
GRAFICO………………
104
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4.2.3 Diseño Físico.
Imagen 4.32. Diseño Fisico Modulo Bodega.
105
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4.3 Diagramas.
El módulo Bodega contempla los siguientes casos de usos.
Creación de Orden de Compra
Creación de Producto
Creación de Proveedor
Entrada de Producto
Salida de Producto
4.4.3.1 Casos de Uso.
Tabla 4-16 Caso de Uso. Creación de Orden de Compra.
Descripción de Caso de Uso
Nombre Creación de Orden de Compra
Alias
Actores Usuario
Función Crear una nueva orden de compra en el sistema.
Descripción
El Usuario ingresa los datos para crear una nueva orden de
compra en el sistema. El sistema valida estos datos y crea la
orden de compra o envía un error.
106
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Tabla 4-17 Caso de Uso. Creación de Producto.
Descripción de Caso de Uso
Nombre Creación de Producto
Alias
Actores Usuario
Función Crear un nuevo producto en el sistema.
Descripción
El Usuario ingresa los datos para crear una nueva orden de
compra en el sistema. El sistema valida estos datos y crea el
producto o envía un error.
Tabla 4-18 Caso de Uso. Creación de Proveedor.
Descripción de Caso de Uso
Nombre Creación de Proveedor
Alias
Actores Usuario
Función Crear un nuevo Proveedor en el sistema.
Descripción
El Usuario ingresa los datos para crear un nuevo Proveedor
en el sistema. El sistema valida estos datos y crea al
proveedor o envía un error.
107
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Tabla 4-19 Caso de Uso. Entrada de Producto.
Descripción de Caso de Uso
Nombre Entrada de Producto
Alias Entrada
Actores Usuario
Función Ingresa una nueva cantidad del Producto en el sistema.
Descripción
El Usuario ingresara una nueva cantidad de Producto en el
sistema. El sistema valida estos datos y sumara una nueva
cantidad en el producto o envía un error.
Tabla 4-20 Caso de Uso. Salida de Producto.
Descripción de Caso de Uso
Nombre Salida de Producto
Alias Salida
Actores Usuario
Función Retira una cantidad del Producto en el sistema.
Descripción
El Usuario retira una cantidad de Producto en el sistema. El
sistema valida estos datos y restara una cantidad en el
producto o envía un error.
108
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Tabla 4-21 Generación de Reportes.
Descripción de Caso de Uso
Nombre Generación de Reportes
Alias Reportes
Actores Usuario
Función Generar un Reporte de Productos.
DescripciónEl Usuario le solicita al sistema generar un reporte de
productos existentes en el sistema.
109
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.4.4 Interfaces.
Imagen 4.33. Listado de Órdenes de Compra.
Imagen 4.34. Nueva Orden de Compra.
110
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.35. Eliminar Orden de Compra.
Imagen 4.36. Listado de Productos.
111
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.37. Agregar Nuevo Producto.
Imagen 4.38. Eliminar Producto.
112
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.39. Listar Proveedores.
Imagen 4.40. Nuevo Proveedor.
113
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5 Modulo Tienda Online.
4.5.1 Introducción.
La tienda virtual, medio tan simplificado para usuarios compradores, pero a
la vez complejo para su administrador, debe tener una especificación clara para
que sea eficiente dada la modalidad caracterizada, procurando uno como
administrador de tener visualizada la carencia, gustos o preferencia de quienes
visiten nuestro sitio web.
Una tienda Online cuenta con los scripts necesarios para realizar las
siguientes tareas:
Registro de Usuarios.
Validez de la cuenta registrada.
Modalidades de Compra, costo y envío.
Exhibición de Productos (categoría, características y detalle
valorizado)
Carro de Usuario registrado.
Perfil de Usuario (editar perfil, datos de identificación, actualización
de datos)
Buzón de pedidos.
Aceptación, eliminación y edición de Usuarios.
Edición de datos e interfaz de la página.
Un responsable de una tienda online debe desenvolverse con soltura con las
principales disciplinas de marketing online mediante uso de:
114
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
CMS: es básica la facilidad y prioridad de aprender a utilizar
gestores de contenidos. Por eso deberemos estimar la experiencia
con cualquier tipo de CMS como WordPress, Prestashop, Drupal,
Magento, entre otros.
Copywriting: la capacidad de redacción es imprescindible para el
administrador de la plataforma virtual responsable debe manejar la
buena dicción al ofertar los productos; sepa escribir rápido y de
forma creativa para poder llegar al mercado de quien se interese en
nuestros productos.
No es obligatorio que sea un experto en cada una de ellas, pero sí debe tener
el conocimiento suficiente como para supervisar de una forma eficaz la
subcontratación de estos servicios.
115
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.2 Base de Datos.
4.5.2.1 Especificación de requisitos
Cuando de especificación hablamos en cuando a la tienda online,
consideramos un aspecto de gran relevancia.
Para dar inicio a la tienda y tener todo lo necesario en un servidor, es de
carencia tener un servicio de alojamiento web “hosting”, para llevar nuestro
propio servidor gratuito. Cuando expresamos que la tienda online a crear debe
tener ventajas comparativas sobre la competencia, debemos considerar una web
con alta carga de tráfico y por lo demás una potente conexión de red. Según la
programación y estudio realizado MySQL (o similares como MariaDB) como
sistema de gestión de bases de datos y PHP (Perl, Python) como lenguajes de
programación para las apps webs, son las más idóneas, simples y concretas para
dar inicio a la Tienda Online.
116
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.2.2 Diseño Conceptual.
Imagen 4.41. Diseño Conceptual Modulo Tienda.
117
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.2.3 Diseño Lógico.
Productos (id producto, código, nombre, descripción, stock, precio)
Categorías (id categoría, nombre)
Marcas (id marca, nombre)
Pedidos (id pedido, cantidad, precio)
Facturas (id factura, fecha)
Imagen 4.42. Diseño Lógico Modulo Tienda.
118
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.2.4 Diseño Físico.
Imagen 4.43. Diseño Físico Modulo Tienda.
119
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.3 Diagramas.
En El sistema de Tienda Online los escenarios en que actúan los usuarios,
son los siguientes casos de usos:
• Registro de Usuario.
• Confirmar compra.
• Exhibición de catálogo.
• Editar perfil.
• Añadir producto carro.
• Eliminación producto carro.
• Modificar producto catálogo.
• Validación de cuenta.
120
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.3.1 Casos de Uso.
Los casos de uso proporcionan uno o más escenarios que indican cómo
debería interactuar el sistema con el usuario o con otro sistema para conseguir
un objetivo específico.
Tabla 4-22 Registro de usuarios.
Descripción de Caso de Uso
Nombre Registro de Usuarios
Alias Registro
Actores Usuario, Administrador
FunciónAdmisión y validación de un nuevo usuario cliente a la
página.
DescripciónSe validan los datos ingresado del nuevo usuario/cliente
por medio del correo electrónico.
Tabla 4-23 Confirmar Compra.
Descripción de Caso de Uso
Nombre Confirmar compra
Alias Compra - Venta
Actores Usuario, Administrador
121
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Función
Entregar claridad al usuario de la tienda Online, respecto
a precios de compra, precio de envío, métodos de pago y
facilidades de compra, para poder hacerla efectiva y
registrarla en la base de datos.
Descripción Datos del usuario para la compra.
Tabla 4-24 Exhibición de Productos.
Descripción de Caso de Uso
Nombre Exhibición de Productos
Alias Catalogo
Actores Administrador
FunciónOfertar al cliente los productos que tenemos disponible
para la carencia que tenga el usuario.
DescripciónPor medio de la pestaña podremos ver con claridad el
detalle de los productos ofertados.
Tabla 4-25 Editar Perfil de Usuario.
Descripción de Caso de Uso
Nombre Editar Perfil de Usuario
Alias Perfil
122
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Actores Usuario
Función Identificar al cliente registrado
Descripción
Edición de Foto de Perfil, datos de completa
identificación (nombre completo, correo electrónico, fecha
de nacimiento)
Tabla 4-26 Añadir Producto Carro.
Descripción de Caso de Uso
Nombre Añadir producto Carro
Alias Carro
Actores Usuario
Función Sumar un producto más a la compra
DescripciónUna vez registrado el cliente puede añadir al carro de
compra lo que el desee.
Tabla 4-27 Eliminar Producto Carro.
Descripción de Caso de Uso
Nombre Eliminar Producto Carro
Alias Carro
Actores Usuario
123
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Función Restar un producto más a la compra
DescripciónTeniendo los productos seleccionados que desee
comprar, podrá quitar del carro.
Tabla 4-28 Modificar Producto Catalogo.
Descripción de Caso de Uso
Nombre Carro de Usuario Registrado
Alias Carro
Actores Usuarios
FunciónModifica los datos de un producto a excepción
del identificador
DescripciónEl producto ha de existir en la base de datos,
modificando solo datos básicos.
Tabla 4-29 Validez de la cuenta registrada.
Descripción de Caso de Uso
Nombre Validez de la cuenta registrada
Alias Validez
Actores Usuario, administrador
Función Hacer efectivos los datos ingresados por los clientes
124
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
DescripciónAl correo electrónico del usuario llegara un correo para
la validación.
Imagen 4.44. Casos de Usos generales.
125
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
4.5.4 Interfaces.
Imagen 4.45. Listar Productos.
Imagen 4.46. Nuevo Producto.
126
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.47. Editar Producto.
Imagen 4.48. Eliminar producto.
127
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.49. Listado Marcas.
Imagen 4.50. Nueva Marca
128
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.51. Editar Marca.
Imagen 4.52. Eliminar Marca.
129
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.53. Listado de Categorías.
Imagen 4.54. Nueva categoría.
130
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Imagen 4.55. Editar Categoría.
Imagen 4.56. Eliminar Categoría.
131
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
CAPÍTULO 5
MEJORAS A FUTURO
132
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Debido a la naturaleza intrínseca de MVC, recordar que este patrón nos
ayuda a implementar una estructura en donde se separa claramente la lógica del
negocio y la lógica de la aplicación de la interfaz de usuario, mayores cambios
o mejoras no pueden hacerse. Y si por el contrario el proyecto exige un cambio
real a esta estructura talvez la solución más efectiva sea cambiar de patrón.
Un punto a tomar en cuenta antes de empezar a realizar mejoras es atender a
que el Framework es PHP puro, es decir, no contiene una interfaz gráfica que
ayude al programador a generar consultas a la base de datos o a generar vistas
al navegador. Es el programador quien debe realizar estas acciones a través de
clases y objetos que debe ir construyendo siguiendo la estructura MVC. Es
cierto que el framework ya posee una estructura bien definida para estas
situaciones, pero también es cierto que permite la adaptabilidad de quien lo use
según sea su necesidad.
Desde el punto de vista de la lógica de la aplicación las mejoras nacen desde
la necesidad de separar cada vez más los componentes necesarios para
desarrollar un proyecto. Sabemos que es el Controlador quien hace la tarea
principal, la lógica de la aplicación, en esta estructura y que además es el
encargado de unir los demás componentes como la lógica del negocio y la
interfaz de usuario. Asignarle una tarea distinta como por ejemplo la creación
de reportes de los usuarios del sistema (esto puede ocurrir pues según el modelo
MVC, es el usuario a través de la vista que le pide al controlador un informe de
usuarios y es este quien exige los datos al modelo para generar el informe)
violaría el principio de responsabilidad única en donde una clase solo debe de
realizar una sola tarea. El Controlador principal del Framework realiza
validaciones de datos, esta tarea debería ser implementada en otra clase, es
decir abstraer esta responsabilidad a una clase ajena y que el controlador si la
necesita sea capaz de generar una instancia de esta.
133
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Desde la mirada de la Vista, lo mejora más interesante seria realizar una
especie de plantilla base, una clase PHP, que genere HTML. El framework
genera las vistas desde plantillas, pero estas traen código PHP embebido en
ellas. Lo ideal sería que el controlador llamase a una clase que haga de
interprete la vista, reemplazando código PHP y convirtiendo este en salida
HTML.
La lógica del negocio, manejada por el Modelo, quien toma una conexión
desde una clase padre llamada Database podría verse mejorada con la creación
de un ORM y así ir generando de forma automática los datos exigidos por el
controlador. El Framework trabaja con modelos separados, es decir que cada
clase controladora tiene su par en una clase modelo que usa para ir generando
los datos que se le piden. Es decir, si la clase necesita los teléfonos de los
usuarios, el programador escribe un método en el modelo que extraiga los
teléfonos. Desde la concepción del Framework siempre se ha visto con buenos
ojos esta política, de crear funciones a medida que se necesiten, pues si
pensamos en un ORM como el que usan los Frameworks más renombrados
(como Laravel o CodeIgniter), o mejor aún, si pensamos en usar algún ORM
como dependencia (librerías como Doctrine o Eloquent), estos implican clases
que quizás nunca uses en el proyecto actual y solo aporten peso, lentitud y
tiempo de aprendizaje.
Actualizar el Framework a PHP 7 es una necesidad ante las claras mejoras
que esta versión del lenguaje ofrece, más aún si se entiende que el Framework
es PHP puro. Sobre si actualizar JavaScript o cambiar de gestor de Base de
Datos, esto es solo decisión del programador pues no influye en el framework y
si influye en, por ejemplo, la creación de formularios en back-end y su
validación.
134
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 5. Mejoras a futuro
Mejorar la documentación es un tema aparte. Documentar las clases y las
librerías junto a sus métodos se deben mejorar en favor de la calidad del
software. Esto ayuda a la mantención y a las futuras modificaciones de terceros.
A medida que el Framework crece, según el tipo de proyecto, debería ser
capaz de implementar pruebas unitarias bajo PHPUnit como dependencia. Esto
último siempre será opcional y según el tipo de proyecto que se tenga enfrente.
135
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
CAPÍTULO 6
CONCLUSIONES
136
Capítulo 8. Anexos
En Internet se pueden encontrar decenas de tutoriales sobre como empezar
un Framework y sin ir más lejos, este framework se realizó siguiendo una serie
de video tutoriales allá por el año 2012. Desde ese tiempo el Framework ha ido
madurando según las necesidades y las actualizaciones del lenguaje PHP
principalmente.
Escribir un Framework desde cero no es complicado, pero si te toma algo de
tiempo y si estas frente a un desarrollo a corto plazo talvez no sea la mejor
opción que se pueda tomar y elegir un Framework o algún CMS conocido que
cumpla los requerimientos del proyecto ayudara mucho mejor.
No se trata de reinventar la rueda, sino de tomar las herramientas que ya
tienes para construir y mejorar, no modificar, algo que ya existe y de acuerdo a
tus propias necesidades y las de cualquier proyecto presente o futuro.
La POO y MVC es una excelente combinación para ir entendiendo y
aplicando los conceptos vistos en este libro y la realización de un Framework
sería la mejor forma de evaluar el conocimiento-
Realizar un framework propio claramente te ayuda a comprender mejor el
funcionamiento de los ya existentes pues como se ha visto en este libro, las
materias a conocer son muchas y variadas sin embargo no te hará un conocedor
de estos por razones obvias.
137
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
CAPÍTULO 7
BIBLIOGRAFÍA
138
CAPÍTULO 8
ANEXOS
139
Capítulo 8. Anexos
Anexo A. Siglas.
AJAX : Acrónimo de Asynchronous JavaScript And XML
CGI : Common Gataway Interface.
CSS : Hojas de Estilo en Cascada (Cascading Style Sheets)
CMS : Sistema de Administración de Contenidos (Content
Management System).
DAP : Desarrollo de Aplicaciones Web.
DOM : Acrónimo de Document Object Model.
GC : Acrónimo de Garbage Collector.
HTML : Hypertext Markup Language (Lenguaje de Marcado de
Hipertexto)
HTTP : Hypertext Transfer Protocol (Protocolo de Transferencia de
Hipertexto)
LAMP : Acrónimo para Linux – Apache – MySQL – PHP.
ORM : Object Relational Mapping. Mapeo Relacional de Objetos
PDO : Acrónimo recursivo de PHP Data Objects.
PHP : Acrónimo recursivo de PHP Hypertext Preprocessor.
PHTML : Archivo
URL : Uniform Resource Locator.
WAMP : Acrónimo de Windows – Apache – MySQL - PHP
MVC : Modelo – Vista – Controlador (Model – View - Controller)
W3C : World Wide Web Consortium.
140
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 8. Anexos
Anexo B. Sobre Frameworks y CMS
Si bien el motivo final de esta tesis es desarrollar un Framework desde cero
que permita el desarrollo de aplicaciones webs de forma más rápida y sencilla
según requerimientos del proyecto, es necesario dar a conocer las diferentes
alternativas actuales que el mercado ofrece al desarrollador para realizar
cualquier tipo de proyecto web.
Las alternativas básicamente pasan por tres candidatos, un desarrollo desde
cero (razón de esta tesis), un Framework conocido o bien en usar un CMS
(Gestor de Contenidos.
B.1 Sobre los Frameworks.
Algunos de los Frameworks más populares, robustos y madurados hoy en
día y que, por cierto, han empezado desde cero (al menos la mayoría) son:
PHP: Zend, Laravel, Symfony, Codeigniter, CakePHP, Yii.
Python: Django
Ruby: Ruby On Rails
JavaScript: Embed.js, Backbone.js, AngularJS
Ventajas de usar alguno de estos pueden ser su adaptabilidad y escalabilidad
independientes del tipo de proyecto, simple o más complejo. Aportan una
estructura base que se puede adaptar, a lo largo del tiempo, a los requerimientos
del proyecto. Cuentan con una gran comunidad detrás de ellos.
141
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.
Capítulo 8. Anexos
La desventaja más notoria es sin duda el hecho que hay que saber programar
en el lenguaje que está realizado el Framework. Por supuesto hay que entender
que algunos de estos frameworks no llevan un entorno web que facilite su
implementación.
B.2 Sobre los CMS.
Los Sistemas de Administración de Contenidos, CMS, son un conjunto de
funcionalidades que, bajo un entorno web, le permiten al desarrollador (o
usuario) crear contenido web rápido y sencillo sin necesidad de saber
programar.
Algunos MCS que podemos encontrar son:
Wordpress, Joomla.
Prestashop, Magento. Para aplicaciones de eCommerce
Drupal, Para portales y sitios varios.
Las ventajas de estos sistemas varían principalmente en la curva de
aprendizaje, algunos son muy sencillos y fáciles de usar y en otros se puede
necesitar saber algo de programación. Cuentan con un buen soporte detrás en lo
referente a plugins y librerías.
Como desventaja principal, debe tomarse en cuenta que son sistemas
completos y que para aplicaciones web simples (de tres o cuatro secciones)
habría que optimizar el sitio para una mejor carga en el navegador.
142
Desarrollo de un framework en PHP para desarrollo de aplicaciones en entornos webs.