R D S

Reporte de Diseño de
Software (RDS)
[Licencia por enfermedad]
MINISTERIO DE ECONOMIA Y FINANZAS

Oficina General de Administración
ENERO 2013
____________________________________________________________________________________
Reporte de Diseño de Software (RDS) Página 1 de 25
HISTORIAL DE REVISIONES
Fecha de Fecha de Revisado

Versión Autor Descripción
Elaboración Revisión por
Prof.Gisella
<1.0.1> Porras Ángel <Detalles> 25-01-2013 27-01-2013
Guzmán
Ramirez
Tejada
Cristian
Silva Silva
Gerson
Terán
Rebaza
Débora
____________________________________________________________________________________
Contenido
1. Introducción ........................................................................................ 4
1.1. PROPÓSITO .............................................................................................................................. 4
1.2. ALCANCE .................................................................................................................................. 4
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS .................................................................... 4
1.3.1. Definiciones ............................................................................................................... 4
1.3.2. Acrónimos .................................................................................................................. 4
1.3.3. Abreviaturas ............................................................................................................. 4
1.4. REFERENCIAS ........................................................................................................................... 4
2. Vista General de la Arquitectura .................................................. 4

3. Metas y Restricciones de la Arquitectura ................................. 5
4. Modelo de Diseño ............................................................................... 6
4.1. MODELO LÓGICO ..................................................................................................................... 6
4.2. MODELO FÍSICO DE DATOS ................................................................................................... 8
4.3. MODELO DE DISEÑO ............................................................................................................. 11
4.3.1. Vista de Capas y Subsistemas ...................................................................... 11
4.3.1.1. Capa de Presentación ....................................................................................................... 11
4.3.1.2. Capa Controladora ............................................................................................................. 11
4.3.1.3. Capa de Negocio ................................................................................................................. 11
4.3.2. Realización de Casos de Uso – Modelo de Diseño ............................ 11
4.3.2.1. Código del CUS – Nombre del CUS.............................................................................. 11
4.3.2.2. Diagrama de Clases de Diseño ...................................................................................... 12
5. Vista de Procesos ............................................................................. 20

6. Vista de Despliegue ......................................................................... 21
7. Vista de Implementación .............................................................. 22
8. Vista de Integración del Software ............................................. 23
8.1. CRITERIOS DE INTEGRACIÓN DE SOFTWARE ...................................................................... 23
8.2. SECUENCIA DE INTEGRACIÓN............................................................................................... 23
8.3. ENTORNO NECESARIO PARA LA INTEGRACIÓN .................................................................... 24
9. Tamaño y Desempeño .................................................................... 25
____________________________________________________________________________________
1. Introducción
1.1. Propósito
El presente documento provee una visión general de la arquitectura del
sistema, usando diferentes vistas para ilustrar los diferentes aspectos del
mismo. También intenta capturar y transmitir las decisiones de arquitectura que
sean significantes y hayan sido realizadas en el sistema.
1.2. Alcance
Referirse al documento RES.
1.3. Definiciones, Acrónimos y Abreviaturas
1.3.1. Definiciones
Definición Descripción
Jefe de oficina Trabajador encargado de actualizar
la solicitud de licencia por
enfermedad.
Enfermera Trabajadora encargada de generar
licencia por enfermedad.
1.3.2. Acrónimos
Acrónimo Descripción
RUP Rational Unified Process
RES Reporte de Especificación de Software
1.3.3. Abreviaturas
Acrónimo Descripción
MEF Ministerio de Economía y Finanzas.
1.4. Referencias
En ciertas partes del documento se harán referencias al documento RES.
2. Vista General de la Arquitectura

A continuación se muestra la Arquitectura del Sistema de Licencia por
enfermedad, ésta está dividida en tres capas lógicas:
 Capa de Presentación
 Capa Controladora
 Capa de Negocio
Asimismo la aplicación tendrá una distribución en tres capas físicas de la

arquitectura, las cuales se describen a continuación.
 Capa de presentación
