Diseñode Sistema SMA

Proyecto SMA
Sistema de Mantenimiento
de Alumnos
Diseño de Sistemas
Versión 1.03
Preparado por: Julio Curi Huamaní.

Rol: Analista de Sistemas
Abril, 2019
Proyecto: ABC- Sistema de Control de Tiempos
Diseño de Sistemas
CONTROL DE VERSIONES
PARTES QUE DESCRIPCIÓN DEL FECHA DE MODIFICADO REVISADO APROBADO

VERSIÓN
CAMBIAN CAMBIO CAMBIO POR POR POR
Fernando Fernando
1.00 Versión Inicial 13/07/2007 Miguel Paredes
Barahona Barahona
Cambios en la
Se incorporó la
estructura del
sección: 6.
1.01 documento de 24/08/2007 Miguel Paredes
INTEGRACION
acuerdo al estándar
DEL SOFTWARE
del CMMI.
En la sección:
Relación Entre
Componentes y
Requerimientos Observaciones
Func., se enviadas por el
1.02 09/10/2007 Miguel Paredes
completó la equipo de mejora de
información procesos CMMI
faltante
relacionada a las
versiones.
TABLA DE CONTENIDOS
Formato: 02.1.09.03 Pág. 2 de 22
Versión: 1.00 - 13/07/2007 MÉTODOLOGIA GLOBAL DE SOFTWARE Archivo:
Dsño_Sstma v1.03.doc
Ubicación: RAP Actualización: 09/10/2007
Diseño de Sistemas
1. INTRODUCCION.............................................................................................................................. 4
1.1 OBJETIVO..................................................................................................................................... 4
1.2 AMBITO DE APLICACIÓN............................................................................................................ 4
1.3 REFERENCIAS............................................................................................................................. 4
2. ANÁLISIS DE LA SOLUCIÓN.......................................................................................................... 5
2.1 EVALUACIÓN TÉCNICA PRELIMINAR........................................................................................5
2.1.1 DESCRIPCIÓN DE ALTERNATIVAS DE SOLUCIÓN PRELIMINARES....................................5
2.1.2 EVALUACIÓN TÉCNICA PRELIMNAR Y CRITERIOS DE SELECCION...................................5
2.1.3 CONCLUSIONES DERIVADAS DE LAS EVALUACIONES TÉCNICAS PRELIMINARES........5
3. ARQUITECTURA TÉCNICA............................................................................................................. 6
3.1 DIAGRAMA DE ARQUITECTURA TÉCNICA DE OPERACIÓN....................................................6
3.2 ARQUITECTURA TÉCNICA DE DESARROLLO...........................................................................6
4. ESPECIFICACIÓN DE MÓDULOS.................................................................................................. 7
4.1 SUBSISTEMAS DE LA APLICACIÓN...........................................................................................7
4.2 ESPECIFICACIÓN DE LOS MÓDULOS DE LA APLICACIÓN......................................................8
4.3 CONSIDERACIONES DE DISEÑO............................................................................................. 39
5. MODELO DE DATOS..................................................................................................................... 39
5.1 MODELO DE ENTIDAD RELACIÓN........................................................................................... 39
5.2 DICCIONARIO DE DATOS.......................................................................................................... 41
6. INTEGRACION DEL SOFTWARE.................................................................................................. 42
6.1 DIAGRAMA DE INTEGRACION E INTEFACES.........................................................................42
6.2 CRITERIOS PARA EL DISEÑO Y SELECCIÓN DE INTERFACES.............................................42
6.3 CRITERIOS DE INTEGRACION DEL SOFTWARE....................................................................42
6.4 SECUENCIA DE INTEGRACION................................................................................................ 43
6.5 ENTORNO NECESARIO PARA LA INTEGRACION...................................................................43
6.5.1 ENTORNO DE DESARROLLO................................................................................................ 43
6.5.2 ENTORNO DE PRUEBAS....................................................................................................... 45
6.5.3 ENTORNO DE PRODUCCION................................................................................................ 46
7. ESPECIFICACIÓN DE LAS CAPAS DE SOFTWARE...................................................................47
7.1 CAPA DE BASE DE DATOS........................................................................................................ 47
7.2 CAPA HIBERNATE / DAO........................................................................................................... 47
7.3 CAPA DE NEGOCIO................................................................................................................... 47
7.4 CAPA CONTROLADORA............................................................................................................ 48
7.5 CAPA DE CLIENTE.................................................................................................................... 48
8. RELACIÓN ENTRE COMPONENTES Y REQUERIMIENTOS FUNC............................................48
8.1 COMPONENTES DE APLICACIÓN............................................................................................ 48
Formato: 02.1.09.03 Pág. 3 de 22

