CAPITULO III: MODELADO DEL SISTEMA
3.1. ANÁLISIS

3.1.1. Definir requisitos.

Al determinar los requisitos se utilizaron diversas fuentes, tales como: entrevistas, cuestionarios, entre otros; información, que se puede traducir en un formato a seguir para la especificación de requisitos. Este formato de especificación de requisitos no está definido en UML, pero se incluye este punto para resaltar esta actividad que es un paso clave en la creación de software. El formato incluye los siguientes puntos: - Metas o propósitos - Funciones del Sistema

Metas o propósitos

En términos generales, la meta es una mayor automatización de los datos académicos de un alumno, de un curso, y asimismo dar soporte a servicios más rápidos y mejores. Específicamente la meta incluye: * Control sobre el número de alumnos matriculados por especialidad. * Control del dinero ingresado por concepto de matriculas. * Control de los alumnos inscritos en un curso. * Control sobre la programación académica de un semestre. * Control sobre las notas de un alumno en cada semestre para generar reportes sobre el record académico y boletas de notas. * Control del número de aprobados y desaprobados de un curso. * Control sobre el número de alumnos con asignaturas a cargo y/o repitencia. * Control automático de deudas de los alumnos por concepto de matricula.

Funciones del Sistema

El objetivo de describir las funciones del sistema es entender los detalles del análisis y del diseño, no el funcionamiento de la institución académica. Las funciones pueden clasificarse en: Evidente (el usuario debe saber que se ha realizado) y Oculta (debe realizarse, aunque no es visible para el usuario).

A continuación el sistema presenta las siguientes funciones: Tabla III.1: Funciones del sistema.

3.1.2. Casos Esenciales de Uso

Un caso de uso es un documento narrativo que describe las secuencias de eventos de un actor (agente externo) y que constituyen un paso muy útil en las especificaciones del sistema. Dado que estos se clasifican en casos de uso de alto nivel y casos de uso expandidos; primero se ha iniciado por describir los casos de uso de alto nivel para lograr un rápido entendimiento de los procesos principales. A continuación se describen los casos de uso del sistema en desarrollo: 

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Jefe del DFGP envía al operador del SIA la programación de carreras del semestre actual. 2. El operador selecciona la carrera turno y ciclo programado en el semestre. 3. Determina el código programado. Muestra una lista de aulas disponibles.4. El operador selecciona un aula.5. Muestra el código, estado y ubicación del aula.6. Terminada dicha operación, el operador indica al SIA que capturé dicha programación.7. Captura la programación de la carrera en dicho semestre.

Cursos Alternos: - Línea 2: Si ya existe la programación de la carrera y sección se cancela dicha operación.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Jefe del DFGP envía al operador del SIA la distribución académica del semestre en curso. 2. El operador selecciona la carrera, turno y sección programada en el semestre.3. Determina una lista de las posibles asignaturas a programar de acuerdo a la carrera y sección.4. El operador selecciona el nombre de la asignatura a programar.5. Determina el código, tipo y número de horas de la asignatura.6. El operador ingresa el nombre del docente a cargo de la asignatura7. Determina el código del docente.8. Al terminar de registrar la asignatura programada y el respectivo docente, el operador indica que se concluyó la captura de la asignatura. 9. Se registra la programación de la asignatura. Calcula y presenta el total de horas programas a la carrera.

Cursos Alternos: - Línea 6: Invalidar búsqueda de nombre indicado.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Jefe del DFGP envía al operador del SIA el horario de las asignaturas de una determinada carrera - sección en un semestre. 2. El operador selecciona la carrera, turno y sección.3. Procesa una consulta de todas las asignaturas programadas en el semestre por carrera-sección y los muestra. 4. Por cada asignatura, el operador selecciona una asignatura e introduce el día y la hora respectiva.5. Determina el código, número de horas de la asignatura y aula especifica donde se dictará la asignatura.6. Al terminar de registrar el día y hora en que se dictará la asignatura, el operador le indica al SIA que concluyó la captura.7. Registra horario de la asignatura.8. El operador remite al Departamento de Formación General y Profesional un informe del cuadro de distribución de Horas de Clase de una carrera - sección e indica al DFGP que tiene disponibles los horarios por docente. 9. El Jefe del DFGP solicita un reporte de los horarios por docente. 10. El operador solicita al sistema un informe de horarios por docente. 11. Genera un reporte de horarios por docente. Cursos Alternos: - Línea 4: Día u hora no son válidos. Indicar error.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el operador solicita al SIA los deudores de un determinado semestre. 2. El operador introduce el año y semestre.3. Genera un informe de alumnos deudores clasificados por carrera profesional, indicando su saldo por concepto de matricula.4. Indica al sistema que imprima dicho reporte.5. Imprime reporte.6. El operador envía los reportes a Dirección para su uso correspondiente.

