Trabajo Teoorico Final

Ttulo del Proyecto de Investigacin
Transacciones electrnicas
Grupo 301403_60
Presentado por:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
PROGRAMA INGENIERIA ELECTRONICA
COLOMBIA
2015
Ttulo del Proyecto de Investigacin

Transacciones electrnicas
Grupo 301403_60
Presentado por:
Richard Alexander Muoz Castro
Elkin David Aguilar Llanos
Tutor:
Cesar Orlando Jimnez Angarita
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
PROGRAMA INGENIERIA ELECTRONICA
COLOMBIA
2015
CONTENIDO
Listado de Tablas.........................................................................................................4
Listado de figuras.........................................................................................................6
Captulo 1. Introduccin................................................................................................
Captulo 2 Objetivos.....................................................................................................
Captulo 3 Justificacin...............................................................................................
Captulo 4 Marco Terico............................................................................................
Captulo 6 Modelo de Requisitos.................................................................................
6.1. Descripcin del problema.................................................................................14
6.2. Modelo de Caso de Uso....................................................................................15
6.3. Modelo de Interfaces.........................................................................................25
6.4. Actores y Caso de Uso......................................................................................27
6 Modelo de Dominio del Problema........................................................................28
Captulo 7 Modelo de Anlisis......................................................................................
7.1. Arquitectura de clases.......................................................................................29
7.2. Identificacin de clases segn Estereotipos..................................................32
7.3. Clases segn casos de Uso.....................................................................................33
7.4. Diagramas de Secuencia..................................................................................34
7.5. Casos de uso para el sistema..........................................................................39
Captulo 8 Modelo de Diseo.......................................................................................

8.1. Estrategias de Diseo.......................................................................................50
8.2. Diseo de Objetos..............................................................................................52
8.3. Diseo de Sistema.............................................................................................55
8.4. Revisin del Diseo...........................................................................................57
8.5. Diagrama de Secuencia del Diseo................................................................62
Captulo 9 Modelo de Diseo.......................................................................................
9.1. Programacin en java........................................................................................68
9.2. Diagrama de clases..........................................................................................80
10.1. Definicin de conceptos..................................................................................81
10.1. Tipo de pruebas................................................................................................81
Captulo 11 Conclusiones............................................................................................
Captulo 12 Recomendaciones....................................................................................
Capitulo 13 Bibliografa................................................................................................
Listado de Tablas
Tabla 1 Modelo de requisitos Solicitud historial paciente........................................15

Tabla 2 Modelo de requisitos Agregar exmenes....................................................16
Tabla 3 Modelo de requisitos Emitir exmenes........................................................17
Tabla 4 Modelo de requisitos Eliminar reserva hora................................................18
Tabla 5 Modelo de requisitos cambiar historial del paciente..................................19
Tabla 6 Modelo de requisitos Solicitar exmenes....................................................20
Tabla 7 Modelo de requisitos Emitir receta...............................................................21
Tabla 8 Modelo de requisitos Fijar horario disponible.............................................22
Tabla 9 Modelo de requisitos Ingresar exmenes solicitados................................23
Tabla 10 Modelo de requisitos Ingresar resultados exmenes..............................24
Tabla 11 Actores.............................................................................................................27
Tabla 12 Casos de uso para el sistema _Validar Usuario.......................................39
Tabla 13 Casos de uso para el sistema _Solicitar Historial....................................40
Tabla 14 Casos de uso para el sistema _Imprimir Historial....................................40
Tabla 15 Casos de uso para el sistema _Historial de los exmenes....................41
Tabla 16 Casos de uso para el sistema _Ingresar Paciente..................................41
Tabla 17 Casos de uso para el sistema _Consultar Hora Pedida.........................42
Tabla 18 Casos de uso para el sistema _Hora Disponible.....................................43
Tabla 19 Casos de uso para el sistema _Solicitar Hora..........................................43
Tabla 20 Casos de uso para el sistema _Agregar Exmenes...............................44
Tabla 21 Casos de uso para el sistema _Eliminar Hora.........................................45
Tabla 22 Casos de uso para el sistema _Emitir examen........................................45

Tabla 23 Casos de uso para el sistema _Historial Paciente...................................46
Tabla 24 Casos de uso para el sistema _Eliminar del Historial Paciente............46
Tabla 25 Casos de uso para el sistema _Emitir Receta..........................................47
Tabla 26 Casos de uso para el sistema _Imprimir Receta....................................47
Tabla 27 Casos de uso para el sistema _Fijar Horario............................................48
Tabla 28 Casos de uso para el sistema _Resultado Examen................................48
Tabla 29 Casos de uso para el sistema _Ingresa Solicitud Examen....................49
Tabla 30 Revisin del diseo.......................................................................................57
Tabla 31 Clases del dominio funcionario...................................................................68
Listado de figuras
Imagen 1 Modelo Interfaces.............................................................................................25

Imagen 2 Interfaz de usuario.......................................................................................26
Imagen 3 Interfaz Ficha mdica (Medico o doctor)..................................................26
Imagen 4 Interfaz Pedir horas Medicas (Secretaria)...............................................26
Imagen 5 Diagramas casos de uso............................................................................27
Imagen 6 Arquitectura de clases_Consultar historial medico................................29
Imagen 7 Arquitectura de clases_Diagrama Ingresar paciente accidentado......29
Imagen 8 Arquitectura de clases_Diagrama ingresar paciente accidentado.......30
Imagen 9 Arquitectura de clases_Diagrama Consultar hora de atencin del
30
Imagen 10 Arquitectura de clases_Diagrama Examen solicitado.........................31

Imagen 11 Arquitectura de clases_Diagrama Ingresar resultado examen...........31
Imagen 12 Clases segn caso de uso_Diagrama solicitar historial del paciente
...............................................................................................................................................33
Imagen 13 Clases segn caso de uso_Diagrama Ingresar datos paciente
accidentado.........................................................................................................................33
Imagen 14 Clases segn caso de uso_Diagrama Consultar hora pedida...........34
Imagen 15 Diagrama de secuencia_ Solicitar Historial Paciente..........................34
Imagen 16 Diagrama de secuencia_ Ingresar Datos Paciente Accidentado......34
Imagen 17 Diagrama de secuencia_ Consulta Hora Atencin Paciente..............35
Imagen 18 Diagrama de secuencia_ Consulta Hora Disponible..........................35
Imagen 19 Diagrama de secuencia_ Solicitar Hora Atencin Paciente...............36
Imagen 20 Diagrama de secuencia_ Agregar Exmenes......................................36

Imagen 21 Diagrama de secuencia_ Eliminar Reserva Hora...............................36
Imagen 22 Diagrama de secuencia_ Emitir Exmenes.........................................37
Imagen 23 Diagrama de secuencia_ Emitir Exmenes.........................................37
Imagen 24 Diagrama de secuencia_ Eliminar historial del paciente...................37
Imagen 25 Diagrama de secuencia_ Emitir Receta...............................................38
Imagen 26 Diagrama de secuencia_ Fijar Horario Disponible..............................38
Imagen 27 Diagrama de secuencia_ Ingresar resultado examen........................38
Imagen 28 Diagrama de secuencia_ Ingresar Examen solicitado.......................39
Imagen 29 Estrategias de Diseo_Diagrama Consulta Historial Medico.............50
Imagen 30 Estrategias de Diseo_Diagrama Ingresar Paciente Accidentado....50
Imagen 31 Estrategias de Diseo_Diagrama Consulta hora atencin paciente.51
Imagen 32 Estrategias de Diseo_Diagrama Ingresar Examen solicitado..........51
Imagen 33 Estrategias de Diseo_Diagrama Ingresar Resultado Examen........52
Imagen 34 Diseo Paquetes del Dominio.................................................................53
Imagen 35 Diseo Paquete del Recepcionista.........................................................53
Imagen 36 diseo Paquetes de Secretaria...............................................................53
Imagen 37 Diseo Paquete de Funcionario_Clinica_Externa................................54
Imagen 38 Diseo Paquete de Medico......................................................................54
Imagen 39 Diseo Paquete de Laboratorio Clnico.................................................54
Imagen 40 Diseo Paquete ACOS.............................................................................54
Imagen 41 Diseo del sistema....................................................................................55
Imagen 42 Secuencia de diseo Historial del paciente..........................................62
Imagen 43 Secuencia de diseo Ingresar Datos Paciente Accidentado..............63

Imagen 44 Secuencia de diseo Consulta Hora pedida Atencin Paciente........63
Imagen 45 Secuencia de diseo Consulta Hora Disponible Atencin Paciente. 64
Imagen 46 Secuencia de diseo Solicitud hora de atencin..................................64
Imagen 47 Secuencia de diseo Agregar exmenes..............................................64
Imagen 48 Secuencia de diseo Eliminar reserva hora..........................................65
Imagen 49 Secuencia de diseo Emitir exmenes.................................................65
Imagen 50 Secuencia de diseo Cambiar historial paciente.................................66
Imagen 51 Secuencia de diseo Cambiar historial paciente.................................66
Imagen 52 Secuencia de diseo Emitir receta..................................................................66
Imagen 53 Secuencia de diseo Fijar hora disponible.....................................................66
Imagen 54 Secuencia de diseo Ingresar resultado examen................................67
Imagen 55 Secuencia de diseo Ingresar examen solicitado................................67
Captulo 1. Introduccin
Se desarrollara el un problema relacionado con el sistema de atencin a
pacientes en la que se pretende dar solucin a una serie de pasos como procurar
que el hombre de trabajo, en conjunto con las empresas asociadas, ambientes
laborales sanos, seguros y exentos de riesgos, a fin de preservar en plenitud su
integridad tanto fsica como squica, daremos una pequea descripcin del
Sistema Actual, sus necesidades y objetivos perseguidos en este proyecto,
adems de los costos de la implementacin del sistema de informacin.
Captulo 2 Objetivos
2.1. Se propone desarrollar un software que gestione el sistema de Atencin

de Clientes, manejando para esto una base de datos que contendr el registro
de todos los beneficiarios asociados a la Asociacin Chilena de Seguridad.
2.2. Caractersticas Principales del Sistema:
Manejo de Fichas Mdicas automatizado.

