SOLUCIONES INFORMATICAS INGENIERIA INFORMATICA Y DE SISTEMAS

SESIONES DE APRENDIZAJE
CURSO:
“SOLUCIONES INFORMATICAS I”
Lorenzo RODRIGUEZ CAMONES
Ingeniero en Informática y Sistemas
CIP Nº 143225
SESIONESDEAPRENDIZAJE
SOLUCIONESINFORMATICASI

SOLUCIONES INFORMÁTICAS I
Lorenzo RODRIGUEZ CAMONES - Ingeniero en Informática y Sistemas.
2
SOLUCIONES INFORMATICAS I
1. ARQUITECTURA CLIENTE SERVIDOR
Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa
(el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se
ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario
distribuido a través de una red de computadoras. La interacción cliente-servidor es el soporte
de la mayor parte de la comunicación por redes. Ayuda a comprender las bases sobre las
que están construidos los algoritmos distribuidos.
INTRODUCCIÓN:
El servidor debe negociar con su Sistema Operativo un puerto (casi siempre bien conocido)
donde esperar las solicitudes. El servidor espera pasivamente las peticiones en un puerto bien
conocido que ha sido reservado para el servicio que ofrece. El cliente también solicita, a su
sistema operativo, un puerto no usado desde el cual enviar su solicitud y esperar respuesta.
Un cliente ubica un puerto arbitrario, no utilizado y no reservado, para su comunicación.
En una interacción se necesita reservar solo uno de los dos puertos, asignados un identificador
único de puerto para cada servicio, se facilita la construcción de clientes y servidores.
Los servidores por lo general son más difíciles de construir que los clientes pues aunque se
implantan como programas de aplicación deben manejar peticiones concurrentes, así como
reforzar todos los procedimientos de acceso y protección del sistema computacional en el
que corren, y protegerse contra todos los errores posibles. El cliente y el servidor pueden
interactuar en la misma máquina.
EVOLUCIÓN:
Computadora central
Desde sus inicios el modelo de administración de datos a través de computadoras es basaba
en el uso de terminales remotas, que se conectaban de manera directa a una computadora
central. Dicha computadora central se encargaba de prestar servicios caracterizados por
que cada servicio se prestaba solo a un grupo exclusivo de usuarios.
Computadoras dedicadas
Esta es la era en la que cada servicio empleaba su propia computadora que permitía que los
usuarios de ese servicio se conectaran directamente. Esto es consecuencia de la aparición
de computadoras pequeñas, de fácil uso, más baratas y más poderosas de las
convencionales.
Conexión libre
Hace más de 10 años que las computadoras de escritorio aparecieron de manera masiva.
Esto permitió que parte apreciable de la carga de trabajo de cómputo tanto en el ámbito de
cálculo como en el ámbito de la presentación se lleven a cabo desde el escritorio del usuario.
En muchos de los casos el usuario obtiene la información que necesita de alguna
computadora de servicio. Estas computadoras de escritorio se conectan a las computadoras
de servicio empleando software que permite la emulación de algún tipo de terminal. En otros
de los casos se les transfiere la información haciendo uso de recursos magnéticos o por
trascripción.

3
Cómputo a través de redes
Esta es la era que está basada en el concepto de redes de computadoras, en la que la
información reside en una o varias computadoras, los usuarios de esta información hacen uso
de computadoras para laborar y todas ellas se encuentran conectadas entre sí. Esto brinda
la posibilidad de que todos los usuarios puedan acceder a la información de todas las
computadoras y a la vez que los diversos sistemas intercambien información.
Arquitectura cliente-servidor
En esta arquitectura la computadora de cada uno de los usuarios, llamada cliente, produce
una demanda de información a cualquiera de las computadoras que proporcionan
información, conocidas como servidores estos últimos responden a la demanda del cliente
que la produjo.
Los clientes y los servidores pueden estar conectados a una red local o una red amplia, como
la que se puede implementar en una
empresa o a una red mundial como lo es la
Internet.
Bajo este modelo cada usuario tiene la
libertad de obtener la información que
requiera en un momento dado proveniente
de una o varias fuentes locales o distantes y
de procesarla como según le convenga. Los
distintos servidores también pueden
intercambiar información dentro de esta
arquitectura.
PARTES QUE COMPONEN EL SISTEMA:
Cliente: Programa ejecutable que participa activamente en el establecimiento de las
conexiones. Envía una petición al servidor y se queda esperando por una respuesta. Su tiempo
de vida es finito una vez que son servidas sus solicitudes, termina el trabajo.
Servidor: Es un programa que ofrece un servicio que se puede obtener en una red. Acepta la
petición desde la red, realiza el servicio y devuelve el resultado al solicitante. Al ser posible
implantarlo como aplicaciones de programas, puede ejecutarse en cualquier sistema donde
exista TCP/IP y junto con otros programas de aplicación. El servidor comienza su ejecución
antes de comenzar la interacción con el cliente. Su tiempo de vida o de interacción es
“interminable”.
Los servidores pueden ejecutar tareas sencillas (caso del servidor hora día que devuelve una
respuesta) o complejas (caso del servidor ftp en el cual se deben realizar operaciones antes
de devolver una respuesta). Los servidores sencillos procesan una petición a la vez (son
secuenciales o interactivos), por lo que no revisan si ha llegado otra petición antes de enviar
la respuesta de la anterior.
Los más complejos trabajan con peticiones concurrentes aún cuando una sola petición lleve
mucho tiempo para ser servida (caso del servidor ftp que debe copiar un archivo en otra
máquina). Son complejos pues tienen altos requerimientos de protección y autorización.
Pueden leer archivos del sistema, mantenerse en línea y acceder a datos protegidos y a
archivos de usuarios. No puede cumplir a ciegas las peticiones de los clientes, deben reforzar
el acceso al sistema y las políticas de protección. Los servidores por lo general tienen dos
partes:
 Programa o proceso que es responsable de aceptar nuevas peticiones: Maestro o Padre.
 Programas o procesos que deben manejar las peticiones individuales: Esclavos o Hijos.

4
Tareas del programa maestro
 Abrir un puerto local bien conocido al cual pueda acceder los clientes.
 Esperar las peticiones de los clientes.
 Elegir un puerto local para las peticiones que llegan en informar al cliente del nuevo
puerto, (innecesario en la mayoría de los casos).
 Iniciar un programa esclavo o proceso hijo que atienda la petición en el puerto local, (el
esclavo cuando termina de manejar una petición no se queda esperando por otras).
 Volver a la espera de peticiones mientras los esclavos, en forma concurrente, se ocupan
de las anteriores peticiones.
Clasificación de los servidores
En base al recurso que tendrán incorporado, los servidores se pueden clasificar por su
operación como: servidor de comunicaciones (módem), servidor de archivos (disco duro),
servidor de impresión (impresora), servidor de base de datos y servidor de correo.
El servidor más común existente es el servidor de archivos. Como su nombre lo indica, su
recurso principal compartido son los archivos.
1. Servidores de comunicaciones
Realizan todas las operaciones de comunicación requeridas por los usuarios. Un servidor de
comunicaciones se encarga de liberar al servidor de archivos de la carga de las operaciones
relacionadas con las comunicaciones. Con esto se logra incrementar la eficiencia tanto del
servidor de archivos como de los servicios de comunicaciones. En una aplicación típica el
servidor de comunicaciones puede proveer el acceso a los usuarios de la red, a un conjunto
de módems. El servidor se encarga de manejar las peticiones del uso de módems, de tal
manera que, si los módems se encuentran ocupados, el siguiente usuario es informado de tal
situación, y tal vez es agregado a una cola de espera.
2. Servidores de archivos
Un servidor de ficheros es el encargado de gestionar el uso de un disco duro compartido por
parte de varios usuarios y de que en un determinado momento solamente un único usuario
pueda estar utilizando un fichero concreto. Cada ordenador trabajará como si su ordenador
tuviese un disco duro propio.
En un entorno de red local, puesto que puede darse el caso de que varios usuarios intenten
acceder a un mismo dato, se necesita un sistema que permita controlar y ordenar los accesos
al disco de los distintos usuarios de la red, dando paso a unos y haciendo esperar a otros.

5
3. Servidores de impresión
La función de este tipo de servidores es la de administrar los recursos de impresión (colas de
impresión), dentro de la red, de manera eficiente. Generalmente se tiene al servidor
conectado directamente al dispositivo de impresión, dicho servidor se encarga de recibir las
peticiones de impresión de las demás estaciones de la red y de mandarlas a la impresora.
4. Servidores de base de datos
Maneja la administración de una base de datos común. Distribuyen el procesamiento de la
información entre una aplicación, que es ejecutada en la estación de trabajo cliente, y el
manejador de bases de datos que se ejecuta en el servidor. Con esto se reduce, además de
la carga de procesamiento del servidor, el tráfico de la red. Estos servidores pueden manejar
las bases de datos de dos maneras, bases de datos centralizadas y bases de datos
distribuidas.
Bases de datos distribuidas:
 Evitan un cuello de botella potencial en el manejador de las bases de datos.
 Eliminan al servidor como punto único de falla.
 Permiten el real acceso a bases de datos distribuidas a través de puentes y pasarelas.
 Permiten una administración centralizada de las bases de datos.
 Teóricamente, permiten la corrupción de los datos, por cualquiera de las estaciones de
la red.
 No elimina las tareas de actualización y sincronización de las bases de datos.

6
Bases de datos centralizadas:
 Reducen la probabilidad de corrupción de la información.
 Son más fáciles de mantener.
 Permiten el acceso a muchas bases de datos a través de LANs y WANs.
 Permiten el uso de enlaces a WANs de menor velocidad.
5. Servidores de correo
Son aquellos servidores que se encargan de distribuir los correos electrónicos y guardar todos
los mensajes de correo.
CARACTERÍSTICAS DE LA ARQUITECTURA CLIENTE-SERVIDOR:
 Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa
con los recursos a compartir. El proceso del cliente proporciona la interfaz entre el usuario
y el resto del sistema. El proceso del servidor actúa como un motor de software que
maneja recursos compartidos tales como bases de datos, impresoras, Módem, etc.
 Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos
de cómputo como velocidad del procesador, memoria, velocidad y capacidades del
disco e input-output devices.
 Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en
la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.
 Existe una clara distinción de funciones basadas en el concepto de”servicio”, que se
establece entre clientes y servidores.
 La relación establecida puede ser de muchos a uno, en la que un servidor puede dar
servicio a muchos clientes, regulando su acceso a los recursos compartidos.
 Los clientes corresponden a procesos activos en cuanto a que son estos los que hacen
peticiones de servicios. Estos últimos tienen un carácter pasivo, ya que esperan peticiones
de los clientes.
 No existe otra relación entre clientes y servidores que no sea la que se establece a través
del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición
y entrega de solicitudes de servicios.
 El ambiente es heterogéneo. La plataforma de hardware y el sistema operativo del cliente
y del servidor no son siempre los mismos. Precisamente una de las principales ventajas de
esta arquitectura es la posibilidad de conectar clientes y servidores independientemente
de sus plataformas.
 El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier
sistema Cliente-Servidor. La escalabilidad horizontal permite agregar más estaciones de
trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical
permite mejorar las características del servidor o agregar múltiples servidores.

7
VENTAJAS Y DESVENTAJAS DEL ESQUEMA CLIENTE-SERVIDOR:
Existencia de plataformas de hardware cada vez más baratas. Esta constituye a su vez una
de las más palpables ventajas de este esquema, la posibilidad de utilizar máquinas mucho
más baratas que las requeridas por una solución centralizada, basada en sistemas grandes
(mainframes). Además, se pueden utilizar componentes, tanto de hardware como de
software, de varios fabricantes, lo cual contribuye considerablemente a la reducción de
costos y favorece la flexibilidad en la implantación y actualización de soluciones.
Ventajas:
 Facilita la integración entre sistemas diferentes y comparte información, permitiendo por
ejemplo que las máquinas ya existentes puedan ser utilizadas pero utilizando interfaces
más amigables el usuario. De esta manera, se puede integrar PCs con sistemas medianos
y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema operativo.
 Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este
esquema tienen una mayor y más intuitiva con el usuario. En el uso de interfaces gráficas
para el usuario, presenta la ventaja, con respecto a uno centralizado, de que no siempre
es necesario transmitir información gráfica por la red pues esta puede residir en el cliente,
lo cual permite aprovechar mejor el ancho de banda de la red.
 La estructura inherentemente modular facilita además la integración de nuevas
tecnologías y el crecimiento de la infraestructura computacional, favoreciendo así la
escalabilidad de las soluciones.
 Contribuye además a proporcionar a los diferentes departamentos de una organización,
soluciones locales, pero permitiendo la integración de la información.
Desventajas:
 El mantenimiento de los sistemas es más difícil pues implica la interacción de diferentes
partes de hardware y de software, distribuidas por distintos proveedores, lo cual dificulta
el diagnóstico de fallas.
 Cuenta con muy escasas herramientas para la administración y ajuste del desempeño de
los sistemas.
 Es importante que los clientes y los servidores utilicen el mismo mecanismo (por ejemplo
sockets o RPC), lo cual implica que se deben tener mecanismos generales que existan en
diferentes plataformas.
 Hay que tener estrategias para el manejo de errores y para mantener la consistencia de
los datos.
 El desempeño (performance), problemas de este estilo pueden presentarse por
congestión en la red, dificultad de tráfico de datos, etc.
ARQUITECTURA CLIENTE/SERVIDOR EN 3 NIVELES
Arquitectura en 2 niveles:
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el
cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios
recursos. Esto significa que el servidor no requiere otra aplicación para proporcionar parte del
servicio.

8
Arquitectura en 3 niveles:
En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura
generalmente está compartida por:
 Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de
usuario (generalmente un navegador Web) para la presentación.
 El servidor de aplicaciones (también denominado software intermedio), cuya tarea es
proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo.
 El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere.
Comparación entre ambos tipos de arquitecturas
La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la que el servidor
es polivalente, es decir, puede responder directamente a todas las solicitudes de recursos del
cliente.
Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor son
descentralizadas de uno a otro, es decir, cada servidor se especializa en una determinada tarea,
(por ejemplo: servidor web/servidor de bases de datos). La arquitectura en 3 niveles permite:
 Un mayor grado de flexibilidad.
 Mayor seguridad, ya que la seguridad se puede definir independientemente para cada
servicio y en cada nivel.
 Mejor rendimiento, ya que las tareas se comparten entre servidores.
Arquitectura de niveles múltiples:
En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un
servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar
su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una
arquitectura en N-niveles.

9
2. ENTORNO DE DESARROLLO DEL LENGUAJE DE PROGRAMACION ORIENTADO A
OBJETOS.
ENTORNO DE DESARROLLO INTEGRADO:
Un entorno de desarrollo integrado o entorno de desarrollo interactivo, en inglés Integrated
Development Environment (IDE), es una aplicación informática que proporciona servicios
integrales para facilitarle al desarrollador o programador el desarrollo de software.
Normalmente, un IDE consiste de un editor de código fuente, herramientas de construcción
automáticas y un depurador. La mayoría de los IDE tienen auto-completado inteligente de
código (IntelliSense). Algunos IDE contienen un compilador, un intérprete, o ambos, tales
como NetBeans y Eclipse; otros no, tales como SharpDevelop y Lazarus.
El límite entre un IDE y otras partes del entorno de desarrollo de software más amplio no está
bien definido. Muchas veces, a los efectos de simplificar la construcción de la interfaz gráfica
de usuario (GUI, por sus siglas en inglés) se integran un sistema controlador de versión y varias
herramientas. Muchos IDE modernos también cuentan con un navegador de clases, un
buscador de objetos y un diagrama de jerarquía de clases, para su uso con el desarrollo de
software orientado a objetos.
Anjuta, un entorno de desarrollo integrado de C y C++ para el ambiente GNOME.
Generalidades:
Los IDE están diseñados para maximizar la productividad del programador proporcionando
componentes muy unidos con interfaces de usuario similares. Los IDE presentan un único
programa en el que se lleva a cabo todo el desarrollo. Generalmente, este programa suele
ofrecer muchas características para la creación, modificación, compilación, implementación

10
y depuración de software. Esto contrasta con el desarrollo de software utilizando herramientas
no relacionadas, como Vi, GNU Compiler Collection (GCC) o Make.
Uno de los propósitos de los IDE es reducir la configuración necesaria para reconstruir múltiples
utilidades de desarrollo, en vez de proveer el mismo set de servicios como una unidad
cohesiva. Reduciendo ese tiempo de ajustes, se puede incrementar la productividad de
desarrollo, en casos donde aprender a usar un IDE es más rápido que integrar manualmente
todas las herramientas por separado.
Una mejor integración de todos los procesos de desarrollo hace posible mejorar la
productividad en general, más que únicamente ayudando con los ajustes de configuración.
Por ejemplo, el código puede ser continuamente armado, mientras es editado, previendo
retroalimentación instantánea, como cuando hay errores de sintaxis. Esto puede ayudar a
aprender un nuevo lenguaje de programación de una manera más rápida, así como sus
librerías asociadas.
Algunos IDE están dedicados específicamente a un lenguaje de programación, permitiendo
que las características sean lo más cercanas al paradigma de programación de dicho
lenguaje. Por otro lado, existen muchos IDE de múltiples lenguajes tales como Eclipse,
ActiveState Komodo, IntelliJ IDEA, MyEclipse, Oracle JDeveloper, NetBeans, Codenvy y
Microsoft Visual Studio. Xcode, Xojo y Delphi están dedicados a un lenguaje cerrado o a un
tipo de ajustes de tipos de lenguajes de programación.
Mientras la mayoría de los IDE modernos son gráficos, los editores de textos (como Turbo
Pascal) eran populares antes de que los sistemas de ventanas se hicieran disponibles, tales
como Microsoft Windows y X Window System (X11). Estos usan funciones por medio de teclas
rápidas para ejecutar comandos o macros frecuentemente usados.
EVOLUCIÓN HISTÓRICA:
Los IDE fueron posibles cuando se desarrollaba vía consola o terminal de la computadora. Los
primeros sistemas no podían soportarlos, porque los programas eran preparados usando
diagramas de flujo, introduciendo programas con tarjetas agujeradas (o papel cartón,
etcétera) antes de enviarlos a un compilador. Dartmouth BASIC fue el primer lenguaje en ser
creado con un IDE (también fue el primero en ser diseñado para ser utilizado enfrente de la
consola o la terminal). Este IDE (parte de Dartmouth Time Sharing System) fue basado en
código y basado en comandos, y por esto no se parecía mucho a los IDE tan gráficos
actuales. Sin embargo, la edición integrada, manejo de archivos, compilación, depurador y
ejecutable en una manera consistente con los IDE modernos.
"Maestro I" es un producto de Softlab Múnich y fue el primer sistema de desarrollo integrado
IDE,3 para software, creado en 1975. Maestro I fue instalado por 22.000 programadores en
todo el mundo. Hasta 1989, existían 6.000 instalaciones en la República Federal de Alemania.
Maestro fue sin duda el líder mundial en este campo durante los años 1970 y 1980. Uno de los
últimos Maestro I puede ser encontrado en el Museo de Tecnología e Informática en Arlington.
Uno de los primeros IDE con un concepto de plug-in fue Softbench. En 1995 Computerwoche
comentó que el uso de un IDE no era bien recibido por los programadores, ya que afectaría
su creatividad.
Programación visual:
La programación visual es un marco de usuario en la que generalmente se requiere una IDE.
Los IDE visuales le permiten a los usuarios crear nuevas aplicaciones de programación en
movimiento, bloques de construcción, o nodos de código para crear diagramas de flujo o
diagramas de estructura que luego son compilado o interpretado. Estos diagramas de flujo
muchas veces se basan en el lenguaje de modelado unificado.

11
Esta interfaz ha sido popularizada con los Lego Mindstorms, y se ha mantenido activa por un
número de compañías deseando capitalizar el poder de los buscadores personalizados como
los fundados en Mozilla. KTechlab apoya el flowcode y es un IDE de código abierto
(opensource) y un simulador para desarrollar software para micro-controladores.
La programación visual también es responsable del poder de la distribución de software
(LabVIEW y software EICASLAB). Un primitivo sistema visual de programación, Max, fue
modelado a partir de un sintetizador de diseño análogo siendo desarrollado para utilizar el
desempeño de la música en tiempo real desde los años 1980. Otro ejemplo primitivo fue
Prograph, un programa a base de flujo de datos, originalmente desarrollado para la
Macintosh. El ambiente de programación gráfica "Grape" es usado para programar qfix robot
kits.
Este acercamiento es también utilizado por software especializados, tales como Openlab,
donde el usuario final quiere la flexibilidad completa de un lenguaje de programación, sin la
tradicional curva de aprendizaje.
Soportes del lenguaje:
Algunos IDE soportan múltiples lenguajes, tales como GNU Emacs basados en C y Emacs Lisp,
y Eclipse, IntelliJ IDEA, MyEclipse o NetBeans, todos basados en Java, o MonoDevelop,
basados en C#.
Normalmente, el soporte para lenguajes alternativos regularmente es proveído por un plug-
in, permitiéndoles ser instalados en el mismo IDE, al mismo tiempo.4 Eclipse, y Netbeans tienen
plugins para C/C++, Ada, (por ejemplo AdaGIDE), Perl, Python, Ruby, y PHP, los cuales son
seleccionados entre extensión de archivos, ambientes o ajustes de proyectos.
CARACTERÍSTICAS:
Los IDE ofrecen un marco de trabajo amigable para la mayoría de los lenguajes de
programación tales como C++, Python, Java, C#, Delphi, Visual Basic, etc. En algunos
lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se
permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo
orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.
Es posible que un mismo IDE pueda funcionar con varios lenguajes de programación. Este es
el caso de Eclipse, al que mediante plugins se le puede añadir soporte de lenguajes
adicionales.
Un IDE debe tener las siguientes características:
 Multiplataforma
 Soporte para diversos lenguajes de programación
 Integración con Sistemas de Control de Versiones
 Reconocimiento de Sintaxis
 Extensiones y Componentes para el IDE
 Integración con Framework populares
 Depurador
 Importar y Exportar proyectos
 Múltiples idiomas
 Manual de Usuarios y Ayuda
Existen diferentes versiones de los IDEs pero estos son algunos del software que utilizan IDE,
estos son:

12
a) Eclipse: Software libre. Es uno de los entornos Java más utilizados a nivel profesional. El
paquete básico de Eclipse se puede expandir mediante la instalación de plugins para
añadir funcionalidades a medida que se vayan necesitando.
b) NetBeans: Software libre. Otro de los entornos Java muy utilizados, también expandible
mediante plugins. Facilita bastante el diseño gráfico asociado a aplicaciones Java.
c) BlueJ: Software libre. Es un entorno de desarrollo dirigido al aprendizaje de Java (entorno
académico) y sin uso a nivel profesional. Destaca por ser sencillo e incluir algunas
funcionalidades dirigidas a que las personas que estén aprendiendo tengan mayor
facilidad para comprender aspectos clave de la programación orientada a objetos.
d) JBuilder: Software comercial. Se pueden obtener versiones de prueba o versiones
simplificadas gratuitas en la web, buscando en la sección de productos y desarrollo de
aplicaciones. Permite desarrollos gráficos.
e) JCreator: Software comercial. Se pueden obtener versiones de prueba o versiones
simplificadas gratuitas en la web. Este IDE está escrito en C++ y omite herramientas para
desarrollos gráficos, lo cual lo hace más rápido y eficiente que otros IDEs.
COMPONENTES:
 Editor de texto.
 Compilador.
 Intérprete.
 Herramientas de automatización.
 Depurador.
 Posibilidad de ofrecer un sistema de control de versiones.
 Factibilidad para ayudar en la construcción de interfaces gráficas de usuarios.