Diseño de Sistemas
8.1.1 COMPONENTES EXTERNOS................................................................................................ 48

8.1.2 COMPONENTES INTERNOS................................................................................................. 49
8.2 COMPONENTES DE BASE DE DATOS.....................................................................................50
9. FIRMA DE APROBACION.............................................................................................................. 51
1. INTRODUCCION
El presente documento provee una visión general de la arquitectura del Sistema de Control de Tiempos,
considerando que ésta ha sido definida por el CLIENTE según sus estándares en la construcción de sus
aplicativos.
Formato: 02.1.09.03 Pág. 4 de 22

Diseño de Sistemas
1.1 OBJETIVO
Representar la arquitectura técnica de la aplicación y definir estructuras de procesos, prototipo y
especificaciones de componentes de aplicación y de datos.
1.2 AMBITO DE APLICACIÓN

Para la construcción del aplicativo se han considerado los siguientes procesos globales:
 Gestión de Citas.
 Gestión de OT
 Explotación de la Información
 Administración del Sistema
1.3 REFERENCIAS
Procesos de Ingeniería Cosapisoft – CMMI.
Prototipo del Sistema
Informe de Prototipo
Especificación de Requerimientos
2. ANÁLISIS DE LA SOLUCIÓN
2.1 EVALUACIÓN TÉCNICA PRELIMINAR
2.1.1 DESCRIPCIÓN DE ALTERNATIVAS DE SOLUCIÓN PRELIMINARES

No se ha realizado una evaluación preliminar de la arquitectura a utilizar porque su construcción se
basará en la arquitectura definida por el CLIENTE.
Sin embargo, se plantea una nueva forma de acceso a la Base de Datos (DAO), debido que ciertas
funcionalidades del aplicativo (desarrollo de consultas en línea e interfaces de reportes gráficos)
requieren no depender de la capa de persistencia de objetos (HIBERNATE).
Formato: 02.1.09.03 Pág. 5 de 22

Diseño de Sistemas
Se plantea la utilización del AJAX (Asynchronous JavaScript and XML) interactuando con Api’s
(XMLHTTP) para desarrollar las interfaces de operatividad diaria como por ejemplo: Registro de
Trabajos.
2.1.2 EVALUACIÓN TÉCNICA PRELIMNAR Y CRITERIOS DE SELECCION

La capa de persistencia a objetos (HIBERNATE) presenta limitaciones en el perfomance de las
consultas de información y búsquedas invocadas al Servidor de BD porque demandan mayor consumo
de recursos en el Servidor de Aplicaciones.
No implementar el AJAX en la construcción de las interfaces de operatividad diaria sugerirá realizar un

refresco en las páginas involucradas por cada transacción realizada, como consecuencia su
funcionalidad se tornaría más lenta.
2.1.3 CONCLUSIONES DERIVADAS DE LAS EVALUACIONES TÉCNICAS

PRELIMINARES
Finalmente, la alternativa planteada nos proporcionará realizar y ejecutar consultas más rápidas y
eficientes para aquellas funcionalidades que impliquen mayor complejidad e interactúen con muchos
objetos en la BD.
Se recomienda utilizar la capa de persistencia (HIBERNATE), sólo para realizar inserciones y

actualizaciones, toda consulta que implique invocar más de un objeto en la BD deberá realizarse bajo la
nueva alternativa (DAO).
Implementar el AJAX sólo para las páginas cuya funcionalidad lo amerite. Se ha identificado dos
funcionalidades: REGISTRO DE TRABAJOS y CONFIGURACIÓN DE TRABAJOS Y REPUESTOS.
Formato: 02.1.09.03 Pág. 6 de 22

