Desarrollo de un Sistema Informático para la Administración de Expedientes de la Universidad José

  1. Resumen
  2. Introducción
  3. Generalidades
  4. Fundamento teórico
  5. Material y método utilizado en las prácticas pre - profesionales
  6. Resultados de la práctica realizada
  7. Conclusiones y recomendaciones
  8. Bibliografía

RESUMEN

El presente informe de prácticas se desarrollo dentro de la oficina de Servicios Académicos Evaluación y Registro Central (OSAERC) de la Universidad José Carlos Mariátegui.

Se realizaron estudios de las principales actividades y procesos administrativos y

se pudo apreciar que el área de Archivo de Expedientes que se encuentra a cargo de la OSAERC no es controlada a través de un sistema Informático.

Debido a esto, se pretende mejorar la administración de los expedientes dentro del área de Archivo de expedientes a través de un sistema informático usando Tecnologías web.

Se desarrollo el sistema informático de control Evaluación y seguimiento de los expedientes de cada alumno de la UJCM, que es capaz de administrar la información contenida en cada expediente y controlar los movimientos de este dentro de la UJCM.

Este Sistema presenta alternativas de expansión pudiendo funcionar desde internet y tener el control a , debido a que se desarrollo usando tecnologías web.

INTRODUCCIÓN

La Universidad José Carlos Mariátegui tiene varios programas de Educación, entre ellos tenemos, Educación a Distancia, Educación Presencial, Educación para Adultos, Auxiliares de Educación entre otros. Para administrar todos los expedientes de todos los alumnos de cada programa antes mencionados se hace complicado saber que contiene, por lo cual se hacen más lento los trámites que tienen que ver con documentos de los expedientes.

El sistema de control manual que se tiene en la actualidad hace que los expedientes hace difícil la búsqueda debido a que diariamente se adjuntan documentos y se mueven expedientes para algunos trámites como convalidaciones entre otros.

En el presente Informe, se plantea el desarrollo de un sistema informático usando tecnologías web para el área de Archivo de Expedientes de la Universidad José Carlos Mariátegui y obtener un sistema Óptimo.

Este informe comienza con la presentación de la Universidad José Carlos Mariátegui en la cual realicé la práctica pre profesional. En este se incluye toda la información necesaria y requerida para la identificación de la Universidad, como su organización, funciones, objetivos, entre otros.

Cada uno de los capítulos aporta información relevante para lograr el objetivo Propuesto y que a su vez reflejan los conocimientos y vivencias que se fueron dando. Los que proporcionaron la experiencia suficiente para concluir en una aplicación final.

El capítulo I habla de la organización de la Universidad, funciones, ubicación y objetivos de la práctica.

En el capítulo II se le dedica al Marco Teórico, donde se realizan estudios de las metodologías orientadas diseño de sistemas con tecnología web, inicialmente se describen algunos conceptos.

En el capítulo III comprende el material y método utilizado donde se especifican métodos, técnicas que se utilizaron para el desarrollo del informe.

En el Capítulo IV están los resultados, se mencionan las ventajas obtenidas con

el desarrollo del sistema informático propuesto en el presente informe.

Por último, encontramos las conclusiones y sugerencias a las que se arribó en el

desarrollo del informe de prácticas.

En el Capitulo V encontramos las conclusiones y sugerencias a las que se arribó en el desarrollo del informe de prácticas.

GENERALIDADES

  • DE LA INSTITUCIÓN[1]

RAZÓN SOCIAL DE LA INSTITUCIÓN.

Universidad José Carlos Mariátegui.

DESCRIPCIÓN DE LA INSTITUCIÓN.

Fue creada como UNIVERSIDAD PRIVADA DE MOQUEGUA por ley Nº 25153 del 23 de diciembre de 1989 con las carreras profesionales: Ingeniería de Minas, Ingeniería Mecánica, Ingeniería Civil, Ingeniería Ambiental, Ingeniería Pesquera e Ingeniería Agroindustrial.Desde su inicio fue su sede principal en el distrito de Moquegua, provincia de Mariscal Nieto, departamento de Moquegua, donde figura como persona jurídica sin fines de lucro y empezó a brindar su servicio educativo el 15 de abril de 1991. Desde esa fecha se ha convertido por méritos propios en una progresista ventana hacia el desarrolla integral de todos aquellos que son conscientes que para cumplir su sol para con la sociedad, la mejor forma es a través de una eficiente profesionalización, por la cual se ha convertido en una firme esperanza de consolidación de metas de grandeza espiritual y calidad humana.

En el Puerto Industrial de Ilo, en el año 1996 empezaron sus actividades académicas con tres carreras profesionales: Ingeniería Mecánica, Derecho y Contabilidad.


El 03 de abril del 2001 La Comisión Organizadora presidida por el Doctor Miguel Fuentes Chávez y la presidían el Doctor Juan Rodríguez Pantigoso como Vicepresidente Administrativo y el Licenciado Ramón Vera Robalcaba como Vice presidente Académico, asumieron con entrega y convicción el gran compromiso, frente a la plana docente, la familia estudiantil y el pueblo en conjunto de institucionalizar la universidad, la misma que se hizo efectiva en un lapso de 13 meses. Por eso el 28 de mayo del 2002 se consiguió el gran sueño de su institucionalización mediante resolución Nº 389-2002-ANR y como fruto de esta resolución el 13 de noviembre del 2002 se promulgó el primer estatuto de la Universidad y posteriormente el 30 de diciembre del mismo año, fueron elegidos el Rector y Vicerrector en un ambiente democrático y en estricto cumplimiento de la ley universitaria y del mencionado estatuto, actos que garantizan la autonomía y credibilidad de la Universidad Privada de Moquegua "José Carlos Mariátegui".

Desde aquella memorable fecha, figura en su historial institucional como autoridades de la Universidad Privada de Moquegua "José Carlos Mariátegui", su primer Rector Magister Alberto Coayla Vilca y Vicerrector Dr. Javier Flores Arocutipa, quienes por su experiencia y capacidad en estas lides, se han convertido en auténticos líderes de avanzada al poner en práctica todo un conjunto de procesos del sistema de educación superior universitaria, con lo que asegura que egresen de sus aulas, profesionales de excelente calidad, competitivos en cualquier latitud regional nacional y del exterior.

Actualmente, nuestra Universidad oferta trece carreras profesionales y son las siguientes:

  • Ingeniería Comercial

  • Ingeniería Agroindustrial

  • Ingeniería Agronómica

  • Ingeniería Civil

  • Ingeniería Mecánica Eléctrica

  • Ingeniería de Sistemas e Informática

  • Ingeniería Ambiental

  • Obstetricia

  • Contabilidad

  • Odontología

  • Derecho

  • Educación Primaria

  • Educación Inicial

  • Filosofía

  • Enfermería.

La Universidad se dedica plenamente a la Investigación Científica, al estudio constante, la educación superior integral, a la formación académico profesional y a la difusión de la cultura, el arte desde una óptica tecnológica. Con miras a constituirse en una de las mejores universidades peruanas, viene ampliando su infraestructura tanto en Moquegua como en la sede Ilo, se viene equipando con tecnología de punta, ofrece Diplomados, Segundas Especialidades. Pro Títulos, Centro Pre Universitario, Centro de Computo y Sistemas y de Idiomas Escuela de Post Grado con Maestrías y Doctorados, campos deportivos, y en cuanto a carreras a Distancia, lidera en el Sur Peruano y además tiene alumnos en los departamentos de Ica y Lima, Tacna, Arequipa, Puno, Juliaca, etc.

De esta manera la Universidad José Carlos Mariátegui de Moquegua, recibe sus diecisiete años de vida institucional, lleno de optimismo, convertido en una cristalina fuente de profesionalización para la juventud estudiosa que mira el horizonte lleno de esperanzas en vista que se les forma con calidad humana, capaces de realizar las más grandes hazañas de realización personal.

ACTIVIDADES DE LA INSTITUCIÓN

La Universidad es una Institución con personería jurídica de derecho privado sin fines de lucro, que se rige de conformidad con la Constitución Política del Estado, la Ley Universitaria, el presente Estatuto y sus Reglamentos, con autonomía académica, económica, normativa y administrativa, integrada por profesores, estudiantes y graduados.

MISIÓN Y VISIÓN[2]

  • MISIÓN

  • Alcanzar una formación profesional excelente.

  • Realizar una investigación exhaustiva de la realidad nacional, en toda su extensión, incluyendo parte de América del Sur.

  • Guiar la proyección Social de la Universidad por los requerimientos de la realidad nacional menos atendidos; los otros serán cubiertos por una esmerada atención del uso, desarrollo y fomento de aquellas riquezas y recursos naturales que no son suficientemente estudiados y programados para beneficiar a los pueblos del Perú.

  • Convertir los principios metodológicos, científicos y filosóficos que sustentan la misión de la Universidad, en el pensamiento dominante de los profesores, alumnos y egresados. Por esta vía se guiará permanentemente todo el proceso de la misión Institucional de la Universidad.

  • VISIÓN

  • Formar hombres buenos y sabios que respondan con eficiencia y efectividad a las innovaciones que se desarrollen en nuestro país, proyectándose al III milenio y postulando un nuevo enfoque profesional que valore el espíritu humano y a una sociedad moderna que está cambiando en función de los avances de la ciencia y tecnología.

  • Sustentar su acción en el principio de democracia, dispuesta a brindar el derecho al hombre peruano de educarse, capacitarse y profesionalizarse, sin discriminaciones, suministrando información teórica práctica y la formación de valores.

  • Practicar la libertad de conciencia, pensamiento, ciencia, opinión, reunión, derecho a la participación de todos los estamentos que conforman el todo integral de la Universidad José Carlos Mariátegui.

  • El principio de educación como camino a la formación de personal y social se expresa en perfiles profesionales, objetivos de fundamentación y compromiso de la Universidad para que futuros profesionales participen responsablemente en la vida civil y política del país.

  • La Universidad José Carlos Mariátegui cumple su misión en la formación de profesionales, que incluye la personalidad humana, el fortalecimiento, respeto a los derechos humanos y a la libertad, con una nueva visión del futuro y de alternativas de trabajo, debiendo a tales efectos lograr las dimensiones básicas del saber.

  • Realizar una investigación exhaustiva de la realidad nacional, en toda su extensión, incluyendo parte de América del Sur.

  • Guiar la proyección Social de la Universidad por los requerimientos de la realidad nacional menos atendidos; los otros serán cubiertos por una esmerada atención del uso, desarrollo y fomento de aquellas riquezas y recursos naturales que no son suficientemente estudiados y programados para beneficiar a los pueblos del Perú.

  • Convertir los principios metodológicos, científicos y filosóficos que sustentan la misión de la Universidad, en el pensamiento dominante de los profesores, alumnos y egresados. Por esta vía se guiara permanentemente todo el proceso de la misión Institucional de la Universidad.

VISIÓN DE FUTURO 2014

UJCM Motor Del Desarrollo Regional Forjando Los Mejores Profesionales Del Sur Peruano, Liderando La Revolución Del Conocimiento Con Docentes Comprometidos, Infraestructura Y Tecnología De Punta.

NATURALEZA Y JURISDICCIÓN[3]

La Universidad Privada de Moquegua José Carlos Mariátegui es persona jurídica de derecho privado sin fines de lucro; dedicada al Estudio, la Investigación, la Educación Superior, la Formación Académico-Profesional, la Difusión del Saber y la Cultura y a la Extensión y Proyección Universitaria; así como a la Producción de Bienes y Prestación de Servicios; propiciando el desarrollo y el bienestar de la comunidad regional y nacional.

La Universidad es autónoma, en lo académico, económico, normativo y administrativo; dentro de la Constitución y las Leyes vigentes.

FINALIDAD[4]

La Finalidad de la Universidad José Carlos Mariátegui es:

  • Acrecentar y transmitir la cultura universal, con sentido crítico creativo, afirmando preferentemente los valores regionales y nacionales.

  • Realizar investigación científica, en humanidades, ciencia, tecnología y fomentar la creación intelectual y artística.

  • Formar humanistas, científicos y profesionales de alta calidad académica, para cubrir las necesidades de la región y del país, desarrollando en la comunidad universitaria, los valores éticos y cívicos, la actitud de responsabilidad, puntualidad, solidaridad social y el conocimiento la realidad regional nacional.

  • Desarrollar la ciencia crítica y auto crítica, el espíritu solidario y la sensibilidad, para promover la transformación de la sociedad peruana.

  • Promover la Capacitación y perfeccionamiento de los docentes graduados, trabajadores administrativos y de servicios, para alcanzar la calidad total en la formación profesional.

OBJETIVOS

Los Objetivos de la Universidad José Carlos Mariátegui son:

  • Conservar, acrecentar y transmitir la cultura Universal con sentido crítico y creativo afirmando preferentemente los valores nacionales.

  • Formar Profesionales e Investigadores de alto nivel humanístico, científico y tecnológico, acorde con las necesidades locales, regionales y nacionales.

  • Impulsar y realizar Investigación Científica en los campos del saber de las humanidades, la ciencia y la tecnología.

  • Extender y proyectar la acción académica y cultural hacia la comunidad en general, mediante la capacitación, entrenamiento y desarrollo de certámenes académicos y culturales.

  • Impulsar la implementación de servicios y programas de bienestar que contribuyan al mejor rendimiento académico de los estudiantes.

  • Propiciar y generar Centros de Producción y Prestación de Servicios a fin de generar recursos para la Institución.

  • Mejorar gradualmente la infraestructura y el equipamiento de cada una de las Facultades, Carreras Profesionales y dependencias administrativas de nuestra Institución.

  • UBICACIÓN.

La Universidad José Carlos Mariátegui, se encuentra ubicada en la Calle Ayacucho Nº 393 de la Ciudad de Moquegua.

  • Dirección : Calle Ayacucho Nº 393

  • Distrito : Moquegua

  • Provincia : Mariscal Nieto

  • Región : Moquegua.

Tiene dos Campus Universitarios en Moquegua

  • Campus Universitario "La Villa"

Dirección: Av. 25 de Noviembre S/N

El Campus la Villa en el que se desarrollan las carreras

pertenecientes a la Facultad de Ciencias Jurídicas.

  • Campus Universitario San Antonio

También llamada Ciudad Universitaria

Dirección: Centro Poblado Menor San Antonio S/N

El Campus San Antonio en el que se desarrollan las carreras

Profesionales pertenecientes a las Facultades de Ingeniería

Ciencias Biomédicas, así como la Escuela de Postgrado.

  • Campus Universitario Ilo

Dirección: Pampa Inalámbrica S/N

Tiene un campus Universitario en la Ciudad de Ilo – Sede Ilo,

el cual está ubicado en la Pampa inalámbrica de la misma

Ciudad.

  • ORGANIZACIÓN DE LA INSTITUCIÓN[5]

La estructura orgánica de la Universidad, está definida en función directa a sus fines, objetivos y funciones generales; en concordancia con la Ley Universitaria 23733, Ley de Creación de nuestra Universidad 25153 y Estatutos, La Estructura Orgánica de la Universidad José Carlos Mariátegui, es la siguiente:

Monografias.com

Fig. I.1: Organigrama de la UJCM

Fuente: UJCM

NOMBRE DEL ÁREA DE TRABAJO.

OSAERC – Oficina de Servicios Académicos Evaluación y Registro Central.

DESCRIPCIÓN DEL ÁREA DE TRABAJO.

La Oficina de Servicios Académicos se encarga de la correcta administración del historial académico de los alumnos de la Universidad José Carlos Mariátegui.