En esta capa se encuentra la aplicación Web dedicada a la administración
y configuración del sistema “Licencia por enfermedad”, la cual estará
____________________________________________________________________________________
conformada por las pantallas de presentación al usuario. Estas
aplicaciones Web serán páginas JSP’s.
 Capa de Lógica de Negocio

Esta capa provee todo lo que es la lógica del negocio, es decir la
funcionalidad del sistema, ya sean los procesos administrativos y otros.
Además, en esta capa se encuentran los servicios publicados, como los
Web Services y los Servicios EDI sobre TCP/IP.
 Capa de acceso a datos

Esta capa provee los servicios y conexiones a la base de datos requeridos
por la capa de lógica de Negocio. Por otro lado, el manejador de base de
datos utilizado para este sistema será MySQL 5.2 CE
3. Metas y Restricciones de la Arquitectura

Clasificación Descripción Requerimientos
Usabilidad Se enfoca a las RNF-006 - El Sistema contará con
características de una interfaz en donde los usuarios
estética y consistencia internos podrán iniciar sesión y así
en las interfaces acceder a sus respectivas
gráficas funciones.
RNF-007 - El sistema utilizara una

interfaz gráfica con cajas de texto
(en donde insertaran los datos) y
el botón de enviar, guardar,
cancelar y regresar al menú
anterior.
Confiabilidad Se enfoca con las RNF-009 - El sistema contará con
características como una interfaz para iniciar sesión,
disponibilidad (el validando al tipo de usuario y
tiempo disponible del mostrándole las interfaces que le
sistema), exactitud de corresponden dependiendo del
los cálculos del usuario.
sistema, y las
habilidades del sistema
para recuperarse
durante fallos.
Consideraciones Especifica las opciones RNF-002 - La Base de Datos será
de diseño del diseño para el implementada en MYSQL 5.2
sistema.
RNF-003 - Contenedor web:
Apache Tomcat 7.0.
RNF-010 - El sistema utilizará

conexión de área local para
comunicará a través de switchs
de red entre computadoras y
router para comunicación con el
modem. También tendrá la
posibilidad de red inalámbrica.
Requerimientos de Especifica la RNF-001 - El Sistema se
implementación codificación o desarrollara con Lenguaje de
construcción del Programación Java.
sistema, pueden ser
____________________________________________________________________________________
Clasificación Descripción Requerimientos
estándares,
implementaciones,
lenguajes y límites de
los recursos.
Requerimiento Especificaciones RNF-011 - Para usuarios:
físicos físicas impuestas por Computadora con procesador
el hardware usado Intel Core 2 Dúo, 2 Gbs de RAM,
para mantener el 10 Gbs de disco duro libre,
sistema. tarjeta de red 10/100.
RNF-004 - Adquisición de
Servidor con 2 Tb de espacio
mínimo en disco duro.
4. Modelo de Diseño
4.1. Modelo Lógico
Nombre Empleado
Tipo Entidad
Descripción --------------------------------------
Atributo Tipo de Dato Visibilidad Valor inicial
codEmpleado String Privado
nombreEmp String Privado
apellidoPat String Privado
apellidoMat String Privado
fechNac Date Privado
NroDNI String Privado
Correo String Privado
Nombre Solicitud_LE
Tipo Entidad
Descripción --------------------------------------
codSolicitud String Privado
FechaRegistro Date Privado
Certificado String Privado
estado String Privado
fechaInicio Date Privado
fechaFin Date Privado
Obs String Privado
tipoEnfermedad String Privado
____________________________________________________________________________________
Nombre Licencia_Enfermedad
Tipo Entidad
Descripción --------------------------------------
codLicencia String Privado
FechaRegistro Date Privado
estado String Privado
dias Integer Privado
fechaAprobación Date Privado
Nombre Área
Tipo Entidad
Descripción --------------------------------------
codArea String Privado
nomArea String Privado
Nombre Subsidio
Tipo Entidad
Descripción --------------------------------------
codSubsidio String Privado
SubsidioSalud Integer Privado
SubsidioEmpresa Integer Privado
Nombre Usuario
Tipo Entidad
Descripción --------------------------------------
Usuario String Privado
Contraseña String Privado
Nombre Cargo
Tipo Entidad
Descripción --------------------------------------
codCargo String Privado
descCargo String Privado
____________________________________________________________________________________
Nombre Perfil
Tipo Entidad
Descripción --------------------------------------
codPerfil String Privado
descPerfil String Privado
4.2. Modelo Físico de datos
Diccionario de Datos
Tabla: TB_Empleado
Descripción: Contiene los datos de todos los trabajadores que solicitan
Licencia por enfermedad
Campo Tipo Longitud Descripción
codEmpleado Varchar 8 Identificador único del empleado.
nombreEmp Varchar 45 Descripción del nombre del empleado.
apellidoPat Varchar 45 Descripción del apellido paterno del
empleado.
apellidoMat Varchar 45 Descripción del apellido materno del
empleado.
fechNac Date Descripción de la fecha de nacimiento
del empleado.
nroDNI Varchar 45 Descripción del número de DNI del
empleado.
correo Varchar 45 Descripción del correo electrónico del
empleado.
codCargo Varchar 8 Identificador único de cada cargo.
codArea Varchar 8 Identificador único de cada área.
Restricciones: El código de empleado es único.
Todos los campos no deben de ser nulos.
Llaves codEmpleado
Primarias:
Llaves codCargo, codArea.
Foráneas:
Tabla: TB_Solicitud_LE
Descripción: Contiene los datos de la Solicitud de licencia por enfermedad.