Diseño de Sistemas
3. ARQUITECTURA TÉCNICA
3.1 DIAGRAMA DE ARQUITECTURA TÉCNICA DE OPERACIÓN
3.2 ARQUITECTURA TÉCNICA DE DESARROLLO
Formato: 02.1.09.03 Pág. 7 de 22

Diseño de Sistemas
4. ESPECIFICACIÓN DE MÓDULOS
4.1 SUBSISTEMAS DE LA APLICACIÓN
A continuación se detallan los módulos de la aplicación:
GESTIÓN DE CITAS, agrupa las siguientes opciones:
 Registro de Citas
 Consulta y Control de Eventos de Citas.
GESTIÓN DE OT, agrupa las siguientes opciones:
 Registro de Ordenes de Trabajo
 Consulta de Ordenes de Trabajo
 Ejecución de OT
 Seguimiento de OT
EXPLOTACIÓN DE LA INFORMACIÓN, considera todos los reportes definidos para la medición del
control de tiempos y tareas asignadas a los técnicos. A la vez servirán para la toma de decisiones.
ADMINISTRACIÓN DEL SISTEMA, considera el mantenimiento y configuración de las tablas maestras

que servirán de soporte en todas las funcionalidades del sistema.
ALGORITMOS, considera los procesos de estimación de tiempos para la atención de una Orden de
Trabajo y la asignación automática de trabajos a los técnicos disponibles.
Este módulo no presenta interfaz gráfica.
Formato: 02.1.09.03 Pág. 8 de 22

Diseño de Sistemas
4.2 ESPECIFICACIÓN DE LOS MÓDULOS DE LA APLICACIÓN

El sistema (SIGLAPROYSOFTWARE) estará estructurado modularmente de la siguiente manera:
1. GESTION DE CITAS
 REGISTRO DE ALUMNOS
Breve Descripción:
Permite realizar el registro de un alumno actualizar la información del alumno así como registrar
la información.
2. GESTION DE OT
 REGISTRAR DATOS DEL VEHICULO (ORDENES DE TRABAJO)
NOTA:
El detalle de las pantallas y operatividad de las mismas se encuentra en el documento:
Formato: 02.1.09.03 Pág. 9 de 22
Diseño de Sistemas
02.1.11.02-Espcfccion_Cmpnntes 1.00.doc
4.3 CONSIDERACIONES DE DISEÑO

Respecto al tratamiento de data histórica, se ha definido una cantidad adecuada y considerable de
índices sobre las estructuras de datos, teniendo en cuenta los diversos tipos de filtros a emplearse bajo
la utilización del aplicativo, así como en el módulo de explotación de la información.
Las eliminaciones en los registros serán de manera lógica, no de manera física.)
5. MODELO DE DATOS
5.1 MODELO DE ENTIDAD RELACIÓN
A continuación se presenta los diagramas de entidad relación de la aplicación:
 VISTA: MODULO DE MANTENIMIENTO ALUMNOS.
Formato: 02.1.09.03 Pág. 10 de 22

Diseño de Sistemas
5.2 DICCIONARIO DE DATOS

El detalle de las tablas y tipos de datos utilizados se encuentra en el documento:
6. DICCIONARIO DE DATOS
6.1 SUBSISTEMA DE INFORMACIÓN DE ELECTRICIDAD

6.2 DIAGRAMA DE INTEGRACION E INTEFACES
Capa Vista:
==========
- index.jsp => objetos html y javascript (jquery) - Web Pages - index.jsp
- login.jsp => manejo de objetos html - Web Pages - js - login.js
- etc jquery=> manejo de objetos html
Capa Controladora:
==========
- ServletLogin.java => Source Packages - tas.seguridad.servlet - ServletLogin.java
Capa BaseDatos:
==========
- DaoUsuariosImpl.java - Source Packages (Bd Espejo) - tas.Seguridad.Dato.Impl -
- ConectaDb.java => Acceder a los parámetros de conexión de bd - conectarnos
- Util.java => Utilitario conexión
6.3 CRITERIOS PARA EL DISEÑO Y SELECCIÓN DE INTERFACES