VENTAJAS DE LOS IDEs:
 La curva de aprendizaje es muy baja.
 Es más ágil y óptimo para los usuarios que no son expertos en manejo de consola.
 Formateo de código.
 Funciones para renombrar variables, funciones.
 Warnings y errores de sintaxis en pantalla de algo que no va a funcionar al interpretar o
compilar.
 Poder crear proyectos para poder visualizar los archivos de manera gráfica.
 Herramientas de refactoring como por ejemplo seria extraer una porción de código a un
método nuevo.
 No es recomendado pero posee un navegador web interno por si queremos probar las
cosas dentro de la IDE.
De acuerdo a todo esto algunos IDEs no son gratuitos por el mismo motivo que el software son
utilizados para trabajos mejorados, por tal motivo en los IDEs podemos implementar líneas de
código donde podamos resolver algún problema con base al compilador, este es el que nos
permitirá modificar o corregir nuestros errores del programa.
Mi opinión acerca de los IDEs es que algunos de estos necesitan muchas aplicaciones para
poder sacar la aplicación y en otros es muy fácil utilizarlos porque al momento de escribir las
líneas de código te corrige tus problemas de la aplicación, de acuerdo a esto en mi punto
de vista el IDE que se pudiera implementar sería el de JCreator y Eclipse.