OBJETIVOS OFICINA OSAERC.

  • Elaborar y distribuir a los docentes, los respectivos Registros de Evaluación de las asignaturas, según las matriculas de los estudiantes en el correspondiente Plan de Estudios de la carrera profesional y de acuerdo al Cronograma Académico del Semestre.

  • Preparación y entrega a los docentes, de los respectivos listines de Notas, así como de las actas finales de cada asignatura por semestre, según lo normado en el presente reglamento.

  • Al finalizar cada semestre académico, se encargara de preparar y hacer entregara de preparar y hacer entrega a los estudiantes de su respectiva boleta de notas.

  • Compendiar y encargarse de su custodia de los diferentes tipos de actas de Evaluación de cada una de las carreras profesionales, una vez firmadas, según los respectivos Planes de estudio, en forma semestral.

  • Preparar el cuadro de meritos o ranking parcial o total de una determinada carrera profesional para ser emitida a través del Decanato.

  • Procesar los certificados de Estudios en conformidad con las Actas existentes y en estricto acatamiento a las calificaciones contenidas en las mismas.

  • DE LA PRACTICA PROFESIONAL

INFORMACIÓN PERSONAL

Apellidos y Nombres : MAMANI POMA JIMMY ORLANDO

Código Universitario : 0018011

DNI : 42082421

Dirección : Calle Miraflores I - 17

Teléfono : 953 948680

Email : new_word2001@hotmail.com

Carrera profesional : Ingeniería de Sistemas e Informática

PERIODO DE LA PRACTICA PRE – PROFESIONAL

La práctica pre-profesional fue desarrollada en la Oficina Servicios Académicos, Evaluación y Registro Central de la Universidad José Carlos Mariátegui, encargada del área de Control Académico, desde el 01 de Agosto del 2006 al 10 de Agosto del 2007, tal como consta en el certificado emitido por el Área de Personal, que se adjunta en el Anexo 01.

La práctica pre-profesional estuvo bajo la supervisión del Ing. Nilton Zeballos Hurtado, Jefe de Oficina, responsable de mi permanencia en dicha institución por el periodo indicado en el punto anterior.

  • OBJETIVOS DE LA PRÁCTICA.

OBJETIVO GENERAL.

Desarrollar un Sistema Informático para gestionar los expedientes en la OSAERC de la Universidad José Carlos Mariátegui.

OBJETIVOS ESPECIFICOS.

  • a) Analizar los principales procesos y actividades del área de archivo de expedientes, para minimizar tiempos en los trámites.

  • b) Diseño del sistema informático utilizando la Metodología OOHDM para la elaboración del sistema web.

  • c) Utilizar AppServ 2.5.9. para desarrollar el sistema y administrar la base de datos.

  • d) Implementar un prototipo del sistema web utilizando el lenguaje de programación php.

  • ESTADO ACTUAL

La Universidad José Carlos Mariátegui, Oficina de Servicios Académicos, Evaluación y Registro Central no cuenta con un sistema automatizado de Control de Archivos.

PROPUESTA Y JUSTIFICACIÓN

La Universidad José Carlos Mariátegui, se dedica al estudio, la investigación, el desarrollo, la formación profesional y la difusión de la cultura, por lo tanto el Desarrollar un Sistema de Control de Archivos para la oficina de de Servicios Académicos, Evaluación y Registro Central, como resultado de una investigación y desarrollo, permitirá que el personal administrativo y otros puedan obtener un mejor servicio y seguridad acerca de los archivos y expedientes académicos de la Institución.

El crecimiento de institucional obliga la implementación de nuevos sistemas que agilicen los diversos procesos que se llevan a cabo dentro de nuestra universidad.

La automatización del control de archivos y así diversos procesos administrativos, se viene realizando en varias Universidades nacionales y privadas del Perú. Logrando una mejora institucional notable.

El Sistema de Información que se propone, mantendrá un control eficiente sobre el monitoreo de los archivos y expedientes de la universidad y así, apoyar a los diferentes procesos de gestión y una búsqueda del bienestar y mejor servicio brindado a la comunidad Universitaria.

La información podrá ser vista en tiempo real, de acuerdo a la competencia del personal y a la confidencialidad de la información.

Se tendrá la información necesaria en corto tiempo lo que permitirá el ahorro de tiempo así como la impresión de reportes según sean requeridos por los órganos jerárquicos autorizados.

Reducirá la carga documental de archivos físicos. Y generara reportes importantes para la toma de decisiones a Nivel Gerencial.

CAPÍTULO II

FUNDAMENTO TEÓRICO

2.1. MARCO TEÓRICO.

2.1.1. Normativa de Trabajo.

Reglamento de Admisión.

Art.14 La inscripción es personal o por autorización expresa, previa identificación del postulante con su documento de ley (original), debiendo presentar el expediente completo en las fechas y lugares señalados. En ningún caso el postulante presentara dos carpetas (expedientes).

Art. 15 Para inscribirse al examen de admisión ordinario, deberá identificarse presentando el original de su documento de identidad personal, entregando a la persona encargada de la inscripción para aperturar la carpeta de postulante lo siguiente:

  • Solicitud de inscripción al concurso de admisión

  • Partida de nacimiento original

  • Presentar un documento de identidad original y una copia legalizada según sea el caso, siempre y cuando sea mayor de edad (DNI o libreta electoral, libreta militar, boleta de inscripción, etc.)

Para Iniciar este proyecto se requiere de conceptos básicos, para la toma de decisiones con respecto al sistema a desarrollar, el nuevo sistema servirá básicamente para agilizar trámites académicos de la Universidad.

Cada Alumno de esta universidad tiene un expediente dentro del cual se guardan sus documentos, cada expediente es un "Conjunto de datos que dentro de contexto significativo y útil, ésta se comunica a un receptor, quien la utiliza para tomar decisiones" [6]

Todos estos datos requieren ser ordenados para poder tener información útil para todos los que son parte de esta Área. La Información la componen datos que se han colocado en un contexto significativo y útil y se ha comunicado a un receptor, quien la utiliza para tomar decisiones. La información implica la comunicación y recepción de inteligencia o conocimiento. Evalúa y notifica y estimula, reduce incertidumbre revela alternativas adicionales o ayuda a eliminar las irrelevantes o pobres, e influye sobre otros individuos y los estimula a la acción.[7]

Sistema

Es un Conjunto de componentes que interactúan entre sí para lograr un objetivo común. Nuestra sociedad está rodeada de sistemas como por ejemplo las personas se comunican con el lenguaje, que es un sistema muy desarrollado formado por palabras y símbolos que tienen significado para el que habla y para quienes lo escuchan. [8]

2.2.1. Elementos de Sistema [9]

Son elementos estructurales de un sistema:

  • Elementos: Son los componentes fundamentales del sistema. Un elemento es la representación simplificada de alguna característica de la realidad objeto de estudio.

  • Relaciones entre elementos o redes de comunicación: Los elementos o componentes están interrelacionados. En un sistema no se retienen todas las interacciones entre todos los elementos, sino las más significativas para los fines concretos con que esté laborando el sistema. Las redes de comunicación pueden tener un soporte físico o ser redes o conexiones mentales o abstractas.

  • Límites: Un sistema puede tener límites precisos o una zona llamada interfaz, que lo separa del entorno circundante o de otros sistemas, de tal manera que, sin ambigüedad, se sepa si un determinado elemento o red pertenece o no al sistema.

  • El entorno del sistema: aquello que lo rodea, dentro del cual está ubicado.

Las Elementos funcionales de los sistemas son las siguientes:

  • Flujos: Ya sea de materiales, información o energía que circulan entre variables de estado. Esta circulación se hace a través de las redes de comunicación y cuenta con dispositivos: válvulas o grifos que controlan los diversos flujos.

  • Redes de retroalimentación: cadenas de causalidad o influencias circulares entre elementos.

  • Tecnologías Web

Para el desarrollo del Sistema Informático se aplicó las siguientes tecnologías.

Monografias.com Tabla: 2.1 Tecnologias Web - Fuente: Propia

2.3 PHP[10]

PHP es un ampliamente utilizado para fines generales lenguaje de scripting que es especialmente adecuado para el desarrollo Web y puede ser incrustado en HTML.

PHP es un lenguaje de programación interpretado usado normalmente para la creación de páginas web dinámicas. PHP es un acrónimo recursivo que significa "PHP Hypertext Pre-processor" (inicialmente PHP Tools, o, Personal Home Page Tools). Actualmente también se puede utilizar para la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.

Monografias.com

Tabla: 2.2 Php caracteristicas - Fuente: Propia

2.3.1. VISIÓN GENERAL[11]

El gran parecido que posee PHP con los lenguajes más comunes de programación estructurada, como C y Perl, permiten a la mayoría de los programadores crear aplicaciones complejas con una curva de aprendizaje muy corta. También les permite involucrarse con aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones.

Aunque todo en su diseño está orientado a facilitar la creación de página web, es posible crear aplicaciones con una interfaz gráfica para el usuario, utilizando la extensión PHP-Qt o PHP-GTK. También puede ser usado desde la línea de órdenes, de la misma manera como Perl o Python pueden hacerlo, a esta versión de PHP se la llama PHP CLI (Command Line Interface).

Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por el intérprete al servidor, que a su vez se lo envía al cliente. Mediante extensiones es también posible la generación de archivos PDF, Flash, así como imágenes en diferentes formatos.

Permite la conexión a diferentes tipos de servidores de bases de datos tales como MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite.

PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos, tales como UNIX (y de ese tipo, como Linux o Mac OS X) y Windows, y puede interactuar con los servidores de web más populares ya que existe en versión CGI, módulo para Apache, e ISAPI.

PHP es una alternativa a las tecnologías de Microsoft ASP y ASP.NET (que utiliza C#/VB.NET como lenguajes), a ColdFusion de la compañía Adobe (antes Macromedia), a JSP/Java de Sun Microsystems, y a CGI/Perl. Aunque su creación y desarrollo se da en el ámbito de los sistemas libres, bajo la licencia GNU, existe además un IDE (entorno de desarrollo integrado) comercial llamado Zend Studio. Recientemente, CodeGear (la división de lenguajes de programación de Borland) ha sacado al mercado un entorno integrado de desarrollo para PHP, denominado Delphi for PHP, Existe un módulo para Eclipse uno de los IDE más populares.

2.3.2. HISTORIA[12]

PHP fue originalmente diseñado en Perl, seguidos por la escritura de un grupo de CGI binarios escritos en el lenguaje C por el programador danés-canadiense Rasmus Lerdorf en el año 1994 para mostrar su currículum vitae y guardar ciertos datos, como la cantidad de tráfico que su página web recibía. El 8 de junio de 1995 fue publicado "Personal Home Page Tools" después de que Lerdorf lo combinara con su propio Form Interpreter para crear PHP/FI.

Versión

Fecha

Cambios más importantes

PHP 1.0

8 de Junio de 1995

Oficialmente llamado "Herramientas personales de trabajo (PHP Tools)". Es el primer uso del nombre "PHP".

PHP Version 2 (PHP/FI)

16 de Abril de 1996

Considerado por el creador como la "más rapida y simple herramienta" para la creación de páginas webs dinámicas .

PHP 3.0

6 de Junio de 1998

Desarrollo movido de una persona a muchos desarrolladores. Zeev Suraski y Andi Gutmans reescriben la base para esta versión.

PHP 4.0

22 de Mayo de 2000

Se agregan avanzadas de dos etapas analizar/ejecutar la etiqueta-análisis sistema llamado entorno motor Zend.

PHP 4.1

10 de Diciembre de 2001

Introducidas las variables superglobals ($_GET, $_SESSION, etc.)

PHP 4.2

22 de Abril de 2002

Se deshabilitan register_globals por defecto

PHP 4.3

27 de Diciembre de 2002

Introducido la CLI, en adición a la CGI

PHP 4.4

11 de Julio de 2005

PHP 5.0

13 de Julio de 2004

Motor Zend II con un nuevo modelo de objetos.

PHP 5.1

25 de Noviembre de 2005

PHP 5.2

2 de Noviembre de 2006

Habilitado el filtro de extensiones por defecto

PHP 5.2.4

30 de agosto de 2007

PHP 5.2.5

8 de Noviembre de 2007

Versión centrada en mejorar la estabilidad (+60 errores solucionados)

Tabla: 2.3 Historia de Php - Fuente: Propia

  • A) PHP 3

Dos programadores israelíes del Technion, Zeev Suraski y Andi Gutmans, reescribieron el analizador sintáctico (parser en inglés) en el año 1997 y crearon la base del PHP3, cambiando el nombre del lenguaje a la forma actual. Inmediatamente comenzaron experimentaciones públicas de PHP3 y fue publicado oficialmente en junio del 1998.

Para 1999, Suraski y Gutmans reescribieron el código de PHP, produciendo lo que hoy se conoce como Zend Engine o motor Zend, un portmanteau de los nombres de ambos, Zeev y Andi. También fundaron Zend Technologies en Ramat Gan, Israel.

  • B) PHP 4

En mayo de 2000 PHP 4 fue lanzado bajo el poder del motor Zend Engine 1.0. El día 13 de julio de 2007 se anunció la suspensión del soporte y desarrollo de la versión 4 de PHP[1] , a pesar de lo anunciado se ha liberado una nueva versión con mejoras de seguridad,la 4.4.8 publicada el 13 de Enero del 2008. Según esta noticia [[1]] se dará soporte a fallos críticos hasta el 2008-08-08.

  • C) PHP 5

El 13 de julio de 2004, fue lanzado PHP 5, utilizando el motor Zend Engine II (o Zend Engine 2). La versión más reciente de PHP es la 5.2.5 (8 de noviembre de 2007), que incluye todas las ventajas que provee el nuevo Zend Engine 2 como:

Mejor soporte para la Programación Orientada a Objetos, que en versiones anteriores era extremadamente rudimentario, con PHP Data Objects.

Mejoras de rendimiento.

Mejor soporte para MySQL con extensión completamente reescrita.

Mejor soporte a XML ( XPath, DOM, etc. ).

Soporte nativo para SQLite.

Soporte integrado para SOAP.

Iteradores de datos.

Manejo de excepciones.

  • D) PHP 6

Está previsto el lanzamiento en breve de la rama 6 de PHP. Cuando se lance esta nueva versión quedarán solo dos ramas activas en desarrollo (PHP 5 y 6), pues se abandonó el desarrollo y soporte de PHP 4 el 13 de julio de 2007.

2.3.3. USOS DE PHP

Los principales usos del PHP son los siguientes:

Programación de páginas web dinámicas, habitualmente en combinación con el motor de base datos MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión.

Programación en consola, al estilo de Perl o Shell scripting.

Creación de aplicaciones gráficas independientes del navegador, por medio de la combinación de PHP y Qt/GTK+, lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado.

2.3.4. CARACTERÍSTICAS DE PHP

2.3.4.1. VENTAJAS

  • Es un lenguaje multiplataforma.

  • Capacidad de conexión con la mayoría de los manejadores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL

  • Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).

  • Posee una amplia documentación en su página oficial ([2]), entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.

  • Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.

  • Permite las técnicas de Programación Orientada a Objetos.

  • Biblioteca nativa de funciones sumamente amplia e incluida

  • No requiere definición de tipos de variables.

  • Tiene manejo de excepciones.

2.3.4.2. DESVENTAJAS

  • No posee una abstracción de base de datos estándar, sino bibliotecas especializadas para cada motor (a veces más de una para el mismo motor).

  • No posee adecuado manejo de internacionalización, unicode, etc.

  • Por su diseño dinámico no puede ser compilado y es muy difícil de optimizar.

  • Por sus características promueve la creación de código desordenado y complejo de mantener.

  • Está diseñado especialmente para un modo de hacer aplicaciones web que es ampliamente considerado problemático y obsoleto (mezclar el código con la creación de la página web).

  • MYSQL

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL AB pertenece a Sun Microsystems desde enero de 2008[13]

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero las que quieran incorporarlo en productos privativos pueden comprar a la una licencia específica que les permita este uso. Está desarrollado en su mayor parte en ANSI C.

Al contrario que proyectos como Apache, donde el software es desarrollado por una comunidad pública y el copyright del código está en poder del autor individual, MySQL es propiedad y está patrocinado por una privada, que posee el copyright de la mayor parte del código.

Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran vía Internet. MySQL AB fue fundado por David Axmark, Allan Larsson, y Michael Widenius.