codSolicitud Varchar 8 Identificador único de la Solicitud_LE.
FechaRegistro Date Contiene la fecha en que se registrará
la solicitud_LE.
Certificado Varchar 250 Contiene la ruta donde se encuentra
guardado el certificado adjunto de
cada empleado.
estado Varchar 45 Descripción del estado en que se
encuentra la Solicitud_LE.
fechaInicio Date Descripción de la fecha de inicio de la
solicitud_LE.
____________________________________________________________________________________
fechaFin Date Descripción de la fecha de fin de la
solicitud_LE.
Obs Char 10 Descripción de las observaciones de la
Solicitud_LE.
tipoEnfermedad Varchar 100 Descripción del tipo de enfermedad
del empleado.
codEmpleado Varchar 8 Identificador único de cada empleado.
Restricciones: El código de la solicitud_LE es único.
Llaves codSolicitud.
Primarias:
Llaves codEmpleado.
Foráneas:
Tabla: TB_ Licencia_Enfermedad

Descripción: Contiene los datos de la licencia por enfermedad de cada
empleado.
codLicencia Varchar 8 Identificador único de la licencia.
FechaRegistro Date Contiene la fecha en que se
registrará la licencia.
estado Varchar 45 Descripción del estado en que se
encuentra la licencia.
dias Int Descripción de los días que durará la
licencia.
fechaAprobación Date Descripción de la fecha de aprobación
de la licencia.
codSolicitud Varchar 8 Identificador único cada solicitud.
codEmpleado Varchar 8 Identificador único de cada
empleado.
Restricciones: El campo codLicencia es un identificador único.
Llaves codLicencia
Primarias:
Llaves codSolicitud, codEmpleado.
Foráneas:
Tabla: TB_ Área

Descripción: Contiene los datos de las áreas.

codArea Varchar 8 Identificador único del área.
nomArea Varchar 45 Descripción del nombre del área.
Restricciones: El campo codArea es un identificador único.
Llaves codArea
Primarias:
Llaves --------------------
Foráneas:
____________________________________________________________________________________
Tabla: TB_ Subsidio
Descripción: Contiene los datos de subsidio, ya sea empresa o essalud.

codSubsidio Varchar 8 Identificador único de Subsidio.
SubsidioSalud Int Descripción de subsidio de Salud.
SubsidioEmpresa Int 45 Descripción de subsidio de Empresa.
codLicencia Varchar 8 Identificador único de cada licencia.
Restricciones: El campo codSubsidio es un identificador único.