13
Algunos entornos son compatibles con múltiples lenguajes de programación, como Eclipse o
NetBeans, ambos basados en Java; o MonoDevelop, basado en C#. También puede
incorporarse la funcionalidad para lenguajes alternativos mediante el uso de plugins. Por
ejemplo, Eclipse y NetBeans tienen plugins para C, C++, Ada, Perl, Python, Ruby y PHP, entre
otros.
CAPTURA DEL IDE ECLIPSE
3. ESTANDARES DE PROGRAMACION Y BASE DE DATOS:
ESTANDARES DE PROGRAMACIÒN:
En Internet existe una gran cantidad de grupos de personas que se encargan de buscar la
mejor manera de hacer las cosas en todos los aspectos. Y si hablamos de los referentes a las
tecnologías de información podemos encontrarnos con muchos de ellos.
Uno de estos grupos es el Framework Interoperabiliy Group quienes tienen la tarea de hacer
una recopilación de los puntos en común de los proyectos en PHP y encontrar maneras de
trabajar en conjunto.
El FIG cuenta con una serie de recomendaciones las cuales hace llamar PSR o PHP Standar
Recomendation las cuales son elegidas basándose en votaciones realizadas por los miembros
del grupo y hasta la fecha cuentan con 4 PSR aceptadas y una que ha quedado obsoleta.
Descripción de las recomendaciones.
Las recomendaciones están divididas en un uso en específico.