Control de Peticin de Horas de atencin.
Manejo de Historial Clnico de pacientes.
Manejo de Exmenes, en forma digitalizada, de los pacientes
Entrega de Recetas Mdicas.
Acceso externo del sistema, para que otras instituciones puedan ver el
historial Mdico en caso de traslado de paciente.
Acceso interno de distintos usuarios al sistema.
Captulo 3 Justificacin
Por medio del desarrollo y aplicacin de estos conceptos se pretende dar una
gua o herramienta para la puesta en prctica del conocimiento adquirido por
medio de un estudio de caso, brindando al lector una estructura funcional que le
permita llevar una secuencia de los temas ms relevantes al momento de brindar
una solucin sistemtica a un problema y desarrollar un software por medio de la
Programacin Orientada a Objetos.
Captulo 4 Delimitacin
Captulo 5 Programacin Orientada a Objetos en Java
5.1.- Programacin orientada a objetos

Debido a la complejidad del problema a tratar y de los algoritmos a
implementar, se opta por desarrollar la aplicacin en un lenguaje orientado a
objetos.
La orientacin a objetos es un paradigma de programacin que facilita la
creacin de software de calidad por sus factores que potencian el mantenimiento,
la extensin y la reutilizacin del software generado bajo este paradigma.
La programacin orientada a objetos trata de amoldarse al modo de pensar
del hombre y no al de la mquina. Esto es posible gracias a la forma racional con
la que se manejan las abstracciones que representan las entidades del dominio
del problema, y a propiedades como la jerarqua o el encapsulamiento.
El elemento bsico de este paradigma no es la funcin (elemento bsico de
la programacin estructurada), sino un ente denominado objeto. Un objeto es la
representacin de un concepto para un programa, y contiene toda la informacin
necesaria para abstraer dicho concepto: los datos que describen su estado y las
operaciones que pueden modificar dicho estado, y determinan las capacidades del
objeto. (BURGOS, 1999)
Dentro de los lenguajes de programacin orientados a objetos, se ha
optado por el lenguaje JAVA, cuyas principales caractersticas se comentan a
continuacin.
5.2. Programacin Bsica
Conceptos Bsicos de Programacin Orientada a Objetos
En esta entrada veremos algunos conceptos de la

programacin orientada a Objetos (POO)...............................................
Muchas veces cuando empezamos a trabajar con lenguajes de programacin

nos dicen que son orientados a Objetos y nos dan la teora del"porqu" pero
puede que al trabajar con ellos en la practica no sepamos interpretarlo
desconociendo el "como", y entonces seguimos desarrollando por simple inercia
porque as fue que aprendimos pero tal vez no de la forma mas ptima.
Vamos a ver algunos conceptos de POO de forma general, mas adelante
trabajaremos estos conceptos en casos prcticos para ver su aplicacin......
Empecemos!!!
Programacin OO.
La programacin orientada a Objetos bsicamente define una serie de
conceptos y tcnicas de programacin para representar acciones o cosas de la
vida real basada en objetos, a diferencia de otras formas de programacin como
por ejemplo la estructurada, con la POO trabajamos de manera distinta vinculando
diferentes conceptos tales como clases, objetos, mtodos, propiedades, estados,
herencia, encapsulacin entre otros, generando cada vez interrelaciones en
nuestro desarrollo en pro del funcionamiento del sistema principal, definiendo el
programa como un conjunto de estos objetos relacionados entre si.
Veamos algunos de los conceptos principales.....
Clases.
Las clases son uno de los principales componentes de un lenguaje de
programacin, pues en ellas ocurren todos los procesos lgicos requeridos para
un sistema, en si podemos definirlas como estructuras que representan objetos del
mundo real, tomando como objetos a personas, lugares o cosas, en general las
clases poseen propiedades, comportamientos y relaciones con otras clases del
sistema. (Ver Ejemplo...)
una clase se compone por tres partes fundamentales:
Nombre : Contiene el Nombre de la Clase.