Llaves codSubsidio
Primarias:
Llaves Foráneas: codLicencia
Tabla: TB_ Usuario

Descripción: Contiene los datos de los usuarios.

Usuario Varchar 8 Identificador único de usuario.
Contraseña Varchar 45 Descripción del nombre del área.
codEmpleado Varchar 8 Identificador único de cada
empleado.
codPerfil Varchar 8 Identificador único de cada perfil.
Restricciones: El campo Usuario es un identificador único.
Llaves Usuario
Primarias:
Llaves codEmpleado, codPerfil.
Foráneas:
Tabla: TB_ Cargo

Descripción: Contiene los datos de los cargos.

codCargo Varchar 8 Identificador único de cada cargo.
descCargo Varchar 45 Descripción del cargo.
Restricciones: El campo codCargo es un identificador único.
Llaves codCargo
Primarias:
Llaves --------------
Foráneas:
____________________________________________________________________________________
Tabla: TB_ Perfil
Descripción: Contiene los datos de los perfiles.

codPerfil Varchar 8 Identificador único de cada perfil.
descPerfil Varchar 45 Descripción del perfil.
Restricciones: El campo codPerfil es un identificador único.
Llaves codPerfil
Primarias:
Llaves --------------
Foráneas:
4.3. Modelo de Diseño
4.3.1. Vista de Capas y Subsistemas
4.3.1.1. Capa de Presentación
4.3.1.2. Capa Controladora
4.3.1.3. Capa de Negocio
4.3.2. Realización de Casos de Uso – Modelo de Diseño

4.3.2.1. CUS01 – GENERAR SOLICITUD DE LICENCIA
POR ENFERMEDAD
Escenario: ESC01 Flujo Básico de Eventos
Diagrama de Secuencia de Diseño
____________________________________________________________________________________
Diagrama de Clases de Diseño
____________________________________________________________________________________
4.3.2.2 CUS02 – APROBAR LICENCIA POR ENFERMEDAD
____________________________________________________________________________________
____________________________________________________________________________________
4.3.2.3 CUS03 – GENERAR LICENCIA POR ENFERMEDAD
____________________________________________________________________________________
____________________________________________________________________________________
4.3.2.4 CUS04 – INGRESAR AL SISTEMA
____________________________________________________________________________________
____________________________________________________________________________________
4.3.2.5 CUS05–SOLICITUDES LICENCIA POR ENFERMEDAD RECHAZADAS
4.3.2.6 CUS06– LICENCIAS POR ENFERMEDAD POR ENFERMERA
____________________________________________________________________________________
4.3.2.7 CUS07– LICENCIAS POR ENFERMEDAD POR ENFERMERA
____________________________________________________________________________________
1. Vista de Procesos
[Esta sección describe la descomposición del sistema en procesos de primer
nivel (un solo hilo de control) y los procesos de último nivel (grupos de
procesos de primer nivel). También describe la ubicación de objetos y clases.
Organizar la sección por los grupos de los procesos que se comunican u obran
recíprocamente. Describir los modos principales de la comunicación entre los
procesos, tales como el paso de mensajes, interrupciones y qué pasa, las
interrupciones, y puntos de encuentro entre procesos.]
2. Vista de Despliegue
____________________________________________________________________________________
3. Vista de Implementación
[En esta sección se describe la estructura total del modelo de implementación,
utilizando la descomposición del software en capas y subsistemas y cómo éste
se pondrá en práctica. Deberá identificar cualquier componente arquitectónico
significativo. Debe nombrar y definir las capas y contenidos de las mismas, las
reglas que gobiernan la inclusión de una u otra capa, y las características
entre capas. Incluya el diagrama de componentes que muestra las relaciones
entre capas. Para cada capa, incluya una sub-sección con el nombre de la
capa, una enumeración de los subsistemas localizados dentro de la capa y un
diagrama de componentes.]
4. Vista de Integración del Software

[De requerirlo en esta sección pude incluir un diagrama integración del
software desarrollado y su interacción con las diferentes interfaces
identificadas en el modelo de diseño.]
Ejemplo:
INTERFAZ DESCRIPCION BREVE TIPO DE REFERENCIA