No se han definido criterios para el diseño y selección de interfaces. No se han identificado interfaces.
Formato: 02.1.09.03 Pág. 11 de 22

Diseño de Sistemas
6.4 CRITERIOS DE INTEGRACION DEL SOFTWARE

Para la óptima integración del Software se deberán tener que cumplir, considerar y evaluar los
siguientes criterios:
 Antes de realizar la integración todos los componentes deberán haber pasado por pruebas unitarias.
 Antes de realizar la integración, todas las incidencias, errores u otras no conformidades encontradas
durante las pruebas unitarias deberán estar cerradas.
 Se deberá tener preparado los ambientes y entornos para la integración (Entorno de Desarrollo o
Entorno de Integración).
 Deberá haberse ejecutado el script de data inicial básica para el correcto funcionamiento del
sistema. Por ejemplo: estado de las órdenes de trabajo, citas, proformas, entre otros.
 Deberá haberse configurado los parámetros iniciales de las tablas maestras propuestas en el
módulo Administración del Sistema. Por ejemplo: configuración de parámetro de reportes, unidades
de trabajo por centro de servicios, entre otros.
6.5 SECUENCIA DE INTEGRACION

Para que el Software se integre totalmente se seguirá la siguiente secuencia de integración:
 Realizar las pruebas unitarias a todos los componentes desarrollados (De todos los módulos).
 Levantar todos los errores e incidencias encontradas en las pruebas unitarias (De todos los
módulos).
 Realizar revisión de pares al código fuente y levantar las no conformidades.
 Asegurarse que todos los componentes del Sistema estén completamente corregidos (Realización
de nuevas pruebas sobre los errores encontrados).
 Validar que el entorno de integración este listo.
 Validar que la data inicial se encuentre debidamente cargada.
 Validar que la configuración de los parámetros y tablas generales se haya realizado.
 Iniciar la integración
o Realizar pruebas de integración de cada uno de sus módulos.
o Realizar pruebas de integración de cada módulo con respecto a su interacción con los
sistemas externos (actualización de registros en línea por encontrarse todas las entidades
en el mismo esquema de base de datos).
 Finalmente realizar las pruebas del Sistema y luego de ellas las Pruebas de Aceptación con los
Usuarios Finales.
Formato: 02.1.09.03 Pág. 12 de 22

Diseño de Sistemas
6.6 ENTORNO NECESARIO PARA LA INTEGRACION
6.6.1 ENTORNO DE DESARROLLO
NOMBRE DEL SERVIDOR MAQUI07

IP 1.1.15.50
DESCRIPCION Y OBJETIVO DEL SERVIDOR
En este servidor se almacenará el código fuente, en este entorno trabajaran los desarrolladores
y se realizarán las pruebas unitarias.
SERVICIOS
NOMBRE DE
APLICACIÓN FUNCIÓN INICIO USUARIO
SERVICIO
WebSphere WebSphere Servidor de
Application Server Aplicaciones
encargado de la Automático root
publicación del
aplicativo
DB2 IBM DB2 Base de Datos Automático root
CONFIGURACIÓN DE HARDWARE Y SOFTWARE
Nombre del Sistema Operativo OS
Version V5R4
Proveedor del Sistema Operativo IBM
Nombre del Sistema No requerido
Proveedor del Sistema IBM
Modelo del Sistema iSeries 820
Tipo del Sistema IOP - IOA Architecture
Seventh generation 64-bit RISC IBM PowerAS
Procesador
microprocessor
BIOS Version/Date No requerido
SMBIOS Version No requerido
Total de Memoria Física 12GB
Promedio de Memoria Física No requerido
Total de Memoria Virtual No requerido
Promedio de Memoria Virtual No requerido
Tipo de Adaptador No requerido
Tipo de Producto No requerido
Nombre del Servicio No requerido
Máscara de Sub Red IP No requerido
Gateway IP No requerido
Formato: 02.1.09.03 Pág. 13 de 22

Diseño de Sistemas
DHCP Enabled No requerido