14
 PSR-0 - Estándar de auto carga de clases (Obsoleta): Habla sobre la manera en la que
deberían cargarse las clases, este estándar ha quedado obsoleto pero se sigue
presentando por cuestiones de referencias hechas desde otros PSR's.
 PSR-1 - Codificación estándar básica: En su mayoría, este estándar hace referencia a los
archivos como tal, la nomenclatura de que deberían de tener, las etiquetas que deberían
de utilizar, el encoding del texto y los efectos secundarios que no deberían de presentar.
 PSR-2 - Guía de estilo de codificación: Extiende el estándar PSR-1 y contiene material
referente a la sintaxis del código.
 PSR-3 - Interfaz de log: Este estándar no se incluye (hasta el momento) en la
documentación y habla acerca de la manera en la que deberían de trabajar las clases
log.
 PSR-4 - Estándar de auto carga de clases (nueva versión): Esta es la nueva manera
(aceptada) de trabajar con la auto carga de clases. Muchos de los frameworks (p.e.
laravel) y clases que existen adoptan este estándar para realizar la auto carga de clases.
PSR-0 ESTÁNDAR DE AUTOCARGA DE CLASES
Obsoleto - A partir del 21/10/2014 el estándar PSR-0 se ha marcado como obsoleto. Ahora se
recomienda PSR-4 como alternativa.
A continuación se describen los requisitos obligatorios que deben cumplirse para la
interoperabilidad del autoloader.
Obligatorio:
 Un espacio de nombres y clase completamente cualificada debe tener la siguiente
