lunes, 5 de diciembre de 2011
3.5.2 CASOS DE USO A NIVEL ESENCIAL
3.5.2 CASOS DE USO A NIVEL ESENCIAL
3.5.2.1 Inscripción
1. Diagrama de Caso de Uso de Inscripciones
3.5 REQUERIMIENTOS
3.5.1 CASOS DE USO A NIVEL EXPANDIDO
Caso de Uso Expandido: Cada caso de uso tiene su propósito, resumen, tipo y referencias; que estas van incorporada al sistema propuesto que se mostrara a continuación.
Curso Normal de Eventos:
ü Flujos de Información:
a) Pasos que sigue el proceso de Inscripción y Registro:
El proceso de Inscripción y Registro es el primer paso que realizan los padres para que sus hijos puedan pertenecer legalmente a la Unidad Educativa “IRENE NAVA” los pasos a seguir para dicha inscripción son las siguientes:
1. Los padres del niño y/o adolescente solicitan información sobre que documentos se debe presentar para poder inscribir a la Unidad Educativa “TAIWAN” a sus hijos.
2. El sistema proporciona información de todos los documentos que se debe presentar para poder acceder al beneficio.
3. La secretaria de la Unidad Educativa “TAIWAN” proporciona a los padres del niño o adolescente la boleta de compromiso que deben llenar y firmar.
4. Cumplidos con todos los requisitos Los padres presentan los documentos del niño y/o adolescente a la secretaria.
5. La secretaria ordena y verifica toda la documentación y si falta alguna o estos no son los documentos pedidos se procederá a dar nuevamente orientación sobre que requisitos debe adjuntar el niño y/o adolescente.
6. Una vez cumplidos con todos los requisitos la secretaria procede a adjuntar a todos los requisitos anteriores la ficha social del niño y/o adolescente.
7. Posteriormente la secretaria procede a abrir el cuaderno de registro de inscritos
8. La secretaria verifica toda la documentación presentada y procede a registrar los datos necesarios que se necesitan para la inscripción.
Curso Normal de Eventos:
ü Flujos de Información:
a) Pasos que sigue el proceso de Control de asistencia:
El Control de asistencia es un listado que contiene un detalle de las asistencias y faltas del alumno(a) mensualmente durante todo el año.
1. El educador registra la asistencia del alumno (a) en aula.
2. El educador hace la entrega del registro de asistencia a la secretaria.
3. La secretaria registra y está disponible para cualquier consulta de parte del padre de familia o tutor.
· Educadores:
Curso Normal de Eventos:
ü Flujos de Información:
a) Pasos que sigue el proceso de Control de asistencia:
Este proceso de educadores/docentes contiene un horario de consulta en el cual el padre de familia o tutor puede adquirir información sobre el alumno(a).
1. El padre de familia o tutor solicita información del educador/docente del alumno(a).
2. La secretaria informa y provee el listado de educadores/docentes al padre de familia o tutor.
3. El padre de familia o tutor realiza la consulta al educador/docente.
Curso Normal de Eventos:
ü Flujos de Información:
a) Pasos que sigue el proceso de Control de asistencia:
El cronograma de actividades es un listado que contiene un detalle de las actividades a realizar durante el año con los alumnos de la Unidad Educativa “IRENE NAVA”.
1. El educador solicita un informe del cronograma de actividades.
2. La secretaria hace la entrega del cronograma de actividades.
3.4 FASE DE ELABORACIÓN
3.4.1 MODELO DE CASOS DE USO (ALTO NIVEL)
Por Casos de Uso (Tipo Texto)
Caso Uso de Alto Nivel: Cada caso de uso tiene descripción que especifica la funcionalidad que se incorpora al sistema propuesto. Se mostrara a continuación los casos de uso más importantes.
· Inscripción:
3.3.3 MODELO DE CASOS DE USO DEL SISTEMA
3.3.3 MODELO DE CASOS DE USO DEL SISTEMA
Un modelo de caso de uso del sistema describe lo que hace el sistema, este modelo contiene actores, casos de uso y sus relaciones.
En las siguientes figuras se muestra la relación que existe entre los actores y los casos de uso identificados.
Primera Iteración:
· Inicio de Gestión
Segunda Iteración:
· Finalización de Gestión
Tercera Iteración:
· Diagrama para Sistema de Información Administrativa de la Unidad Educativa “TAIWAN”.
EL PROCESO DE EJECUCIÓN DEL SISTEMA
3.3.2 MODELO DE CASOS DE USO DEL NEGOCIO
3.3.2 MODELO DE CASOS DE USO DEL NEGOCIO
En el modelado del negocio describe la funcionalidad de la gestión administrativa de inscripciones, para el cual se desarrolla el sistema, este modelo desarrolla el modelo de casos de uso y actores del negocio.
3.2 FASE DE INICIO
3.2 FASE DE INICIO
En esta fase se establece el contexto del sistema mediante casos de uso logrando definir el alcance del proyecto. Para lograr tal efecto se debe conocer el ámbito del sistema, se define los límites del mismo para proponer una arquitectura, identificar los riesgos, identificar los actores y la interacción de los mismos.
3.2 RUP
3.2 RUP
En este capítulo se desarrolla la solución al problema planteado, para obtener un producto software que brinde información académica de la Unidad Educativa IRENE NAVA”.
La metodología que se emplea es el Proceso Unificado de Desarrollo de software (RUP), y los diagramas UML descritos en el Capitulo 2.
CAPITULO III
CAPITULO III
3. DESARROLLO
El presente proyecto se va desarrollar bajo la siguiente metodología RUP que toma en cuenta como Lenguaje de Programación Java, con el sistema Gestor Base de Datos, MSQL.
2.6.4 ORACLE
2.6.4 ORACLE
Oracle es un sistema de gestión de base de datos relacional (o RDBMS por el acrónimo en inglés de Relational Data Base Management System), desarrollado por Oracle Corporation.
Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su:
Oracle surge a finales de los 70 bajo el nombre de Relational Software a partir de un estudio sobre SGBD (Sistemas Gestores de Base de Datos) de George Koch. Computer World definió este estudio como uno de los más completos jamás escritos sobre bases de datos.
En la actualidad, Oracle (Nasdaq: ORCL) todavía encabeza la lista. La tecnología Oracle se encuentra prácticamente en todas las industrias alrededor del mundo y en las oficinas de 98 de las 100 empresas Fortune 100. Oracle es la primera compañía de software que desarrolla e implementa software para empresas 100 por ciento activado por Internet a través de toda su línea de productos: base de datos, aplicaciones comerciales y herramientas de desarrollo de aplicaciones y soporte de decisiones.
Oracle a partir de la versión 10g Release 2, cuenta con 5 ediciones:
· Oracle Database Enterprise Edition(EE).
· Oracle Database Standard Edition (SE).
· Oracle Database Standard Edition One (SE1).
· Oracle Database Express Edition (XE).
· Oracle Database Personal Edition (PE).
2.6.3 MySQL
2.6.3 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 —desde enero de 2008 una subsidiaria de Sun Microsystems— desarrolla MySQL como software libre en un esquema de licenciamiento dual.
Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia específica que les permita este uso. Está desarrollado en su mayor parte en ANSI C.
MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. 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.
2.6.2 SQlite
2.6.2 SQlite
SQLite es un sistema de gestión de bases de datos relacional compatible con ACID, contenida en una relativamente pequeña (~275 kiB)[2] biblioteca en C. SQLite es un proyecto de dominio público[1] creado por D. Richard Hipp.
A diferencia de los sistemas de gestión de bases de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de eso, la biblioteca SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones. Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son más eficientes que la comunicación entre procesos. El conjunto de la base de datos (definiciones, tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina host. Este diseño simple se logra bloqueando todo el fichero de base de datos al principio de cada transacción.
En su versión 3, SQLite permite bases de datos de hasta 2 Terabytes de tamaño, y también permite la inclusión de campos tipo BLOB.
El autor de SQLite ofrece formación, contratos de soporte técnico y características adicionales como compresión y cifrado.
2.6.1 POSTGRESQL
2.6.1 POSTGRESQL
Como muchos otros proyectos de código abierto, el desarrollo de PostgreSQL no es manejado por una empresa y/o persona, sino que es dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyados por organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreSQL Global Development Group).
Nombre del producto
El uso de caracteres en mayúscula en el nombre PostgreSQL puede confundir a algunas personas a primera vista. Las distintas pronunciaciones de "SQL" pueden llevar a confusión.
Es también común oír abreviadamente como simplemente "Postgres", el que fue su nombre original. Debido a su soporte del estándar SQL entre la mayor parte de bases de datos relacionales, la comunidad consideró cambiar el nombre al anterior Postgres. Sin embargo, el PostgreSQL Core Team anunció en 2007 que el producto seguiría llamándose PostgreSQL. El nombre hace referencia a los orígenes del proyecto como la base de datos "post-Ingres", y los autores originales también desarrollaron la base de datos Ingres.
Historia
PostgreSQL ha tenido una larga evolución, la cual se inicia en 1982 con el proyecto Ingres en la Universidad de Berkeley. Este proyecto, liderado por Michael Stonebraker, fue uno de los primeros intentos en implementar un motor de base de datos relacional. Después de haber trabajado un largo tiempo en Ingres y de haber tenido una experiencia comercial con él mismo, Michael decidió volver a la Universidad en 1985 para trabajar en un nuevo proyecto sobre la experiencia de Ingres, dicho proyecto fue llamado post-ingres o simplemente POSTGRES.
El proyecto post-ingres pretendía resolver los problemas con el modelo de base de datos relacional que habían sido aclarados a comienzos de los años 1980. El principal de estos problemas era la incapacidad del modelo relacional de comprender "tipos", es decir, combinaciones de datos simples que conforman una única unidad. Actualmente estos son llamados objetos. Se esforzaron en introducir la menor cantidad posible de funcionalidades para completar el soporte de tipos. Estas funcionalidades incluían la habilidad de definir tipos, pero también la habilidad de describir relaciones - las cuales hasta ese momento eran ampliamente utilizadas pero mantenidas completamente por el usuario. En Postgres la base de datos «comprendía» las relaciones y podía obtener información de tablas relacionadas utilizando reglas. Postgres usó muchas ideas de Ingres pero no su código.
La siguiente lista muestra los hitos más importantes en la vida del proyecto Postgres.
· 1986: Se publicaron varios papers que describían las bases del sistema.
· 1988: Ya se contaba con una versión utilizable.
· 1989: El grupo publicaba la versión 1 para una pequeña comunidad de usuarios.
· 1990: Se publicaba la versión 2 la cual tenía prácticamente reescrito el sistema de reglas.
· 1991: Publicación de la versión 3, esta añadía la capacidad de múltiples motores de almacenamiento.
· 1993: Crecimiento importante de la comunidad de usuarios, la cual demandaba más características.
· 1994: Después de la publicación de la versión 4, el proyecto terminó y el grupo se disolvió.
Después de que el proyecto POSTGRES terminara, dos graduados de la universidad, Andrew Yu y Jolly Chen, comenzaron a trabajar sobre el código de POSTGRES, esto fue posible dado que POSTGRES estaba licenciado bajo la BSD , y lo primero que hicieron fue añadir soporte para el lenguaje SQL a POSTGRES, dado que anteriormente contaba con un intérprete del lenguaje de consultas QUEL (basado en Ingres), creando así el sistema al cual denominaron Postgres95.
Para el año 1996 se unieron al proyecto personas ajenas a la Universidad como Marc Fournier de Hub.Org Networking Services, Bruce Momjian y Vadim B. Mikheev quienes proporcionaron el primer servidor de desarrollo no universitario para el esfuerzo de desarrollo de código abierto y comenzaron a trabajar para estabilizar el código de Postgres95.
En el año 1996 decidieron cambiar el nombre de Postgres95 de tal modo que refleje la característica del lenguaje SQL y lo terminaron llamando PostgreSQL, cuya primera versión de código abierto fue lanzada el 1 de agosto de 1996. La primera versión formal de PostgreSQL (6.0) fue liberada en enero de 1997. Desde entonces, muchos desarrolladores entusiastas de los motores de base de datos se unieron al proyecto, coordinaron vía Internet y entre todos comenzaron a incorporar muchas características al motor.
Aunque la licencia permitía la comercialización de PostgreSQL, el código no se desarrolló en principio con fines comerciales, algo sorprendente considerando las ventajas que PostgreSQL ofrecía. La principal derivación se originó cuando Paula Hawthtorn (un miembro del equipo original de Ingres que se pasó a Postgres) y Michael Stonebraker conformaron Illustra Information Technologies para comercializar Postgres.
En 2000, ex inversionistas de Red Hat crearon la empresa Great Bridge para comercializar PostgreSQL y competir contra proveedores comerciales de bases de datos. Great Bridge auspició a varios desarrolladores de PostgreSQL y donó recursos de vuelta a la comunidad, pero a fines de 2001 cerró debido a la dura competencia de compañías como Red Hat y pobres condiciones del mercado.
En 2001, Command Prompt, Inc. lanzó Mammonth PostgreSQL, la más antigua distribución comercial de PostgreSQL. Continúa brindando soporte a la comunidad PostgreSQL a través del auspicio de desarrolladores y proyectos, incluyendo PL/Perl, PL/php y el alojamiento de proyectos de comunidades como PostgreSQL Build Farm.
En enero de 2005, PostgreSQL recibió apoyo del proveedor de base de datos Pervasive Software, conocido por su producto Btrieve que se utilizaba en la plataforma Novell Netware. Pervasive anunció soporte comercial y participación comunitaria y logró algo de éxito. Sin embargo, en julio de 2006 dejó el mercado de soporte de PostgreSQL.
A mediados de 2005 otras dos compañías anunciaron planes para comercializar PostgreSQL con énfasis en nichos separados de mercados. EnterpriseDB añadió funcionalidades que le permitían a las aplicaciones escritas para trabajar con Oracle ser más fáciles de ejecutar con PostgreSQL. Greenplum contribuyó mejoras directamente orientadas a aplicaciones de Data Warehouse e Inteligencia de negocios, incluyendo el proyecto BizGres.
En octubre de 2005, John Loiacono, vicepresidente ejecutivo de software en Sun Microsystems comentó: "No estamos yendo tras el OEM de Microsoft pero estamos viendo a PostgreSQL ahora", aunque no se dieron especificaciones en ese momento. Para noviembre de 2005, Sun Solaris 10 (lanzamiento 6/06) incluía PostgreSQL.
En agosto de 2007 EnterpriseDB anunció el Postgres Resource Center y EnterpriseDB Postgres, diseñados para ser una completamente configurada distribución de PostgreSQL incluyendo muchos módulos contribuidos y agregados. EnterpriseDB Postgres fue renombrado Postgres Plus en marzo de 2008.
El proyecto PostgreSQL continúa haciendo lanzamientos principales anualmente y lanzamientos menores de reparación de bugs, todos disponibles bajo la licencia BSD, y basados en contribuciones de proveedores comerciales, empresas aportantes y programadores de código abierto mayormente.
Características de PostgreSQL
Algunas de sus principales características son, entre otras:
Alta concurrencia
Mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en inglés) PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una visión consistente de lo último a lo que se le hizo commit. Esta estrategia es superior al uso de bloqueos por tabla o por filas común en otras bases, eliminando la necesidad del uso de bloqueos explícitos.....
Amplia variedad de tipos nativos
PostgreSQL provee nativamente soporte para:
· Números de precisión arbitraria.
· Texto de largo ilimitado.
· Figuras geométricas (con una variedad de funciones asociadas).
· Direcciones IP (IPv4 e IPv6).
· Bloques de direcciones estilo CIDR.
· Direcciones MAC.
· Arrays.
Adicionalmente los usuarios pueden crear sus propios tipos de datos, los que pueden ser por completo indexables gracias a la infraestructura GiST de PostgreSQL. Algunos ejemplos son los tipos de datos GIS creados por el proyecto PostGIS.
Otras características
Claves ajenas también denominadas Llaves ajenas o Claves Foráneas (foreign keys).
Disparadores (triggers): Un disparador o trigger se define como una acción específica que se realiza de acuerdo a un evento, cuando éste ocurra dentro de la base de datos. En PostgreSQL esto significa la ejecución de un procedimiento almacenado basado en una determinada acción sobre una tabla específica. Ahora todos los disparadores se definen por seis características:
· El nombre del disparador o trigger.
· El momento en que el disparador debe arrancar.
· El evento del disparador deberá activarse sobre...
- La tabla donde el disparador se activará.
- La frecuencia de la ejecución.
- La función que podría ser llamada.
Entonces combinando estas seis características, PostgreSQL le permitirá crear una amplia funcionalidad a través de su sistema de activación de disparadores (triggers).
· Vistas.
· Integridad transaccional.
· Herencia de tablas.
· Tipos de datos y operaciones geométricas.
Funciones
Bloques de código que se ejecutan en el servidor. Pueden ser escritos en varios lenguajes, con la potencia que cada uno de ellos da, desde las operaciones básicas de programación, tales como bifurcaciones y bucles, hasta las complejidades de la programación orientada a objetos o la programación funcional.
Los disparadores (triggers en inglés) son funciones enlazadas a operaciones sobre los datos.
Algunos de los lenguajes que se pueden usar son los siguientes:
· Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).
· C.
· C++.
· Java PL/Java web.
· PL/Perl.
· plPHP.
· PL/Python.
· PL/Ruby.
· PL/sh.
· PL/Tcl.
· PL/Scheme.
· Lenguaje para aplicaciones estadísticas R por medio de PL/R.
PostgreSQL soporta funciones que retornan "filas", donde la salida puede tratarse como un conjunto de valores que pueden ser tratados igual a una fila retornada por una consulta (query en inglés).
Suscribirse a:
Entradas (Atom)