DHCP Server No requerido
MAC Address No requerido
Memory Address No requerido
SOFTWARE ADICIONAL Ninguno
RELACION CON OTROS
Ninguno
SERVIDORES
6.6.2 ENTORNO DE PRUEBAS

IP 1.1.15.50
y se realizarán las pruebas del sistema.
SERVICIOS
NOMBRE DE
SERVICIO
publicación del
aplicativo
Nombre del Sistema Operativo OS
Version V5R4
Modelo del Sistema iSeries 820
Tipo del Sistema IOP - IOA Architecture
Seventh generation 64-bit RISC IBM PowerAS
Procesador
microprocessor
Total de Memoria Física 12GB
Formato: 02.1.09.03 Pág. 14 de 22

Diseño de Sistemas

RELACION CON OTROS
Ninguno
SERVIDORES
6.6.3 ENTORNO DE PRODUCCION

IP 1.1.15.50
y se realizarán las pruebas implantación.
SERVICIOS
NOMBRE DE
SERVICIO
publicación del
aplicativo
Nombre del Sistema Operativo I5/OS
Version V5R4
Modelo del Sistema System I 520
Tipo del Sistema I5
Procesador POWER5+™ 64-bit processor
Total de Memoria Física 6,144 MB
Formato: 02.1.09.03 Pág. 15 de 22
Diseño de Sistemas

RELACION CON OTROS
SERVIDORES
7. ESPECIFICACIÓN DE LAS CAPAS DE SOFTWARE

A continuación se describe cada una de las capas utilizadas en el desarrollo de la aplicación:
El gráfico que detalla las capas a implementar en el desarrollo del software se referencia en:
3.2. ARQUITECTURA TÉCNICA DE DESARROLLO.
7.1 CAPA DE BASE DE DATOS

En este nivel se encuentra la base de datos física del aplicativo, es responsable del almacenamiento de
los datos y la estructura de los mismos.
7.2 CAPA HIBERNATE / DAO

En este nivel se encuentran los componentes de persistencia de objetos y mapeos de los mismos en
ficheros XML. (esquema HIBERNET).
Se encuentran los componentes que interactúan directamente con la BD. (esquema DAO).
7.3 CAPA DE NEGOCIO

En este nivel se obtienen los datos (accediendo a los servicios de la capa de acceso a datos HIBERNET
/ DAO), enviándolos a los componentes de la capa de CONTROLADORA, que los formatean y los
muestran y ejecutan las operaciones.
Formato: 02.1.09.03 Pág. 16 de 22

Diseño de Sistemas
7.4 CAPA CONTROLADORA

En este nivel se encuentran los componentes que dirigen ó asignan peticiones a la capa de negocios
mediante mapeos que mantienen correspondencias entre la capa CLIENTE y la capa de NEGOCIOS.
7.5 CAPA DE CLIENTE

Denominada también Capa de Servicios de Interfaz o de Servicios de Usuario, pues se ocupa
fundamentalmente de la comunicación con el operador del aplicativo. Incluye todos los componentes
cuya responsabilidad primaria es recibir las entradas del usuario, o presentarle la información al mismo.
Los formularios de ingreso de datos ó los presentadores de reportes, son los ejemplos clásicos de esta
capa.
8. RELACIÓN ENTRE COMPONENTES Y REQUERIMIENTOS FUNC.

8.1 COMPONENTES DE APLICACIÓN
Se detalla el listado de los componentes a desarrollar que cubrirán los requerimientos especificados, los
cuales se clasifican de la siguiente manera:
8.1.1 COMPONENTES EXTERNOS