Monografias.com

Tabla: 2.4 Mysql Caracteristicas - Fuente: Propia

  • HISTORIA[14]

SQL (Lenguaje de Consulta Estructurado) fue comercializado por primera vez en 1981 por IBM, el cual fue presentado a ANSI y desde ese entonces ha sido considerado como un estándar para las bases de datos relacionales. Desde 1986, el estándar SQL ha aparecido en diferentes versiones como por ejemplo: SQL:92, SQL:99, SQL:2003. MySQL es una idea originaria de la opensource MySQL AB establecida inicialmente en Suecia en 1995 y cuyos fundadores son David Axmark, Allan Larsson, y Michael "Monty" Widenius. El objetivo que persigue esta consiste en que MySQL cumpla el estándar SQL, pero sin sacrificar velocidad, fiabilidad o usabilidad.

Michael Widenius en la década de los 90 trató de usar mSQL para conectar las tablas usando rutinas de bajo nivel ISAM, sin embargo, mSQL no era rápido y flexible para sus necesidades. Esto lo conllevó a crear una API SQL denominada MySQL para bases de datos muy similar a la de mSQL pero más portable.

La procedencia del nombre de MySQL no es clara. Desde hace más de 10 años, las herramientas han mantenido el prefijo My. También, se cree que tiene relación con el nombre de la hija del cofundador Monty Widenius quien se llama My.

Por otro lado, el nombre del delfín de MySQL es Sakila y fue seleccionado por los fundadores de MySQL AB en el concurso "Name the Dolphin". Este nombre fue enviado por Ambrose Twebaze, un desarrollador de Open source Africano, derivado del idioma SiSwate, el idioma local de Swazilandia y corresponde al nombre de una ciudad en Arusha, Tanzania, cerca de Uganda la ciudad origen de Ambrose.

  • APLICACIONES

MySQL es muy utilizado en aplicaciones web como MediaWiki o Drupal, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.

  • ESPECIFICACIONES

MySQL funciona sobre múltiples plataformas, incluyendo:

  • AIX

  • BSD

  • FreeBSD

  • HP-UX

  • GNU/Linux

  • Mac OS X

  • NetBSD

  • Novell Netware

  • OpenBSD

  • OS/2 Warp

  • QNX

  • SGI IRIX

  • Solaris

  • SunOS

  • SCO OpenServer

  • SCO UnixWare

  • Tru64

  • Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Vista y otras versiones de Windows.

  • OpenVMS

  • Fedora

  • CARACTERISTICAS

  • Un amplio subconjunto de ANSI SQL 99, y varias extensiones.

  • Soporte a multiplataforma

  • Procedimientos almacenados

  • Triggers

  • Cursores

  • Vistas actualizables

  • Soporte a VARCHAR

  • INFORMATION_SCHEMA

  • Modo Strict

  • Soporte X/Open XA de transacciones distribuidas; transacción en dos fases como parte de esto, utilizando el motor InnoDB de Oracle

  • Motores de almacenamiento independientes (MyISAM para lecturas rápidas, InnoDB para transacciones e integridad referencial)

  • Transacciones con los motores de almacenamiento InnoDB, BDB Y Cluster; puntos de recuperación(savepoints) con InnoDB

  • Soporte para SSL

  • Query caching

  • Sub-SELECTs (o SELECTs anidados)

  • Replication with one master per slave, many slaves per master, no automatic support for multiple masters per slave.

  • indexing y buscando campos de texto completos usando el motor de almacenamiento MyISAM

  • Embedded database library

  • Soporte completo para Unicode

  • Conforme a las reglas ACID usando los motores InnoDB, BDB y Cluster

  • Shared-nothing clustering through MySQL Cluster

  • Características adicionales [editar]Usa GNU Automake, Autoconf, y Libtool para portabilidad

  • Uso de multihilos mediante hilos del kernel.

  • Usa tablas en disco b-tree para búsquedas rápidas con compresión de índice

  • Tablas hash en memoria temporales

  • El código MySQL se prueba con Purify (un detector de memoria perdida comercial) así como con Valgrind, una herramienta GPL

  • Completo soporte para operadores y funciones en cláusulas select y where.

  • Completo soporte para cláusulas group by y order by, soporte de funciones de agrupación

  • Seguridad: ofrece un sistema de contraseñas y privilegios seguro mediante verificación basada en el host y el tráfico de contraseñas está cifrado al conectarse a un servidor.

  • Soporta gran cantidad de datos. MySQL Server tiene bases de datos de hasta 50 millones de registros.

  • Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2).

  • Los clientes se conectan al servidor MySQL usando sockets TCP/IP en cualquier plataforma. En sistemas Windows se pueden conectar usando named pipes y en sistemas Unix usando ficheros socket Unix.

La serie en desarrollo de MySQL Server actualmente, es la 5.1 al cual se añaden nuevas características en relación a la serie 5.0. La serie de producción actual de MySQL es 5.0, cuya penúltima versión estable es la 5.0.26 lanzada en octubre de 2006. Actualmente, se puede descargar la serie 5.0.27. La serie de producción anterior fue la 4.1, cuya versión estable es 4.1.7 lanzada en octubre de 2004. A estas versiones de producción sólo se arreglan problemas, es decir, ya no se añaden nuevas características. Y a las versiones anteriores solamente se les corrigen bugs críticos.

2.5. HTML

HTML, sigla de HyperText Markup Language (Lenguaje de Etiquetas de Hipertexto), es el lenguaje de marcado predominante para la construcción de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir un script (por ejemplo Javascript), el cual puede afectar el comportamiento de navegadores web y otros procesadores de HTML.

HTML también es usado para referirse al contenido del tipo de MIME text/html o todavía más ampliamente como un término genérico para el HTML, ya sea en forma descendida del XML (como XHTML 1.0 y posteriores) o en forma descendida directamente de SGML (como HTML 4.01 y anteriores).

Monografias.com

Tabla: 2.5 HTML caracteristicas - Fig. Fuente: Propia

2.5.1. HISTORIA

La primera descripción de HTML disponible públicamente fue un documento llamado HTML Tags (Etiquetas HTML), mencionado por primera vez en Internet por Berners-Lee en 1991[15]Describe 22 elementos comprendiendo el diseño inicial y relativamente simple de HTML. Trece de estos elementos todavía existen en HTML 4.[16]

Berners-Lee consideraba a HTML una ampliación de SGML, pero no fue formalmente reconocida como tal hasta la publicación de mediados de 1993, por la IETF, de una primera proposición para una especificación de HTML: el boceto Hypertext Markup Language de Berners-Lee y Dan Conolly, el cual incluía una Definición de Tipo de Documento SGML para definir la gramática.El boceto expiró luego de seis meses, pero fue notable por su reconocimiento de la etiqueta propia del navegador Mosaic usada para insertar imágenes sin cambio de línea, reflejando la filosofía del IETF de basar estándares en prototipos con éxito. Similarmente, el boceto competidor de Dave Raggett HTML+ (Hypertext Markup Format) (Formato de marcaje de hipertexto), de 1993 tardío, sugería, estandarizar características ya implementadas tales como tablas.

HTML consiste de varios componentes vitales, incluyendo elementos y sus atributos, tipos de data, y la declaración de tipo de documento.

2.5.2. ELEMENTOS

Los elementos son la estructura básica de HTML. Los elementos tienen dos propiedades básicas:

Monografias.com

Fig. II.1 Elementos HTML

Monografias.com

Monografias.com

2.5.3. CÓDIGOS HTML BÁSICOS

Monografias.com

El lenguaje HTML puede ser creado y editado con cualquier editor de textos básico, como puede ser Gedit en Linux, el Bloc de Notas de Windows, o cualquier otro editor que admita texto sin formato como GNU Emacs, Microsoft Wordpad, TextPad, Vim, Note pad++, etc.

Existen además, otros programas para la realización de sitios Web o edición de código HTML, como por ejemplo Microsoft FrontPage, el cual tiene un formato básico parecido al resto de los programas de Office. También existe el famoso software de Macromedia (que adquirió la empresa Adobe) llamado Dreamweaver, siendo uno de los más utilizados en el ámbito de diseño y programación Web. Estos programas se les conoce como editores WYSIWYG o What You See Is What You Get (en español: "lo que ves es lo que obtienes"). Esto significa que son editores en los cuales se ve el resultado de lo que se está editando en tiempo real a medida que se va desarrollando el documento. Ahora bien, esto no significa una manera distinta de realizar sitios web, sino que una forma un tanto más simple ya que estos programas, además de tener la opción de trabajar con la vista preliminar, tiene su propia sección HTML la cual va generando todo el código a medida que se va trabajando.

Combinar estos dos métodos resulta muy interesante, ya que de alguna manera se ayudan entre sí. Por ejemplo; si se edita todo en HTML y de pronto se olvida algún código o etiqueta, simplemente me dirijo al editor visual o WYSIWYG y se continúa ahí la edición, o viceversa, ya que hay casos en que sale más rápido y fácil escribir directamente el código de alguna característica que queramos adherirle al sitio, que buscar la opción en el programa mismo.

Existe otro tipo de editores HTML llamados WYSIWYM (Lo que ves es lo que quieres decir) que dan más importancia al contenido y al significado que a la apariencia visual. Entre los objetivos que tienen estos editores es la separación del contenido y la presentación, fundamental en el diseño Web.

HTML utiliza etiquetas o marcas, que consisten en breves instrucciones de comienzo y final, mediante las cuales se determina la forma en la que debe aparecer en su navegador el texto, así como también las imágenes y los demás elementos, en la pantalla del ordenador.

Toda etiqueta se identifica porque está encerrada entre los signos menor que y mayor que (< >), y algunas tienen atributos que pueden tomar algún valor. En general las etiquetas se aplicarán de dos formas especiales:

Monografias.com

Las etiquetas básicas o mínimas son:

Monografias.com

Fuente: Propia

2.5.4. ACCESIBILIDAD WEB[17]

El diseño en HTML aparte de cumplir con las especificaciones propias del lenguaje debe respetar unos criterios de accesibilidad web, siguiendo unas pautas, o las normativas y leyes vigentes en los países donde se regule dicho concepto. Se encuentra disponible y desarrollado por el W3C a través de las Pautas de Accesibilidad al Contenido Web 1.0 WCAG, aunque muchos países tienen especificaciones propias como España con la Norma UNE 139803.[7]

2.6. CSS[18]

2.6.1. Hojas de estilo en cascada

Usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los agentes de usuario o navegadores.

La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación.

Monografias.com

La información de estilo puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. En este último caso podrían definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo "style".

Monografias.com

Tabla: 2.6 HTML Caracteristicas - Fuente: Propia

2.6.2. Los tres tipos de estilos

CSS proporciona tres caminos diferentes para aplicar las reglas de estilo a una página Web:

  • 1. Una hoja de estilo externa, que es una hoja de estilo que está almacenada en un archivo diferente al archivo donde se almacena el código HTML de la página Web. Esta es la manera de programar más potente, porque separa completamente las reglas de formateo para la página HTML de la estructura básica de la página.

  • 2. Una hoja de estilo interna, que es una hoja de estilo que está incrustada dentro de un documento HTML. (Va a la derecha dentro del elemento head). De esta manera se obtiene el beneficio de separar la información del estilo, del código HTML propiamente dicho. Se puede optar por copiar la hoja de estilo incrustada de una página a otra, (esta posibilidad es difícil de ejecutar si se desea para guardar las copias sincronizadas). En general, la única vez que se usa una hoja de estilo interna, es cuando se quiere proporcionar alguna característica a una página Web en un simple fichero, por ejemplo, si se está enviándo algo a la página web.

  • 3. Un estilo en línea, que es un método para insertar el lenguaje de estilo de página, directamente, dentro de una etiqueta HTML. Esta manera de proceder no es excesivamente adecuada. Al incrustar el formateo dentro del documento de la página Web la descripción de la página, a nivel de código se convierte en una tarea larga, tediosa y poco elegante de resolver el problema de la programación de la página. Este modo de trabajo se podría usar de manera ocasional si se pretende aplicar un formateo con prisa, al vuelo. No es todo lo claro, o estructurado, que debería ser, pero funciona.

2.6.3. Ventajas de usar las hojas de estilo

Las ventajas de utilizar CSS (u otro lenguaje de estilo) son:

  • Control centralizado de la presentación de un sitio web completo con lo que se agiliza de forma considerable la actualización del mismo.

  • Los Navegadores permiten a los usuarios especificar su propia hoja de estilo local que será aplicada a un sitio web, con lo que aumenta considerablemente la accesibilidad. Por ejemplo, personas con deficiencias visuales pueden configurar su propia hoja de estilo para aumentar el tamaño del texto o remarcar más los enlaces.

  • Una página puede disponer de diferentes hojas de estilo según el dispositivo que la muestre o incluso a elección del usuario. Por ejemplo, para ser impresa, mostrada en un dispositivo móvil, o ser "leída" por un sintetizador de voz.

  • El documento HTML en sí mismo es más claro de entender y se consigue reducir considerablemente su tamaño (siempre y cuando no se utilice estilo en línea).

2.6.4. Versiones CSS

Hay varias versiones: CSS1 y CSS2, con CSS3 en desarrollo por el World Wide Web Consortium (W3C). Los navegadores modernos implementan CSS1 bastante bien, aunque existen pequeñas diferencias de implementación según marcas y versiones de los navegadores.[1] CSS2, sin embargo, está solo parcialmente implementado en los más recientes.

2.6.5. Diagramado de página en CSS

Antes de que estuviera disponible CSS, la única forma de componer espacialmente una página era el uso de tablas. Aunque es una técnica cómoda y versátil, se está usando un elemento con una semántica particular, que es la de expresar información tabular, solamente por su efecto en la presentación.

La introducción de CSS ha permitido en muchos casos reemplazar el uso de tablas. Sin embargo CSS todavía no permite la versatilidad que ofrecían las tablas, lograr un diagramado de una página compleja suele ser una tarea compleja en CSS y las diferencias entre navegadores dificultan aún más la tarea. Se espera que futuros desarrollos en CSS3 resuelvan esta deficiencia y hagan de CSS un lenguaje más apto para describir la estructura espacial de una página.

2.7. UML: Lenguaje Unificado de Modelado[19]

Lenguaje Unificado de Modelado (Unified Modeling Language), está compuesto por una gama de diagramas, que permiten graficar o tomar una radiografía a los procesos para una interpretación de los mismos desde el punto de vista de usuario como de los desarrolladores de Software, el UML es como que si fuese el Castellano que utiliza un abecedario compuesto de letras, las cuales formaran silabas, palabras, oraciones, párrafos y documentos que contendrán un pensamiento, mediante el castellano Usted podrá escribir una novela, una canción una poesía entres otros.

Existiendo para ello un lenguaje común de comunicación, Cuando no se usa la notación UML(conjuntos de Diagramas) se tiene la problemática de no encontrar los términos adecuados, ya que los analistas usan términos informáticos de difícil entendimiento por los usuarios, y por otra parte los desarrolladores no entienden el lenguaje que usan los usuarios del mundo real de estudio.

UML es un lenguaje estándar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web[20]

2.7.1. DIAGRAMAS

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

  • Diagrama de clases

  • Diagrama de componentes

  • Diagrama de objetos

  • Diagrama de estructura compuesta (UML 2.0)

  • Diagrama de despliegue

  • Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

  • Diagrama de actividades

  • Diagrama de casos de uso

  • Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

  • Diagrama de secuencia

  • Diagrama de colaboración

  • Diagrama de tiempos (UML 2.0)

  • Diagrama de vista de interacción (UML 2.0)

2.7.2. HISTORIA

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.

Booch había escrito "Object-Oriented Analysis and Design with Applications" un libro de referencia en el análisis y diseño orientado a objetos desarrollando su propia notación.

Por su parte James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented Modeling and Design".

Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven Approach".