Cursos Alternos: - Línea 2: Año y semestre no válidos. Indicar error.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Secretario Docente entrega al operador del SIA la copia de la boleta de pago por derecho de matricula. 2. El operador verifica la copia de la boleta de pago: Si la boleta tiene adjunto el expediente de un nuevo alumno, iniciar Registrar nuevo alumno. De lo contrario, ingresa el código del alumno. 3. Determina el nombre, apellidos, carrera y ciclo al que pertenece el alumno. Muestra el costo de la matricula.4. El operador ingresa el número de la boleta, fecha y el pago respectivo.5. Actualiza y muestra el saldo de la matricula.6. Al terminar de registrar el pago, el operador indica al SIA capturar la matricula efectuada.7. Registra la matricula. 8. El operador retorna la boleta de pago al Secretario Docente.

Cursos alternos: - Línea 2: El código es incorrecto. Se indica el error y se cancela la operación. - Línea 4: Número de boleta ya existe. Se indica el error y se cancela la operación. Pago es mayor que el costo de matricula. Desplegar mensaje: Monto excedido. Caso de uso relacionado: Registrar Nuevo AlumnoCURSO NORMAL DE LOS EVENTOSAcción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el operador al verificar la copia de la boleta de pago por derecho de matricula tiene adjunto el expediente de un nuevo alumno. 2. El operador escoge la opción nuevo alumno. Y luego registra los datos del nuevo alumno.3. Muestra ventana que permite ingreso de datos del alumno. Genera el código del nuevo alumno y lo muestra. Captura los datos del nuevo alumno.4. El operador indica al SIA retornar a la pantalla anterior y prosigue.5. Muestra pantalla anterior.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Secretario Docente entrega al Operador del SIA la ficha de matricula con las asignaturas en las que se ha inscrito un alumno. 2. El operador ingresa el código del alumno. 3. Determina y muestra el nombre, carrera y ciclo correspondiente al alumno. Muestra una lista de las posibles asignaturas programadas para la especialidad y ciclo en que el alumno se ha matriculado. Determina y muestra las asignaturas de cargo y/o repitencia que el alumno tuviere.4. El operador verifica las secciones de las asignaturas: Por cada asignatura que pertenece al semestre, el operador selecciona la asignatura respectiva.5. Determina y muestra el código, número de horas de la asignatura. Muestra el nombre del docente que estará a cargo de la asignatura.6. Al terminar de registrar la asignatura, el operador indica al SIA que añada el curso a la inscripción de cursos.7. Captura la inscripción de la asignatura. Muestra el total de horas que hasta ese momento el alumno lleva.8. Al terminar de registrar los cursos, el operador remite la copia de la ficha de matricula al Secretario Docente.

Cursos Alternos: - Línea 2: El código es incorrecto. Desplegar error y cancelar la operación.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el Director autoriza y firma la Ficha de Datos del nuevo docente, para posteriormente enviarla al operador del sistema. 2. El operador registra la información del docente.

3. Al terminar el operador indica al SIA que ha concluido el ingreso de datos.4. Registra el nuevo docente.5. El operador retorna la ficha de datos del docente.

CURSO NORMAL DE LOS EVENTOS

Acción de los ActoresRespuesta del Sistema1. Este caso de uso comienza cuando el operador del sistema enciende el equipo de cómputo para utilizar el sistema. 2. El operador hace clic en el icono del Sistema de Información Académica.3. Presenta el formulario Acceso al Sistema. 4. El operador ingresa la clave y contraseña de usuario.5. Si clave y contraseña son correctas ingresa al Menú Principal. De lo contrario muestra un mensaje de error "Ingrese clave y contraseña correcta".6. El operador tiene la disponibilidad de usar el sistema para la operación que quiera ejecutar.

Cursos Alternos: - Línea 4: Error clave y contraseña no son válidas. Indicar error y cancelar operación. 3.1.3. Crear Diagramas de casos de Uso. La figura III.1 describe el Sistema de Información Académico del ISTMYE, el sistema tiene cuatro actores: Jefe del DFGP, Secretario Docente, Director y Operador del Sistema (Asistente del Secretario Docente). Algunos de ellos no interactúan directamente con el sistema, pero se les incluye para darle mayor claridad a la descripción de su funcionalidad (este criterio se ha basado en el método de desarrollo orientado a objetos que propone Craig Larman en su publicación "UML Y PATRONES"; a su vez Xavier Ferré Grau y María Isabel Sánchez Segura de la U.P.M en su publicación: "Desarrollo Orientado a Objetos con UML").