INTERFAZ
INT1 La interfaz 1 apoya la Interfaz Interna La Especificación de esta
integración del Paquete 1 interfaz se encuentra en el
y el Paquete 2, incluye las documento de
clases C1, C2, etc…. Especificación de
Componentes
INT2 La interfaz 1 apoya la Interfaz Interna La Especificación de esta
integración del Paquete 1 interfaz se encuentra en el
y el Paquete 2, incluye las documento de
clases C1, C2, etc…. Especificación de
____________________________________________________________________________________
INTERFAZ DESCRIPCION BREVE TIPO DE REFERENCIA
INTERFAZ
Componentes
INT3 Interfaz Interna La Especificación de esta
interfaz se encuentra en el
documento de
Especificación de
Componentes
INT4 Interfaz Externa La Especificación de esta
documento de
Especificación de
Componentes
INT5 Interfaz Externa La Especificación de esta
documento de
Especificación de
Componentes
4.1. Criterios de Integración de Software

[Identifique los criterios que se deberán considerar para la integración
de los componentes de software y sus interfaces.
Ejemplo:
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 inicializado y migrado data consistente previa a la
integración.
 Otros Criterios que apoyen a que la integración resulte un éxito.]
4.2. Secuencia de Integración

[Defina la secuencia de integración que se aplicarán a los componentes
de software y sus interfaces.
Ejemplo:
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 haya sido migrada satisfactoriamente.
 Iniciar la integración
o Integrar Modulo 1 y Modulo 2 - Realizar pruebas de
integración entre ambos módulos.
o Integrar Modulo 1 y Modulo 2 y Modulo3 - Realizar
pruebas de integración entre módulos.
o Integrar Modulo 1 y Modulo 2 y Modulo n - Realizar
pruebas de integración entre módulos.
 Finalizada la Integración entre módulos, realizar la integración con
aplicativos externos al sistema en desarrollo.
o Integrar Sistema en desarrollo con Sistema Externo1
(Aplicativo Externo) y Realizar Pruebas.
o Integrar Sistema en desarrollo con Sistema Externo2
(Aplicativo Externo) y Realizar Pruebas.
 Finalmente realizar las pruebas del Sistema y luego de ellas las
Pruebas de Aceptación con los Usuarios Finales.
4.3. Entorno Necesario para la Integración

[En esta sección se deberán identificar y especificar los diversos
entornos que se usarán o que están involucrados en la integración del
Software.]
NOMBRE DEL SERVIDOR Serv_Desa

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. Aquí se realizarán las pruebas unitarias.
SERVICIOS
NOMBRE DE
APLICACIÓN FUNCIÓN INICIO USUARIO
SERVICIO
Por Ejemplo: Por ejemplo: Por ejemplo:
Asynchronous AJAX Presentación
JavaScript + basada en
Automático Adminservice
XML estándares
usando XHTML
y CSS
<Servicio 1> <Aplicación 1> <Función 1> Local System
Automático
Account
<Servicio 2> <Aplicación 2> <Función 2> Local System
Automático
Account
<Servicio N> <Aplicación N> <Función 1> Local System
Automático
Account
____________________________________________________________________________________
CONFIGURACIÓN DE HARDWARE Y SOFTWARE
Microsoft ( R) Windows (R ) Server
Nombre del Sistema Operativo
200.Enterprise Edition
Version 2.2.3790 Service Pack 2 Build 3790
Proveedor del Sistema Operativo Microsoft Corporation
Nombre del Sistema DEIPSBATCH
Proveedor del Sistema IBM
Modelo del Sistema -[865811Y]-
Tipo del Sistema X86 – based PC

x86 Family 6 Model 8 Stepping 3 Genuineintel -
Procesador
664
BIOS Version/Date IBM ILKT44AUS, 20/09/2001
SMBIOS Version 2.1
Total de Memoria Física 2,047.49 MB
Promedio de Memoria Física 1.37 GB
Total de Memoria Virtual 3.86 GB
Promedio de Memoria Virtual 3.47 GB
Tipo de Adaptador Ethernet 802.3
Tipo de Producto IBM Netfinity Fault Tolerante PCI Adapter
Nombre del Servicio PCNet5
Dirección IP 10.203.32.9
Máscara de Sub Red IP 255.255.255.0
Gateway IP 10.203.32.254
DHCP Enabled No
DHCP Server Not Available

MAC Address 00:06:29:D5:38:0F
Memory Address 0XFEB7FC00-0XFEB7FC1F
SOFTWARE ADICIONAL
USARIOS CON PERMISOS AL
SERVIDOR
RELACION CON OTROS
SERVIDORES
5. Tamaño y Desempeño
[En esta sección se pueden incluir descripciones de las principales
características del dimensionamiento del software que afectan la arquitectura,
así como las restricciones de desempeño. Si trabaja estas características en el
RES haga referencia a dicho documento.]
____________________________________________________________________________________

R D S

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

R D S

Încărcat de

Drepturi de autor:

Formate disponibile

Reporte de Diseño de

MINISTERIO DE ECONOMIA Y FINANZAS

Fecha de Fecha de Revisado

2. Vista General de la Arquitectura .................................................. 4

5. Vista de Procesos ............................................................................. 20

9. Tamaño y Desempeño .................................................................... 25

Referirse al documento RES.

1.3. Definiciones, Acrónimos y Abreviaturas

2. Vista General de la Arquitectura

Asimismo la aplicación tendrá una distribución en tres capas físicas de la

 Capa de Lógica de Negocio

 Capa de acceso a datos

3. Metas y Restricciones de la Arquitectura

RNF-007 - El sistema utilizara una

RNF-010 - El sistema utilizará

4.1. Modelo Lógico

4.2. Modelo Físico de datos

Campo Tipo Longitud Descripción

Tabla: TB_ Licencia_Enfermedad

Tabla: TB_ Área

Campo Tipo Longitud Descripción

Campo Tipo Longitud Descripción

Restricciones: El campo codSubsidio es un identificador único.

Tabla: TB_ Usuario

Campo Tipo Longitud Descripción

Tabla: TB_ Cargo

Campo Tipo Longitud Descripción

Campo Tipo Longitud Descripción

4.3. Modelo de Diseño

4.3.1. Vista de Capas y Subsistemas

4.3.1.1. Capa de Presentación

4.3.1.2. Capa Controladora

4.3.1.3. Capa de Negocio

4.3.2. Realización de Casos de Uso – Modelo de Diseño

Escenario: ESC01 Flujo Básico de Eventos

Diagrama de Secuencia de Diseño

Escenario: ESC02 Flujo Básico de Eventos

Diagrama de Secuencia de Diseño

Escenario: ESC03 Flujo Básico de Eventos

Diagrama de Secuencia de Diseño

Escenario: ESC04 Flujo Básico de Eventos

Diagrama de Secuencia de Diseño

Escenario: ESC05 Flujo Básico de Eventos

Diagrama de Clases de Diseño

4.3.2.6 CUS06– LICENCIAS POR ENFERMEDAD POR ENFERMERA

Escenario: ESC06 Flujo Básico de Eventos

Diagrama de Clases de Diseño

Escenario: ESC07 Flujo Básico de Eventos

Diagrama de Clases de Diseño

4. Vista de Integración del Software

INTERFAZ DESCRIPCION BREVE TIPO DE REFERENCIA

4.1. Criterios de Integración de Software

4.2. Secuencia de Integración

4.3. Entorno Necesario para la Integración

NOMBRE DEL SERVIDOR Serv_Desa

Proveedor del Sistema Operativo Microsoft Corporation

Nombre del Sistema DEIPSBATCH

Proveedor del Sistema IBM

Modelo del Sistema -[865811Y]-

Tipo del Sistema X86 – based PC

SMBIOS Version 2.1

Total de Memoria Física 2,047.49 MB

Promedio de Memoria Física 1.37 GB