A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.

En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Rational.

En 1997 salió a la luz la versión 1.0 de UML.

2.7.3. ELEMENTOS ESTRUCTURALES

Conceptos Básicos de UML [21]

  • Clase: Los Objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Los valores de los atributos podrán ser distintos para cada una de ellos, pero todos comparten los mismos atributos y comportamiento (las operaciones que se pueden realizar sobre ellos). Una clase esta representada por el siguiente grafico.

  • Abstracción: Se refiere a quitar las operaciones y acciones de un objeto para dejar solo aquellas que sean necesarias.

  • Herencia: Se refiere a la Compartición de atributos y operaciones basada en una relación jerárquica entre varia clases, una clase definirse de forma general y luego refinare en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y añade sus propiedades particulares.

  • Polimorfismo: Permite que una misma operación pueda llevarse a cabo de forma deferente en clases diferente.

  • Encapsulamiento: La esencia del encapsulamiento es cuando un objeto trae consigo funcionalidad, esta última se oculta.

  • Envío de mensaje: Un sistema de objeto trabaja en conjunto. Esto se logra mediante al envío de mensaje para realizar una operación, y el objeto envía a otro un mensaje para realizar una operación, y el objeto receptor ejecutara la operación.

  • Asociación: Los objetos se relacionan entre sí, de alguna forma. Una clase puede asociarse con más de una clase distinta.

La multiplicidad en un importante aspecto de las asociaciones, indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada.

  • Agregación: Es cuando los objetos se integran pero conservan su independencia. Una PC es un ejemplo de composición ya que sus objetos como el Mouse, los parlantes, el teclado, son objetos que pueden sacarse de una computadora a otra.

Los elementos estructurales en UML, es su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales.

  • a) Clases

Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.

Clase

Monografias.com

Describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces.

Fig. II. 2.1 Fuente: Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • b) Interfaz

Una interfaz es una colección de operaciones que especifican un servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su implementación. Se representa con un circulo, , y rara vez se encuentra aislada sino que más bien conectada a la clase o componente que realiza.

Interfaz

Monografias.comMonografias.com

Agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un círculo para representar las interfaces.

Fig. II. 2.2 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • c) Colaboración

Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Las colaboraciones tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las colaboraciones representan la implementación de patrones que forman un sistema. Se representa mediante una elipse con borde discontinuo.

Colaboración

Monografias.com

Define una interacción entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.

Fig. II. 2.3 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • d) Casos de Uso

Un caso de uso es la descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboración. Se representa como en la figura 6, una elipse con borde continuo.

Caso de uso

Monografias.com

Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de interés. Se emplea para estructurar los aspectos de comportamiento de un modelo.

Fig. II. 2.4 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • e) Clase Activa

Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución por lo y tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Se representa igual que una clase, pero con líneas más gruesas

Clase activa

Monografias.com

Se trata de una clase, en la que existe procesos o hilos de ejecución concurrentes con otros elementos. Las líneas del contorno son más gruesas que en la clase "normal".

Fig. II. 2.5 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • f) Componentes

Un componente es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

Componente

Monografias.com

Parte física y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos.

Fig. II. 2.6 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • g) Nodos

Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso

Computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Nodo

Monografias.com

Elemento físico que existe en tiempo de ejecución y representa un recurso computacional con capacidad de procesar.

Fig. II. 2.7 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

Estos siete elementos vistos son los elementos estructurales básicos que se pueden incluir en un modelo UML. Existen variaciones sobre estos elementos básicos, tales como actores, señales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas (tipos de componentes).

2.7.4. ELEMENTOS DE COMPORTAMIENTO

Los elementos de comportamiento son las partes dinámicas de un modelo. Se podría decir que son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio. Los principales elementos son los dos que siguen.

  • a) Interacción

Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito específico. Una interacción involucra otros muchos elementos, incluyendo mensajes, secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La representación de un mensaje es una flecha dirigida que normalmente con el nombre de la operación.

  • b) Maquinas de estados

Es un comportamiento que especifica las secuencias de estados por las que van pasando los objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a esos eventos. Una maquina de estados involucra otros elementos como son estados, transiciones (flujo de un estado a otro), eventos (que disparan una transición) y actividades (respuesta de una transición)

Monografias.com

Fig. II. 2.9 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • c) Elementos de agrupación

Forman la parte organizativa de los modelos UML. El principal elemento de agrupación es el paquete, que es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos de agrupación se pueden incluir en un paquete.

Un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente se representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.

Elementos

de

agrupación

Paquete

Monografias.com

Se emplea para organizar otros elementos en grupos.

Fig. II. 2.10 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • d) Elementos de anotación

Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.

El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de elementos.

Elementos

de

notación

Nota

Monografias.com

Partes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo.

Fig. II. 2.11 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • e) Relaciones

Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización y realización, estas se describen a continuación:

  • f) Dependencia

Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Dependencia

Monografias.com

Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro.

Fig. II. 2.12 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • g) Asociación

Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados.

Asociación

Monografias.com

Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.

Fig. II. 2.13 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • h) Generalización

Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.

Generalización

Monografias.com

Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.

Fig. II. 2.14 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

  • i) Realización

Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía.

Realización

Monografias.com

Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).

Fig. II. 2.15 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5. DIAGRAMAS

Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema.

2.7.5.1. Diagramas de Clases


Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas).

Diagrama de Clases

Monografias.com

Fig. II. 2.16 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.2. Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Casos de Uso

Monografias.com

Muestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organización del sistema.

Fig. II. 2.17 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.3. Diagramas de Secuencia y de Colaboración

Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin perdida de información, lo mismo ocurren en sentido opuesto.

Monografias.com

Fig. II. 2.18 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.4. Diagramas de Estados

Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.

Estados

Monografias.com

Muestra una máquina de estados, con sus estados, transiciones, eventos y actividades. Cubren la vista dinámica de un sistema. Modelan comportamientos reactivos en base a eventos.

Fig. II. 2.19 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.5. Diagramas de Actividades

Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Actividades

Monografias.com

Tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema.

Fig. II. 2.20 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.6. Diagramas de Componentes

Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones

Monografias.com

Fig. II. 2.21 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.7. Diagramas de Despliegue

Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más componentes.

Monografias.com

Fig. II. 2.22 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.6. Arquitectura

El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde diferentes perspectivas. Diferentes usuarios (usuario final, analistas, desarrolladores, integradores, jefes de proyecto...) siguen diferentes actividades en diferentes momentos del ciclo de vida del proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de qué interese más en cada instante de tiempo.

La arquitectura es el conjunto de decisiones significativas sobre:

  • La organización del sistema

  • Selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema.

  • El Comportamiento, como se especifica las colaboraciones entre esos componentes.

  • Composición de los elementos estructurales y de comportamiento en subsistemas.

Progresivamente más grandes.

  • El estilo arquitectónico que guía esta organización: elementos estáticos y dinámicos y sus interfaces, sus colaboraciones y su composición.

La una arquitectura que no debe centrarse únicamente en la estructura y en el comportamiento, sino que abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptación, reutilización, capacidad para ser comprendida, restricciones, compromisos entre alternativas, así como aspectos estéticos. Para ello se sugiere una arquitectura que permita describir mejor los sistemas desde diferentes vistas, donde cada una de ellas es una proyección de la organización y la estructura centrada en un aspecto particular del sistema.

La vista de casos de uso comprende la descripción del comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los diagramas de casos de uso para capturar los aspectos estáticos mientras que los dinámicos son representados por diagramas de interacción, estados y actividades.

La vista de diseño comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y de la solución. Esta vista soporta principalmente los requisitos funcionales del sistema, o sea, los servicios que el sistema debe proporcionar. Los aspectos estáticos se representan mediante diagramas de clases y objetos y los aspectos dinámicos con diagramas de interacción, estados y actividades.

2.8. OOHDM

Es un Método de Diseño de Desarrollo en Hipermedia Orientado a Objetos (Object-Oriented Hypermedia Design Method) y abarca las cuatro actividades:

  • El Modelo Conceptual

  • Diseño de la Navegación

  • Diseño Interfaz Abstracta

  • Implementación

Estas actividades se realizan en una mezcla de estilo incremental, iterativo y basado en prototipos de desarrollo.

En el dominio de la hypermedia hay requerimientos contradictorios que deben ser satisfechos en una estructura unificada. En el manual, de la aplicación final, la navegación y la conducta funcional debe integrarse transparentemente. Por otro lado, durante el proceso del diseño se debe ser capaz al desacoplar decisiones de diseño relacionadas con la estructura de navegación de aplicación de aquéllas relacionados con el propio modelo del dominio. Desde que la mayoría al que los ambientes de implementación no dan apoyo completo al soporte de conceptos orientados a objetos, los modelos de diseño deben traducirse fácilmente en las plataformas existentes.

Según OOHDM, el desarrollo de aplicaciones de hypermedia ocurre cuando cuatro actividades se procesan:

Que se realiza en una mezcla de estilos de desarrollo iterativo e incremental; en cada paso un modelo será construido o mejorado.

Los principios básicos del método de OOHDM son:

  • Contempla los objetos que representan la navegación como vistas de los objetos detallados en el modelo conceptual.

  • El uso de abstracciones apropiadas para organizar el espacio de la navegación, con la introducción de contextos de navegación.

  • La separación de las características de interfaz de las características de la navegación.

  • Una identificación explícita que hay en las decisiones de diseño que sólo necesitan ser hechos en el momento de la implementación.

OOHDM es una mezcla de estilos de desarrollo basado en prototipos, en desarrollo interactivo y de desarrollo incremental. En cada fase se elabora un modelo orientado a objetos conceptual que recoge las características a resaltar en la misma incrementando los resaltados de la fase o fases anteriores.

El punto de partida es la elaboración de modelo del dominio de la aplicación, qué determina el universo de discurso. Esto se hace durante la fase del Modelo Conceptual y usa principios modelados orientado a objetos bien conocidos [Wirfs-Brock 90, Rumbaugh 91] aumentó con algunas primitivas como perspectivas del atributo y sub- sistemas.

2.8.1. MODELO CONCEPTUAL

Durante esta actividad, se construye un esquema conceptual que representa objetos, sus relaciones y colaboraciones que existen en el dominio designado. En aplicaciones de hypermedia convencionales, es decir, aquellos en los que los componentes de la hypermedia no serán modificados durante su ejecución, se podría usar un modelo semántico estructural [Banerjee87], sin embargo, cuando la base de información puede cambiar dinámicamente o si se piensa realizar cómputos complejos o consultas en los objetos o el esquema, se necesita una abundante conducta del modelo orientado a objetos.

En OOHDM, el esquema conceptual es construido en las clases, relaciones y sub-sistemas. Las clases son descritas como de costumbre en el modelo orientado a objetos, sin embargo, pueden multi-digitar atributos representando perspectivas diferentes de la misma entidad del mundo. Se usa una notación que es similar a UML [OMG 00], la Clase y Tarjetas de las relaciones, similar a las tarjetas de CRC [Wirfs-Brock 90] son usadas como una ayuda de la documentación, ayudando remontar decisiones de diseño enviados y al revés.

Procesos diferentes de modelo de objeto o modelo Conceptual y el diseño son pensados y discutidos por:

Las metodologías orientadas a objetos y bibliografía en el área. Sin embargo hay algunas decisiones modeladas que aparecen en cualquier proceso en el que puede impactar en la estructura navegacional de aplicaciones de la hypermedia. En este papel, se enfoca en las decisiones de diseño que afectan tal estructura.

Se describe un modelo de primitivas brevemente en los párrafos siguientes.

Como la mayoría de ellos son variaciones ligeras de su equivalente modelo orientado a objetos y métodos de diseño, no se elaboran más allá. En cambio, se enfoca adelante esos problemas que afectan la actividad del diseño de navegación.

En OOHDM el esquema de la clase consiste en una colección de clases conectado por relaciones. Los objetos son instancias de clases, y de esa manera, cuando una relación se mantiene entre las clases. Las Clases se usarán después, durante el Diseño de navegación para derivar Nodos, y las Relaciones que serán usadas para derivar Enlaces (Links).

Se observa un modelo conceptual simplificado de un almacén de discos compactos. Los objetos de clase del Cliente serán responsables procesar las peticiones relacionadas con arreglos para requisitos particulares individuales como. El modelo conceptual en OOHDM incluye el modelo de la clase en métodos orientados al objeto tradicionales. Siendo basado en UML, puede ser complementado obviamente con otros modelos de UML usando casos de uso, diagramas de secuencia, el etc.

Monografias.com

Fig. II.2 Modelo Conceptual para una Tienda de CD's. Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html

Decidiendo así para expresar una relación como un atributo, un método o una combinación de ambos es un problema de diseño que ha sido principalmente discutido en el objeto de comunidad. Como una alternativa, situacional se acerca como responsabilidad de Wirfs-Brockos manejo de diseño [Wirfs-Brock 90] servicio que usa diagramas de la colaboración en lugar de relaciones en el estilo de UML.

Desde el punto de vista diseño de hypermedia las relaciones expresan un aspecto importante del dominio de la aplicación y ellos no deben esconderse en clase atributos (por lo menos hasta que se necesita llevar a cabo esas clases). Esto significa que una relación debe especificarse siempre que un atributo represente una entidad conceptual compleja intentada para ser explorada en la hypermedia final. De hecho, cuando la implementación de aplicaciones usa una arquitectura orientada a objetos proporcionando acceso a las relaciones será una responsabilidad de la clase fuente y será implementado como un método y quizá accede a una variable del caso. En [Lange94], una extensión a la clase diagrama de OMT [Rumbaugh91] se presenta para reforzar relaciones.

En esta aproximación de diseño, se proporcionan tres construcciones de abstracciones: Agregación, Generalización / Especialización y un concepto del empaquetamiento de Sub-sistemas. El primero es útil para describir clases complejas como agregación es más simple y el segundo para construir Jerarquías de la Clase y la herencia usando como un mecanismo compartido. Los sub-sistemas son un mecanismo del empaquetamiento por abstracciones de modelo de dominios enteros.

Escogiendo usar objetos, agregado, atributos complejos o relaciones son una decisión de modelo que puede variar de la aplicación a aplicación. Dado que la agregación es una relación estructural importante, se sugiere descomponer un objeto en partes cada tiempo se supone que estas partes son exploradas en la aplicación de la hypermedia como no-atómico. Existiendo heurísticas en el dominio del modelo orientado a objetos puede usarse para identificar estructuras de agregación.

Se usa la misma semántica de herencia como en [Rumbaugh 91] es decir las clases heredan los atributos, parte-estructura, relaciones y conducta de super-clase.

Monografias.com

Fig. II.3 Modelo Conceptual de ejemplo Fuente: http://es.wikipedia.org/wiki/OOHDM

Usando la conducta del modelo orientado a objeto para describir aspectos diferentes de una aplicación de hipermedia permite expresar una gran variedad de actividades de la informática como preguntas dinámicas a una base objeto, las modificaciones del objeto on-líne, búsquedas basadas en heurísticas, etc. El tipo de funcionamiento requerido en el modelo conceptual depende en los aspectos deseados de la aplicación. Para muchas aplicaciones, en particular, aquélla implementación que llevan a cabo un Browser (es decir sólo leer) la funcionalidad, comportamiento de la clase, más allá de la funcionalidad de conectarse puede parecer innecesario. En este caso, el comportamiento llega a acceder una base de información de multimedia navegando encima de las relaciones, y podría ser "integrado" en el propio modelo.

En contraste, en aplicaciones en las que la base de información subyacente puede que cambie dinámicamente como el efecto de acciones del usuario, o cuando la red de hipermedia es simplemente un componente de una aplicación corporativa más grande, se puede necesitar definir métodos que implemente ese comportamiento en clases conceptuales. Durante el diseño Navegacional y el Diseño de Interfaz, se especifica la manera en que la interfaz de objetos activa el comportamiento de ambos en el modelo de navegación y conceptual.