ÍTEM PAQUETE O COMPONENTE VERSIÓN DESCRIPCIÓN REQUERIMIENTO
1 antlr.jar 1.1 Permiten la implementación delTodos los
commons-beanutils.jar
framework a utilizar. requerimientos
commons-digester.jar
commons-fileupload.jar
commons-logging.jar
commons-validator.jar
jakarta-oro.jar
struts.jar
2 antlr-2.7.6.jar 2.0 Permiten la implementación delTodos los
asm.jar
HIBERNET requerimientos
asm-attrs.jar
c3p0-0.9.1.jar
cglib-2.1.3.jar
commons-collections-2.1.1.jar
commons-logging-1.0.4.jar
concurrent-1.3.2.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
hibernate2.jar
jacc-1_0-fr.jar
jaxen-1.1-beta-7.jar
jdbc2_0-stdext.jar
jta.jar
log4j-1.2.11.jar
xml-apis.jar
3 jt400.jar 5.4.0.2 Permite implementar la conexión con laTodos los
Formato: 02.1.09.03 Pág. 17 de 22

Diseño de Sistemas
Base de Datos. requerimientos

4 XMLHTTP Ninguna. Api que permite transferir informaciónREQ-0003
codificada XML con el propósito de
REQ-0016
actualizar la página del sistema sin
cargarla nuevamente.
8.1.2 COMPONENTES INTERNOS
ÍTEM PAQUETE O COMPONENTE VERSIÓN DESCRIPCIÓN REQUERIMIENTO

1 (SIGLAPROYSOFTWARE)_ALGORITMO_BO 1.0 Encapsula la lógica del REQ-0015
negocio para los REQ-0021
procesos de estimación
de tiempos y asignación
automática de
actividades.
2 (SIGLAPROYSOFTWARE)_ASISTENCIA_BO 1.0 Encapsula la lógica del REQ-0054
negocio para los
procesos de control de
la disponibilidad de los
técnicos.
3 (SIGLAPROYSOFTWARE)_CITA_BO 1.0 Encapsula la lógica del REQ-0002
negocio para el REQ-0003
tratamiento de las citas, REQ-0004
control de eventos, etc. REQ-0005
4 (SIGLAPROYSOFTWARE)_CLIENTE_BO 1.0 Encapsula la lógica del REQ-0006
tratamiento de registro y
actualización de datos
de los clientes
(propietarios,
facturaciones, contactos,
usuarios, etc.)
5 (SIGLAPROYSOFTWARE)_EJECUCION_BO 1.0 Encapsulta la lógica del REQ-0019
procesos de ejecución REQ-0055
de actividades y control REQ-0057
del inicio y fin de las
actividades.
6 (SIGLAPROYSOFTWARE)_ORDEN_TRABAJO_BO 1.0 Encapsulta la lógica del REQ-0010
tratamiento a las REQ-0020
Ordenes de Trabajo. REQ-0025
REQ-0046
REQ-0047
REQ-0051
REQ-0058
REQ-0059
7 (SIGLAPROYSOFTWARE)_PROFORMA_BO 1.0 Encapsula la lógica del REQ-0007
procesos de proformas REQ-0013
vigentes. REQ-0046
8 (SIGLAPROYSOFTWARE)_REPORTES_BO 1.0 Encapsula la lógica del REQ-0022
procesos de explotación REQ-0024
Formato: 02.1.09.03 Pág. 18 de 22
Diseño de Sistemas
de la información. REQ-0033
REQ-0034
REQ-0035
REQ-0036
REQ-0037
REQ-0038
REQ-0039
REQ-0040
REQ-0041
REQ-0042
REQ-0043
REQ-0044
REQ-0045
9 (SIGLAPROYSOFTWARE)_SISTEMAS_BO 1.0 Encapsula la lógica del REQ-0046
negocio para los
procesos de interacción
con otros sistemas que
se encuentran en el
mismo esquema de BD.
10 (SIGLAPROYSOFTWARE)_TABLA_BO 1.0 Encapsula la lógica del REQ-0009
procesos de REQ-0028
mantenimiento y REQ-0030
configuraciones base del REQ-0032
sistema. REQ-0052
REQ-0053
REQ-0054
11 (SIGLAPROYSOFTWARE)_TRABAJO_BO 1.0 Encapsula la lógica del REQ-0015
tratamiento a los REQ-0018
trabajos ó servicios REQ-0031
asignados a las Ordenes REQ-0049
de Trabajo. REQ-0050
12 (SIGLAPROYSOFTWARE)_VEHICULO_BO 1.0 Encapsula la lógica del REQ-0001
procesos de consulta y
actualización de datos
del vehículo.
8.2 COMPONENTES DE BASE DE DATOS