estructura <Nombre del proveedor>(<Paquete>)*<Nombre de clase>.
 Cada espacio de nombres debe tener un espacio de nombres de nivel superior ("Nombre
del proveedor").
 Cada espacio de nombres puede tener tantos sub-espacios de nombres como sea
necesario.
 Cada separador de espacio de nombres se convierte en la constante
DIRECTORY_SEPARATOR cuando se carga desde el sistema de archivos. [^1]
 Cada carácter _ en el nombre de la clase se convierte en la constante
DIRECTORY_SEPARATOR. El carácter _ no tiene ningún significado especial en el espacio
de nombres.
 Al espacio de nombres y la clase completamente cualificada se le añade el sufijo .php
cuando se cargue desde el sistema de archivos.
 Los caracteres alfabéticos en los nombres de proveedor, espacios de nombres y nombres
de clase pueden contener cualquier combinación de mayúsculas y minúsculas.
Ejemplos:
 DoctrineCommonIsolatedClassLoader =>
/directorio/del/proyecto/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
 SymfonyCoreRequest =>
/directorio/del/proyecto/lib/vendor/Symfony/Core/Request.php
 ZendAcl => /directorio/del/proyecto/lib/vendor/Zend/Acl.php
 ZendMailMessage => /directorio/del/proyecto/lib/vendor/Zend/Mail/Message.php
Guiones bajos en Espacios de nombres y nombres de Clase:
 espacio_de_nombrespaqueteNombre_De_Clase =>
/directorio/del/proyecto/lib/proveedor/espacio_de_nombres/paquete/Nombre/De/Cla
se.php
 espacio_de_nombresnombre_de_paqueteNombre_De_Clase =>
/directorio/del/proyecto/lib/proveedor/espacio_de_nombres/nombre_de_paquete/No
mbre/De/Clase.php

15
El estándar aquí descrito, debe ser el mínimo común denominador para la interoperabilidad
del autoloader. Puede comprobar que sigue estas normas mediante la utilización de la
implementación de ejemplo de autoloader SplClassLoader, capaz de cargar clases de PHP
5.3.
Ejemplo de implementación:
A continuación, se muestra una función de ejemplo para demostrar de forma sencilla cómo
se cargan automáticamente las clases con la propuesta anterior:
<?php
function autoload($nombreDeClase)
{
$nombreDeClase = ltrim($nombreDeClase, '');
$nombreDeFichero = '';
$nombreDeEspacio = '';
if ($ultimaPos = strrpos($nombreDeClase, '')) {
$nombreDeEspacio = substr($nombreDeClase, 0, $ultimaPos);
$nombreDeClase = substr($nombreDeClase, $ultimaPos + 1);
$nombreDeFichero = str_replace('', DIRECTORY_SEPARATOR, $nombreDeEspacio) . DIRECTORY_SEPARATOR;
}
$nombreDeFichero .= str_replace('_', DIRECTORY_SEPARATOR, $nombreDeClase) . '.php';
require $nombreDeFichero;
}
PSR-1 CODIFICACIÓN ESTÁNDAR BÁSICA:
Esta sección de la norma comprende lo que debe considerarse la norma de codificación de
los elementos que se requieren para garantizar un alto nivel técnico de interoperabilidad
entre el código PHP.
Visión general:
 Los archivos DEBEN utilizar solamente las etiquetas <?php y <?=.
 Los archivos DEBEN emplear solamente la codificación UTF-8 sin BOM para el código PHP.
 Los archivos DEBERÍAN declarar cualquier estructura (clases, funciones, constantes, etc,...)
o realizar partes de la lógica de negocio (por ejemplo, generar una salida, cambio de
configuración ini, etc,...) pero NO DEBERÍAN hacer las dos cosas.
 Los espacios de nombres y las clases DEBEN cumplir el estándar PSR-0.
 Los nombres de las clases DEBEN declararse en notación StudlyCaps. [^1]
 Las constantes de las clases DEBEN declararse en mayúsculas con guiones bajos como
separadores CONSTANTE_DE_CLASE.
 Los nombres de los métodos DEBEN declararse en notación camelCase. [^2]
Archivos:
Etiquetas PHP:
El código PHP DEBE utilizar las etiquetas largas <?php ?> o las etiquetas cortas para imprimir
salida de información <?= ?>; NO DEBE emplear otras variantes.
Codificación de caracteres:
El código PHP DEBE utilizar codificación UTF-8 sin BOM.
Efectos secundarios:
Un archivo DEBERÍA declarar estructuras (clases, funciones, constantes, etc,...) y no causar
efectos secundarios, o DEBERÍA ejecutar partes de la lógica de negocio, pero NO DEBERÍA
hacer las dos cosas.

16
La frase "efectos secundarios" significa: que la ejecución de la lógica de negocio no está
directamente relacionado con declarar clases, funciones, constantes, etc, simplemente la de
incluir el archivo.
"Efectos secundarios" incluyen, pero no se limitan a: generar salidas, uso explícito de requiere
o include, conexiones a servicios externos, modificación de configuraciones iniciales, enviar
errores o excepciones, modificar variables globales o estáticas, leer o escribir un archivo, etc.
El siguiente ejemplo muestra un archivo que incluye las dos: declaraciones y efectos
secundarios; Un ejemplo de lo que debe evitar:
<?php
// efecto secundario: cambiar configuracion inicial
ini_set('error_reporting', E_ALL);
// efecto secundario: cargar ficheros
include "archivo.php";
// efecto secundario: generar salida
echo "<html>n";
// declaración
function foo()
{
// cuerpo de la función
}
El siguiente ejemplo es el de un archivo que contiene declaraciones sin efectos secundarios;
Un ejemplo que puede seguir:
Espacios de nombres y nombres de las Clases:
Los espacios de nombres y las clases DEBEN seguir el estándar PSR-0.
Esto significa que cada clase estará en un fichero independiente y está dentro de un espacio
de nombres en al menos un nivel: un nombre de proveedor de nivel superior.
Los nombres de las clases DEBEN declararse con notación StudlyCaps. [^1]
El código escrito para PHP 5.3 o superior DEBE hacer un uso formal de los espacios de nombres.
Por ejemplo:
<?php
// declaración
function foo()
{
}
// una declaración condicional *no* es un
// efecto secundario
if (! function_exists('bar')) {
function bar()
{
}
}
<?php
// PHP 5.3 o superior:
namespace ProveedorModelo;
class Foo
{
}

17
El código escrito para PHP 5.2.x o inferior DEBERÍA emplear una convención de pseudo-
espacios de nombres con prefijos en los nombres de las clases con el formato Proveedor_.
Constantes de Clases, Propiedades y Métodos:
El término "clases" hace referencia a todas las clases, interfaces y traits.
Constantes:
Las constantes de las clases DEBEN declararse siempre en mayúsculas y separadas por
guiones bajos. Por ejemplo:
Propiedades:
Esta guía evita intencionadamente cualquier recomendación respecto al uso de las
notaciones $StudlyCaps, $camelCase, o $guion_bajo en los nombres de las propiedades. [^1]
[^2]
Cualquiera que sea la convención en nomenclatura, DEBERÍA ser utilizada de forma
coherente con un alcance razonable. Este alcance PUEDE ser a nivel de proveedor, a nivel
de paquete, a nivel de clase o a nivel de método.
Métodos:
Los nombres de los métodos DEBEN declararse en notación camelCase(). [^2]
Notas:
[^1] StudlyCaps, es una forma de notación de texto que sigue el patrón de palabras en
minúscula sin espacios y con la primera letra de cada palabra en mayúscula.
[^2] camelCase, es una forma de notación de texto que sigue el patrón de palabras en
minúscula sin espacios y con la primera letra de cada palabra en mayúsculas exceptuando
la primera palabra.
PSR-2 GUÍA DE ESTILO DE CODIFICACIÓN
Esta guía amplía y extiende el estándar de codificación básica PSR-1.
La objetivo de esta guía es la de reducir la dificultad cuando se lee código de diferentes
autores. Lo realiza mediante la enumeración de una serie de reglas común y expresiones sobre
cómo dar formato al código PHP.
Visión general
 El código DEBE seguir el estándar PSR-1.
 El código DEBE usar 4 espacios como indentación, no tabuladores.
<?php
// PHP 5.2.x o inferior:
class Proveedor_Modelo_Foo
{
}
<?php
namespace ProveedorModelo;
class Foo
{
const VERSION = '1.0';
const FECHA_DE_APROBACION = '2012-06-01';
}

18
 NO DEBE haber un límite estricto en la longitud de la línea; el límite DEBE estar en 120
caracteres; las líneas DEBERÍAN tener 80 caracteres o menos.
 DEBE haber una línea en blanco después de la declaración del namespace, y DEBE haber
una línea en blanco después del bloque de declaraciones use.
 Las llaves de apertura de las clases DEBEN ir en la línea siguiente, y las llaves de cierre
DEBEN ir en la línea siguiente al cuerpo de la clase.
 Las llaves de apertura de los métodos DEBEN ir en la línea siguiente, y las llaves de cierre
DEBEN ir en la línea siguiente al cuerpo del método.
 La visibilidad DEBE estar declarada en todas las propiedades y métodos; abstract y final
DEBEN estar declaradas antes de la visibilidad; static DEBE estar declarada después de la
visibilidad.
 Las palabras clave de las estructuras de control DEBEN tener un espacio después de ellas,
las llamadas a los métodos y las funciones NO DEBEN tenerlo.
 Las llaves de apertura de las estructuras de control DEBEN estar en la misma línea, y las de
cierre DEBEN ir en la línea siguiente al cuerpo.
 Los paréntesis de apertura en las estructuras de control NO DEBEN tener un espacio
después de ellos, y los paréntesis de cierre NO DEBEN tener un espacio antes de ellos.
Ejemplo:
Este ejemplo incluye algunas de las siguientes reglas a modo de visión general rápida:
General:
Codificación estándar básica:
El código DEBE seguir las normas expuestas en el estándar PSR-1.
Archivos:
 Todos los archivos PHP DEBEN usar el final de línea Unix LF.
 Todos los archivos PHP DEBEN terminar con una línea en blanco.
 La etiqueta de cierre ?> DEBE ser omitida en los archivos que sólo contengan código PHP.
Líneas:
 NO DEBE haber un límite estricto en la longitud de la línea.
 El límite flexible de la línea DEBE estar en 120 caracteres; los correctores de estilo
automáticos DEBEN advertir de ésto, pero NO DEBEN producir errores.
<?php
namespace ProveedorPaquete;
use FooInterfaz;
use BarClase as Bar;
use OtroProveedorOtroPaqueteBazClase;
class Foo extends Bar implements FooInterfaz
{
public function funcionDeEjemplo($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClase::bar($arg2, $arg3);
}
}
final public static function bar()
{
// cuerpo del método
}
}

