Sigesmed Guia Desarrollo v3.0
Sigesmed Guia Desarrollo v3.0
Universidad Católica de
Santa María
SIGESMED
Sistema de Gestión y monitoreo educativo
GUIA DE DESARROLLO
SIGESMED_GUIA_V3.0
Historial de Revisiones
1. INTRODUCCIÓN
2. DISEÑO CONCEPTUAL
2.1. ARQUITECTURA
2.1.1. Vista de la arquitectura
2.1.2. Diseño contextual
2.2. TECNOLOGÍAS UTILIZADAS
2.2.1. Tecnologías utilizadas en la arquitectura
2.2.2. Entorno de programación
3. PROCEDIMIENTO DE INSTALACIÓN
3.1. INSTALACIÓN DE PROGRAMAS
3.2. CONFIGURACIÓN
3.2.1. Creación de la Base de Datos
3.2.2. Configuración inicial de proyecto en Netbeans
4. ESTRUCTURA DEL PROYECTO
4.1. ESTRUCTURA DEL BACKEND ( carpeta “java” )
4.1.1. core
4.1.2. logic
4.1.3. service
4.1.4. util
4.2. ESTRUCTURA DEL FRONTEND ( carpeta “webapp” )
4.2.1. META-INF
4.2.2. WEB-INF
4.2.4. archivos
4.2.5. recursos
4.2.6. login.html
4.2.7. appLogin.js
4.3. ESTRUCTURA DE RECURSOS ( carpeta “resources”)
5. DESARROLLO DE NUEVOS MÓDULOS
5.1. EN EL FRONTEND
5.1.1. Entregables.
5.1.2. Integracion
5.2. EN EL BACKEND
5.2.1. Entregables
5.2.2. Integracion
5.3. EN LA BASE DE DATOS
5.3.1. Reglas para el diseño de BD.
5.3.2. Diccionario de Datos.
5.4. FORMATO DEL JSON
5.4.1. JSON de consulta
5.4.2. JSON de respuesta
6. REUTILIZABLES
6.1. REUTILIZABLES EN EL FRONTEND
6.2. REUTILIZABLES EN EL BACKEND
7. EJEMPLOS REALIZADOS
7.1. EN EL BACKEND
7.1.1. Creación del servicio
7.1.2. Creación del componente de lógica
7.1.3. Mapeo de Pojos
7.2. EN EL FRONTEND
7.2.1. Creación de la interfaz
7.2.2. Creación del controlador
8. FUNCIONAMIENTO
9. EJEMPLOS PROPUESTOS
10. AUTOEVALUACIÓN
11. REFERENCIAS
1. INTRODUCCIÓN
La guía de desarrollo del software SIGESMED tiene como finalidad brindar un amplio conocimiento al
desarrollador acerca del entorno de construcción, la arquitectura, instalación, ejemplos de uso, y otros
aspectos importantes.
2. DISEÑO CONCEPTUAL
2.1. ARQUITECTURA
2.1.1. Vista de la arquitectura
2.1.2. Diseño contextual
El diseño contextual hace referencia al modelo de arquitectura empleado, además de dar a conocer de
manera general cómo está conformada la arquitectura y la comunicación entre sus partes.
Framework como AngularJS incorporan los principios básicos del patrón MVC original a su manera de
construir aplicaciones web actuales. Delegando gran parte de responsabilidades al cliente como
(renderización de html validación de datos), y liberando de carga al servidor. Siendo este utilizado
solamente para nutrir de datos al cliente.
Es un estilo de arquitectura para desarrollar servicios, donde se debe cumplir las siguiente premisas:
● utiliza los métodos HTTP de manera explícita (POST, GET, PUT ,DELETE, HEAD)
● no mantiene estado
● expone URIs con forma de directorios
● transfiere XML, JavaScript Object Notation (JSON), o ambos
Los servicios están disponibles y son puntos de acceso para consumir los recursos del servidor.
Para homogeneizar el intercambio de información entre el servidor y el cliente, se hace uso de JSON el
cual tiene un formato ligero y fácil de entender
2.2. TECNOLOGÍAS UTILIZADAS
Se realiza una descripción de las tecnologías que son utilizadas en la arquitectura, de acuerdo a las
capas o partes que posee la misma; para ello se utiliza el siguiente cuadro de especificación.
2.2.1.1. Presentación
Plantillas y componentes bootstrap Framework que combina código HTML, CSS y Javascript
diseñado para ayudar a construir sitios y aplicaciones web
100% responsive adaptable a dispositivos
2.2.1.2. Servicios
Seguridad por Tokens Un valor que nos autentifica frente al servidor. A diferencia de
una contraseña, se puede anular o hacer caducar sin causar
excesivas molestias al usuario.
2.2.1.3. Lógica de negocio
Tecnología utilizada Descripción
2.2.1.4. Persistencia
Tecnología utilizada Descripción
Se realiza una descripción de las tecnologías que son utilizadas para la programación del sistema, ya
sea en entorno gráfico, de servidores, entre otros; para ello se utiliza el siguiente cuadro de
especificación.
Servidor Glassfish 4.1 Servidor de aplicaciones de software libre desarrollado por Sun
Microsystems, compañía adquirida por Oracle Corporation. Soporta
e implementa toda la tecnología definida por la plataforma java.
Inspector de código de Google Herramienta para el renderizado, estilo y estructura de las paginas
Chrome web, asi mismo nos permite ver a profundidad cómo es el
intercambio de recursos en la red.
Git * https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
* se pueden instalar de manera independiente, sin embargo Netbeans en un entorno de desarrollo
completo que ya cuenta con estas herramientas al momento de instalarlo.
3.2. CONFIGURACIÓN
Abrimos el programa pgadmin de postgrest para crear la BD con el nombre ya indicado, encoding UTF8
y el owner postgres por default.
Después abrimos el editor de sql dando click en execute arbitrary SQL queries , ahí copiamos
el script de la BD y ejecutamos esto nos creará todo el esquema.
El mapeo se hará con anotaciones del estándar JPA de javaee , y se llama a la ubicacion de esos archivos
<!--configguracion inicial-->
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.FuncionSistema" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.SubModuloSistema" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.ModuloSistema" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.Organizacion" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.Area" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.OrganizacionRol" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.Rol" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.RolFuncion" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.Usuario" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.TipoOrganizacion" />
<!--tramite documentario-->
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.TipoTramite" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.RequisitoTramite" />
<mapping class="com.dremo.ucsm.gsc.sigesmed.core.entity.RutaTramite" />
Una vez configurada la conexión, descargamos las dependencias del proyecto haciendo click derecho
en el Proyecto y en la opción Build with Dependencies.
Subimos la aplicación al servidor para ello damos click derecho en el Proyecto y en la opción Run, o
presionamos la tecla F6 elegimos.
A continuación se detalla la estructura de los archivos del proyecto, el cual se divide en tres partes
principales:
● Carpeta “java”: Lugar donde se implementa el BackEnd, aquí encontraremos los archivos .java
● Carpeta “webapp”: Lugar donde se implementa el FrontEnd, aquí se encuentran los archivos
.html, .css, .js
● Carpeta “resources”: Lugar donde se configura el mapeo de datos con la BD utilizando
framework Hibernate, aquí encontramos archivos de configuración .xml
4.1. ESTRUCTURA DEL BACKEND ( carpeta “java” )
4.1.1. core
capa principal donde se implementa el motor del sistema, que tiene funciones de arranque inicial,
seguridad, integracion de modulos de negocio y servicios,e intercambio de datos con el FrontEnd. Asi
mismo la capa core está compuesta por:
● datastore componente que sirve para hacer la coneccion con la base de datos
● entity capa donde encontramos todos los POJOs( (plain old objeto Java) que representan
datos que son mapeados a cada una de las tabla.
● integration encontramos los componentes para hacer la integración de los módulos de la
lógica del negocio, y los servicios implementado.
● security componente para hacer el control de seguridad y acceso al sistema.
● service se encuentran los componentes para la implementación de los servicios web, e inicio
del sistema.
4.1.2. logic
capa para la “lógica del negocio del sistema”, aquí se implementaran todos los módulos del forman
parte del SIGESMED, aqui desarrolladores pondrán sus implementaciones de los sub-módulos que
tendrán a cargo.
En la imágen siguiente vemos los sub-módulos y componentes que ya están siendo implementados:
● Sub-módulo configuracion_inicial: t rata sobre gestión de usuario, roles, organizaciones,
áreas, módulos, submódulos y funciones que son parte esencial para correcto funcionamiento
del sistema y que solo podrán ser accedidas por el administrador.
● Sub-módulo tramite_documentario: en proceso de construcción, ver módulo Tramite
documentario.
● Componente login: comprende la verificación de las credenciales para todo usuario
SIGESMED
4.1.3. service
Capa donde se implementaran todos los servicios Rest que brindara el sistema, la principal función de
esta capa es la de comunicar el FrontEnd con la capa de logic (Lógica de Negocio)
Por cada módulo en la capa “lógica” existirá un servicio rest, que nos permita acceder a el. El Servicio
para el Login es genérico porque se le utiliza solo para autenticar a un usuario, antes de acceder a los
demás módulos.
4.1.4. util
Aquí se encontrarán todos las funciones, clases o componentes que sirvan para complementar el
correcto funcionamiento de la parte de logic, además que deberán ser implementados de forma que
sean reutilizables para los módulos.
4.2.1. META-INF
4.2.2. WEB-INF
carpeta para la configuración del proyecto web en java y para subirlo al servidor glassfish.
4.2.3. app
Capa que contiene todo el FrontEnd del SIGESMED, y donde se implementa el patrón MVC, para ello
se utilizó el framework AngularJS. Los desarrolladores deberán colocar sus interfaces con sus
respectivos controladores de acuerdo al sub-módulo asignado.
La organización del proyecto en el lado del cliente, está dada como se ve en la figura.
● Encontramos los cuatros módulos principales de la lógica del negocio, que a su vez contienen
los sub-módulos que las conforman.
● app.js es el archivo principal para la configuración del proyecto angular.
● index.html plantilla principal que se utilizara para la navegación del sistema.
● mis-directivas.js archivos destinados para incluir todas los componentes nuevos, que se
creen para la interfaz basadas en directivas angular.
● mis-servicios.js archivos destinados para incluir los servicios públicos para toda la aplicación
4.2.4. archivos
Capa que contendrá todos los documentos, archivos, imágenes etc. que sean de interés y utilizados en
la “lógica del sistema”. (ejemplo: doc, pdf, jpg, xls, etc).
4.2.5. recursos
Capa donde estarán todos los recursos web (css,js,jpg,png,font) que servirán para una mejor
presentación, visualización del sistema en el lado del cliente. Aquí ya se definió las plantilla que se
utilizara, que está basada en la librería “bootstrap”. Todo recurso que se añada deberá ser informado.
4.2.6. login.html
Archivo que contiene la presentación del login, donde los usuarios podrán iniciar una sesión en el
sistema, presentando debidamente sus credenciales.
4.2.7. appLogin.js
Archivo controlador para el login.html, que solicitara el token de autenticación para para accesar al
sistema SIGESMED.
● En el FrontEnd
● En el BackEnd
5.1. EN EL FRONTEND
En la carpeta app/ se deberá crear una interfaz que permita la comunicación con el cliente, donde se
pueda visualizar y manipular datos, de acuerdo al caso de uso. Después y siguiendo el patrón MVC se
deberá crear también el controlador, donde se implemente la funcionalidad para que dé soporte a la
interfaz, tener en cuenta que el controlador deberá de comunicarse y consumir el servicio creado en el
BackEnd si este lo requiera.
5.1.1. Entregables.
● Un archivo .html donde estará la interfaz, basada en la plantilla elegida por el equipo. El
nombre del archivo deberá tener concordancia con el caso de uso a realizar, empezando por la
primera letra en minúscula.
● Un archivo .js donde estará el controlador de la interfaz, que está basado en el framework
angularjs. IMPORTANTE: El nombre del archivo será igual al de la interfaz añadiendo el sufijo
Ctrl, asi mismo el nombre del controlador deberá ser el mismo al del archivo .js.
Todo recurso web externo al proyecto ( .css, plugins, font, imágenes etc. ) que se necesiten para el
buen desarrollo en la parte del FrontEnd, se deberá informar al encargado para que realice una correcta
incorporación del recurso al proyecto.
5.1.2. Integracion
● Ubicar la carpeta donde se alojarán los archivos, para ello deberán ubicar primero el módulo
principal, seguido del sub-módulo al cual pertenecen.
● Para añadir la función al sistema, abrimos el modulo: AGREGADOS y al submódulo:
CONFIGURACIÓN DEL SISTEMA y al menú: FUNCIÓN SISTEMA
● Y finalmente cerramos sesión y volvemos a iniciar sesión, y veremos que nuestra función se
añadió correctamente al submódulo que le asignamos, para ello verificamos con el inspector de
código, si todo salió correctamente no debe de haber ningun error en la consola.
5.2. EN EL BACKEND
Se trabajará sobre las carpetas:
● service/rest/ donde se creará un micro servicio rest basado en el estándar de java, que atienda
peticiones del cliente y redirigirlas a sus respectivas operaciones que se encuentran en la lógica.
● logic/ donde se implementaran las operaciones que involucran la lógica de negocio de acuerdo al
caso de uso encomendado. Cada componente de lógica nuevo tiene que tener la siguiente
estructura. Debe estar dado por la versión (v1, v2,...) que se tenga del componente, seguido del
core donde se configura el componente para que pueda ser añadido al sistema y la carpeta tx
donde se ubican todas las operaciones o transacciones que se realicen.
5.2.1. Entregables
Durante el trabajo del en el BackEnd el desarrollador deberá presentar sus archivos .java:
● Un archivo donde se encuentre el micro-servicio rest. El nombre del archivo deberá tener
coherencia o igual nombre al sub-módulo, terminando con la palabra Service.
● Uno o varios archivos donde se implementen parte de la lógica, que serán tratadas como
operaciones o transacciones. El nombre del archivo o archivos, debe tener coherencia con la
función a realizar, asi mismo deben terminar con el sufijo Tx.
● Un archivo, de configuración donde se registran las operaciones de la lógica, que formarán parte
del sistema. Este archivo siempre tendrá el nombre de ComponentRegister.java. Y siempre
estara presente en cada componente nuevo que se cree.
● Adicionalmente podrán crear clases que ayuden al buen desarrollo de dichas operaciones. Si
necesitaran un componente adicional, deberán informar al encargado para que les de solución ya
sea creando uno o utilizando una librería externa.
5.2.2. Integracion
Antes de la integración al sistema cada componente de logica debe ser registrado internamente. Esto
se realiza en el archivo ComponentRegister.java que se encuentra en cada componente.
Se debe considerar el módulo al cual pertenecen, nombre del componente que lo identifica, la versión y
las diferentes operaciones indicando de manera explicita que tipo de operacion es. (POST, GET,
DELETE, UPDATE).
Hecho esto el sistema al iniciar cargará automáticamente todos los servicios y componentes
de lógica que deben estar ubicados correctamente.
● Para los servicios el lugar ubicacion es service/rest/ y ubicar el sub-módulo al cual pertenece.
● Para los componentes de lógica será en la carpeta logic/ y ubicar el sub-módulo al cual
pertenecen.(no olvidar la estructura del componente de lógica).
1. Todos los nombres de las tablas, atributos, vistas, procedimientos almacenados deberán estar
escritos en minúscula.
2. Los nombre de las tablas no serán abreviados y las palabras serán separados por “_”.
3. Los atributos serán abreviados por las tres primeras letras de cada palabra y separados por “_”.
4. Los atributos clave deberán terminar con el sufijo “id”.
5. Si es una clave incremental, esta deberá ser un tipo serial ( propia de Postgres).
6. Las tablas tendrán tres atributos fijos
dominio@version:operacion
dominio: ámbito o nombre del componente dentro del sistema donde se desea realizar la operación
versión: número de versión con la cual se desea trabajar
operación: nombre de la operación al cual se quiere acceder
{
"i.type" : "inet-res",
"scope" : "web",
"response" : "",
"responseSta" : true,
"responseMsg" : "la inserción fue correcta",
"meta":{},
"data":[
"1",
"2",
"3",
"4",
{
"selement1":"e1",
"selement2":"e2"
}
]
}
● i.type: campo indispensable, tipo “string”, indica el tipo de JSON si es consulta o respuesta
● scope: campo indispensable, tipo “string”, plataforma de trabajo ejem: web
● response: campo indispensable, tipo “string”, contiene información adicional acerca de la
respuesta del servidor
● responseSta: campo indispensable, tipo “boolean”, nos indica si la operación realizada tuvo éxito
(true) o hubo algún error (false)
● responseMsg: campo indispensable, tipo “string”, siempre tiene que haber un mensaje del
servidor.
● meta: campo indispensable, tipo “object”, información adicional acerca de los datos
● data: campo opcional, tipo ”objeto o array”, donde va toda la información que se desea enviar al servidor
6. REUTILIZABLES
Es la capacidad de los productos software para ser reutilizados, en su totalidad o en parte, en otras
aplicaciones, con la idea de evitar soluciones redundantes a problemas que ya se han solucionado con
anterioridad. Así, un programa debe agrupar en una serie de módulos aislados a los aspectos
dependientes de la aplicación particular.
3. Métodos adicionales
● mensaje( título, mensaje)
● crearRequest(identity,scope)
WebRequest Es una clase que nos permite leer los datos tipo JSON que
llegen al servidor. Además de verificar y validar la estructura
de los datos que envía el cliente. Ademas nos permite invocar
la transaccion u operacion que se encuentra en el JSON
Métodos:
● createFromJSON( JSONObject )
retorna: un WebRequest
● fromJSON(JSONObject)
JSONObject: objeto con formato json
● toJSON()
retorna: String
● invoke()
retorna: WebResponse
Métodos:
● fromJSON(JSONObject)
JSONObject: objeto con formato json
● toJSON()
retorna: String
● crearWebResponseError(mensaje)
retorna: WebResponse
mensaje: mensaje para enviar al cliente
● crearWebResponseExito(mensaje)
retorna: WebResponse
mensaje: mensaje para enviar al cliente
7. EJEMPLOS REALIZADOS
Antes de ver los ejemplos a nivel de código, es un requisito indispensable que el desarrollador tenga un
amplio conocimiento acerca de SIGESMED en los siguientes aspectos:
Ya vimos como es el funcionamiento del sistema, pero ahora vamos a ver como es el funcionamiento a
nivel de código, tomando el mismo ejemplo anterior LISTA DE TRAMITE:
Primero analizamos el caso de uso que nos dice que se desea insertar, editar, eliminar y ver los tipos
de trámites (CRUD).
7.1. EN EL BACKEND
Todo servicio debe tener las cuatro operaciones descritas anteriormente, solo se diferencian en la forma
de obtener los datos, el POST y el PUT reciben los datos en un objeto, mediante la notación
@Consumes y el GET, DELETE lo reciben dentro del url de la consulta, para leerlo se utiliza la
notación @QueryParam. Los datos son JSONs que están en forma de String.
Archivo TramiteDocumentarioService.java
@Path("/tramiteDocumentario")
public class TramiteDocumentarioService {
private static Logger logger = Logger.getLogger(TramiteDocumentarioService.class.getName());
@POST
@Consumes(MediaType.TEXT_PLAIN)
@Produces(MediaType.APPLICATION_JSON)
public String recursoPost(String content){
JSONObject jsonObject = new JSONObject(content);
WebRequest wRequest = WebRequest.createFromJSON(jsonObject);
WebResponse wResponse =
wRequest.invoke(Sigesmed.MODULO_TRAMITE_DOCUMENTARIO,TypeTransaction.type_transaction_POST);
return wResponse.toJSON().toString();
}
@GET
@Produces(MediaType.APPLICATION_JSON)
public String recursoGet(@QueryParam("content") String content){
Para tratar la petición en los cuatro casos es el mismo. Primero parseamos el String recibido a un
JSON con la clase JSONObject, después leemos y validamos su estructura del JSON con el método
createFromJSON de la clase WebRequest, luego se llama al método invoke para ejecutar la
operación solicitada en la lógica, para ello le indicamos explicitamente a que módulo pertenece
(Sigesmed.MODULO_TRAMITE_DOCUMENTARIO) y que tipo de transaccion
(TypeTransaction.type_transaction_PUT) sera, esto nos nos devolverá una clase WebResponse que
contendrá la respuesta de haber hecho la operación, y finalmente lo enviamos como un String al cliente.
Segundo, implementamos las operaciones en la lógica para ello solo veremos el caso de insertar tipo
de trámite en el siguiente código:
Archivo InsertarTipoTramiteTx.java
public class InsertarTipoTramiteTx implements ITransaction{
@Override
public WebResponse execute(WebRequest wr) {
/*
* Parte para la lectura, verificacion y validacion de datos
*/
TipoTramite nuevoTipoTramite = null;
List<FileBaseObject> listaArchivos = new ArrayList<FileBaseObject>();
try{
BaseObject requestData = (BaseObject)wr.getData();
String nombre = requestData.getElementString("nombre");
String descripcion = requestData.getElementString("descripcion");
short duracion = requestData.getElementShort("duracion");
double costo = requestData.getElementDouble("costo");
boolean tipo = requestData.getElementBoolean("tipo");
short tipoOrganizacion = requestData.getElementShort("tipoOrganizacionID");
BaseArray listaRequisitos = requestData.getElementBaseArray("requisitos");
BaseArray listaRutas = requestData.getElementBaseArray("rutas");
nuevoTipoTramite = new TipoTramite(0, "asd", nombre, descripcion, duracion, new BigDecimal(costo), tipo, new
Date(), 1, 'A', new TipoOrganizacion(tipoOrganizacion));
/*
* Parte de Logica de Negocio
* descripcion: El Sitema debe generar el codigo para el nuevo Tipo de Tramite antes de insertar a la BD
*/
nuevoTipoTramite.setCod("COD-01");
//Fin
/*
* Parte para la operacion en la Base de Datos
*/
Session session = HibernateUtil.getSessionFactory().openSession();
Transaction miTx = session.beginTransaction();
try{
//insertanto mi tipo Tramite
session.persist( nuevoTipoTramite);
miTx.commit();
}catch(Exception e){
miTx.rollback();
return WebResponse.crearWebResponseError("No se pudo registrar el tipo de tramite ", e.getMessage() );
}
finally{
session.close();
}
//Fin
TipoTramite.java
@Entity
@Table(name="tipo_tramite" ,schema="administrativo")
public class TipoTramite implements java.io.Serializable {
@Id
@Column(name="tip_tra_id", unique=true, nullable=false)
@SequenceGenerator(name = "secuencia_tipotramite", sequenceName="administrativo.tipo_tramite_tip_tra_id_seq" )
@GeneratedValue(generator="secuencia_tipotramite")
private int tipTraId;
@Column(name="cod", nullable=false, length=16)
private String cod;
@Column(name="nom", length=64)
private String nom;
@Column(name="des", length=256)
private String des;
@Column(name="dur")
private short dur;
@Column(name="cos", precision=9)
private BigDecimal cos;
@Column(name="tip")
private Boolean tip;
@Temporal(TemporalType.TIMESTAMP)
@Column(name="fec_mod", length=29)
private Date fecMod;
@Column(name="usu_mod")
private Integer usuMod;
@Column(name="est_reg", length=1)
private Character estReg;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumn(name="tip_org_id", nullable=false)
private TipoOrganizacion tipoOrganizacion;
@OneToMany(fetch=FetchType.LAZY, mappedBy="tipoTramite",cascade=CascadeType.PERSIST)
private List<RequisitoTramite> requisitoTramites ;
@OneToMany(fetch=FetchType.LAZY, mappedBy="tipoTramite",cascade=CascadeType.PERSIST)
private List<RutaTramite> rutaTramites ;
public TipoTramite() {
}
public TipoTramite(int tipTraId, String cod) {
this.tipTraId = tipTraId;
this.cod = cod;
}
public TipoTramite(int tipTraId, String cod, String nom, String des, short dur, BigDecimal cos, Boolean tip, Date fecMod,
Integer usuMod, Character estReg, TipoOrganizacion tipoOrganizacion) {
this.tipTraId = tipTraId;
this.cod = cod;
this.nom = nom;
this.des = des;
this.dur = dur;
this.cos = cos;
this.tip = tip;
this.fecMod = fecMod;
this.usuMod = usuMod;
this.estReg = estReg;
this.tipoOrganizacion = tipoOrganizacion;
}
public int getTipTraId() {
return this.tipTraId;
}
public void setTipTraId(int tipTraId) {
this.tipTraId = tipTraId;
}
public String getCod() {
return this.cod;
}
public void setCod(String cod) {
this.cod = cod;
}
public String getNom() {
return this.nom;
}
public void setNom(String nom) {
this.nom = nom;
}
public String getDes() {
return this.des;
}
public void setDes(String des) {
this.des = des;
}
public short getDur() {
return this.dur;
}
public void setDur(short dur) {
this.dur = dur;
}
public BigDecimal getCos() {
return this.cos;
}
public void setCos(BigDecimal cos) {
this.cos = cos;
}
public Boolean getTip() {
return this.tip;
}
public void setTip(Boolean tip) {
this.tip = tip;
}
public Date getFecMod() {
return this.fecMod;
}
public void setFecMod(Date fecMod) {
this.fecMod = fecMod;
}
7.2. EN EL FRONTEND
Archivo tipoTramite.html
app.controller("tipoTramiteCtrl",["$scope","crud","modal", function($scope,crud,modal){
Después se definen las variables que nos servirá para vincular con la interfaz
$scope.tipoOrganizaciones = [];
$scope.areas = [];
//Implenetacion del controlador
$scope.tiposTramites = [];//arreglo donde estan todos los tipos de tramites
//variable que servira para crear un nuevo tipo de tramite
$scope.tipoTramite = {codigo:"",nombre:"",descripcion:"",tipo:true,costo:"0.0",duracion:0,tipoOrganizacionID:0};
//variable temporal, para la seleccion de un tramite
$scope.tipoTramiteSel = {};
//varible para la creacion de un nuevo requisito
$scope.requisito = {descripcion:"",archivo:{}};
$scope.requisitoSel = {descripcion:"",archivo:{}};
//lista de requisitos del tramite
$scope.requisitos = [];
Después definimos la función listar que hara un consulta de todos los tipos de trámites que existen en
el sistema.
Utilizamos nuestro servicio crud para crear un objeto tipo de Request p
ara hacer nuestra consulta,
definimos el usuario y el ambito, luego con el metodo setCmd() definimos el nombre del componente,
la versión, y la operación a realizar. Finalmente llamamos al mentodo listar() donde se define el path
del servicio a consumir y le enviamos nuestro objeto Request, y esperamos a que el servidor nos dé
una respuesta. Si todo salio correctamente recibiremos la data con la todos los tipos de tramite que se
encuentran registrados.
$scope.listarTiposTramites = function(){
//preparamos un objeto request
var request = crud.crearRequest("admin","web");
//asignamos la operacion a realizar
request.setCmd('tipoTramite',1,'listarTipoTramite');
//llamamos al servicio listar, le damos la ruta donde se encuentra el recurso,el objeto request
//y las funciones de exito y error
crud.listar("/tramiteDocumentario",request,function(data){
$scope.tiposTramites = data.data;
},function(data){
console.info(data);
});
};
Ahora enlazamos los datos con la interfaz, con la interfaz, para ello utilizamos las directivas de angular:
ng-click: es una instrucción que se ejecuta cuando ocurre el evento del click realizado en un
determinado componente.
8. FUNCIONAMIENTO
Para probar la funcionalidad de la arquitectura del SIGESMED, se tomó como caso de prueba la función
de Lista de Trámite (todo el CRUD), del sub-módulo de Trámite documentario que a su vez pertenece al
módulo Administrativo.
Se nos presenta el login para acceder al sistema,el usuario de probar es admin y la contraseña admin
Vemos la pantalla de inicio y vamos al menú Trámite Documentario luego a Tipo Tramite.
Damos en listar los Tipos de Trámite y veremos los datos que están insertados actualmente.
Ahora vamos a insertar un nuevo Tipo de Trámite, para eso llenamos el formulario y damos en guardar
Si insertamos correctamente nos dará un mensaje de confirmación, y se añadirá a nuestra lista actual
Ahora vamos a eliminar un dato de la lista y simplemente damos click en la fila que queremos eliminar y
el sistema nos mostrara un dialogo de confirmación, aceptar.
Si se elimino correctamente el sistema mostrará el mensaje de confirmacion.
Ahora editaremos un dato de la tabla, para eso se nos abrirá un formulario donde podremos editar el
campo que elegimos.
Si todo sale bien recibiremos un mensaje de confirmación que nos dice que la actualización se realizó
con éxito.
9. EJEMPLOS PROPUESTOS
9.1. EN EL FRONTEND
a. Al momento de iniciar los tipo de tramites, debemos hacer click para visualizar los datos, siendo
esto no muy incómodo para el cliente. Lo que se pide es que los datos se cargan solos al
momento de ver esta sección. ( averiguar la instruccion: ng-init).
b. Para eliminar el sistema debe mostrarnos un mensaje donde pregunte si en realidad se desea
eliminar el dato, esto por cuestiones de seguridad. ( crear un ventana modal).
c.
9.2. EN EL BACKEND
a. Para insertar un tipo de trámite se debe generar el código de acuerdo, a la institución a la que
pertenece.
b. Implementar una nueva operacion para el componente, donde se resuelva la búsqueda de un
tipo de trámite por su id.
Avanzado: completar la inserción del tipo de tramites son sus respectivos requerimientos. (El tipo de
tramite debe tener un arreglo donde están sus requisitos, persistencia con relación uno a muchos).
10. AUTOEVALUACIÓN
11. REFERENCIAS
Página que explica conceptos importantes sobre java, MVC y servicios web
http://www.arquitecturajava.com/
IEEE Std. 1012 – 1986 Standard for Software Verification and Validation Plans
https://standards.ieee.org/findstds/standard/1012-1986.html