Capa Vista:
==========
- index.jsp => objetos html y javascript (jquery) - Web Pages - index.jsp
- login.jsp => manejo de objetos html - Web Pages - js - login.js
- etc jquery=> manejo de objetos html
Capa Controladora:
Formato: 02.1.09.03 Pág. 19 de 22

Diseño de Sistemas
==========
- ServletLogin.java => Source Packages - tas.seguridad.servlet - ServletLogin.java
Capa BaseDatos:
==========
- DaoUsuariosImpl.java - Source Packages (Bd Espejo) - tas.Seguridad.Dato.Impl -
- ConectaDb.java => Acceder a los parámetros de conexión de bd - conectarnos
- Util.java => Utilitario conexión
--Sequence--
create sequence juliocuri.SQ_UAP_ALUMNO
minvalue 1
maxvalue 9999999999999999999999999999
start with 4
increment by 1
nocache;
--PK MANT--
CREATE OR REPLACE PACKAGE juliocuri.PK_UAP_MANT
AS
TYPE CUR_DATO IS REF CURSOR;
PROCEDURE SP_BUSCA_ALUMNO
(
PO_CURSOR IN OUT CUR_DATO,
PI_ALU_NOMBRES VARCHAR,
PI_ALU_APELLIDOS VARCHAR
);
PROCEDURE SP_INSERTA_ALUMNO
(
);
PROCEDURE SP_ACTUALIZA_ALUMNO
(
PI_ALU_ID NUMBER,
);
PROCEDURE SP_INST_PRB1_TRIGGER
(
PI_CAMPO2 VARCHAR,
PI_CAMPO3 VARCHAR
);
PROCEDURE SP_INST_PRB1_TRIG_T1
Formato: 02.1.09.03 Pág. 20 de 22
Diseño de Sistemas
(
PO_VRETORNO OUT VARCHAR2,
PI_CAMPO2 VARCHAR,
PI_CAMPO3 VARCHAR
);
--PK seguridad de logeo--

CREATE OR REPLACE PACKAGE juliocuri.PK_UAP_SEGURIDAD
AS
TYPE CUR_DATO IS REF CURSOR;
PROCEDURE SP_UAP_VALIDALOGEO
(
PVI_USR_LOGIN VARCHAR2,
PVI_CLAVE VARCHAR2,
PVO_MSGRPTA OUT VARCHAR2
);
--SP Mantenimiento--
CREATE OR REPLACE PACKAGE BODY juliocuri.PK_UAP_MANT
IS
PROCEDURE SP_BUSCA_ALUMNO
(
PO_CURSOR IN OUT CUR_DATO,
)
IS
BEGIN
OPEN PO_CURSOR FOR
SELECT ALU.ALU_ID, ALU.ALU_NOMBRES, ALU.ALU_APELLIDOS, ALU.ALU_ESTADO
FROM juliocuri.UAP_ALUMNO ALU
WHERE
ALU.ALU_NOMBRES LIKE '%'|| PI_ALU_NOMBRES ||'%'
AND
ALU.ALU_APELLIDOS LIKE '%'|| PI_ALU_APELLIDOS ||'%';
END;
PROCEDURE SP_INSERTA_ALUMNO
(
)
Formato: 02.1.09.03 Pág. 21 de 22

Diseño de Sistemas
9. FIRMA DE APROBACION
Para dar la conformidad al presente documento, se requiere las firmas de las personas indicadas a
continuación:
(Nombre Jefe Cliente) Nombres y Apellidos

Jefe de Sistemas Jefe de Proyecto
(Nombre Empresa Cliente) (Nombre Empresa Cliente)
Nombres y Apellidos
Gerente del Proyecto
NOMBRE EMPRESA PROVEEDORA
Fecha: Lunes, 13 de Julio del 2007.
Formato: 02.1.09.03 Pág. 22 de 22


Diseñode Sistema SMA

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseñode Sistema SMA

Uploaded by

Copyright:

Available Formats

Proyecto SMA

Preparado por: Julio Curi Huamaní.