19
 Las líneas NO DEBERÍAN ser más largas de 80 caracteres; las líneas más largas de estos 80
caracteres DEBERÍAN dividirse en múltiples líneas de no más de 80 caracteres cada una.
 NO DEBE haber espacios en blanco al final de las líneas que no estén vacías.
 PUEDEN añadirse líneas en blanco para mejorar la lectura del código y para indicar
bloques de código que estén relacionados.
 NO DEBE haber más de una sentencia por línea.
Indentación:
El código DEBE usar una indentación de 4 espacios, y NO DEBE usar tabuladores para la
indentación.
Nota: Utilizar sólo los espacios, y no mezclar espacios con tabuladores, ayuda a evitar problemas con diffs,
parches, historiales y anotaciones. El uso de los espacios también facilita a ajustar la alineación entre
líneas.
Palabras clave y true/false/null.
 Las Palabras clave de PHP DEBEN estar en minúsculas.
 Las constantes de PHP true, false y null DEBEN estar en minúsculas.
Espacio de nombre y declaraciones use
 Cuando esté presente, DEBE haber una línea en blanco después de la declaración del
namespace.
 Cuando estén presentes, todas las declaraciones use DEBEN ir después de la declaración
del namespace.
 DEBE haber un use por declaración.
 DEBE haber una línea en blanco después del bloque de declaraciones use.