Atributos : Representan las propiedades que caracterizan la clase.
Mtodos : Representan el comportamiento u operaciones, la forma como
interacta la clase con su entorno.
En java se representa as :
/**Principal define el nombre de la Clase*/
public class Principal {
3
4
public String atributo="Esto es un atributo";
5
6
/**Esto es un mtodo, donde se definen las operaciones*/
public void metodo(){
/**aqui van las sentencias que definen
* el comportamiento del mtodo*/
10
11
Objeto.
Los objetos representan una entidad concreta o abstracta del mundo real, en
programacin bsicamente se le conoce como la instancia de una clase en si es lo
que da el sentido a estas.
Al igual que las clases se componen de tres partes fundamentales:
Estado: Representa los atributos o caractersticas con valores concretos del
objeto. Comportamiento : Se define por los mtodos u operaciones que se
pueden realizar con el. Identidad : Es la propiedad nica que representa al objeto
y lo diferencia del resto.
en la imagen, los moldes representan las clases,

mientras que las galletas obtenidas de estos moldes representan los objetos
instancias de estas clases, por ejemplo atributos del objeto galleta podra ser
sabor, color, tamao etc......
En java se representa creando una instancia de la clase por medio de la
palabra new al hacer eso creamos el objeto de la clase y podemos hacer uso de
los mtodos o atributos de esta (dependiendo de la visibilidad de los mismos ) por
medio de un punto (.) as:
1
/**Creamos el objeto como instancia de la clase Principal*/
Principal miObjeto= new Principal();
miObjeto.atributo="Este es el nuevo valor del atributo para el objeto";
miObjeto.metodo();
Herencia.
La herencia en java representa lo que conocemos de herencia en el mundo real,

bsicamente mediante esta obtenemos las caractersticas o rasgos comunes de
nuestros padres o abuelos, en java es el mismo enfoque permitiendo la creacin
de nuevas clases basadas en clases ya existentes, con las cuales podemos
obtener las caractersticas de las clases padres, heredando campos, atributos,
mtodos o funcionalidades.
En Java solo se puede heredar de una sola clase padre y se representa mediante
la palabra extends (Ver Ejemplo...)
public class Animal{
public String tamao;
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public void comer(){

/**Comportamiento.....*/
}
class Perro extends Animal
public int dientes;
public void correr(){

}
}
class Paloma extends Animal{

public int plumas;
public void volar(){
}
Encapsulamiento.
Este concepto es uno de los mas importantes en trminos de seguridad dentro de
nuestra aplicacin, la encapsulacin es la forma de proteger nuestros datos dentro
del sistema, estableciendo bsicamente los permisos o niveles de visibilidad o
acceso de nuestros datos
Se representa por 3 niveles :
Pblico: Se puede acceder a todos los atributos o mtodos de la

clase. Protegido: Se puede acceder a los atributos o mtodos solo en la misma
jerarqua de herencia. Privado: Solo se puede acceder a los atributos o mtodos
de la clase en la que se encuentran.
con la Encapsulacin mantenemos nuestros datos seguros, ya que podemos
evitar que por ejemplo se hagan modificaciones al estado o comportamiento de un
objeto desde una clase externa, una buena practica es trabajar
con mtodos setter y getter que permiten manipular nuestros datos de forma
segura.
en Java lo representamos as:
1
2
3
4
5
6
7
8
9
10
11
12
13
public class Principal{

public String atributo1;
private String atributo2;
protected String atributo3
/**Mtodos Set y Get para trabajar con las variables*
public String getAtributo2() {
return atributo2;
}
public void setAtributo2(String atributo2) {
this.atributo2 = atributo2;
}
14
Clases Abstractas.
La abstraccin permite resaltar la parte mas representativa de algo, ignorando

detalles para centrarse en lo principal.
La imagen es muy fcil de identificar, con base a ella podemos crear una clase
persona, o la
clase hombre, humano entre otras, pero obviamente vemos que la

imagen no tiene elementos como ojos, nariz, boca, rostro en general, ni dedos,
pies, manos o cuello....... pero entonces porque decimos que es una
persona?.........Precisamente aqu estamos aplicando el concepto de abstraccin,
ya que nos fijamos en lo mas representativo de algo, en este caso vemos que se
tiene una cabeza, tronco, brazos y pies, con esto es suficiente para saber que es
una persona sin fijarnos en los detalles mencionados anteriormente.
Las clases abstractas permiten crear mtodos generales con un
comportamiento comn para otras clases concretas sin importar sus
caractersticas ni el comportamiento que usen para dichos mtodos.
La Abstraccin en java solo tiene lgica mediante la Herencia, ya que una clase
abstracta posee al menos un mtodo abstracto el cual no tiene implementacin, el
comportamiento de estos mtodos lo definen las clases concretas que lo hereden.
Podemos usarlos cuando existan varias clases con caractersticas o acciones
comunes pero con diferentes comportamientos..............mediante el uso de la
herencia y componentes abstractos hacemos mas ptima y organizada nuestra
aplicacin. (hay que tener en cuenta que a diferencia de las clases concretas, las
clases abstractas no se pueden instanciar). (Ver Ejemplo...)
En Java representamos la abstraccin mediante la palabra reservada abstract,
as:
1
public abstract class Principal{
2
3
/**Mtodo Abstracto sin implementacin*/
public abstract void metodoAbstracto();
7
8
class subClase extends Principal{
9
10
@Override
11
public void metodoAbstracto() {
12
/**Implementacin definida por la clase concreta*/
13
14
15
Interfaces.
Las interfaces son el mecanismo que utiliza Java para simular la

herencia mltiple, como mencionamos en Java solo se puede extender de una
sola clase, mediante el uso de interfaces esto se puede simular ya que el lenguaje
permite implementar el numero de interfaces que necesitemos, bsicamente son
clases completamente abstractas, es comn relacionarlas con un contrato en el
que se define que se debe hacer, as cada clase concreta que implemente una
interfaz esta obligada a implementar todos los mtodos que la compongan.
las interfaces definen lo que la clase que la implemente deber hacer, mas no la
forma como lo har.
al decir que las interfaces son clases completamente abstractas significa que
todos sus mtodos lo son y por ende no poseen implementacin, no requieren el
uso de la palabra reservada abstract, ya que al ser completamente abstracta todo
dentro de ella lo es, al igual que las clases abstractas la implementacin de
los mtodos depende de las clases concretas que las usen.
Se debe tener en cuenta que toda variable definida en una
interfaz automticamente se convierte en una constante, adems tampoco se
puede instanciar una interfaz..... (Ver Ejemplo...)

En java se representan con la palabra interface y se usan con la
palabraimplements as:
1
2
3
interface InterfacePrincipal
public void metodoAbstracto();
public String otroMetodoAbstracto();
4
5
6
}
public class Principal implements InterfacePrincipal{
public void metodoAbstracto() {
7
8
9

}
public String otroMetodoAbstracto() {
10
11
12
13
return "retorno";
}
}
Polimorfismo.
Este tal vez sea uno de los conceptos de la programacin orientada a objetos
mas usados pero muchas veces sin saber que se aplica ya que el concepto
inicialmente puede ser un poco confuso, bsicamente mediante el polimorfismo
programamos de forma general en lugar de hacerlo de forma especifica, se usa
cuando se trabajen con la herencia y objetos de caractersticas comunes los
cuales comparten la misma superClase y rbol jerrquico, al trabajar con este
concepto optimizamos y simplificamos en gran medida nuestro trabajo.
bsicamente podemos definirlo como la capacidad que tienen los objetos de

comportarse de mltiples formas sin olvidar que para esto se requiere de la
herencia, en si consiste en hacer referencia a objetos de una clase que puedan
tomar comportamientos de objetos descendientes de esta.
con el polimorfismo usamos la generalizacin olvidando los detalles concretos de
los objetos para centrarnos en un punto en comn mediante una clase padre.
Tomando como ejemplo la imagen anterior, podemos decir que un objeto de la
clase FiguraGeometrica puede usarse para referirse a cualquier objeto de
cualquier subClase de FiguraGeometrica.............. en otras palabras una figura
geomtrica puede ser un cuadro, un tringulo, un cuadrado o cualquier figura que
en trminos generales sea geomtrica...... (Ejemplo1) (Ejemplo2)
Veamos este proceso como se representa en Java.
1
class FiguraGeometrica{
3
4
11
12
class Cuadrado extends FiguraGeometrica {
13
14
15
16
class Triangulo extends FiguraGeometrica {
17
18
19
class Circulo extends FiguraGeometrica{
}
20
21
public class Principal{
22
23
24
25
26
27
28
29
30
31
32
33
34
public void metodo(){

/**Puedo crear objetos concretos*/
FiguraGeometrica miFiguraGeometrica = new FiguraGeometrica();
Cuadrado miCuadro=new Cuadrado();
/**Puedo crear objetos polimorficos*/

miFiguraGeometrica=miCuadro;
/**Objeto Cuadrado de tipo FiguraGeometrica*/

FiguraGeometrica miCuadrado= new Cuadrado();
/**Objeto Circulo de tipo FiguraGeometrica*/
FiguraGeometrica miCirculo=new Circulo();
/**Objeto Triangulo de tipo FiguraGeometrica*/
FiguraGeometrica miTriangulo=new Triangulo();
}
}
Como vemos en el ejemplo la clase FiguraGeometrica puede convertirse en

cualquier figura que se encuentra en su jerarqua de Herencia pudiendo utilizar las
propiedades que compartan entre ellas, hay que tener presente que solo se
permite el polimorfismo de clases padre a clases hija mas no al contrario, mas
adelante explicaremos este concepto en detalle...

Hasta aqu vimos algunos de los principales conceptos de la programacin
Orientada a Objetos, en futuras entradas trabajaremos otros ejemplos y
aplicaciones, ya que cada concepto posee sus restricciones con respecto al
proceso de desarrollo.
5.3. Programacin Avanzada

En las siguientes secciones se describen conceptos mas avanzados de la
programacion
en Java.
ARCHIVOS En Java es relativamente sencillo tener acceso a archives, como lo
ilustra el siguiente codigo en Java:
File file = new File(ch" r,archive) ;
BufferedReader is = new BufferedReader(new FileReader(file));
String s = is. readLineQ ;
is.close();
Captulo 6 Modelo de Requisitos

6.1. Descripcin del problema
Descripcin del Problema
La Asociacin Colombiana de Seguridad es una Empresa Privada sin fines de
lucro dedicada a otorgar cobertura total en caso de accidentes Laborales y
sobre todo a la prevencin de estos. Su misin es: "procurar para el hombre
de trabajo, en conjunto con las empresas asociadas, ambientes laborales
sanos, seguros y exentos de riesgos, a fin de preservar en plenitud su
integridad tanto fsica como squica"
Dentro de esta empresa existe un departamento clnico, que es el encargado
de la atencin de los pacientes que sufrieron algn accidente de trabajo en
alguna de las empresas asociadas, este se encarga de la atencin mientras
se recuperan y puedan retornar a sus puestos de trabajo.
Se desea automatizar el sistema de atencin al paciente y el sistema de fichas
mdicas para mejorar la coordinacin de las distintas unidades que posee la
ACOS; para esto, el proyecto consta de realizar un sistema de que maneje
toda la parte relacionada con los pacientes y que pueda interactuar de forma
adecuada con otros sistemas sin problemas.
Cuando a un trabajador le ocurre un accidente, ste es derivado al centro de
atencin ms cercano, una vez ah da los datos del accidente, y la
recepcionista cursa el ingreso del paciente a la Mutual, si el paciente no est
asociado se crea la ficha mdica, luego la secretaria del departamento clnico
registra al paciente y lo deriva a la atencin mdica.
El mdico evala si el paciente necesita derivarse a un hospital o clnica
externa, al enviarlo a una entidad externa se debe enviar al paciente junto con
su historial mdico, y si no lo enva, puede modificar su tratamiento. El mdico
tambin evala si debe dar el alta al paciente o no, si le da el alta, la secretaria
debe registrar los datos del alta en la ficha mdica, y si no, puede modificar el
tratamiento que est siguiendo el paciente.
6.2. Modelo de Caso de Uso

Iniciaremos la obtencin de los diferentes casos de uso del sistema, as como el
modelado conceptual y las dems etapas del modelado de requisitos y nos
ayudarn en la comprensin del funcionamiento del sistema de atencin pacientes
de la ACOS.
Descripcin de los casos de uso esenciales del sistema atencin pacientes en
el cual se describirn las distintas actividades que son posibles realizar por el
sistema para los distintos actores.
Con su mdico tratante, mientras ste no le d el alta.
Tabla 1 Modelo de requisitos Solicitud historial paciente
Resumen: El actor ingresa sus datos y solicita el historial de un paciente

determinado ingresando para ello el Rut del paciente, donde podr consultar las
distintas enfermedades preexistentes o los distintos remedios a los que el
paciente puede ser alrgico, as como el de conocer el historial mdico ( Datos
Histricos paciente).
Actor Principal: Secretaria Departamento Clnico.
Personal Involucrado:
Secretaria Departamento Clnico: Ingresa los exmenes del paciente a su historial
de atencin (Ficha).
Precondiciones: El Paciente pertenece a la ACOS.
Poscondiciones: Actualizacin de Historial lista para otra actualizacin.
Flujo Bsico:
1. La secretaria departamento clnico ingresa sus datos al sistema.
2. El Sistema verifica los datos ingresados.
3. La secretaria departamento clnico ingresa los datos del paciente.
4. El Sistema verifica los datos del paciente.
5. El Sistema pondr a disposicin el historial del paciente para ingresar los
exmenes.
6. La secretaria departamento clnico ingresa los exmenes del paciente.
7. Repetir 5 hasta terminar el ingreso de exmenes del paciente.
8. Fin ingreso de exmenes.
Requisitos Especiales:
- Los Datos de horario de atencin debern ser ordenados por fecha y hora.
Lista de Tecnologas y Variaciones de Datos:
Cuestiones Pendientes: Asignar a otro mdico cuando el mdico tratante no
este disponible.
Tabla 2 Modelo de requisitos Agregar exmenes
Resumen: La secretaria departamento clnico ingresa sus datos e ingresa los

exmenes hechos al paciente a su historial, para ello ingresa el identificador del
paciente y los anexa al Histrico de Pacientes (Datos Histricos Paciente).
Recepcionista ACOS: Realizar consulta historial paciente, para poder imprimir
alguna parte de la ficha para ser enviado hacia una consulta externa.
Secretara Departamento Clnico: Realiza consulta historial paciente, para poder
imprimir
alguna parte de la ficha para ser enviado hacia una consulta para otro
tratamiento fuera del
ACOS.
Doctor: Realiza consulta historial paciente, para consultar tratamientos
realizados anteriormente, as como enfermedades preexistentes del pacientes.
Clnica Externa: Realiza consulta historial paciente, para ver antecedentes de
alergias u enfermedades preexistentes, o si se encuentra bajo algn tratamiento.
Precondiciones: El paciente debe estar registrado en la ACOS.
Poscondiciones: Impresin ficha paciente, consulta cerrada historial paciente.
Flujo Bsico:
1. El Usuario ingresa sus datos al sistema.
3. El Usuario ingresa los datos del paciente.
5. El Sistema pondr a disposicin el historial del paciente.
6. El Usuario podr imprimir historial mdico paciente, cmo solo consultarlo.
7. Repetir 3 hasta terminar consulta historial pacientes.
8. Fin consulta paciente.
Flujo Alternativo:
2.1 Si los datos del usuario no son vlidos.
2.1.2 Ir al paso 1 o salir del sistema paso 8.
4.1 Si los datos del paciente no son validos
- Los exmenes debern ser ordenados por fecha ms reciente.
Cuestiones Pendientes: Crear un historial paciente cuando sea paciente
nuevo...
Tabla 3 Modelo de requisitos Emitir exmenes
Resumen: La secretaria departamento clnico ingresa sus datos y entrega los

exmenes (impresos) al paciente ingresando para ello el identificador del
paciente, estos son realizados por el laboratorio clnico (Datos Exmenes Lab.).
Actor Principal: Secretaria Departamento Clnico: Busca los exmenes del
paciente para su entrega y los imprime.
Laboratorio Clnico: Ingresa los resultados de los exmenes al sistema.
Secretaria Departamento Clnico: Ingresa los exmenes del paciente a su
historial de atencin (Ficha).
Precondiciones: Al Paciente le ingresan exmenes al laboratorio clnico.
Poscondiciones: El sistema est listo para emitir nuevos exmenes
Flujo Bsico:
1. La secretaria departamento clnico ingresa sus datos al sistema.
3. La secretaria departamento clnico ingresa los datos del paciente.
5. El Sistema pondr a disposicin los exmenes realizados al paciente para
imprimirlos.
6. La secretaria departamento clnico selecciona exmenes a imprimir.
7. Repetir 5 hasta terminar de imprimir los exmenes del paciente.
8. Fin emisin de exmenes.
Flujo Alternativo:
2.1 Si los datos del usuario no son vlidos.
- Los exmenes debern ser ordenados por fecha ms reciente.
Cuestiones Pendientes:
Tabla 4 Modelo de requisitos Eliminar reserva hora
Resumen: La secretaria departamento clnico ingresa sus datos y solicita el

horario de consulta del mdico, ingresando para ello la identificacin del mdico,
para poder ver el horario que se le asign al paciente para eliminarla
Resumen: El doctor ingresa sus datos y solicita el historial de un paciente

(Reservacin Horario de Atencin).
determinado ingresando para ello el rut del paciente, donde podr agregar los
exmenes hechos al pacientes, los medicamentos aplicados y el tratamiento
(Personal
Datos Histricos
paciente).
Involucrado:
Actor Principal: Doctor
Secretaria Departamento Clnico: Realizar consulta hora de atencin mdico
pedida por el paciente para eliminarla.
Doctor: EsInvolucrado:
quien fija el horario de atencin que tiene disponible
Personal
Precondiciones:
El Paciente debe
haber pedido
hora de
atencinlos
mdico.
Doctor:
Realiza modificaciones
al historial
del paciente
agregando
Poscondiciones:
La
reservacin
del
doctor
en
el
bloque
eliminado
est
tratamientos realizados luego del accidente.
disponible.
Precondiciones:
El paciente debe estar registrado en la ACOS.
Flujo
Bsico:
Poscondiciones: El sistema est listo para actualizar historial paciente
1. La secretaria
Flujo
Bsico: departamento clnico ingresa sus datos al sistema.
2. ElDoctor
Sistema
verifica
datos
1El
ingresa
suslos
datos
al ingresados.
sistema.
3. El
La Sistema
secretaria
departamento
ingresa los datos del mdico.
2.
verifica
los datosclnico
ingresados.
4. El Doctor
Sistemaingresa
verificalos
losdatos
datosdel
delpaciente.
mdico.
3.
5. El Sistema verifica
pondr a
el horario de atencin del mdico.
4.
losdisposicin
datos del paciente.
6. El
La Sistema
secretaria
departamento
clnico
podr eliminar
el bloque asignado al
5.
pondr
a disposicin
el historial
del paciente.
paciente
y podr actualizar el historial mdico paciente.
6.
El Mdico
Dejarlo
libre
para otro
paciente
que lo solicite.
7.
Repetir
3 hasta
terminar
actualizacin
de historial pacientes.
7. Fin
Repetir
6 hasta
terminar eliminacin de horario mdico.
8.
consulta
paciente.
8. Fin eliminacin reserva hora.
Flujo
Flujo Alternativo:
Alternativo:
2.1 Si
Si los
los datos
datos del
del usuario
usuario no
no son
son vlidos.
vlidos.
2.1
2.1.2
al datos
paso 1del
o salir
del no
sistema
paso 8.
4.1 SiIrlos
mdico
son validos
4.1
SiIrlos
paciente
no son paso
validos
4.1.1
al datos
paso 3del
o salir
del sistema
8. 8.
Requisitos
Especiales:
Requisitos
- Los Datos Especiales:
de horario de atencin debern ser ordenados por fecha y hora.
de Tecnologas
y Variaciones
de Datos:
-Lista
Los Datos
del paciente
debern ordenarse
por fecha de exmenes ms
recientes.
- Se deber ingresar al lado del examen una breve descripcin
Tabla 5 Modelo de requisitos cambiar historial del paciente

Tabla 6 Modelo de requisitos Solicitar exmenes
Resumen: El doctor ingresa sus datos e ingresa los datos del paciente (Datos
Resumen: El para
doctor
ingresa
sus datos
datos del los
paciente
y se le
Beneficiario)
poder
seleccionar
enelaingresa
receta los
desplegada
medicamentos
despliega
la solicitud
de exmenes.
El doctor selecciona los exmenes que
para
el tratamiento
a seguir
por el paciente.
debe realizar
el paciente
Actor
Principal:
Doctor en el laboratorio clnico o externamente.
Actor Principal:
Doctor
Personal
Involucrado:
Personal
Involucrado:
Doctor: Solicita
de los exmenes
que debe
Doctor: Registra los medicamentos
en larealizacin
receta desplegada
para el tratamiento
hacer
el paciente.
del
paciente.
Precondiciones: El
El paciente
paciente debe
debe estar
estar en
en el
el sistema
sistema de
de atencin
atencin.
Precondiciones:
Poscondiciones:
El
sistema
est
listo
para
solicitar
nuevos
exmenes.
Poscondiciones: El sistema est listo para emitir nueva receta.
Flujo Bsico:
Bsico:
Flujo
. El doctor
doctor ingresa
ingresa sus
sus datos
datos al
al sistema.
sistema.
1El
2. El
El Sistema
Sistema verifica
verifica los
los datos
datos ingresados.
ingresados.
2.
3. El
El doctor
doctor ingresa
ingresa los
los datos
datos del
del paciente.
paciente.
3.
4. El
El Sistema
Sistema verifica
verifica los
los datos
datos del
del paciente.
paciente.
4.
5. El
El Sistema
Sistema pondr
pondr a
a disposicin
disposicin la
la receta
solicitud
de exmenes
ha de realizar
5.
a rellenar
por losque
distintos
el paciente.
medicamentos.
6. El
El doctor
doctor selecciona
selecciona los
exmenes
a realizar
el paciente.
6.
medicamentos
para
el paciente.
7.
Repetir
5
hasta
terminar
la
solicitud
de
exmenes
al paciente.
7. Repetir 4 hasta terminar de registrar las recetas mdicas.
8. Fin
Fin emisin
solicitar exmenes.
8.
receta.
Flujo Alternativo:
Alternativo:
Flujo
2.1 Si
Si los
los datos
datos del
del doctor
usuariono
noson
sonvlidos.
vlidos.
2.1
2.1.1 Ir
Ir al
al paso
paso 1
1o
o salir
salir del
del sistema
sistema paso
paso 8.
8.
2.1.1
4.1 Si
Si los
los datos
datos del
del paciente
paciente no
no son
son validos
validos
4.1
4.1.1 Ir
Ir al
al paso
paso 3
3o
o salir
salir del
del sistema
sistema paso
paso 8.
8
4.1.1
Especiales:
Requisitos
- Losmedicamentos
exmenes debern
indicar
si son realizados
en alfabtico.
el laboratorio clnico de la
Los
debern
ser ordenados
en orden
ACOS.
Lista de Tecnologas
y Variaciones
de Datos:
Cuestiones
Pendientes:
Se deber ingresar
a cada receta la firma digital del
Cuestiones
Pendientes:
Registro
de
exmenes
pendientes del paciente.
doctor.
Tabla 7 Modelo de requisitos Emitir receta
Resumen:
clnico
datosa elaingresa
la orden
solicitud
Resumen: El
El laboratorio
doctor ingresa
susingresa
datos esus
ingresa
Reservacin
de de
Horarios
de atencin,
exmenes, registrando los datos del paciente, como los exmenes a realizar.
de
Actor
Laboratorio
Clnico.
DondePrincipal:
podr marcar
su horario
de disponibilidad de atencin para los pacientes
Personal
Involucrado:
que estn en tratamiento con l (Reservacin Horario de Atencin).
Laboratorio
Clnico:
Ingresa
datos
paciente
exmenes
Actor Principal:
Doctor:
Es los
quien
fija del
el horario
deyatencin
quesolicitados.
tiene
Precondiciones:
El
usuario
debe
estar
en
el
sistema
de
atencin.
disponible.
Poscondiciones:
Existen
exmenes
a efectuar
por eldisponible.
laboratorio.
Doctor: Es quien fija
el horario
de atencin
que tiene
Flujo
Bsico:
Precondiciones: El doctor dispone de bloques disponibles para fijar.
1.
El laboratorio clnico
ingresa sus
datos elegir
al sistema.
Poscondiciones:
Los pacientes
pueden
algn bloque disponible del
2.
El
Sistema
verifica
los
datos
ingresados.
doctor para solicitar atencin.
3.
El laboratorio
Flujo
Bsico: clnico ingresa los datos del paciente.
4.
verificasus
losdatos
datosaldel
paciente.
1. El
El Sistema
doctor ingresa
sistema.
5.
disposicin
la solicitud de exmenes para que el
2. El
El Sistema
Sistema pondr
verifica a
los
datos ingresados.
laboratorio
registre
cuales
debe hacrseles
paciente.
3. El Sistema
pondr
a disposicin
el horarioalde
atencin del mdico.
6.
Repetir
3
hasta
terminar
ingreso
de
los
exmenes
a pacientes.
4. El doctor podr asignar los bloques que tiene disponible
para la atencin de
7.
Fin
Ingreso
de
exmenes
solicitados.
los
Pacientes
que lo solicitan.
Flujo Alternativo:
5.
3 hasta
asignacin
horario
mdico.
2.1Repetir
Si los datos
delterminar
laboratorio
clnico no
son vlidos.
6.
FinIrfijar
horario
atencin
mdico.
2.1.1
al paso
1 ode
salir
del sistema
paso 7.
4.1
Si Alternativo:
los datos del paciente no son validos
Flujo
4.1.1
al datos
paso 3del
o salir
delno
sistema
paso 7.
2.1 SiIrlos
doctor
son vlidos.
2.1.1
Ir al paso
1 o salir del sistema paso 6.
Requisitos
Especiales:
Los
exmenes
deben estar disponibles para su seleccin por el laboratorio
Requisitos
Especiales:
clnico.
Los Datos de horario de atencin debern ser desplegados como un calendario
Lista
de Tecnologas
Variaciones
de Datos:los bloques en los que dispone
de programacin
dondey el
doctor seleccionar
Cuestiones
Pendientes:
de tiempo disponible.
Cuestiones Pendientes: El doctor podr eliminar algn bloque si no puede
atender.
Tabla 8 Modelo de requisitos Fijar horario disponible
Tabla 9 Modelo de requisitos Ingresar exmenes solicitados
Tabla 10 Modelo de requisitos Ingresar resultados exmenes
Resumen: El laboratorio clnico ingresa sus datos, e ingresa los resultados de

los exmenes efectuados a algn paciente al sistema de atencin mdica
(Datos Exmenes).
Actor Principal: Laboratorio Clnico.
Laboratorio Clnico: Ingresa los datos del paciente determinado al sistema.
Precondiciones: Existe la solicitud de exmenes para el paciente.
Poscondiciones: Se pueden Emitir los exmenes hechos al paciente.
Flujo Bsico:
1. El laboratorio clnico ingresa sus datos al sistema.
3. El laboratorio clnico ingresa los datos del paciente.
5. El Sistema pondr a disposicin el registro de datos de exmenes del
laboratorio.
6. El laboratorio clnico ingresa los resultados de los exmenes hechos al
paciente.
7. Repetir 3 hasta terminar ingreso de los exmenes a pacientes.
8. Fin Ingreso de Resultados de exmenes.
Flujo Alternativo:
2.1 Si los datos del laboratorio clnico no son vlidos.
Los exmenes deben estar ordenados por fecha de resultados.
6.3. Modelo de Interfaces
Imagen 1 Modelo Interfaces
Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos
Imagen 2 Interfaz de usuario
Imagen 3 Interfaz Ficha mdica (Medico o doctor)
Imagen 4 Interfaz Pedir horas Medicas (Secretaria)
Pgina
88

6.4. Actores y Caso de Uso
Se describen en total 2 actores en el sistema de transacciones electrnicas. El
Usuario interacta con todos los casos de uso. En el que con el programa el usuario
realizara sus conversiones dependiendo de la base numrica de su pas y de la del
pas de donde se le hace l envi.
Tabla 11 Actores
Actor
Casos de
uso
Tipo
Descripcin
Usuario
Consultar su valor
Primario
Es el actor principal y representa a la persona que desee utilizar
el sistema.
Diagrama casos de uso
Imagen 5 Diagramas casos de uso.
Pgina
89

6 Modelo de Dominio del Problema
La interfaz para cada usuario estar determinada por la funcin que ocupa en
el sistema, este le permitir acceder a toda la gama de opciones que le son
propias en la interaccin con el sistema de atencin al paciente.
La interfaz debe ser lo ms acorde al procedimiento tpico de atencin, como lo

realizan actualmente, bajo el mismo orden de pasos.
Se debe ingresar los datos del paciente antes de ocurrido el accidente

(almacenar todos los datos al servidor de bases de datos PostGre).
Una base de datos centralizada (PostGre) para el funcionamiento del sistema

de atencin.
Se requiere identificar y entregar privilegios a los distintos usuarios del sistema

de atencin (nombre de usuario y contrasea).
Se requiere que la empresa que inscriba al trabajador ingrese sus

antecedentes mdicos para almacenarlos en el sistema de atencin.
El paciente debe pedir hora de atencin solo a la secretaria del departamento

clnico.
Pgina
90
Captulo 7 Modelo de Anlisis

7.1. Arquitectura de clases
Consulta Historial Medico
Imagen 6 Arquitectura de clases_Consultar historial medico
Diagrama Ingresar Paciente Accidentado
Pgina
91
Imagen 7 Arquitectura de clases_Diagrama Ingresar paciente accidentado

Imagen 8 Arquitectura de clases_Diagrama ingresar paciente accidentado

Diagrama Consulta Hora Atencin Paciente
Pgina
Imagen 9 Arquitectura de clases_Diagrama Consultar hora de atencin del

paciente
92
Ingresar
Examen solicitado
Imagen 10 Arquitectura de clases_Diagrama Examen solicitado
Pgina
93
Ingresar Resultado Examen
Imagen 11 Arquitectura de clases_Diagrama Ingresar resultado examen

7.2. Identificacin de clases segn Estereotipos
Arquitectura sistema
Las Operaciones que el sistema debe realizar son las siguientes:
Sistema
Validar_Usuario( rut_usuario, clave)

Solicitar Historial Paciente
Solicitar_Historial( rut_paciente)
Imprimir_Historial( rut_paciente, fecha_inicio, fecha_termino)
Ingresar Datos Paciente Accidentado
Ingresar_Paciente( rut_paciente, nombre_paciente, empresa,fecha_ingreso,
datos_accidente)
Consulta Hora Atencin Paciente
Consultar_Hora_Pedida( rut_paciente)
Consultar_Hora_Disponible( rut_mdico, Fecha)
Solicitar Hora Atencin Paciente
Solicitar_Hora( rut_paciente, nombre_medico, fecha, hora)
Pgina
94
Agregar Exmenes
Agregar_examenes( rut_paciente, Nombre_examen, tipo_Examen,
Fecha_Examen, resultados)
Eliminar Reserva Hora
Eliminar_Hora( rut_paciente, nombre_medico, fecha, hora)
Emitir Exmenes
Emitir_examen( rut_paciente, nombre_examen, tipo_examen)
Cambiar Historial Paciente
Agregar_al_Historial_Paciente(rut_paciente,medico_tratante, datos_nuevos,
fecha)
Eliminar_del_Historial_Paciente(rut_paciente,Nombre_medico,
fecha_a_eliminar)
Emitir Receta
Emitir_Receta(rut_paciente, datos_receta)
Imprimir_Receta(rut_paciente, datos_receta)
Fijar Horario Disponible
Fijar_Horario(rut_medico, horario)
Ingresar_Resultado_Examen(rut_paciente, nombre_examen, tipo_examen,
fecha_examen, resultado)
Ingresar Examen solicitado
Ingresa_Solicitud_Examen(rut_paciente, nombre_examen,tipo_examen,
fecha_solicitud)
7.3. Clases segn casos de Uso
Pgina
95
Imagen 12 Clases segn caso de uso_Diagrama solicitar historial del paciente
Imagen 13 Clases segn caso de uso_Diagrama Ingresar datos paciente

accidentado
Consultar Hora Pedida:
Pgina
96
Imagen 14 Clases segn caso de uso_Diagrama Consultar hora pedida
7.4. Diagramas de Secuencia
Imagen 15 Diagrama de secuencia_ Solicitar Historial Paciente
Imagen 16 Diagrama de secuencia_ Ingresar Datos Paciente Accidentado

Pgina
97
Imagen 17 Diagrama de secuencia_ Consulta Hora Atencin Paciente
Consulta Hora Disponible
Imagen 18 Diagrama de secuencia_ Consulta Hora Disponible
Pgina
98
Imagen 19 Diagrama de secuencia_ Solicitar Hora Atencin Paciente
Agregar Exmenes
Imagen 20 Diagrama de secuencia_ Agregar Exmenes

Imagen 21 Diagrama de secuencia_ Eliminar Reserva Hora

Emitir Exmenes
Pgina
99
Imagen 22 Diagrama de secuencia_ Emitir Exmenes
Imagen 23 Diagrama de secuencia_ Emitir Exmenes
Eliminar historial del paciente
Imagen 24 Diagrama de secuencia_ Eliminar historial del paciente
Pgina
100

Emitir Receta
Imagen 25 Diagrama de secuencia_ Emitir Receta
Imagen 26 Diagrama de secuencia_ Fijar Horario Disponible
Ingresar resultado examen
Imagen 27 Diagrama de secuencia_ Ingresar resultado examen
Pgina
101

Imagen 28 Diagrama de secuencia_ Ingresar Examen solicitado
7.5. Casos de uso para el sistema
Tabla 12 Casos de uso para el sistema _Validar Usuario
Nombre
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
Salida
Precondiciones
Pos condiciones
Validar Usuario(rut_usuario, clave)

Permite verificar si el usuario es un
usuario autorizado, adems permite
discriminar entre los distintos tipos de
usuarios para proporcionarles a estos
la interfaz apropiada.
Sistemas
Todos
Al estar incorrecto el RUT o la clave
Despliega men de usuario
Exista el rut y la clave en la base de
datos
Usuario ingresado a Sistema
Pgina
102

Nombre
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
Permite obtener los datos del historial o
ficha del paciente, adems de los
exmenes de esos.
Sistemas
El rut del paciente no existe o es

errneo, que el historial no exista.
Salida
Despliega la ficha mdica por pantalla
Precondiciones
Que exista el rut del paciente en la
base de datos
Pos condiciones
El historial mdico desplegado por
pantalla
Tabla 13 Casos de uso para el sistema _Solicitar Historial
Tabla 14 Casos de uso para el sistema _Imprimir Historial
Nombre:
Imprimir Historial( rut_paciente,

fecha_inicio,
fecha_termino)
Responsabilidad:
Permite imprimir un historial o una ficha

en caso de tener que trasportar estos
datos a un lugar sin un sistema
computacional.
Tipo
Sistema
Caso de uso
Solicitar Historial paciente
Excepciones

errneo, la fecha de inicio y/o la de
termino no existen en el historial, la
fecha de inicio debe ser menor que la
Pgina
103

Nombre
Responsabilidad
Salida
Precondiciones
Tipo
Caso de Uso
Notas
Pos condiciones:
Excepciones
de termine.
Permite obtener los datos del historial o
ficha del paciente, adems de los
Imprime el historial o la parte del
exmenes de esos.
historial solicitada
Que
exista el rut del paciente en la
Sistemas
base
de datos,
que
existan
Solicitar
Historial
Paciente
las fechas dentro del historial
El historial impreso
errneo, que el historial no exista.
Salida
Precondiciones
Despliega la ficha mdica por pantalla

Que exista el rut del paciente en la base
de datos
Pos condiciones
El historial mdico desplegado por

pantalla
Tabla 15 Casos de uso para el sistema _Historial de los exmenes
Tabla 16 Casos de uso para el sistema _Ingresar Paciente
Nombre:
Ingresar_Paciente( rut_paciente,
nombre_paciente, empresa,
fecha_ingreso, datos_accidente)
Responsabilidad
Permite que los datos del paciente y del

accidente sufrido
estn disponibles para el mdico o
cualquiera que lo solicite
Tipo:
Sistema
Caso de uso
Notas:
Excepciones:
No exista el rut del paciente o ese esta

equivocado
Pgina
104

Salida:
Precondiciones:
Pues condiciones:
Una confirmacin de que los datos se

ingresaron a la ficha
Rut del paciente accidentado se
encuentre registrado
Datos guardados en la ficha o historial
mdico Sistemas de Informacin
Tabla 17 Casos de uso para el sistema _Consultar Hora Pedida
Nombre:
Responsabilidad:
Tipo:
Caso de uso:
Notas:
Excepciones:
Salida:
Precondiciones:
Pos condiciones:
Consultar_Hora_Pedida( rut_paciente)
Permite verificar las horas pedidas por
un paciente.
Sistema
En caso de que el usuario no tenga
horas perdida la lista saldr vaca.
Rut paciente no existe o est
equivocado, no existan horas pedidas
Una lista con las horas pedidas por el
paciente
Que exista el rut del paciente en la
base de datos
Una lista es desplegada con el nombre
del mdico y la fecha
Tabla 18 Casos de uso para el sistema _Hora Disponible
Nombre:
Responsabilidad:
Tipo:
Consultar_Hora_Disponible( rut_mdic
o, Fecha)
Permite obtener las horas disponibles
de un mdico para una determinada
fecha, esto es indispensable para poder
pedir hora.
Sistema
Pgina
105

Caso de uso:
Notas:
Excepciones:
Salida:
Precondiciones:
Pos condiciones

El medico se elige desde una lista por
lo que puede ocurrir un error con su rut
La fecha no tiene ninguna hora
disponible.
Despliega una lista con las horas
disponibles para su posterior seleccin.
Existan mdicas en registro y fechas
disponibles
Una lista con las horas disponibles.
Llenado de las horas para seleccin del
paciente
Tabla 19 Casos de uso para el sistema _Solicitar Hora
Nombre:
Responsabilidad:
Tipo:
Caso de uso:
Notas:
Excepciones:
Salida:
Solicitar_Hora( rut_paciente,
nombre_medico, fecha, hora)
Asigna una hora a un paciente
Sistema
El medico se elige desde una lista por
lo que puede ocurrir un error con su rut,
lo mismo ocurre con la fecha y la hora.
El rut del paciente es errneo o no
existe en registro.
Confirmacin de operacin exitosa
Precondiciones
Que se realizara con anterioridad la

consulta de horas disponibles
Pos condiciones:
La hora almacenada en la base de

datos
Tabla 20 Casos de uso para el sistema _Agregar Exmenes
Pgina
106

Nombre
Responsabilidad:
Tipo:
Caso de uso:
Notas:
Excepciones:
Salida:
Precondiciones:
Pos condiciones:
Agregar_examenes( rut_paciente,
Nombre_examen,
tipo_Examen, Fecha_Examen,
resultados)
Agregar exmenes realizados en
laboratorios externos
Sistema
Agregar Exmenes
Rut de paciente no existe o es errado
Confirmacin de operacin exitosa
Exista el rut del paciente en la base de
datos
El examen almacenado en la base de
datos
Tabla 21 Casos de uso para el sistema _Eliminar Hora
Nombre:
Responsabilidad:
Tipo
Caso de uso:
Excepciones:
Salida:
Precondiciones:
Pos condiciones
Eliminar_Hora( rut_paciente,
nombre_medico, fecha, hora)
Permite liberar una hora mdica, para
que otro paciente pueda hacer uso de
ella.
Sistema
Rut del paciente no existe o es
incorrecto, el paciente no tiene hora
asignada
Confirmacin de que la operacin fue
llevada a cabo con
Exista el rut y exista la hora
La eliminacin de la hora de la base de
datos
Pgina
107

Tabla 22 Casos de uso para el sistema _Emitir examen
Nombre
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
salida
precondiciones
pos condiciones
Emitir_examen( rut_paciente, nombre_examen,

tipo_examen)
Imprime los exmenes de un paciente
Sistema
Emitir Exmenes
El rut del paciente no existe o es errneo, el
paciente no
posee exmenes registrados
Impresin de la exmenes
Exista el paciente, existan exmenes
Examen Impreso
Tabla 23 Casos de uso para el sistema _Historial Paciente
Nombre
Agregar_al_Historial_Paciente(rut_paciente,medico_tratante
,
datos_nuevos, fecha)
Responsabilidad
Agrega datos al historial del paciente reciente, la fecha la

asigna el sistema
Tipo
Caso de Uso
Notas
Sistema
Los datos son guardados por fecha y se ordenan desde el
ms
El rut del paciente no existe o esta errado
Confirmacin de que los datos se agregaron al historial, el
historial es desplegado por pantalla
Exista el rut del paciente, exista el historial
Los datos son ingresados al historial, guardados en la base
de
datos y desplegados por pantalla
Excepciones
salida
precondiciones
pos condiciones
Pgina
108
Tabla 24 Casos de uso para el sistema _Eliminar del Historial Paciente
Nombre
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
salida
precondiciones
pos condiciones
Eliminar_del_Historial_Paciente(rut_paciente,Nombre_medico
,
fecha_a_eliminar)
Elimina una parte del historial que se encuentre errado
Sistema
No existe datos registrados en el historial solo los bsicos
Confirmacin de la eliminacin exitosa y despliegue del
historial modificado
Exista el rut del paciente, exista el historial
Los datos son eliminados del historial y la base de datos.
Los datos del historial desplegados por pantalla.
Tabla 25 Casos de uso para el sistema _Emitir Receta
Nombre
Responsabilidad
Emitir_Receta(rut_paciente, datos receta

Permite guardar los datos de la receta en el
historial y los
pone a disposicin para imprimirlos con
posterioridad
Tipo
Caso de Uso
Notas
Excepciones
Sistema
Emitir Receta
salida
precondiciones
pos condiciones
Rut del paciente no existe o esta errado, no

existen datos
Confirmacin de que los datos fueron guardados
Rut y datos existan
Datos guardados y disponibles para imprimir.
Pgina
109

Tabla 26 Casos de uso para el sistema _Imprimir Receta
Nombre
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
salida
precondiciones
pos condiciones
Imprimir_Receta(rut_paciente, datos receta)

Permite imprimir la receta.
Sistema
No existe datos registrados en el historial solo los
bsicos
Confirmacin de la eliminacin exitosa y
despliegue del
historial modificado
Que exista la receta (este emitida)
Receta Impresa
Tabla 27 Casos de uso para el sistema _Fijar Horario
Nombre
Fijar_Horario(rut_medico, horario)
Responsabilidad
Figa el horario que un medico tiene disponible

para la atencin de pacientes.
Sistema
Tipo
Caso de Uso
Notas
Excepciones
salida
precondiciones
pos condiciones
Rut mdico no valido o no existe, no se eligi

horario
Una tabla con las fechas y horas disponibles
Exista el rut del mdico, y los datos de los
horarios
: Horario fijado guardado el la base de datos.
Tabla 28 Casos de uso para el sistema _Resultado Examen
Pgina
110

Nombre
Ingresar_Resultado_Examen( rut_paciente,
nombre_examen,
tipo_examen, fecha_examen, resultado)
Responsabilidad
Ingresa los resultados de los exmenes emitidos

por el laboratorio interno.
Tipo
Caso de Uso
Notas
Excepciones
Sistema
salida
precondiciones
pos condiciones
Los resultados no son vlidos, el Rut del paciente

no existe o
es errado
Datos guardados en base de datos y el historial.
: Horario fijado guardado en la base de datos.
Tabla 29 Casos de uso para el sistema _Ingresa Solicitud Examen
Nombre
Ingresa_Solicitud_Examen( rut_paciente,
nombre_examen
,tipo_examen, fecha_solicitud) resultado)
Responsabilidad
Tipo
Caso de Uso
Notas
Excepciones
Ingresa la solicitud de examen

Sistema
salida
precondiciones
pos condiciones

Rut existe y nombre examen existe
Los datos se encuentran guardados en la base
de datos.
El rut del paciente no es vlido o no existe, el

nombre del examen es no valido.
Pgina
111
Captulo 8 Modelo de Diseo

8.1. Estrategias de Diseo
Consulta Historial Medico
Imagen 29 Estrategias de Diseo_Diagrama Consulta Historial Medico
Pgina
112
Imagen 30 Estrategias de Diseo_Diagrama Ingresar Paciente Accidentado
Diagrama Consulta hora atencin paciente
Imagen 31 Estrategias de Diseo_Diagrama Consulta hora atencin paciente
Pgina
113
Imagen 32 Estrategias de Diseo_Diagrama Ingresar Examen solicitado
Imagen 33 Estrategias de Diseo_Diagrama Ingresar Resultado Examen
Pgina
114
8.2. Diseo de Objetos

Para un buen diseo de objetos se debe pensar en trminos de objetos, en lugar de
procedimientos, un objeto agrupa datos encapsulados y procedimientos para
representar una entidad, en esta etapa se defina las formas de interactuar con el objeto,
este lenguaje se caracteriza por la interaccin de estos objetos para la resolucin del
problema identificado en el anlisis orientado a objetos.
Un objeto contiene toda la informacin que permite definirlo e identificarlo, dispone
de mecanismos de interaccin que ayudan a la comunicacin entre objetos, estos son
como unidades invisibles en las que no se separan informacin y procesamiento.
Continuando con el proceso de diseo se debe determinar las clases, atributos y
asociaciones del modelo de anlisis, aunque tambin se pueden modificar o eliminar
clases.
Para el diseo de un objeto se sigue el diseo por responsabilidades con el modelo
cliente servidor donde las clases pueden ser de ambos tipos dependiendo si generan
una peticin (Cliente) o reciben una peticin (Servidor).
Paquetes del Dominio
Imagen 34 Diseo Paquetes del Dominio

Paquete del Recepcionista
Pgina
115
Imagen 35 Diseo Paquete del Recepcionista

Paquetes de Secretaria
Imagen 36 diseo Paquetes de Secretaria

Paquete de Funcionario_Clinica_Externa
Imagen 37 Diseo Paquete de Funcionario_Clinica_Externa

Paquete de Medico
Imagen 38 Diseo Paquete de Medico

Paquete de Laboratorio Clnico
Pgina
116
Imagen 39 Diseo Paquete de Laboratorio Clnico

Paquete ACOS
Imagen 40 Diseo Paquete ACOS

8.3. Diseo de Sistema
Imagen 41 Diseo del sistema

La aplicacin posee una arquitectura cliente-servidor de tipo cliente delgado, el cual
consta de tres capas, contiene cdigo de presentacin, cdigo de procesamiento de
datos y cdigo de almacenamiento de datos.
Capa de Presentacin
Pgina
117

Los servicios de presentacin proporcionan la interfaz necesaria para presentar
informacin y reunir datos. Tambin aseguran los servicios de negocio necesarios para
ofrecer las operaciones requeridas e integran al usuario con la aplicacin para ejecutar
un proceso de negocio.
Los servicios de presentacin generalmente son identificados con la interfaz de
usuario, y normalmente residen en un programa ejecutable localizado en la estacin de
trabajo del usuario final.
Se separa la programacin que da acceso a los datos en las bases de datos y
aplicaciones desde el diseo y otros contenidos de la pgina Web. Esto ayuda a
asegurar que durante el proceso de desarrollo se pue da enfocarse en escribir la
aplicacin en componentes sin preocuparse acerca de cmo se muestra la salida.
Recprocamente, esto da libertad a los diseadores de usar herramientas familiares
para modificar la interfaz.
La capa de servicios de presentacin es responsable de:
Obtener informacin del usuario (tipo usuario y clave).

Obtener informacin de pacientes y/o mdicos (horas mdicas, fichas,
exmenes).
Enviar la informacin del paciente y/o mdico a los servicios de negocio para su
procesamiento.
Recibir los resultados del procesamiento de los servicios de negocios.
Presentar estos resultados al usuario.
Capa de Negocio
Los servicios de negocio son los que procesan las peticiones del usuario permiten a
los usuarios acceder a los servicios de datos o sea permiten la interaccin de los
usuarios no los datos. Responden a peticiones del usuario (u otros servicios de
negocio) para ejecutar una tarea. Cumplen con las distintas tareas aplicando
procedimientos formales y las reglas de negocio previamente establecidas. Cuando los
datos necesarios residen en un servidor de bases de datos, garantizan los servicios de
datos indispensables para cumplir con la tarea de negocio. Esto asla al usuario de la
interaccin directa con la base de datos.
Capa de Datos
Pgina
118
El nivel de servicios de datos es responsable de:
Almacenar los datos.

Recuperar los datos.
Mantener los datos.
La integridad de los datos.
Pgina
119

8.4. Revisin del Diseo
Tabla 30 Revisin del diseo
Objetivo de informacin:
Registro paciente accidentado
Atributos:
rut_paciente.
nombre
empresa
fecha_ingreso
datos_accidente
Restricciones:
Actividad:
Ingreso al sistema paciente
accidentado
Origen: Solicitud paciente.
Agente: Recepcionista ACOS.
Precondiciones:
Poscondiciones:
Para cada ingreso de pacientes

se ingresa al sistema de
atencin.
El paciente est activo en el

sistema hasta que se le d el
alta.
El rut de paciente es nico para

el sistema, por lo que permitir
identificar completamente.
El
accidentado
es
solo
ingresado al sistema por la
recepcionista ACOS
Se puede atender en un bloque

El
paciente
debe
estar
de horario con el mdico
ingresado previamente en el
tratante.
sistema.
Caso de uso del sistema:
Ingresa datos paciente
El paciente tiene al menos accidentado.
registrado su historial de
enfermedades
preexistentes,
como los medicamentos que no
pueden ser aplicados, as como
sus alergias.
Clase del dominio: Funcionario
Pgina
120

Atencin Mdico
Atributos:
rut_paciente.
nombre mdico
fecha
hora
Restricciones:
El usuario debe haber sido
ingresado al sistema de
atencin.
El paciente debe estar
registrado previamente en el
sistema.
El paciente tiene al menos
enfermedades
preexistentes,
sus alergias.
El paciente para ser atendido
debe solicitar hora.
Actividad: Asignacin de hora de

atencin.
Agente: Secretaria Departamento
Clnico.
Precondiciones:
El paciente debe haber sido
ingresado por la recepcionista
Poscondiciones:
El paciente pude ser atendido
por el mdico tratante.
El pude seguir pidiendo horas
mdico.
tratante.
Caso de uso del sistema: Solicitar
hora atencin paciente.
Actividad: El paciente es atendido
por el mdico.
Origen: verifica si el paciente ha
solicitado hora de atencin que le
corresponde.
Agente:
Secretara Departamento Clnico
Precondiciones:
Existe disponibilidad de hora de
atencin con el mdico
tratante.
Pos condicin: El paciente se le
solicitan exmenes.
El paciente se le emite una
receta mdica.
El paciente es dado de alta
Pgina
121

Pendiente.
Actividad: Al paciente se le deben
realizar exmenes.
Origen: Solicita exmenes a
paciente.
Agente: Doctor.
Precondiciones:
El doctor tiene una lista de
exmenes a solicitar al
paciente.
Poscondiciones:
Poscondiciones:
El paciente obtiene el listado de

exmenes a realizar.
exmenes.
Actividad: El doctor emite receta.
Origen: verifica si el paciente tiene
alguna contraindicacin de algn
medicamento.
Agente: Doctor
Precondiciones:
El doctor tiene una lista
medicamentos a recetar al
paciente.
Poscondicin:
El paciente se le indican los
medicamentos a tomar.
receta mdica.
Caso de uso del sistema: Emitir
receta.
Pgina
122

Actividad: El doctor actualiza el
historial mdico del paciente.
Origen: verifica el historial mdico
del paciente para ser actualizado
Agente: Doctor
Precondiciones:
El doctor tiene una lista de los
exmenes solicitado al
paciente
Poscondicin:
Se ha actualizado el historial
clnico del paciente
El sistema est listo para
ingresar ms actualizaciones
del historial clnico de los
pacientes.
Cambiar Historial Paciente.
Exmenes hechos al paciente
Atributos:
rut_paciente.
nombre_examen
tipo_de_examen
fecha_examen
resultado
Restricciones:
El accidentado es solo
ingresado al sistema por la
recepcionista ACOS
Actividad:
Ingreso examen al Laboratorio.
Agente: Laboratorio Clnico.
Precondiciones:
El doctor debe haber emitido
una lista de exmenes.
ACOS.
Poscondiciones:
Los exmenes son ingresados
al sistema de atencin
paciente.
El mdico tiene acceso al
resultado de los exmenes por
Pgina
123

medio del historial clnico del
sistema.
paciente
El sistema de atencin contiene
Caso de uso del sistema: Ingresar
todos los exmenes hechos a
examen solicitado.
los pacientes.
Actividad: Ingreso resultado de
exmenes al sistema.
Clase del dominio: Laboratorio
Origen: Verifica si existen
Clnico.
exmenes hechos al paciente.
Precondiciones:
Los exmenes del paciente
debe haber sido ingresado al
laboratorio.
Poscondiciones:
paciente.
Se actualiza el historial Clnico
del paciente.
Resultado exmenes.
Solicita historial de paciente
clnica externa
Atributos:
rut_paciente.
id_clinica
clave
Restricciones:
sistema.
Actividad: Solicitud al sistema

paciente Historial clnico de paciente
.
Origen: Se verifica que el paciente
Solicitado este registrado en el
sistema.
Agente: Clnica externa atencin.
Precondiciones:
El paciente tiene un historial
clnico
Poscondiciones:
El sistema est listo para una
nueva consulta.
Pgina
124

Solicitud historial paciente.
enfermedades preexistentes,
sus alergias.
La clnica externa est

registrada en el sistema.
Clase del dominio:

Clinica_Externa
8.5. Diagrama de Secuencia del Diseo
Solicitar Historial del Paciente
Imagen 42 Secuencia de diseo Historial del paciente
Pgina
125
Imagen 43 Secuencia de diseo Ingresar Datos Paciente Accidentado

Imagen 44 Secuencia de diseo Consulta Hora pedida Atencin Paciente
Consulta Hora pedida disponible Paciente
Imagen 45 Secuencia de diseo Consulta Hora Disponible Atencin Paciente

Pgina
126

Imagen 46 Secuencia de diseo Solicitud hora de atencin

Agregar Exmenes
Imagen 47 Secuencia de diseo Agregar exmenes
Imagen 48 Secuencia de diseo Eliminar reserva hora
Pgina
127

Emitir Exmenes
Imagen 49 Secuencia de diseo Emitir exmenes
Imagen 50 Secuencia de diseo Cambiar historial paciente
Imagen 51 Secuencia de diseo Cambiar historial

Emitir
paciente
Receta
Pgina
128
Imagen 52 Secuencia de diseo Emitir receta

Imagen 53 Secuencia de diseo Fijar hora disponible
Imagen 54 Secuencia de diseo Ingresar resultado examen

Ingresar Examen Solicitado
Imagen 55 Secuencia de diseo Ingresar examen solicitado
Pgina
129
Captulo 9 Modelo de Diseo
9.1. Programacin en java
Pgina
130

Tabla 31 Clases del dominio funcionario
Pgina
131
Atencin Mdico

atencin.
Atributos:
rut_paciente.
nombre mdico
Clnico.
fecha
hora
Precondiciones:
Restricciones:

Poscondiciones:

ingresado al sistema de atencin.
El paciente debe estar registrado

previamente en el sistema.
El paciente
tiene
al menos
registrado
su
historial
de
enfermedades preexistentes, como los
medicamentos que no pueden ser
aplicados, as como sus alergias.
El paciente para ser atendido debe

solicitar hora.
El paciente pude ser atendido por

el mdico tratante.
mdico.
Se puede atender en un bloque de
horario con el mdico tratante.
Actividad: El paciente es atendido por
el mdico.
corresponde.
Agente:
Precondiciones:

atencin con el mdico tratante.
Poscondicin: El paciente se le
solicita exmenes.
El paciente se le emite una receta

mdica.
Caso de uso del sistema: Pendiente.
Pgina
realizar exmenes.
Origen: Solicita exmenes a paciente.
132

Registro paciente accidentado
Atributos:
rut_paciente.
nombre
Actividad:
Ingreso al sistema paciente
accidentado
empresa
fecha_ingreso
datos_accidente
Restricciones:
El rut de paciente es nico para el

sistema, por lo que permitir identificar
completamente.
El accidentado es solo ingresado al

sistema por la recepcionista ACOS
El paciente debe estar ingresado

El
paciente
tiene
al
menos
registrado su historial de enfermedades
preexistentes, como los medicamentos
que no pueden ser aplicados, as como sus
alergias.

Agente: Recepcionista ACOS.
Precondiciones:
Poscondiciones:
Para cada ingreso de pacientes se

ingresa al sistema de atencin.
El paciente est activo en el

sistema hasta que se le d el alta.
Se puede atender en un bloque de

horario con el mdico tratante.
Ingresa datos paciente accidentado.

Atencin Mdico

atencin.
Atributos:
rut_paciente.
nombre mdico
Clnico.
Pgina
133

fecha
hora
Preconiciones:
Restricciones:

ingresado al sistema de atencin.
El paciente debe estar registrado
registrado
su
historial
de
enfermedades
preexistentes,
sus alergias.
El paciente para ser atendido
debe solicitar hora.
Clase del dominio:Funcionario

Poscondiciones:
El paciente pude ser atendido por

el mdico tratante.
mdico.
tratante.
Actividad: El paciente es atendido
por el mdico.
corresponde.
Agente:
Precondiciones:

atencin con el mdico tratante.
Poscondicin: El paciente se le
solicitan exmenes.

receta mdica.
Pendiente.
Pgina
134

realizar exmenes.
Origen: Solicita exmenes a
paciente.
Agente: Doctor.
Precondiciones:
El doctor tiene una lista de

exmenes a solicitar al paciente.
Poscondiciones:
Poscondiciones:
El paciente obtiene el listado de

exmenes a realizar.
exmenes.
Actividad: El doctor emite receta.
Origen: verifica si el paciente tiene
alguna contraindicacin de algn
medicamento.
Agente: Doctor
Precondiciones:
El doctor tiene una lista

medicamentos a recetar al
paciente.
Poscondicin:
El paciente se le indican los

medicamentos a tomar.
receta mdica.
Caso de uso del sistema: Emitir
Pgina
135

receta.
Actividad: El doctor actualiza el
historial mdico del paciente.
Origen: verifica el historial mdico
del paciente para ser actualizado
Agente: Doctor
Precondiciones:
El doctor tiene una lista de los

exmenes solicitado al paciente
Poscondicin:
Se ha actualizado el historial
clnico del paciente
El sistema est listo para
ingresar ms actualizaciones del
historial clnico de los pacientes.
Caso de uso del sistema: Cambiar
Historial Paciente.
Actividad:
Exmenes hechos al paciente
Ingreso examen al Laboratorio.
Atributos:
rut_paciente.
nombre_examen
tipo_de_examen
Precondiciones:
fecha_examen
resultado
El doctor debe haber emitido una

lista de exmenes.
ACOS.
Pgina
136

Restricciones:

El accidentado es solo ingresado
al sistema por la recepcionista
ACOS
El sistema de atencin contiene
todos los exmenes hechos a los
pacientes.
Poscondiciones:
Los exmenes son ingresados al

sistema de atencin paciente.
paciente
examen solicitado.
Actividad: Ingreso resultado de
exmenes al sistema.
Clase del dominio: Laboratorio

Clnico.
Origen: Verifica si existen exmenes

hechos al paciente.
Precondiciones:
Los exmenes del paciente debe

haber sido ingresado al
laboratorio.
Poscondiciones:

paciente.
Se actualiza el historial Clnico
del paciente.
Resultado exmenes.
Solicita historial de paciente
clnica externa
Actividad:Solicitud al sistema
paciente Historial clnico de paciente
.
Atributos:
Origen: Se verifica que el paciente
rut_paciente.
Solicitado este registrado en el
Pgina
137

id_clinica
clave
sistema.
Agente: Clnica externa atencin.
Restricciones:

enfermedades preexistentes,
sus alergias.
La clnica externa est registrada
en el sistema.
Precondiciones:
El paciente tiene un historial

clnico
Poscondiciones:
El sistema est listo para una

nueva consulta.
Caso de uso del sistema: Solicitud
historial paciente.
Clase del dominio: Clinica_Externa
Lo primero que hay que hacer es crear una fuente de datos en Windows. Para ello, desde el men
de Inicio, vamos eligiendo las siguientes opciones.
Inicio/panel de control/ herramientas del sistema/Orgenes de datos ODBC.
dBASE Files y agregar
Pgina
138
Imagen 56 Administrador de origenes de datos

Despus aparece la siguiente ventana.
Y elegimos Microsoff Access Driver (*mdb)y finalizar
Imagen 57 Crear nuevo origen de datos

Lugo nos aparece
Le damos el nombre con el cual se identifica el origen de los datos y oprimimos
crear
Pgina
139
Imagen 58 Configuracion de OBCD

Se nos despliega esta ventana
Y le damos la ruta donde est ubicada nuestra base de datos y aceptar
Imagen 59 Seleccionar base de datos

Se nos despliega la ventana anterior pero ya configurada la ruta de la BD y le damos
Aceptar
Pgina
140
Imagen 60 Configuracion de ODBC
Imagen 61 Administrador de origenes de datos ODBC
Pgina
141

9.2. Diagrama de clases
Interaccion del sistema
Imagen 62 Interaccin del sistema

Captulo 10 Modelo de Prueba
10.1. Definicin de conceptos
Pgina
142

Para este modelo la mayor vulnerabilidad que puede presentar es la del error
humano ya sea por un error al digitar los datos de los pacientes o por cruzar
informacin de los mismos.
Se presenta informacin general relacionada con cada rea involucrada en la
atencin de pacientes, identificando los procesos que presentan cada una de estas,
desprendiendo de estos las diversas funcionalidades que el nuevo sistema deber
satisfacer.
10.1. Tipo de pruebas
Como primera medida los tipos de pruebas sern de verificacin y validacin, para
esto se deben tener ciertos requisitos para garantizar su funcionamiento, estos son
fundamentales porque sin ellos tenemos la certeza de que nuestro sistema no cumplira
las expectativas requeridas por el usuario:
Ingresar paciente, Tratamiento del paciente, Gestionar Citas mdicas, Alta Paciente
Requisitos de Interfaces:
Interfaces de Usuario, Hardware, Comunicacin, Rendimiento, Desarrollo,
Tecnolgicos
TCNICA DE PRUEBAS
Para este modelo la tcnica de pruebas a implementar ser:
Prueba de Casos de Uso: se probara por medio de modelos de casos de uso como
por ejemplo
Pgina
143
Descripcin de los casos de uso esenciales del sistema atencin pacientes en el cual
se describirn las distintas actividades que son posibles realizar por el sistema para los
distintos actores.
PROCESO DE PRUEBAS
Pgina
144
Se considera tomar como estrategia de prueba el Orden de Pruebas lo que nos

refiere a los diagramas de secuencia del diseo, esto nos ayudara a definir en qu
momento y en qu orden se aplicaran las pruebas:
A su vez esto aplica tambin a las tcnicas de pruebas como gua para las pruebas
de Casos de Uso.
Pgina
145
Captulo 11 Conclusiones
A travs de un caso de uso se desarrolla el contenido de la materia para adquirir

destreza y conocimiento en el desarrollo de software orientado a objetos
Descripcin y reconocimiento de los actores involucrados en un ejemplo prctico
para el desarrollo de una solucin de software.
Pgina
146
Captulo 12 Recomendaciones
Como se expone al inicio de este trabajo, se brinda una breve orientacin para el
desarrollo de software con la Programacin Orientada a Objetos, no se busca
implementar esta gua si no al contrario se da un abrebocas para que el lector se
pueda orientar.
Se recomienda utilizar muchas ms fuentes de informacin que puedan aclarar

temas o que su limitacin sea ms amplia que la que se ofrece.
Se debe aplicar este conocimiento brindado en la prctica, es decir realizar

varios ejercicios donde se aplique el conocimiento adquirido en la teora.
Pgina
147
Captulo 13 Bibliografa
Anonimo. (2006). Universidad de terapaca. Recuperado el 10 de Abril de 2015, de
http://chitita.uta.cl/cursos/2010-2/0001282/recursos/r-2.pdf
(2005). A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java

e Internet Mexico City: Cengage Learning. Retrieved from
http://go.galegroup.com/ps/i.do?id=GALE|
2VGZ&v=2.1&u=unad&it=aboutBook&p=GVR&sw=w&id=GALE|2VGZ (2006). J. M.
Prez Menor, J. Carretero Prez, F.
Garca Carballeira, & J. M. Prez Lobato, Problemas resueltos de
programacin en
lenguaje Java. Madrid: Paraninfo. Retrieved from
http://go.galegroup.com/ps/i.do?id=GALE|
3ATV&v=2.1&u=unad&it=aboutBook&p=GV&
sw=w&id=GALE|3ATV.
Holzner, Steven. Java. Phoenix, AZ, USA: Paraglyph Press, 2001. p 254.
http://site.ebrary.com/lib/unad/Doc?id=5003060&ppg=288Copyright 2001.
Paraglyph
Press. All rights reserved.
Mastering Zukowski, John. Mastering Java 2, J2SE 1.4. Alameda, CA, USA: Sybex,
2002. p (1). http://site.ebrary.com/lib/unad/Doc?id=10152550&ppg=1 Copyright
2002. Sybex. All rights reserved.
Java 2 Game Programming Petchel, Thomas. Java 2 Game Programming Boston,
MA, USA: Course Technology / Cengage Learning, 2001. pi.
http://site.ebrary.com/lib/unad/Doc?id=10067191&ppg=1Copyright 2001. Course
Technology /Cengage Learning. All rights reserve.
http://datateca.unad.edu.co/contenidos/301403/2015_1/Presaberes_Teorico/Capitulo
_5/5.1._Introducci_n_a_Java.PDF
Pgina
148
Pgina
149

Trabajo Teoorico Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Trabajo Teoorico Final

Enviado por

Direitos autorais:

Formatos disponíveis

Ttulo del Proyecto de Investigacin

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Ttulo del Proyecto de Investigacin

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Captulo 8 Modelo de Diseo.......................................................................................

Tabla 1 Modelo de requisitos Solicitud historial paciente........................................15

Tabla 22 Casos de uso para el sistema _Emitir examen........................................45

Imagen 1 Modelo Interfaces.............................................................................................25

Imagen 10 Arquitectura de clases_Diagrama Examen solicitado.........................31

Imagen 20 Diagrama de secuencia_ Agregar Exmenes......................................36

Imagen 43 Secuencia de diseo Ingresar Datos Paciente Accidentado..............63

2.1. Se propone desarrollar un software que gestione el sistema de Atencin

Manejo de Fichas Mdicas automatizado.

5.1.- Programacin orientada a objetos

En esta entrada veremos algunos conceptos de la

Muchas veces cuando empezamos a trabajar con lenguajes de programacin

Nombre : Contiene el Nombre de la Clase.

/**Principal define el nombre de la Clase*/

public class Principal {

public String atributo="Esto es un atributo";

/**Esto es un mtodo, donde se definen las operaciones*/

public void metodo(){

/**aqui van las sentencias que definen

* el comportamiento del mtodo*/

en la imagen, los moldes representan las clases,

/**Creamos el objeto como instancia de la clase Principal*/

Principal miObjeto= new Principal();

miObjeto.atributo="Este es el nuevo valor del atributo para el objeto";

La herencia en java representa lo que conocemos de herencia en el mundo real,

public class Animal{

public String tamao;

public void comer(){

public void correr(){

class Paloma extends Animal{

Pblico: Se puede acceder a todos los atributos o mtodos de la

public class Principal{

La abstraccin permite resaltar la parte mas representativa de algo, ignorando

clase hombre, humano entre otras, pero obviamente vemos que la

public abstract class Principal{

/**Mtodo Abstracto sin implementacin*/

public abstract void metodoAbstracto();

class subClase extends Principal{

public void metodoAbstracto() {

/**Implementacin definida por la clase concreta*/

Las interfaces son el mecanismo que utiliza Java para simular la

puede instanciar una interfaz..... (Ver Ejemplo...)

/**Implementacin definida por la clase concreta*/

/**Implementacin definida por la clase concreta*/

bsicamente podemos definirlo como la capacidad que tienen los objetos de

class Cuadrado extends FiguraGeometrica {

class Triangulo extends FiguraGeometrica {

class Circulo extends FiguraGeometrica{

public class Principal{

public void metodo(){

/**Puedo crear objetos polimorficos*/

/**Objeto Cuadrado de tipo FiguraGeometrica*/

Como vemos en el ejemplo la clase FiguraGeometrica puede convertirse en

adelante explicaremos este concepto en detalle...

5.3. Programacin Avanzada

Captulo 6 Modelo de Requisitos

6.2. Modelo de Caso de Uso

Resumen: El actor ingresa sus datos y solicita el historial de un paciente

Tabla 2 Modelo de requisitos Agregar exmenes