Desde que OOHDM es un método de Diseño y no un armazón de aplicación, se asume que los métodos para lograr el valor de atributos de un objeto son automáticamente generados. Cuando deben hacerse otros cómputos y deben corresponderse deben especificarse métodos. Usando la terminología de métodos orientado a objetos se puede decir que el Modelo Conceptual contendrá aspectos de Modelos de Análisis y Diseño.

Cuando la aplicación se ejecute en un ambiente de soporte (distribuido) de objetos, las clases en el modelo conceptual serán implementadas directamente como están definidos, que especifican perspectivas múltiples como atributos separados. Si no, ellos servirán como especificaciones de diseño para el de navegación y actividades de diseño de interfaz.

2.8.2. Diseño Navegacional

La primera generación de aplicaciones de multimedia intentaba realizar la navegación a través de un espacio de información usando un solo modelo de datos de hipermedia. A pesar de estos problemas que son bien conocidos en la comunidad de la hipermedia, ellos raramente han sido tomados en cuenta por los diseñadores de Multimedia y Web Sites.

El mayor esfuerzo de diseño normalmente se ha puesto en aspectos de interfaz del usuario y la estructura de la navegación se construye en jerarquías simples. Ahora que los navegadores (Browser) de Web son la interfaz, y a veces el Host, para los tipos diferentes de aplicaciones, hay un riesgo en la navegación a ser considerada simplemente otro tipo de de comportamiento de aplicación.

En OOHDM, la navegación es considerada un paso crítico en el diseño de una aplicación de hipermedia. Un Modelo de navegación se construye como una vista más de un modelo conceptual y permite la construcción de modelos diferentes según los perfiles diferentes de los usuarios. Cada modelo de navegación proporciona una vista "Subjetiva" del modelo conceptual.

Mientras se diseña la estructura de navegación de una aplicación Web, se tiene en cuenta varios aspectos como:

¿Que objetos serán navegados, que atributos poseen, y que son las relaciones entre estos objetos y los mismos definidos en el esquema conceptual? Se hará esto definiendo nodos y enlaces (Links) como vistas orientadas a objetos de objetos conceptuales y relaciones.

¿Qué tipo de estructuras de composición existe entre los objetos de navegación y cómo son relacionados?

¿Cuál es la estructura fundamental de navegación?

¿En qué contexto el usuario navegará?

Se introducirá el concepto de contextos de navegación, una arquitectura primitiva para organizar el espacio de la navegación. Se necesita decidir los objetos navegados que pueden parecer diferentes según el contexto en el que ellos son visitados, y se debe especificar esas diferencias claramente.

¿Cuales conexiones y estructuras de acceso existen entre objetos que serán navegados (enlaces, trayecto de búsqueda, camino o trayecto, índices, etc.)? ¿Cómo procede la navegación cuando el usuario salta "Jump" de un objeto a otro, es decir, lo que es el efecto de navegación en la fuente "source" y en el destino "target object" y posiblemente en otro objeto relacionado también?

El diseño de navegación se expresa en dos esquemas, el esquema de la Clase De navegación, y el Esquema del Contexto De navegación. Los objetos navegables de una hipermedia en la aplicación es definida por un esquema de la clase navegacional cuyas clases reflejan la vista escogida sobre del dominio de la aplicación. En OOHDM, hay un juego de tipos pre-definidos de clases de navegación: nodos, links o enlaces, y estructuras de acceso. La semántica de nodos y enlaces es el usual en aplicaciones de hipermedia, y estructuras de acceso, como índices y recorridos guiados, que represente posibles maneras de acceso a los nodos.

Se introducirá el concepto de contextos de navegación, una arquitectura primitiva para organizar el espacio de la navegación. Se necesita decidir los objetos navegados que pueden parecer diferentes según el contexto en el que ellos son visitados, y se debe especificar esas diferencias claramente.

¿Cuales conexiones y estructuras de acceso existen entre objetos que serán navegados (enlaces, trayecto de búsqueda, camino o trayecto, índices, etc.)? ¿Cómo procede la navegación cuando el usuario salta "Jump" de un objeto a otro, es decir, lo que es el efecto de navegación en la fuente "source" y en el destino "target object" y posiblemente en otro objeto relacionado también?

El diseño de navegación se expresa en dos esquemas, el esquema de la Clase De navegación, y el Esquema del Contexto De navegación. Los objetos navegables de una hypermedia en la aplicación es definida por un esquema de la clase navegacional cuyas clases reflejan la vista escogida sobre del dominio de la aplicación. En OOHDM, hay un juego de tipos pre-definidos de clases de navegación: nodos, links o enlaces, y estructuras de acceso. La semántica de nodos y enlaces es el usual en aplicaciones de hipermedia, y estructuras de acceso, como índices y recorridos guiados, que represente posibles maneras de acceso a los nodos.

2.8.2.1. Nodos: Los nodos son contenedores básicos de información de las aplicaciones hipermedia. Se definen como vistas orientadas a objeto de las clases definidas durante el diseño conceptual usando un lenguaje basado en query, permitiendo así que un nodo sea definido mediante la combinación de atributos de clases diferentes relacionadas en el modelo de diseño conceptual. Los nodos contendrán tanto atributos de tipos básicos (donde se pueden encontrar tipos como imágenes o sonidos) y enlaces.

2.8.2.2. Enlaces: Los enlaces reflejan la relación de navegación que puede explorar el usuario. Ya se sabe que para un mismo esquema conceptual puede haber diferentes esquemas navegacionales y los enlaces van a ser imprescindibles para poder crear esas vistas diferentes. Las clases enlaces sirven para especificar los atributos de enlaces y estos a su vez para representar enlaces entre clases nodos o incluso entre otros enlaces. En cualquier caso, el enlace puede actuar como un objeto intermedio en un proceso de navegación o como un puente de conexión entre dos nodos.

2.8.2.3. Estructuras de Acceso: Las estructuras de acceso actúan como índices o diccionarios que permiten al usuario encontrar de forma rápida y eficiente la información deseada. Los menús, los índices o las guías de ruta son ejemplos de estas estructuras. Las estructuras de acceso también se modelan como clases, compuestas por un conjunto de referencias a objetos que son accesibles desde ella y una serie de criterios de clasificación de las mismas.

2.8.2.4. Contexto Navegacional: Para diseñar bien una aplicación hipermedia, hay que prever los caminos que el usuario puede seguir, así es como únicamente se podrá evitar información redundante o que el usuario se pierda en la navegación. En OOHDM un contexto navegacional está compuesto por un conjunto de nodos, de enlaces de clases de contexto y de otros contextos navegacionales. Estos son introducidos desde clases de navegación (enlaces, nodos o estructuras de acceso), pudiendo ser definidas por extensión o de forma implícita.

2.8.2.5. Clase de Contexto: Es otra clase especial que sirve para complementar la definición de una clase de navegación. Por ejemplo, sirve para indicar qué información está accesible desde un enlace y desde dónde se puede llegar a él.

La especificación de las Transformaciones de Navegación describe la dinámica de la aplicación, mostrando los cambios espaciales de navegación cuando el usuario navega, es decir, qué nodos se activan y qué nodos son desactivados cuando un enlace es continuado (Notese en la Figura 4). La semántica de navegación predefinida en OOHDM es que cuando un enlace es continuado, el nodo de la fuente se deja desactivado y el nodo objetivo activado. Esta interpretación normalmente es el valor por defecto encontrado en los navegadores (Browsers) de Web.

De una manera análoga, los enlaces reflejan que las relaciones pretenden ser exploradas por el usuario final y también se define como vistas en relaciones en el esquema conceptual. Los enlaces conectan objetos de navegación y pueden ser uno-a-uno o uno-a-muchos.

Monografias.com

Fig. II.4 Esquema básico navegacional para my.yahoo.com. Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html

El resultado de atravesar un enlace es expresado por cualquier definición de semántica navegacional proceduralmente como resultado de la conducta del enlace o usando una máquina de transición de estado orientada a objeto similar a Statecharts, las estructuras de Acceso (índices) son también definidos como clases y maneras alternativas presentes para la navegación en la aplicación de la hipermedia. En términos Orientado a Objetos, las relaciones entre los nodos y los objetos conceptuales, y entre los enlaces y relaciones en el esquema, son expresados como instancias del patrón o modelo de diseño del Observador. La sintaxis general para definir los atributos del nodo se muestran debajo (la sintaxis para los enlaces es similar).

Donde: El name, es el nombre de la clase de nodos que se está creando. El className, es el nombre de una Clase Conceptual (donde el nodo está trazándose). El nodeClass, es el nombre de la súper-clase Los attri, son los nombres de atributos para esa clase, typei los tipos del atributos. Los namei de · son los asuntos para la expresión de la pregunta y los

Si se toma en cuenta el ejemplo anterior, sobre producirá la definición del Nodo siguiente:

Note que el valor del atributo del toAuthor es un enlace que es el parámetro con la clase de Enlace Is Author of. Al definir la apariencia de la interfaz del Nodo Clase Historia se puede, por ejemplo, hacer aparecer el enlace como un botón invisible sobre del nombre del autor (autor del atributo). Aunque puede que parezca que ambos atributos tienen la misma conducta, sólo el enlace actúa en contestación a un evento de la interfaz.

Monografias.com

Fig. II.5 Información de Nodos Fuente: http://es.wikipedia.org/wiki/OOHDM

Las aplicaciones hypermedia bien diseñadas deben tomar en cuenta la manera qué el usuario explora el espacio de la hypermedia. La información redundante debe ser juiciosamente usada y se debe poder ayudar que el usuario pueda escoger la manera en que él navega de una manera consecuente y controlada. Desgraciadamente, los nodos y enlaces no son suficientes para cumplir este objetivo. Aunque la solución usual a este problema es llevar a cabo herramientas de orientación, también se piensa que nivel más alto que deben ser usados por primitivas de navegación arquitectónicos.

Este es el punto donde los contextos de navegación aparecen.

En OOHDM, la estructuración principal primitiva del espacio de navegación es el concepto de Contexto de Navegación. Un contexto de navegación es un conjunto de nodos, enlaces, contexto, clases y otros contextos de navegación (anidados).

Clase basados en Objetos, en este tipo de contexto pertenecen a la misma clase C y son seleccionados por dar una propiedad P, por el que debe satisfacerse a una propiedad todos los elementos: Contexto = {e | P(e), e ? C}. Un caso común es cuando incluye todas las instancias de una clase (P es idénticamente verdad).

2.8.3. Diseño de Interfaz Abstracta

Una vez que las aplicaciones de estructura navegacional han sido definidos, se debe especificar ahora aspectos de la interfaz. Esto significa definir la manera en que diferentes objetos de navegación aparecerán, qué objetos de navegación de la interfaz se activara y otra funcionalidad de aplicación, y qué transformaciones de la interfaz tendrán lugar y cuando.

Una separación ordenada entre ambas preocupaciones, de navegación y diseño de interfaz abstracta, permite construir interfaces diferentes para el mismo modelo de navegación, llevando a un grado más alto de independencia de tecnología de la interfaz de usuario. En suma, esta separación permite entender mejor la aplicación global de la estructura para indicar qué transformaciones claramente en la interfaz serán transformaciones navegacionales.

Aunque se ha discutido que el aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones de la web) es un componente crítico, moderno, las metodologías tienden a descuidar este aspecto. Ellos relegan la especificación para herramientas de implementación-dependientes, y por consiguiente las decisiones de diseño en este nivel raramente se documentan. Es más, como llevar a cabo la interfaz de la Web normalmente se hacen aplicaciones por medio de los editores de HTML especializados, muchos críticos pueden ignorar aspectos de la interfaz.

En OOHDM, se usa un acercamiento del Diseño de Datos de Vista Abstractos (ADVs), para describir la interfaz del usuario de una aplicación de hypermedia [Cowan 95]. ADVs son objetos en los que tienen un estado y una interfaz, donde la interfaz puede ser ejercido a través de mensajes (en particular, eventos externos generados por el usuario). Las ADVs son abstractas en el sentido de que ellos sólo representan la interfaz y el estado, y no la aplicación. Las ADVs han sido usados para representar interfaces entre dos medios de comunicación diferentes como un usuario, una red o un dispositivo (un cronómetro, por ejemplo) o como una interfaz entre dos u mas Objetos de Datos Abstractos (ADOs). Los ADOs son objetos que no soportan externamente eventos generados por el usuario [Cowan 95]. Desde un punto de vista arquitectónico, las ADVs son observadores para ADOss, para que el protocolo de comunicación entre la interfaz y los objetos de aplicación siga las reglas descritas en el Modelo de Diseño de Observador [Gamma 95].

En la Figura 4 se observan los datos abstractos jerarquizados, "cuadro", "descripción", "interfaz del contexto", "descripción de la demostración" y las "referencias de la demostración" exhiben un comportamiento usuario-perceptible. Por ejemplo cuando el usuario corre la "descripción de la demostración" en los ADV se exhibe la "descripción". la "interfaz del contexto" alternadamente se compone de las anclas que ponen en ejecución jerarquizadas de ADVs para la navegación del contexto, básicamente una vision simple del diseño final de las pantallas.

Monografias.com

Fig. II.6 Diagrama de Configuración para los nodos ADV. Fuente: OOHDM's Design Process http://www-di.inf.puc-rio.br/schwabe/HT96WWW/section3.html

Un ADV usado en el diseño de aplicaciones Web puede verse como un objeto de interfaz. Comprende un conjunto de atributos (y objetos de interfaz anidado) qué define sus propiedades de percepción, y el conjunto de eventos que puede manejar, como eventos generados por el usuario. Los ejemplos de eventos generados por el usuario son MouseClick, MouseDoubleClick, MouseOn, etc. Las ADVs pueden ser fácilmente implementadas en ambientes orientados a objetos para el Web o puede traducirse a documentos HTML. Pueden definirse valores del atributo como constantes y pueden definirse estilos particulares de apariencia como posición, color, o sonido. Los modelos de interfaz ADV unen al modelo que permite tratar estos rasgos de una manera abstracta y los relega al paso de la aplicación. En general, los ADVs especifican la organización y el comportamiento de la interfaz, pero la apariencia física real o de los atributos, y el diseño de la ADV en la pantalla real se hace en la fase de la implementación.

En el contexto de OOHDM, los objetos de navegación como nodos, e índices actuarán como ADOs, y su ADVs asociados se usará para especificar su apariencia al usuario. A continuación se usará el término ADV para referirse a clases de interfaz y objetos. Cuando sea necesario se hablará sobre las clases de ADV. Las abstracciones diferentes y mecanismos de la composición son usados en el diseño de ADV; primero las ADVs pueden ser compuestas por agregación o composición de ADVs de nivel más bajo, permitiendo la construcción de usuarios de interfaces así con objetos perceptibles anidados. Por ejemplo, supóngase que se tiene una aplicación sobre pinturas. Figura 9 muestras cómo un ADV que describe una pintura pudiera hacerse fuera de tres ADVs, conteniendo una imagen, texto, y un botón. Además, ADVs pueden ser organizados en jerarquías del generalización/especialización que proporcionan un poderoso armazón conceptual por definir jerarquías de objetos de la interfaz.

Monografias.com

Fig. II.7 Nodo ADV referente a la página de Descargas del CMS ASOAJEDRENEFuente: http://es.wikipedia.org/wiki/OOHDM

En Figura 5, "Texto Buscar" es un Objeto de la Interfaz que envía un conjunto de anclas o enlaces al TextField (Campo de texto) más general. Entretanto el "Botón Buscar" especializado agregando una conducta más personalizada (no mostrado en la Figura). Cuando se implementa esta aplicación Web usando un ambiente de soporte de ciertos tipos de objetos de interfaz, se puede usar como ADVs primitivos para producir esta especificación de diseño.

En resumen, ADVs:

La manera en que se estructuran objetos de la interfaz usando agregación y generalización/especialización como mecanismos de abstracción. ADVs expresan la estructura del esquema estático que lleva a cabo la metáfora de la interfaz [Hannemann 93]. Las ADVs permiten definir la apariencia de la interfaz de objetos de navegación y otros objetos de la interfaz útiles (como barras del menú, botones y menús).

Se muestra un ADV correspondiente al Diseño del sitio Web Portinari (http://www.portinari.org.br /) un aplicación de hypermedia que contiene parte del trabajo y documentos relacionados de Candido Portinari, pintor brasileño famoso.

El ADV Painting contiene algunos atributos que describen ciertos aspectos del cuadro y muchos ADVs anidados como Picture (Cuadro), References y People (Referencias y Personas). En la notación de Figura 8 Referencias y las Personas no se intentan ser mostradas al mismo tiempo y para que sus ADVs son sobrepuestas. ADVs ShowPeople (Mostrar personas), ShowReferences (Mostrar personas) son mandos activos que permiten mostrar uno de los ADVs previamente mencionado. El ADV de THeme InContext implementa la interfaz de la Clase de InContext Theme y proporciona mandos de la navegación dentro del Contexto De navegación: Cuadros de un Tema. Las ADVs similares deben ser especificados por otros Contextos navegacionales como Picture (Cuadros) de una estrategia. Mientras los diagramas de arriba o anteriores muestra la naturaleza estática de interfaces de Pictures (Cuadros), las dinámicas son descritas usando ADV-mapas, se especifica que cuando ShowPeople es clicked (pulsar el botón), envía la lista al despliegue del mensaje de las personas asociadas con la pintura, y lo mismo ocurre para ShowReference. Nota que éste es una interfaz pura de efecto no involucra navegar a otro nodo.

Entretanto, cuando el objeto de la interfaz Anterior "Previous" es clicked (hacer click), envía el mensaje anchorSelected (anterior) a la DIFICULTAD correspondiente, en este caso un Objeto de InContext para que se comunique con el ancla (etiqueta, enlace) correspondiente y así se navega a otra pintura. Aún cuando la aplicación no es orientada a objetos, este modelo de comunicación es fácil de implementar en la mayoría de las plataformas. Para acabar esta sección se muestra la interfaz real del sitio Web Portinari y como los objetos de la interfaz están relacionados con sus partes equivalentes implementados.

2.8.4. Implementación.

En esta fase, el diseñador realmente implementará el diseño. Hasta ahora, todos los modelos fueron deliberadamente construidos de semejante manera en lo que se refiere a ser independiente de la plataforma de implementación; en esta fase el ambiente particular de (tiempo de ejecución) runtime se toma el derecho de acceso a un servidor o a la red internet. A continuación se fijará cómo los diseños de OOHDM pueden ser implementados en el WWW, tener cuidado para no arreglar una sola alternativa, desde que hay muchos acercamientos posibles a través de los cuales esto puede ser logrado. Cuando la fase de implementación se alcanza, el diseñador ya tiene definido los artículos de información que son parte del dominio del problema. También tiene identificado cómo estos artículos deben ser organizados según el perfil del Usuario y asignaciones; ya que se ha decidido lo que la interfaz se parecerá, y cómo se comportará. En orden para implementar todos esto en el ambiente de WWW y aplicaciones de multimedia, el diseñador tiene que decidir cómo los artículos de información (ambos conceptual y objeto de navegación) será almacenada. También debe decidir cómo se comprenderán la apariencia de la interfaz y el comportamiento serán realizados usando HTML y posiblemente use algunas extensiones. En general, note que la apariencia actual será definida por un profesional de diseño gráfico que será parte el equipo de Diseño. Aunque OOHDM es un método en términos de modelos de OO orientados a objetos, no requiere un ambiente de aplicación OO; (pero no en la Web) se describe en [Milet 96]; las aplicaciones basadas en Java son de baja tendencia. Tabla 4 obsérvese un resumen de esta fase.

Fase Implementación Productos Aplicación ejecutable. Herramientas El entorno del lenguaje de programación. Mecanismos Los ofrecidos por el lenguaje. Objetivo de diseño Obtener la aplicación ejecutable. Tabla 4: Fase de Implementación de OOHDM

Mapeo de Información de Artículos

Los artículos de información (qué corresponde a los ADOs en el modelo de interfaz abstracta) puede guardarse en archivos o en una base de datos. Debido a la naturaleza y la complejidad de los tipos de aplicaciones para las que en OOHDM sea más conveniente, recuérdese usar una base de datos para guardar los objetos Conceptuales y de Navegación.

Desde la mayoría de los DBMSs disponibles en el mercado hoy son relacionales, un mapeo de modelos OO hacia los modelos relacionales equivalentes deben ser hechos. Hay varias técnicas y heurísticas para hacer esto. Los métodos asociados con las clases son implementados como un conjunto de procedimientos que acceden a la base de datos para ejecutar sus cómputos.

Para ilustrar el tipo de decisiones de diseño, se discutirá brevemente una alternativa de mapeo. Cada clase en el modelo de OO para ser implementado es enviar hacia una tabla, donde cada columna guarda un atributo, y cada fila corresponde a un objeto de esa clase. Un atributo distinguido puede usarse como una llave de la base de datos, o un identificador interno que corresponden a un puntero (que le permite al programa acceder a un recurso como una función) del objeto y pueden usarse como una llave.

Para atributos cuyo tipo no se apoya directamente en el DBMS (ej. datos de multimedia), una tabla auxiliar separada debe ser implementada, y los atributos de objetos almacenan el atributo Identificador ID de una fila en la tabla auxiliar correspondiente. Alternativamente, almacenar el nombre de un archivo en el sistema operativo que contiene el valor actual. Ambas alternativas tienen limitaciones; por ejemplo, el primero requiere asociación extra, y segundo es vulnerable a los cambios fuera del control del DBMS. Desgraciadamente, esto sólo puede evitarse si el DBMS ofrece soporte para tipos de datos complejos, como es adecuado lo más común en la última generación de productos que llegan al mercado. En sección se declaró que el Modelo de la Navegación ha terminado una vista del Modelo conceptual. El diseñador tiene la opción de reflejar esta organización en la base de datos que corresponden a cada modelo. En otras palabras, él puede definir la base de datos conteniendo los objetos de Navegación (nodos, links, etc...) como una vista, soportada por el DBMS, de la base de datos que corresponde al modelo Conceptual. En el caso donde el DBMS no soporta el mecanismo de vista directamente, o por las razones de eficacia, el diseñador tiene la opción a la mano la vista de informática. En este caso, solo quiere llevar a cabo al modelo de la Navegación, desde que es el primero que el usuario estará accediendo. Evidentemente, esta alternativa tiene limitaciones o anomalías en términos de evolución del esquema el cuál puede llegar a ser evidente cuando el mismo banco de datos Conceptual se usa como la base para varios aplicaciones. Éste es el caso, por ejemplo, cuando las compañías tienen sitios en su intranets, y la parte de estos sitios es visible (normalmente con una interfaz diferente) en el WWW. Además de trazar definiciones de la clase en el modelo del banco de datos cualquier (correlativo, OO, etc...) usándose, también es necesario llevar a cabo clase "InContext" que funcionan como decoradores para los objetos dentro de los contextos particulares. Típicamente, esto implica enriquecer al modelo de los datos usado en la base de datos para adicionar atributos, y definiendo funciones de control en las que hacen estos atributos accesible en los contextos apropiados. Si la implementación esta directamente basada en el sistema del archivo, éstos controlan las funciones que accederán a archivos adicionales que contienen la información contextual.

Una vez que las bases de datos son definidos, ellos deben ser integrados en el WWW. Hay muchas maneras en las que esto puede hacerse, y no se elaborará este extenso; basta decir que cualquiera de estas técnicas puede emplearse. En este respeto, el criterio para escoger el método de la integración será igual que otras aplicaciones, como se discutió en la teoría.

2.8.5. Usando OOHDM

Los modelos usados en las cuatro fases abordadas en la sección anterior son suficientes para permitir el plan de sistemas de información basados en la Web. No obstante, como con cualquier método, hay conocimiento adicional en el que es recogido por diseñadores en prácticas, que no es parte del propio método. La investigación acerca de OOHDM incluye varios desarrollos en esta dirección fuera de la que está llevándose, a continuación se dará un cuadro global brevemente de OOHDM y la investigación relacionada.

Monografias.com

Fig. II.8 Ambiente OOHDM-Web. Fuente: Ribeiro M. OOHDM-Web Manual do Usuário

Un método que ha sido usado recientemente captura conocimiento del diseño, sobre todo en el campo de OO orientado a objetos, es el uso de Modelos de Diseño los cuales se nombran sistemáticamente, explique y evalúe diseños importantes y recurrentes en sistemas del software. Ellos describen problemas que ocurren repetidamente, y describen el centro de la solución a ese problema, de semejante manera se puede usar esta solución muchas veces en diferentes contextos y aplicaciones. Mirando usos conocidos de un modelo del diseño particular, se puede ver cómo un diseñador exitoso resuelve problemas recurrentes. De esta manera, se exige esto usando a diseñadores de prototipos de diseño pueden ganar desde conocimiento del diseño en el que existe varias comunidades, como hypermedia o diseño de interfase de usuario. Se ha estado coleccionando modelos de diseño conveniente para la aplicación del diseño de hypermedia [Rossi 97]. El objetivo es desarrollar un sistema de modelos inter-relacionados bastante compactos para poder expresar diseños completos como la aplicación sucesiva de modelos en este sistema. Se ha estructurado estos modelos en tres sub-grupos, particularmente arquitectónico, navegación y modelos de la interface. Los modelos arquitectónicos dan pautas para implementar substrates del software para las aplicaciones de hypermedia. Estos modelos son bastante similares a los modelos en [la Gamma 95], desde que ellos se dirigen problemas como navegación de desacoplar de otros tipos de conductas, organizando jerarquías de links y fin tipos de nodos, desacoplar link de activación del proceso de determinar el punto extremo del link. Más detalles pueden encontrarse en [Rossi96a, Garrido 97].

Modelos en la ayuda de categoría de navegación la organización de la estructura navegacional de una aplicación de hypermedia para lograr aclarar y significativo para los lectores deseados. Ellos dirigen problemas recurrentes cuya solución determina el grado de éxito de aplicaciones de hypermedia. Un ejemplo interesante de una navegación el modelo es el modelo de "Referencia Activa" cuya meta es proporcionar una referencia perceptible y permanente sobre el estado actual de navegación. Combina herramientas de orientación con una manera fácil de navegar a un juego de nodos relacionados, al mismo o posición más alta en la estructura de la navegación. Este modelo ayuda construir un camino simple para espectadores actualmente no con tal de que por browsers de WWW actual.

El modelo de "Referencia Activa" ha sido usado en muchos sitios Webs para mejorar la navegación. Por ejemplo, en http://city.net/countries / brazil/rio_de_janeiro, hay una barra con una representación del camino lógico de la raíz al nodo corriente. El lector tiene una manera simple de entender donde él esta, donde él puede ir luego mientras accede a datos sobre una ciudad, en este caso Río de Janeiro. Vea [Rossi 97] para una descripción completa de este modelo.

Modelos de la interfase significa para diseñadores de GUI de Hipermedia. Ellos son abstractos y por consiguiente independientes del ambiente usado para la implementación.

El diseño de la interfase gráfica es una tarea compleja, relacionada principalmente con encontrar el combinación correcta de elementos (ambos en cantidad y en sus relaciones espaciales), de tal manera que esos elementos actúan recíprocamente para una presentación eficaz de la información.

También pueden aplicarse modelos en este grupo fuera del área de aplicaciones de hypermedia, en el contexto más extenso de diseño de GUI. Por ejemplo el diseño de patrones "Desacoplar Información/Interacción" modelo de diseño es apuntar a resolver el problema de cómo hacer la interacción entre la aplicación y el usuario, a la interfase gráfica de un nodo. Este modelo es particularmente útil en sitios Web cuando se generan páginas dinámicamente y no se puede definir etiquetas de links como hotwords empotrado en el texto.

El modelo "Information/Interaction Decoupling" da pautas claras con respecto a la colocación física de links de la navegación. El diseño de patrones de "Behavioral Grouping" ayuda al diseñador a construir una interfase de semejante manera que el usuario puede fácilmente entender el tipo de funcionamientos que le permiten realizar en la interfase.

Este modelo resuelve el problema de organizar la interfase cuando muchos tipos diferentes de transacción, deben proporcionarse navegación y funcionalidades de la interfase simultáneamente. Una descripción más profunda de modelos de la interfase puede encontrarse en [Garrido 97].

Aunque se ha declarado que ese Diseño de la Navegación debería hacerse tomando en cuenta a los perfiles de usuario y tareas, el propio OOHDM no proporciona, hasta ahora, cualquier indicación en cómo esto realmente debe hacerse. Se ha estado investigando [Barroso 98] el uso de escenarios de usuarios-centrados para ayudar identifica a la clase de usuario y tareas típicas para ser apoyado por la aplicación.

El método pensado empieza con un modelo conceptual preliminar dibujado por el diseñador desde su comprensión del dominio. Observando escenarios descritos por clases diferentes de usuarios, el diseñador construye la navegación parcial, y esquemas de Clase de navegación parcial. Después de que todos los guiones se han analizado, el diseñador empieza un proceso de anexar los senderos parciales y esquemas con los que culminan un Diagrama de Contexto de navegación y un esquema de Clase de Navegación actualizado.

En el de esta investigación, se ha extendido OOHDM para incorporar un modelo de seguridad para permitir acceso controlado a los objetos. Este modelo toma en cuenta a la clase de usuario y contextos, y define mecanismos para especificar ciertos tipos de contextos dinámicos que se construyen como resultado de acciones del usuario especificadas.

Otro problema importante está construyendo ambientes del software para dar soporte al método; ha seguido dos acercamientos diferentes:

Se ha construido un ambiente de un CASO que le permite a un diseñador describir el concepto de navegación y modelos de la interfase que usan la notación de OOHDM y le proporciona la documentación automatizada sobre esos modelos. Él puede luego generar plantillas de implementación para las escenas diferentes, como Asymetrixs, Toolbook o HTML.

Se ha diseñado e implementado un prototipo orientado a objetos (OONavigator) para reforzar sistemas de información orientados a objetos, mejorando el acceso a sus recursos de información agregando un frontal "navigational", transparentemente, integrando esta funcionalidad de la navegación con sus propias aplicaciones computacionales.

En OONavigator, conceptos del hipermedia (nodos, links, índices, y contextos) son modelados como componentes que se entrelazan con objetos de la aplicación. La clase de aplicación presenta el papel de clases conceptuales de OOHDM, mientras los objetos de prototipo (nodos y links) comprendan el componente de navegación de la aplicación. Se ha enriquecido los MVC estándar paradigma de interfase [Krasner 88] con fijar medios de semejante manera que el apoyo a la metáfora de interfaces de nodos "point y click" del hipertexto. La interfase puede publicarse en los browsers de la Web que usa herramientas como VisualWave. Usando Navegador orientado a objetos, un diseñador puede enriquecer la aplicación -orientada a objetos con características de hypertext siguiendo pautas de OOHDM. En este caso la hipermedia de "instantiates" de diseñador y clases de la interfase (usando una herramienta visual) y conectarlos a sus clases de la aplicación para permitir navegación a través del espacio de información de aplicaciones[22]

CAPÍTULO III

MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS PRE - PROFESIONALES

3.1 MATERIALES

3.1.1. Recursos Humanos.

Cantidad

Recurso Humano

01

Analista

01

Programador

01

Diseñador

Tabla III.1: Todos los roles son asumidos por el bachiller Orlando Jimmy Mamani Poma.

Fuente: Elaboración propia.

  • Recursos de Software

Cantidad

Recurso de Software

01

Microsoft Windows XP

01

Macromedia Dreamweaver CS3

01

Macromedia Fireworks CS3

01

Microsoft Office 2007

01

ERwin 4.10

01

Appserv

01

EDrawMindMap

Tabla III.2: Software Utilizado en el Desarrollo del Informe de Prácticas Pre Profesionales

Fuente: Elaboración propia

  • Recursos de Hardware

Cantidad

Recurso de Hardware

01

Computadora AMD 3000+ de 1.8Ghz

01

Impresora Hp 840.

01

USB 16GB – Kingston

01

Scanner Hp

Tabla III.3: Equipos y materiales Utilizados en el Desarrollo del Informe de Prácticas Pre Profesionales

Fuente: Elaboración propia.

3.2 ANÁLISIS

3.2.1. IDENTIFICACIÓN DEL PROYECTO:

  • TITULO: Desarrollo de un Sistema Informático para la Administración de Expedientes de la Universidad José Carlos Mariátegui.

  • DESCRIPCIÓN: Es un sistema Web que mediante sus módulos se puede administrar los expedientes de los alumnos de la UJCM.

  • AUTOR Orlando Jimmy Mamani Poma

  • VERSIÓN: 1.0

  • FECHA: 20/03/08

3.2.2. DOCUMENTACIÓN DEL ANÁLISIS

La Universidad José Carlos Mariátegui es una Institución Educativa que agrupa varios Modalidades de Estudio.(Carreras a Distancia, Pregrado, Auxiliares de Educación, Complementación Académica, Otros )

La oficina de mantener los documentos académicos de cada alumno está a cargo de OSAERC (Oficina de Servicios Académicos Evaluación y Registro Central), todos los documentos están almacenados en la Oficina Cercana o también llamada Archivo, que está a cargo de la OSAERC.

Todos los alumnos de la Universidad José Carlos Mariátegui Tienen documentos (Certificados de Estudio, partida de Nacimiento, Copia de DNI, Constancia de Ingreso a la UJCM entre otros), los cuales están clasificados en un expediente. Se genera un expediente por cada alumno, en donde además de los documentos antes descritos; también se almacenan otros documentos generados a partir de tramites Universitarios (Resoluciones, Dictámenes, Futs, Constancias de Biblioteca, Conformidad de documentos).Todos los expedientes están clasificados según facultad, Especialidad, y año de ingreso.

En el transcurso del año académico se trasladan los expedientes a diferentes oficinas por razones de trámites, los expedientes son solicitados a OSAERC, para evaluación. La forma de búsqueda es manual no se tiene un registro exacto de donde se encuentre un expediente, dado a que no se cuenta con un sistema que tenga registrado el estado del expediente; generando muchas veces demora en la búsqueda con lo cual se genera demora en la atención del trámite.

3.2.3. DOCUMENTACIÓN DE DESARROLLO

En primer lugar identificamos los actores que interactúan con el sistema.

Monografias.com

Fig. III.1 Diagrama General del Sistema. Fuente: Propia

3.2.3.1 DIAGRAMA DE PAQUETES:

Monografias.com

Fig. III.2 Diagrama de Paquetes

Fuente: Propia

Podemos dividir el Sistema en 4 Sub-sistemas:

  • Sub – Sistema Expedientes

  • Sub – Sistema Administración

  • Sub – Sistema Oficinas

  • Sub – Sistema de Alumnos

3.2.3.2 DIAGRAMAS DE CASOS DE USO - DESCRIPCIÓN

A) SUB - SISTEMA DE OFICINAS