Por ejemplo:
Clases, propiedades y métodos:
El término "clase" hace referencia a todas las clases, interfaces o traits.
Extensiones e implementaciones:
Las palabras clave extends e implements DEBEN declararse en la misma línea del nombre de
la clase.
La llave de apertura de la clase DEBE ir en la línea siguiente; la llave de cierre DEBE ir en la
línea siguiente al cuerpo de la clase.
<?php
use FooClass;
// ... código PHP adicional ...
<?php
use FooClase;
class NombreDeClase extends ClasePadre implements ArrayAccess, Countable
{
// constantes, propiedades, métodos
}

20
La lista de implements PUEDE ser dividida en múltiples líneas, donde las líneas subsiguientes
serán indentadas una vez. Al hacerlo, el primer elemento de la lista DEBE estar en la línea
siguiente, y DEBE haber una sola interfaz por línea.
Propiedades:
 La visibilidad DEBE ser declarada en todas las propiedades.
 La palabra clave var NO DEBE ser usada para declarar una propiedad.
 NO DEBE declararse más de una propiedad por sentencia.
 Los nombres de las propiedades NO DEBERÍAN usar un guión bajo como prefijo para
indicar si son privadas o protegidas.
Una declaración de propiedades tendrá el siguiente aspecto.
Métodos:
 La visibilidad DEBE ser declarada en todos los métodos.
 Los nombres de los métodos NO DEBERÍAN usar un guión bajo como prefijo para indicar si
son privados o protegidos.
 Los nombres de métodos NO DEBEN estar declarados con un espacio después del nombre
del método. La llave de apertura DEBE situarse en su propia línea, y la llave de cierre DEBE
ir en la línea siguiente al cuerpo del método. NO DEBE haber ningún espacio después del
paréntesis de apertura, y NO DEBE haber ningún espacio antes del paréntesis de cierre.
La declaración de un método tendrá el siguiente aspecto. Fíjese en la situación de los
paréntesis, las comas, los espacios y las llaves:
Argumentos de los métodos:
En la lista de argumentos NO DEBE haber un espacio antes de cada coma y DEBE haber un
espacio después de cada coma.
<?php
use FooClase;
class NombreDeClase extends ClasePadre implements
ArrayAccess,
Countable,
Serializable
{
// constantes, propiedades, métodos
}
<?php
class NombreDeClase
{
public $foo = null;
}
<?php
class NombreDeClase
{
public function fooBarBaz($arg1, &$arg2, $arg3 = [])
{
}
}

21
Los argumentos con valores por defecto del método DEBEN ir al final de la lista de argumentos.
La lista de argumentos PUEDE dividirse en múltiples líneas, donde cada línea será indentada
una vez. Cuando se dividan de esta forma, el primer argumento DEBE estar en la línea
siguiente, y DEBE haber sólo un argumento por línea.
Cuando la lista de argumentos se divide en varias líneas, el paréntesis de cierre y la llave de
apertura DEBEN estar juntos en su propia línea separados por un espacio.
Abstract, final, y static
Cuando estén presentes las declaraciones abstract y final, DEBEN preceder a la declaración
de visibilidad.
Cuando esté presente la declaración static, DEBE ir después de la declaración de visibilidad.
Llamadas a métodos y funciones
Cuando se realice una llamada a un método o a una función, NO DEBE haber un espacio
entre el nombre del método o la función y el paréntesis de apertura, NO DEBE haber un
espacio después del paréntesis de apertura, y NO DEBE haber un espacio antes del paréntesis
de cierre. En la lista de argumentos, NO DEBE haber espacio antes de cada coma y DEBE
haber un espacio después de cada coma.
<?php
class NombreDeClase
{
public function foo($arg1, &$arg2, $arg3 = [])
{
}
}
<?php
class NombreDeClase
{
public function metodoConNombreLargo(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = []
) {
}
}
<?php
abstract class NombreDeClase
{
protected static $foo;
abstract protected function zim();
final public static function bar()
{
}
}
<?php
bar();
$foo->bar($arg1);
Foo::bar($arg2, $arg3);

22
La lista de argumentos PUEDE dividirse en múltiples líneas, donde cada una se indenta una
vez. Cuando esto suceda, el primer argumento DEBE estar en la línea siguiente, y DEBE haber
sólo un argumento por línea.
Estructuras de control
Las reglas de estilo para las estructuras de control son las siguientes:
 DEBE haber un espacio después de una palabra clave de estructura de control.
 NO DEBE haber espacios después del paréntesis de apertura.
 NO DEBE haber espacios antes del paréntesis de cierre.
 DEBE haber un espacio entre paréntesis de cierre y la llave de apertura.
 El cuerpo de la estructura de control DEBE estar indentado una vez.
 La llave de cierre DEBE estar en la línea siguiente al final del cuerpo.
El cuerpo de cada estructura DEBE estar encerrado entre llaves. Esto estandariza el aspecto
de las estructuras y reduce la probabilidad de añadir errores como nuevas líneas que se
añaden al cuerpo de la estructura.
if, elseif, else
Una estructura if tendrá el siguiente aspecto. Fíjese en el lugar de los paréntesis, los espacios y
las llaves; y que else y elseif están en la misma línea que las llaves de cierre del cuerpo anterior.
La palabra clave elseif DEBERÍA ser usada en lugar de else if de forma que todas las palabras
clave de la estructura estén compuestas por palabras de un solo término.
switch, case
Una estructura switch tendrá el siguiente aspecto. Fíjese en el lugar donde están los paréntesis,
los espacios y las llaves. La palabra clave case DEBE estar indentada una vez respecto al
switch y la palabra clave break o cualquier otra palabra clave de finalización DEBE estar
indentadas al mismo nivel que el cuerpo del case. DEBE haber un comentario como // no
break cuando hay case en cascada no vacío.
<?php
$foo->bar(
$argumentoLargo,
$argumentoMaslargo,
$argumentoTodaviaMasLargo
);
<?php
if ($expr1) {
// if cuerpo
} elseif ($expr2) {
// elseif cuerpo
} else {
// else cuerpo;
}
<?php
switch ($expr) {
case 0:
echo 'Primer case con break';
break;
case 1:
echo 'Segundo case sin break en cascada';
// no break
case 2:
case 3:
case 4:
echo 'Tercer case; con return en vez de break';
return;
default:
echo 'Case por defecto';
break;
}