PARTES QUE DESCRIPCIÓN DEL FECHA DE MODIFICADO REVISADO APROBADO

Formato: 02.1.09.03 Pág. 3 de 22

8.1.1 COMPONENTES EXTERNOS................................................................................................ 48

Formato: 02.1.09.03 Pág. 4 de 22

1.2 AMBITO DE APLICACIÓN

 Administración del Sistema

2.1.1 DESCRIPCIÓN DE ALTERNATIVAS DE SOLUCIÓN PRELIMINARES

Formato: 02.1.09.03 Pág. 5 de 22

2.1.2 EVALUACIÓN TÉCNICA PRELIMNAR Y CRITERIOS DE SELECCION

No implementar el AJAX en la construcción de las interfaces de operatividad diaria sugerirá realizar un

2.1.3 CONCLUSIONES DERIVADAS DE LAS EVALUACIONES TÉCNICAS

Se recomienda utilizar la capa de persistencia (HIBERNATE), sólo para realizar inserciones y

Formato: 02.1.09.03 Pág. 6 de 22

3.2 ARQUITECTURA TÉCNICA DE DESARROLLO

Formato: 02.1.09.03 Pág. 7 de 22

GESTIÓN DE CITAS, agrupa las siguientes opciones:

 Consulta y Control de Eventos de Citas.

GESTIÓN DE OT, agrupa las siguientes opciones:

 Registro de Ordenes de Trabajo

 Consulta de Ordenes de Trabajo

ADMINISTRACIÓN DEL SISTEMA, considera el mantenimiento y configuración de las tablas maestras

Este módulo no presenta interfaz gráfica.

Formato: 02.1.09.03 Pág. 8 de 22

4.2 ESPECIFICACIÓN DE LOS MÓDULOS DE LA APLICACIÓN

4.3 CONSIDERACIONES DE DISEÑO

Las eliminaciones en los registros serán de manera lógica, no de manera física.)

 VISTA: MODULO DE MANTENIMIENTO ALUMNOS.

Formato: 02.1.09.03 Pág. 10 de 22

5.2 DICCIONARIO DE DATOS

6.1 SUBSISTEMA DE INFORMACIÓN DE ELECTRICIDAD

- index.jsp => objetos html y javascript (jquery) - Web Pages - index.jsp

- login.jsp => manejo de objetos html - Web Pages - js - login.js

- etc jquery=> manejo de objetos html

- ServletLogin.java => Source Packages - tas.seguridad.servlet - ServletLogin.java

- DaoUsuariosImpl.java - Source Packages (Bd Espejo) - tas.Seguridad.Dato.Impl -

- ConectaDb.java => Acceder a los parámetros de conexión de bd - conectarnos

- Util.java => Utilitario conexión

6.3 CRITERIOS PARA EL DISEÑO Y SELECCIÓN DE INTERFACES

Formato: 02.1.09.03 Pág. 11 de 22

6.4 CRITERIOS DE INTEGRACION DEL SOFTWARE

6.5 SECUENCIA DE INTEGRACION

Formato: 02.1.09.03 Pág. 12 de 22

6.6 ENTORNO NECESARIO PARA LA INTEGRACION

6.6.1 ENTORNO DE DESARROLLO

NOMBRE DEL SERVIDOR MAQUI07

Formato: 02.1.09.03 Pág. 13 de 22

DHCP Enabled No requerido

6.6.2 ENTORNO DE PRUEBAS

NOMBRE DEL SERVIDOR MAQUI09

Formato: 02.1.09.03 Pág. 14 de 22

Tipo de Adaptador No requerido

6.6.3 ENTORNO DE PRODUCCION

NOMBRE DEL SERVIDOR MAQUI02

Promedio de Memoria Física No requerido

7. ESPECIFICACIÓN DE LAS CAPAS DE SOFTWARE

7.1 CAPA DE BASE DE DATOS

7.2 CAPA HIBERNATE / DAO

7.3 CAPA DE NEGOCIO

Formato: 02.1.09.03 Pág. 16 de 22

7.4 CAPA CONTROLADORA

7.5 CAPA DE CLIENTE