Fig. III.3 Diagrama de Gestión de Actores

Monografias.com

Fuente: Propia

ACT 001

PERSONAL DE ARCHIVO

Descripción

Actor que representa a la persona que tiene permisos para gestionar todo el sistema

Comentario

También llamado personal.

ACT 002

OFICINA (USUARIO)

Descripción

Actor que representa a la Oficina que solicita o interactúa con los expedientes.

Comentario

También llamado Usuario.

Fig. III.4 Diagrama de Gestión de usuarios

Monografias.com

Fuente: Propia

DESCRIPCIÓN DE CASO DE USO:

CU-001

NUEVO USUARIO

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "nuevo".

CU-002

BUSCAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "BUSCAR".

Dependencias

-

Precondición

-

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente deseado y el caso de uso finaliza correctamente.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

Comentarios

Ninguno.

CU-003

MODIFICAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "MODIFICAR".

Dependencias

-

Precondición

-

Secuencia normal

N

Acción

1

Se realiza el caso de uso Buscar (CU-002)

2

El Actor (ACT 001) realiza los cambios.

3

El Actor (ACT 001) selecciona Aceptar cambios.

4

El sistema evalúa si los datos introducidos son validos.

5

El sistema pide confirmación sobre los datos introducidos.

6

El Actor (ACT 001) confirma la petición

7

El sistema realiza las modificaciones y el caso de uso finaliza con éxito.

Post condición

La base de datos ha de estar en un estado consistente

Excepciones

N

Acción

1

Si la búsqueda no finalizo exitosamente, el sistema finaliza el caso de uso, a continuación este caso de uso queda sin efecto.

4

Si los datos introducidos no son validos, el sistema vuelve al paso 2, a continuación este caso de uso continua.

6

Si el actor (ACT-001) no confirma la modificación, el sistema finaliza el caso de uso, a continuación este caso de uso queda sin efecto.

Comentarios

En cualquier momento el Actor (ACT 001) puede seleccionar "Cancelar" y salir del caso de uso sin realizar ningún cambio (la cancelación deberá confirmarse).

CU-004

ELIMINAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "ELIMINAR USUARIO".

Dependencias

-

Precondición

-

Secuencia normal

N

Acción

1

Se realiza el caso de uso Buscar (CU-002)

2

El Actor (ACT 001) confirma que desea eliminar un Usuario.

3

El sistema elimina el usuario de la B.D.

4

El sistema finaliza el caso de uso.

Post condición

La base de datos ha de estar en un estado consistente

Excepciones

N

Acción

1

Si la búsqueda no finalizo exitosamente, el sistema finaliza el caso de uso, a continuación este caso de uso queda sin efecto.

2

Si no lo confirma, el sistema refleja la excepción, a continuación este caso de uso queda sin efecto.

Comentarios

Ninguno.

B) SUB - SISTEMA DE EXPEDIENTES

Fig. III.5 Diagrama de Gestión de Archivo:

Monografias.comFuente: Propia



CU-005

MODIFICAR EXPEDIENTE

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "MODIFICAR EXPEDIENTE" En este modulo se podrá agregar más documentos al expediente del Alumno.

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

Agrega los documentos a su expediente.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-006

ELIMINAR EXPEDIENTE

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "ELIMINAR EXPEDIENTE" En este caso de uso se podrá eliminar documentos en caso de haber llenado mal.

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

Elimina el expediente seleccionado.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

  • El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

  • Al eliminar un expediente se eliminara al alumno así como también todos los movimientos y traslados que el alumno realizo; por lo cual esta función deberá de usarse con la seguridad del caso.

CU-007

VER EXPEDIENTE

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "VER EXPEDIENTE".

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

El sistema muestra detalles del expediente.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

Comentarios

Ninguno

CU-008

TRASLADAR EXPEDIENTE

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "TRASLADAR EXPEDIENTE"

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

El Actor (ACT 001) modifica la ubicación del expediente según el documento.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-009

AGREGAR DOCUMENTOS

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "AGREGAR DOCUMENTOS"

Dependencias

(CU 005) Modificar Expediente.

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

El Actor (ACT 001) agrega nuevos documentos.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-010

RETIRAR EXPEDIENTE

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "RETIRAR EXPEDIENTE". Este caso de uso se dará cuando un alumno tramite su retiro de la Universidad por razones personales.

Dependencias

(CU 005) Modificar Expediente.

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

El Actor (ACT 001) ejecuta retiro de alumno.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-011

EGRESAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "EGRESAR". Este caso de uso se dará cuando un alumno tramite constancia de Egresado.

Dependencias

(CU 005) Modificar Expediente.

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el expediente del alumno deseado.

4

El Actor (ACT 001) modifica el estado del expediente.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

c) SUB - SISTEMA DE ALUMNOS

Fig. III.6 Diagrama de Gestión de Alumnos

Monografias.comFuente: Propia

CU-012

NUEVO ALUMNO

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "NUEVO ALUMNO".

CU-013

MODIFICAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "MODIFICAR" (Datos del Alumno) En este modulo se modificaran datos del Alumno.

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados al alumno deseado.

4

Modifica datos del alumno.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-014

ELIMINAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "ELIMINAR" (Datos del Alumno).

Dependencias

-

Precondición

El alumno debe estar registrado en la Base de Datos.

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados al alumno deseado.

4

Elimina registro del alumno.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

D) SUB - SISTEMA DE ADMINISTRACIÓN

Fig. III.7 Diagrama de Administración del Sistema

Monografias.com

Fuente: Propia

Podemos hallar las siguientes relaciones:

Fig. III.8 Diagrama de Administración de Especialidad

Monografias.com

Monografias.com

Fig. III.9 Diagrama de Administración de Facultad

Fuente: Propia

Monografias.com

Fig. III.10 Diagrama de Administración de Sedes

Fuente: Propia

Fig. III.11 Diagrama de Administración de Documentos

Monografias.com

Fuente: Propia

Diagrama de Administración del Sistema:

CU-015

MODIFICAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "MODIFICAR" En este modulo se modificaran datos.

Dependencias

-

Precondición

Secuencias Normal

N

Acción

1

El Actor (ACT 001) realiza la búsqueda (CU 002)

2

El sistema muestra los resultados de la búsqueda.

3

El Actor (ACT 001) selecciona de entre los resultados el deseado.

4

Modifica datos del Sistema.

5

Confirma y finaliza el caso de Uso.

Post condición

-

Excepciones

N

Acción

1

Si el sistema no encuentra resultados para la búsqueda, el sistema se lo indica al actor y vuelve al paso 1, a continuación este caso de uso continúa.

5

Si el Actor (ACT 001) no confirma, no se guardaran los cambios.

Comentarios

El Actor (ACT 001) podrá cancelar en cualquier momento el caso de Uso.

CU-016

NUEVO

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "nuevo".

CU-017

ELIMINAR

Versión

1.0

Actor

ACT 001

Descripción

El sistema deberá comportarse tal como se describe en este C.U. cuando seleccione "ELIMINAR".

Dependencias

-

Precondición

-

Secuencia normal

N

Acción

1

Se realiza el caso de uso Buscar (CU-002)

2

El Actor (ACT 001) confirma que desea eliminar.

3

El sistema elimina de la B.D.

4

El sistema finaliza el caso de uso.

Post condición

La base de datos ha de estar en un estado consistente

Excepciones

N

Acción

1

Si la búsqueda no finalizo exitosamente, el sistema finaliza el caso de uso, a continuación este caso de uso queda sin efecto.

2

Si no lo confirma, el sistema refleja la excepción, a continuación este caso de uso queda sin efecto.

Comentarios

Ninguno.

Personal de Archivo

ACT-001

PERSONAL DE ARCHIVO

Versión:

1.0 ( 20/03/2008 )

Autor

Orlando Jimmy Mamani Poma

Fuentes:

Descripción:

Este actor representa la persona que tiene permisos para gestionar todo el sistema

Comentarios:

Ninguno

Administrativo

ACT-002

Administrativo

Versión:

1.0 ( 20/03/2008 )

Autor

Orlando Jimmy Mamani Poma

Fuentes:

Descripción:

Este actor representa la persona que interacciona con los expedientes

Comentarios:

Ninguno

  • APLICANDO METODOLOGIA OOHDM:

Para Diseñar el sistema de Archivo en se uso la metodología OOHDM en el cual se desarrollo usando los siguientes pasos.

Según Según OOHDM, el desarrollo de aplicaciones de hypermedia ocurre cuando cuatro actividades se procesan:

  • Modelo Conceptual

  • Diseño Navegacional

  • Diseño Interfaz Abstracta

  • Implementación

  • Modelo Conceptual.

Para tener una mejor idea del concepto del esquema conceptual; graficaremos los diagramas de clases, relaciones. Las clases son descritas como de costumbre en el modelo orientado a objetos.

Monografias.com

Fig. III. 12 Diagrama de ClasesFuente: Propia

  • Diseño Navegacional.

El diseño navegacional en OOHDM corresponde a un conjunto de modelos que se van desarrollando paso a paso, es el esquema del sitio Web.

El diseño Navegacional de Siarch se divide en dos Niveles:

  • Nivel usuarios

  • Nivel Administración

  • Nivel de Usuarios.

Este nivel comprende el modo de navegación básico, es decir en donde los usuarios podrán realizar consultas al sistema.

Monografias.com

Fig. III. 13 Diagrama Navegacional, nivel usuariosFuente: Propia

3.3.2.2. Nivel de Administración.

Este nivel comprende el modo de personalización del sistema, es decir en donde el administrador podrá realizar modificaciones al sistema.

Monografias.com

Fig. III. 14 Diagrama Navegacional, nivel AdministraciónFuente: Propia

3.3.2.3. Diagrama General Navegacional.

Monografias.com

Fig. III.15 Diagrama Navegacional, nivel GeneralFuente: Propia

  • Diseño Interfaz Abstracta

Una vez finalizado el diseño navegacional, será necesario especificar las diferentes interfaces de la aplicación. Esto significa definir.

Fig. III.16 ADV: AGREGAR ALUMNO

Monografias.com

Fuente: Propia

Fig. III.17 ADV: BUSCAR ALUMNO

Monografias.com

Fuente: Propia

Fig. III.18 ADV: MODIFICAR ALUMNO

Monografias.com

Fuente: Propia

Monografias.com

Fig. III.19 ADV: TRASLADAR ALUMNO

Fig. III.20 ADV ESTADO DE EXPEDIENTE

Monografias.com

Fuente: Propia

Monografias.com

Fig. III.21 ADV REALIZAR PRESTAMO DE EXPEDIENTE

Fuente: Propia

Fig. III.22 ADV DEVOLUCIÓN DE EXPEDIENTE

Monografias.com

Fuente: Propia

Monografias.com

Fig. III.23 ADV PERSONALIZAR FACULTAD

Fuente: Propia

Monografias.com

Fig. III.24 ADV PERSONALIZAR ESPECIALIDAD

Fuente: Propia

Monografias.com

Fig. III.25 ADV PERSONALIZAR SEDES

Fuente: Propia

El modelo Entidad/Relación se basa en entidades y en las interrelaciones que se establecen entre estas entidades y pone énfasis en el tipo de interrelaciones y la cardinalidad que hay entre los elementos.

Fig. III.26 MODELO ENTIDAD / RELACIÓN

Monografias.com

Fuente: Propia

En esta fase el objetivo es transformar el esquema conceptual obtenido en la fase previa, adaptándola al modelo de datos (relacional) que se va a utilizar y de acuerdo a un SGBD particular. La meta de esta fase es producir un Esquema lógico que sea eficiente para las operaciones de consulta y actualización.

Fig. III.27 MODELO LOGICO DE LA BASE DE DATOS

Monografias.com

Fuente: Propia

En esta fase el objetivo es conseguir transformar el esquema lógico es un esquema físico. Un Esquema físico es la implantación en términos de almacenamiento y de métodos de acceso, lo más eficiente posible.

Fig. III.28 MODELO FISICO DE LA BASE DE DATOS

Monografias.com

Fuente: Propia

  • IMPLEMENTACIÓN:

Para construir la base de datos utilizaremos la herramienta MySQL Maestro con el cual construiremos la base de datos. En las siguientes imágenes se muestra paso a paso los pasos realizados para el desarrollo.

Monografias.com

Fig.III.29: Ventana de creación de nombre de la base de datos.

Fuente: Elaboración Propia.

Monografias.com

Fig.III.30: Conexión con el servidor local

Fuente: Elaboración Propia

Monografias.com

Fig.III.31: Base de datos Creada

Fuente: Elaboración Propia

Monografias.com

Fig.III.32: Conectando la base de datos

Fuente: Elaboración Propia

Monografias.com

Fig.III.33: Editando la tabla