23
while, do while
Una instrucción while tendrá el siguiente aspecto. Fíjese en el lugar donde están los paréntesis,
los espacios y las llaves.
Igualmente, una sentencia do while tendrá el siguiente aspecto. Fíjese en el lugar donde están
los paréntesis, los espacios y las llaves.
for
Una sentencia for tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los
paréntesis, los espacios y las llaves.
foreach
Un sentencia foreach tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los
try, catch
Un bloque try catch tendrá el siguiente aspecto. Fíjese en el lugar donde aparecen los
PSR-4 ESTÁNDAR DE AUTOCARGA DE CLASES
Visión general:
Este PSR describe una especificación para la autocarga de clases desde rutas de archivos. Es
completamente interoperable, y se puede utilizar en conjunto con cualquier otra
especificación de autocarga, incluyendo PSR-0. Además, este PSR describe donde colocar
los archivos que serán autocargados de acuerdo a la especificación.
Especificación:
 El término "clase" se refiere a clases, interfaces, traits, y otras estructuras similares.
<?php
while ($expr) {
// cuerpo de la estructura
}
<?php
do {
// cuerpo de la estructura;
} while ($expr);
<?php
for ($i = 0; $i < 10; $i++) {
// cuerpo del for
}
<?php
foreach ($iterable as $key => $value) {
// cuerpo foreach
}
<?php
try {
// cuerpo del try
} catch (PrimerTipoDeExcepcion $e) {
// cuerpo catch
} catch (OtroTipoDeExcepcion $e) {
// cuerpo catch
}

24
 Un nombre completo de clase tiene la siguiente forma:
- El nombre completo de clase DEBE tener un espacio de nombre inicial también
conocido como "vendor namespace".
- El nombre completo de clase PUEDE tener uno o mas sub-espacios de nombres.
- El nombre completo de clase DEBE terminar con un nombre de clase.
- Los guiones bajos no tienen significado especial en ningúna parte del nombre
completo de clase.
- Los caracteres alfabéticos en el nombre completo de clase PUEDEN ser cualquier
combinación de minusculas y mayusculas.
- Todas los nombres de clases DEBEN ser hacer referencia distinguiendo minusculas y
mayusculas.
 Cuando se cargue un archivo que corresponda a un nombre completo de clase.
- Una serie continua de uno o más nombres de espacio iniciales y subsecuentes, sin
incluir el separador del espacio de nombres, el nombre completo de clase (un "prefijo
de espacio de nombres") corresponde al menos a un "directorio base".
- Una serie continua de sub-espacios de nombre después del "prefijo del espacio de
nombres" corresponde a un subdirectorio con un "directorio base", en el cual los
separadores del espacio de nombres representan los separadores del directorio. El
nombre del sub-directorio DEBE coincidir con los nombres de los sub-espacios de
nombres.
- El nombre de clase corresponde al nombre del archivo terminando en '.php'. El
nombre del archivo DEBE coincidir con el nombre de la clase en terminación.
 La implementación de la autogarga NO DEBE lanzar excepciones, NO DEBE lanzar errores
de ningún nivel, y NO DEBERIA retornar un valor.
Ejemplos:
La siguiente tabla muestra la ruta de archivo correspondiente para cada nombre completo
de clase, prefijo de espacios de nombres, y directorios base.
Nombre completo de
clase
Prefijo de
espacios de
nombres
Directorio base Ruta de archivo resultante
AcmeLogWriterFile_Writer AcmeLogWriter ./acme-log-writer/lib/ ./acme-log-writer/lib/File_Writer.php
AuraWebResponseStatus AuraWeb /path/to/aura-web/src/ /path/to/aura-
web/src/Response/Status.php
SymfonyCoreRequest SymfonyCore ./vendor/Symfony/Core/ ./vendor/Symfony/Core/Request.php
ZendAcl Zend /usr/includes/Zend/ /usr/includes/Zend/Acl.php
<NombreDelEspacioDeNombres>(<SubNombreDelEspacioDeNombres>)*<NombreDeClase>

25
BASE DE DATOS
Definición:
Una base de datos (cuya abreviatura es BD)
es una entidad en la cual se pueden
almacenar datos de manera estructurada,
con la menor redundancia posible. Diferentes
programas y diferentes usuarios deben poder
utilizar estos datos. Por lo tanto, el concepto
de base de datos generalmente está
relacionado con el de red, ya que se debe
poder compartir esta información.
Generalmente se habla de un "Sistema de
información" para designar a la estructura
global que incluye todos los mecanismos para
compartir datos.
¿Por qué utilizar una base de datos?
Una base de datos proporciona a los usuarios el acceso a datos, que pueden visualizar,
ingresar o actualizar, en concordancia con los derechos de acceso que se les hayan
otorgado. Se convierte más útil a medida que la cantidad de datos almacenados crece.
Una base de datos puede ser local, es decir que puede utilizarla solo un usuario en un equipo,
o puede ser distribuida, es decir que la información se almacena en equipos remotos y se
puede acceder a ella a través de una red.
La principal ventaja de utilizar bases de datos es que múltiples usuarios pueden acceder a
ellas al mismo tiempo.
Administración de bases de datos:
Rápidamente surgió la necesidad de contar con un sistema de administración para controlar
tanto los datos como los usuarios. La administración de bases de datos se realiza con un
Sistema de Gestión de Bases de Datos (SGBD) también llamado DBMS (Database
Management System). El DBMS es un conjunto de servicios (aplicaciones de software) que
permite a los distintos usuarios un fácil acceso a la información y proporciona las herramientas
para la manipulación de los datos encontrados en la base (insertar, eliminar, editar).
El DBMS puede dividirse en tres subsistemas: el sistema de administración de archivos, cuya
función es almacenar la información en un medio físico; el DBMS interno, que sirve para ubicar
la información en orden; y el DBMS externo, que representa a la interfaz de usuario.

SOLUCIONES INFORMATICAS INGENIERIA INFORMATICA Y DE SISTEMAS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Similar a SOLUCIONES INFORMATICAS INGENIERIA INFORMATICA Y DE SISTEMAS

Similar a SOLUCIONES INFORMATICAS INGENIERIA INFORMATICA Y DE SISTEMAS (20)

Último

Último (20)

SOLUCIONES INFORMATICAS INGENIERIA INFORMATICA Y DE SISTEMAS