Fuente: Elaboración Propia

Monografias.com

Fig.III.34: Editando los campos de la tabla

Fuente: Elaboración Propia

Monografias.com

Fig.III.35: Tablas del sistema siarch

Fuente: Elaboración Propia

  • Tablas del Sistema de Archivo.

Resultado final donde se muestran las tablas generadas después de todo el proceso.

Una vez culminado la generación de las tablas, es necesario verificar dicha generación, por el motivo el cual iremos al servidor del MySQL, y seleccionaremos la Base de datos siarch, el cual se mostrara con las tablas ya creadas y se muestra a continuación:

Monografias.com

Fig.III.36: Servidor MySQL, donde se muestra tablas generadas

Fuente: Elaboración Propia

CAPÍTULO IV

RESULTADOS DE LA PRÁCTICA REALIZADA

  • 4.1. DESCRIPCIÓN E INTERFACES DEL SISTEMA

En este capítulo se realizará la descripción del Sistema de Administración de los expedientes de la UJCM SIARCH (Sistema de Administración de Archivo).

El sistema se subdivide de dos módulos básicos para el control y verificación del sistema:

  • Modulo de Administración.

  • Modulo de Consulta.

  • MÓDULO DE CONSULTA:

Monografias.com

Descripción del modulo consulta de expedientes, el cual es la siguiente Figura:

Monografias.com

Datos: Resultados de búsqueda, se muestran datos básicos del alumno además de 4 pestañas que muestran más datos sobre su expediente.

En la siguiente imagen se muestran los detalles de las siguientes Pestañas:

  • Datos: Muestra datos básicos del alumno.

  • Docs: Muestra los documentos que tiene el alumno en su expediente.

  • Traslados: Muestra los posibles traslados internos o externos de carrera.

  • Prestamos: Muestra los movimientos del expediente en las áreas que haya sido solicitado el mismo.

  • DOCS: Documentos Del Expediente De Cada Alumno

Monografias.com

Fig. IV.3: Documentos que contiene el expediente

Fuente: Elaboración Propia

  • Traslados: Si el Alumno hace traslado de carrera se registra en este modulo.

Monografias.com

Fig. IV.4: Traslado Interno o cambio de carrera

Fuente: Elaboración Propia

  • Prestamos: Este modulo sirve para saber los movimientos del expediente a las diferentes oficinas de la Universidad.

Monografias.com

Fig.IV.5 : Prestamos de expediente.

Fuente: Elaboración Propia

  • MÓDULO DE ADMINISTRACIÓN:

Para entrar al sistema primero tiene que teclear el usuario y password para tener acceso en este caso para ingresar al sistema tendrá que escribir:

Usuario: admin

Password: admin

Monografias.com

Fig.IV.6: Control de Acceso

Fuente: Elaboración Propia

Para poder acceder a este modulo deberá escribir esta dirección:

http://localhost/siarch/admin/index.php

La dirección del sistema web es variable depende de la configuración del servidor, ya sea a nivel local o a través de internet.

  • Panel de Administración:

Desde aquí se administra todo el sistema, como se muestra en la imagen:

  • Facultad.

  • Especialidad.

  • Sede.

  • Oficina.

  • Tipo de Documento.

  • Modo de Documento.

  • Buscar Alumno.

  • Ingresar Alumno.

  • Ver Préstamos.

  • Devolver Préstamos.

Monografias.com

Fig.IV.7: Panel de Administración

Fuente: Elaboración Propia

  • Facultad: Permite personalizar y listar las facultades de la UJCM.

Monografias.com

Fig.IV.8: Menú Facultad

Fuente: Elaboración Propia

4.3.3. Especialidad: Permite personalizar y listar las carreras de la UJCM.

Monografias.com

Fig.IV.9: Menú especialidad

Fuente: Elaboración Propia

4.3.4. Sede: Permite personalizar y listar las sedes de la UJCM.

Monografias.com

Fig. IV.10: Menú sedes

Fuente: Elaboración Propia

4.3.5. Oficina. Permite personalizar y listar las Oficinas de la UJCM.

Monografias.com

Fig.IV.11: Menú Oficinas

Fuente: Elaboración Propia

  • Tipo Documento: Permite personalizar los documentos que contiene el expediente.

Monografias.com

4.3.7. Modo de Documento. Permite personalizar el detalle de los documentos que contiene el expediente.

Monografias.com

  • Buscar Alumno: En el modulo de administración el resultado de la búsqueda genera más opciones de administración del expediente.

Monografias.com

Fig.IV.14: Resultados de búsqueda de alumnos

Fuente: Elaboración Propia

  • Ver: Nos muestras datos del alumno con más detalle al igual que en la vista de consulta mediante el modo administración podemos hacer cambios ya sea, ver, modificar, eliminar, guardar, cancelar y hacer traslados de carrera o sede.

  • Pantallas de Opciones del menú buscar alumno.

Monografias.com

Monografias.com

Fig.IV.15: Detalles de búsqueda de alumno

Fuente: Elaboración Propia

  • Ingresar Alumno. Mediante es modulo ingresaremos los alumnos al sistema de archivo en el cual especificaremos nombres, apellidos, carrera, facultad, además de los documentos que contiene sus expediente y el lugar de ubicación en donde será colocado el expediente para una búsqueda más rápida mediante el sistema.

Monografias.com

Fig.IV.16: Detalles de ingreso de expediente de alumnos.

Fuente: Elaboración Propia

Esta es una parte muy importante del sistema dado a que es aquí donde inicia todo el ingreso de datos al sistema para brindar información para realizar los trámites correspondientes.

  • Para iniciar ubicamos el icono de ingreso de alumnos situado en la página principal del modulo de administración.

  • Al acceder a este vínculo nos mostrara campos básicos del alumno que se muestran en la siguiente imagen.

  • La pestaña Expend. hace referencia a la ubicación del expediente en la oficina de archivo.

  • Después de completar los datos básicos continuamos con la siguiente pestaña, que se refiere a los documentos que contiene cada expediente.

  • Una vez completado todos estos datos, guardamos y tenemos todos los datos ingresados al sistema.

Monografias.com

Fig. IV.17: Detalles de ingreso de expediente de alumnos.

Fuente: Elaboración Propia

Monografias.com

Fig. IV.18: Detalles de ingreso de expediente de alumnos.

Fuente: Elaboración Propia

Monografias.com

Después de llenar los datos del alumno pasamos a llenar el estado y ubicación del expediente.

Cuando un expediente es de un alumno de un ingreso reciente su estado será en Archivo.

Cuando un alumno es de un ingreso anterior puede que al hacer tramites, su expediente pase de una oficina a otra, y es aquí donde se varía el estado del expediente a prestado o varía según el caso.

Cada Alumno tiene en su expediente documentos que adjunta cuando ingresa a la Universidad, las cuales se ingresan mediante este modulo.

Luego de completar todos los datos, guardamos la información, para consolidar todos los datos en el sistema.

  • Prestar expedientes.

Para realizar préstamos entramos desde el menú principal a realizar préstamo desde el cual podremos, filtrar por facultad, especialidad y sede para obtener todos los expedientes que deseamos, luego de seleccionarlos ejecutamos prestar.

Monografias.com

Fig.IV.20: Formulario de préstamo de expedientes

Fuente: Elaboración Propia

  • Devolver Préstamos. Se accede desde el menú principal y se aplica en todos los casos de devolución de expedientes al archivo de expedientes.

Monografias.com

Fig.IV.21: Formulario de Devolución de expedientes

Fuente: Elaboración Propia

CAPÍTULO V

CONCLUSIONES Y RECOMENDACIONES

  • CONCLUSIONES

Se logró desarrollar el sistema informático obteniendo resultados positivos, en la OSAERC, con lo cual se cumple con el objetivo general, puesto que el sistema informático de gestión de expedientes desarrollado ha contribuido de manera eficiente en minimizar el tiempo en la búsqueda, ubicación y la actualización de documentos.

Se analizó los procesos de administración de archivos y se desprende que muchos de ellos son factibles de informatización. No solo en lo que respecta a control de documentos, sino también, dentro de las diversas funciones que se realizan dentro de la OSAERC.

Se logró diseñar el sistema informático usando la metodología OOHDM, por ser esta metodología una de las más usadas y de gran popularidad dentro del grupo de Metodologías Estructuradas.

Se utilizó el sistema Appserv para desarrollo de la aplicación; ya que permitió generar de manera sencilla y rápida las estructuras de almacenamiento de datos, además de garantizar la seguridad de los mismos.

Se logró desarrollar e implementar el sistema Informático para administrar los expedientes de la Universidad José Carlos Mariátegui con el lenguaje de Programación php que permite diseñar sistemas dinámicos.

  • RECOMENDACIONES

El desarrollo del Siarch, hace ver la necesidad de proseguir el proceso de informatización de las demás actividades que realizan dentro de la OSAERC, logrando así un avance Tecnológico y de Calidad de Gestión.

Se propone realizar un levantamiento de procesos a fondo, dentro de la OSAERC, logrando así la automatización de procesos dentro de toda la oficina buscando de esta manera conformar un sistema integrado.

Es recomendable apoyar a la metodología OOHDM con otras metodologías que complementen a esta, por ejemplo XP, u otras, para tener un sistema eficiente.

Se propone informatizar las demás funciones dentro de la oficina para lograr así un sistema de gestión administrativa que se ocupe de todas las operaciones realizadas dentro de la OSAERC.

Se propone una revisión de los reglamentos y normas para robustecer más el accionar del sistema y del personal en caso de presentarse casos especiales.

CAPÍTULO VI

BIBLIOGRAFÍA

  • 2. Universidad José Carlos Mariátegui (2003), Reglamento de Evaluación y Proceso de enseñanza, Primera Edición, Pág. 19, Perú.

  • 3. Universidad José Carlos Mariátegui (2006), Reglamento General de Estudios, Segunda Edición, Pág. 2, Perú.

  • 4. Monzon F.J. (2005) - "Análisis y Diseño de Sistemas Informático", Segunda Edición, Página 15

  • 5. Burch Jhon G. - Grudnitski,Gary (2007) "Diseño de Sistemas de Información", Wesley Iberoamericana, S.A. Quinta Edición. cita Pág. 23, U.S.A.

  • 6. James A. Senn (1996) "Análisis y Diseño de Sistemas Información", Segunda Edición, GRUPO EDITORIAL IBEROAMERICANA. Pág. 19, México.

  • 7. KENDALL Kenneth E., KENDALL Julie E. (1997), "Análisis y Diseño de Sistemas", PRENTICE HALL HISPANOAMERICANA, 3ra Edición, México

  • 15. Toboada Jiménez, Alberto "UML", Página 7

  • 16. Alarcón Raúl, "Diseño Orientado a Objetos con UML", Página 15

  • 17. Rumbaugh James, Jacobson I, Booch Gardy,(2000) "UML Lenguaje de Modelado Unificado", Madrid.

ANEXOS

ANEXO 1: Certificado de Practicas

Monografias.com

ANEXO 2

MODULO – CONEXIÓN CON EL SERVER

Monografias.com

Monografias.com

ANEXO 3

MODULO – BUSQUEDA

Monografias.com

ANEXO 4

MODULO – REPORTES DE PRÉSTAMOS DE EXPEDIENTES

Monografias.com

ANEXO 5

MODULO – REPORTES BUSQUEDA DE ALUMNOS

Monografias.com

DEDICATORIA

A las personas que desde un inicio me apoyaron que son mis padres.

A mis amigos y amigas por su apoyo y concejos.

Orlando Jimmy Mamani Poma

UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI

FACULTAD DE INGENIERÍASCARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

Monografias.com

Informe de Prácticas Pre Profesionales

Fecha de Práctica: 01 de Agosto 2006 al 10 de Agosto del 2007

Moquegua-Perú

2009

 

[1] Universidad José Carlos Mariátegui Información, Datos básicos de la Universidad José Carlos Mariátegui (Perú-2005), http://www.ujcm.edu.pe/web/index.php [Consultada el 15 de Febrero del 2008].

[2] Reglamento de Organización y Funciones 2004 (Moquegua-Perú, 2004), pp.1.

[3] Reglamento de Organización y Funciones 2004 (Moquegua-Perú, 2004), pp.1.

[4] Reglamento de Organización y Funciones 2004 (Moquegua-Perú, 2004), pp. 1.

[5] Reglamento de Organización y Funciones 2004 (Moquegua-Perú, 2004), pp. 35

[6] Monzon F.J. - “Análisis y Diseño de Sistemas Informático” Página 15

[7] Burch Jhon G. - Grudnitski,Gary “Diseño de Sistemas de Información”, cita Página 19

[8] James A. Senn “Análisis y Diseño de Sistemas Información”, Cita Página 19

[9] Kendall Kenneth E., Kendall Julie E., “Análisis y Diseño de Sistemas”

[10] PHP.net (2001-2008 ). ¿Que es PHP? [web en línea]. Disponible desde Internet en: http://www.php.net/tut.php

[11] Universidad Evangélica de El Salvador. Visión General. [web en línea]. Disponible desde Internet en: www.cvirtualuees.edu.sv/mod/book/view.php?id=552

[12] PHP.net (2001-2008). Historia Php [web en línea]. Disponible desde Internet en: http://www.php.net/~derick/meeting-notes.html

[13] By Robin Schumacher & Arjen Lentz (2008) “Dispelling the Myths” Information MySql. Sun Microsystems. [Publicación en línea] Disponible desde Internet en: http://dev.mysql.com/tech-resources/articles/dispelling-the-myths.html

[14] Wikipedia.org. MySql Historia y Aplicaciones [Publicación en línea] Disponible desde Internet en: http://es.wikipedia.org/wiki/MySQL#cite_note-0

[15] W3.org.(2007) World Wide Web Consortium. [Publicación en línea]. Disponible desde Internet en: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html

[16] W3.org.(2007) Index of elements in HTML 4. [Publicación en línea]. Disponible desde Internet en: http://www.w3.org/TR/1999/REC-html401-19991224/index/elements

[17] Inteco (2004). Norma UNE 139803:2004.Centro de Referencia en Accesibilidad y Estándares web. [web en línea]. Disponible en Internet en: http://www.inteco.es/Accesibilidad/Normativa_1/Descarga/DescargaUNE_139803

[18] Eric A. Meyer (2006) Cascading Style Sheets: The Definitive Guide, Third Edition [Publicación en línea] Disponible desde Internet en: http://oreilly.com/catalog/9780596527334/

[19] Toboada Jiménez, Alberto “UML”, Página 7

[20] Alarcón Raúl, “Diseño Orientado a Objetos con UML”, Página 15

[21] Rumbaugh James, Jacobson I., Booch Gardy “UML Lenguaje de Modelado Unificado”

[22] Schwabe, D. y Rossi, G. (1999). The Object-Oriented Hipermedia Design Model (OOHDM)

 

 

Autor:

Bach. Orlando Jimmy Mamani Poma

new_word2001[arroba]hotmail.com

Twitter: new_word


Artículo original: Monografías.com

Mantente al día de todas las novedades

Desarrollo de un Sistema Informático para la Administración de Expedientes de la Universidad José

Indica tu email.
Indica tu Provincia.
Al presionar "Enviar" aceptas las políticas de protección de datos y privacidad de Plusformación.
Avatar

exceltente sistema, deberias de compartir el proyecto se ve muy bueno...

Gracias por tu comentario Jack. Nos alegra que el recurso te haya sido útil.
Un saludo!

Escribir un comentario

Deja tu comentario/valoración:

El contenido de este campo se mantiene privado y no se mostrará públicamente.
Si especificas la url de tu página o perfil de Google+, aparecerá el avatar que tengas en Google+
Deja tu comentario y nosotros te informaremos
CAPTCHA
Esta pregunta se hace para comprobar que es usted una persona real e impedir el envío automatizado de mensajes basura.
10 + 7 =
Resuelva este simple problema matemático y escriba la solución; por ejemplo: Para 1+3, escriba 4.