Trabajo Teoorico Final 1

Título del Proyecto de Investigación
Transacciones electrónicas
Grupo 301403_60
Presentado por:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
PROGRAMA INGENIERIA ELECTRONICA
COLOMBIA
2015
Título del Proyecto de Investigación
Transacciones electrónicas
Grupo 301403_60
Presentado por:
Richard Alexander Muñoz Castro
Elkin David Aguilar Llanos
Tutor:
Cesar Orlando Jiménez 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
Capítulo 1. Introducción................................................................................................
Capítulo 2 Objetivos.....................................................................................................
Capítulo 3 Justificación...............................................................................................
Capítulo 4 Marco Teórico............................................................................................
Capítulo 6 Modelo de Requisitos.................................................................................
6.1. Descripción 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
Capítulo 7 Modelo de Análisis......................................................................................
7.1. Arquitectura de clases.......................................................................................29
7.2. Identificación de clases según Estereotipos..................................................32
7.3. Clases según casos de Uso.....................................................................................33
7.4. Diagramas de Secuencia..................................................................................34
7.5. Casos de uso para el sistema..........................................................................39

Capítulo 8 Modelo de Diseño.......................................................................................
8.1. Estrategias de Diseño.......................................................................................50
8.2. Diseño de Objetos..............................................................................................52
8.3. Diseño de Sistema.............................................................................................55
8.4. Revisión del Diseño...........................................................................................57
8.5. Diagrama de Secuencia del Diseño................................................................62
Capítulo 9 Modelo de Diseño.......................................................................................
9.1. Programación en java........................................................................................68
9.2. Diagrama de clases..........................................................................................80
10.1. Definición de conceptos..................................................................................81
10.1. Tipo de pruebas................................................................................................81
Capítulo 11 Conclusiones............................................................................................
Capítulo 12 Recomendaciones....................................................................................
Capitulo 13 Bibliografía................................................................................................
Listado de Tablas
Tabla 1 Modelo de requisitos Solicitud historial paciente........................................15
Tabla 2 Modelo de requisitos Agregar exámenes....................................................16
Tabla 3 Modelo de requisitos Emitir exámenes........................................................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 exámenes....................................................20
Tabla 7 Modelo de requisitos Emitir receta...............................................................21
Tabla 8 Modelo de requisitos Fijar horario disponible.............................................22
Tabla 9 Modelo de requisitos Ingresar exámenes solicitados................................23
Tabla 10 Modelo de requisitos Ingresar resultados exámenes..............................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 exámenes....................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 Exámenes...............................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 Revisión del diseño.......................................................................................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 médica (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 atención del 30
Imagen 10 Arquitectura de clases_Diagrama Examen solicitado.........................31
Imagen 11 Arquitectura de clases_Diagrama Ingresar resultado examen...........31
Imagen 12 Clases según caso de uso_Diagrama solicitar historial del paciente
...............................................................................................................................................33
Imagen 13 Clases según caso de uso_Diagrama Ingresar datos paciente
accidentado.........................................................................................................................33
Imagen 14 Clases según 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 Atención Paciente..............35
Imagen 18 Diagrama de secuencia_ Consulta Hora Disponible..........................35
Imagen 19 Diagrama de secuencia_ Solicitar Hora Atención Paciente...............36

Imagen 20 Diagrama de secuencia_ Agregar Exámenes......................................36
Imagen 21 Diagrama de secuencia_ Eliminar Reserva Hora...............................36
Imagen 22 Diagrama de secuencia_ Emitir Exámenes.........................................37
Imagen 23 Diagrama de secuencia_ Emitir Exámenes.........................................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 Diseño_Diagrama Consulta Historial Medico.............50
Imagen 30 Estrategias de Diseño_Diagrama Ingresar Paciente Accidentado....50
Imagen 31 Estrategias de Diseño_Diagrama Consulta hora atención paciente.51
Imagen 32 Estrategias de Diseño_Diagrama Ingresar Examen solicitado..........51
Imagen 33 Estrategias de Diseño_Diagrama Ingresar Resultado Examen........52
Imagen 34 Diseño Paquetes del Dominio.................................................................53
Imagen 35 Diseño Paquete del Recepcionista.........................................................53
Imagen 36 diseño Paquetes de Secretaria...............................................................53
Imagen 37 Diseño Paquete de Funcionario_Clinica_Externa................................54
Imagen 38 Diseño Paquete de Medico......................................................................54
Imagen 39 Diseño Paquete de Laboratorio Clínico.................................................54
Imagen 40 Diseño Paquete ACOS.............................................................................54
Imagen 41 Diseño del sistema....................................................................................55
Imagen 42 Secuencia de diseño Historial del paciente..........................................62

Imagen 43 Secuencia de diseño Ingresar Datos Paciente Accidentado..............63
Imagen 44 Secuencia de diseño Consulta Hora pedida Atención Paciente........63
Imagen 45 Secuencia de diseño Consulta Hora Disponible Atención Paciente. 64
Imagen 46 Secuencia de diseño Solicitud hora de atención..................................64
Imagen 47 Secuencia de diseño Agregar exámenes..............................................64
Imagen 48 Secuencia de diseño Eliminar reserva hora..........................................65
Imagen 49 Secuencia de diseño Emitir exámenes.................................................65
Imagen 50 Secuencia de diseño Cambiar historial paciente.................................66
Imagen 51 Secuencia de diseño Cambiar historial paciente.................................66
Imagen 52 Secuencia de diseño Emitir receta..................................................................66
Imagen 53 Secuencia de diseño Fijar hora disponible.....................................................66
Imagen 54 Secuencia de diseño Ingresar resultado examen................................67
Imagen 55 Secuencia de diseño Ingresar examen solicitado................................67

Capítulo 1. Introducción
Se desarrollara el un problema relacionado con el sistema de atención a

pacientes en la que se pretende dar solución 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 física como síquica, daremos una pequeña descripción del
Sistema Actual, sus necesidades y objetivos perseguidos en este proyecto,
además de los costos de la implementación del sistema de información.
Capítulo 2 Objetivos
2.1. Se propone desarrollar un software que gestione el sistema de Atención

de Clientes, manejando para esto una base de datos que contendrá el registro
de todos los beneficiarios asociados a la Asociación Chilena de Seguridad.
2.2. Características Principales del Sistema:
 Manejo de Fichas Médicas automatizado.

 Control de Petición de Horas de atención.
 Manejo de Historial Clínico de pacientes.
 Manejo de Exámenes, en forma digitalizada, de los pacientes
 Entrega de Recetas Médicas.
 Acceso externo del sistema, para que otras instituciones puedan ver el
historial Médico en caso de traslado de paciente.
 Acceso interno de distintos usuarios al sistema.
Capítulo 3 Justificación
Por medio del desarrollo y aplicación de estos conceptos se pretende dar una
guía o herramienta para la puesta en práctica 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 más relevantes al momento de brindar
una solución sistemática a un problema y desarrollar un software por medio de la
Programación Orientada a Objetos.
Capítulo 4 Delimitación
Capítulo 5 Programación Orientada a Objetos en Java
5.1.- Programación orientada a objetos
Debido a la complejidad del problema a tratar y de los algoritmos a

implementar, se opta por desarrollar la aplicación en un lenguaje orientado a
objetos.
La orientación a objetos es un paradigma de programación que facilita la

creación de software de calidad por sus factores que potencian el mantenimiento,
la extensión y la reutilización del software generado bajo este paradigma.
La programación orientada a objetos trata de amoldarse al modo de pensar

del hombre y no al de la máquina. 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 jerarquía o el encapsulamiento.
El elemento básico de este paradigma no es la función (elemento básico de

la programación estructurada), sino un ente denominado objeto. Un objeto es la
representación de un concepto para un programa, y contiene toda la información
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 programación orientados a objetos, se ha

optado por el lenguaje JAVA, cuyas principales características se comentan a
continuación.
5.2. Programación Básica

Conceptos Básicos de Programación Orientada a Objetos
En esta entrada veremos algunos conceptos de la

programación orientada a Objetos (POO)...............................................
Muchas veces cuando empezamos a trabajar con lenguajes de programación
nos dicen que son orientados a Objetos y nos dan la teoría 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 prácticos para ver su aplicación......
Empecemos!!!
Programación OO.
La programación orientada a Objetos básicamente define una serie de

conceptos y técnicas de programación para representar acciones o cosas de la
vida real basada en objetos, a diferencia de otras formas de programación como
por ejemplo la estructurada, con la POO trabajamos de manera distinta vinculando
diferentes conceptos tales como clases, objetos, métodos, propiedades, estados,
herencia, encapsulación 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

programación, pues en ellas ocurren todos los procesos lógicos 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.
Métodos : Representan el comportamiento u operaciones, la forma como
interactúa la clase con su entorno.
En java se representa así :
1 /**Principal define el nombre de la Clase*/
2 public class Principal {
4 public String atributo="Esto es un atributo";
6 /**Esto es un método, donde se definen las operaciones*/
7 public void metodo(){
8 /**aqui van las sentencias que definen
9 * el comportamiento del método*/
10 }
11 }
Objeto.
Los objetos representan una entidad concreta o abstracta del mundo real, en
programación básicamente 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 características con valores concretos del

objeto. Comportamiento : Se define por los métodos 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 podría ser
sabor, color, tamaño 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 métodos 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*/
2 Principal miObjeto= new Principal();
3 miObjeto.atributo="Este es el nuevo valor del atributo para el objeto";
4 miObjeto.metodo();
Herencia.
La herencia en java representa lo que conocemos de herencia en el mundo real,

básicamente mediante esta obtenemos las características o rasgos comunes de
nuestros padres o abuelos, en java es el mismo enfoque permitiendo la creación
de nuevas clases basadas en clases ya existentes, con las cuales podemos
obtener las características de las clases padres, heredando campos, atributos,
métodos o funcionalidades.
En Java solo se puede heredar de una sola clase padre y se representa mediante
la palabra extends (Ver Ejemplo...)
1 public class Animal{
2 public String tamaño;

3
4
public void comer(){
5
/**Comportamiento.....*/
6
}
7
class Perro extends Animal
8
public int dientes;
9
10
public void correr(){
11
12
}
13
}
14
15
class Paloma extends Animal{
16
public int plumas;
17
public void volar(){
18
19
}
Encapsulamiento.
Este concepto es uno de los mas importantes en términos de seguridad dentro de

nuestra aplicación, la encapsulación es la forma de proteger nuestros datos dentro
del sistema, estableciendo básicamente los permisos o niveles de visibilidad o
acceso de nuestros datos
Se representa por 3 niveles :

Público: Se puede acceder a todos los atributos o métodos de la
clase. Protegido: Se puede acceder a los atributos o métodos solo en la misma
jerarquía de herencia. Privado: Solo se puede acceder a los atributos o métodos
de la clase en la que se encuentran.
con la Encapsulación 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 métodos setter y getter que permiten manipular nuestros datos de forma
segura.
en Java lo representamos así:
2
public class Principal{
3
public String atributo1;
4
private String atributo2;
5
protected String atributo3
6
/**Métodos Set y Get para trabajar con las variables*
7
public String getAtributo2() {
8
return atributo2;
9
}
10
public void setAtributo2(String atributo2) {
11
this.atributo2 = atributo2;
12
}
13
14
Clases Abstractas.
La abstracción permite resaltar la parte mas representativa de algo, ignorando
detalles para centrarse en lo principal.
La imagen es muy fácil 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 abstracción,
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 métodos generales con un

comportamiento común para otras clases concretas sin importar sus
características ni el comportamiento que usen para dichos métodos.
La Abstracción en java solo tiene lógica mediante la Herencia, ya que una clase
abstracta posee al menos un método abstracto el cual no tiene implementación, el
comportamiento de estos métodos lo definen las clases concretas que lo hereden.
Podemos usarlos cuando existan varias clases con características o acciones
comunes pero con diferentes comportamientos..............mediante el uso de la
herencia y componentes abstractos hacemos mas óptima y organizada nuestra
aplicación. (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 abstracción mediante la palabra reservada abstract,

así:
1 public abstract class Principal{
3 /**Método Abstracto sin implementación*/
4 public abstract void metodoAbstracto();
5
6 }
8 class subClase extends Principal{
10 @Override
11 public void metodoAbstracto() {
12 /**Implementación definida por la clase concreta*/
13 }
14
15 }
Interfaces.
Las interfaces son el mecanismo que utiliza Java para simular la

herencia múltiple, 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, básicamente son
clases completamente abstractas, es común 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 métodos 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 métodos lo son y por ende no poseen implementación, 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 implementación de
los métodos depende de las clases concretas que las usen.
Se debe tener en cuenta que toda variable definida en una

interfaz automáticamente se convierte en una constante, además tampoco se
puede instanciar una interfaz..... (Ver Ejemplo...)
En java se representan con la palabra interface y se usan con la

palabraimplements así:
1
interface InterfacePrincipal
2
public void metodoAbstracto();
3
public String otroMetodoAbstracto();
4
}
5
public class Principal implements InterfacePrincipal{
6
public void metodoAbstracto() {
7
/**Implementación definida por la clase concreta*/
8
}
9
public String otroMetodoAbstracto() {
10
/**Implementación definida por la clase concreta*/
11
return "retorno";
12
}
13
}
Polimorfismo.
Este tal vez sea uno de los conceptos de la programación orientada a objetos
mas usados pero muchas veces sin saber que se aplica ya que el concepto
inicialmente puede ser un poco confuso, básicamente 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 características comunes los
cuales comparten la misma superClase y árbol jerárquico, al trabajar con este
concepto optimizamos y simplificamos en gran medida nuestro trabajo.
básicamente podemos definirlo como la capacidad que tienen los objetos de
comportarse de múltiples 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 generalización olvidando los detalles concretos de

los objetos para centrarnos en un punto en común 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
geométrica puede ser un cuadro, un triángulo, un cuadrado o cualquier figura que
en términos generales sea geométrica...... (Ejemplo1) (Ejemplo2)
Veamos este proceso como se representa en Java.
1 class FiguraGeometrica{
4 }
11
12 class Cuadrado extends FiguraGeometrica {
13
14 }
15
16 class Triangulo extends FiguraGeometrica {
17
18 }
19
class Circulo extends FiguraGeometrica{
20
public class Principal{
21
22
public void metodo(){
23
/**Puedo crear objetos concretos*/
24
FiguraGeometrica miFiguraGeometrica = new FiguraGeometrica();
25
Cuadrado miCuadro=new Cuadrado();
26
27
/**Puedo crear objetos polimorficos*/
28
miFiguraGeometrica=miCuadro;
29
30
/**Objeto Cuadrado de tipo FiguraGeometrica*/
31
FiguraGeometrica miCuadrado= new Cuadrado();
32
/**Objeto Circulo de tipo FiguraGeometrica*/
33
FiguraGeometrica miCirculo=new Circulo();
34
/**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 jerarquía 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 programación

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. Programación 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();
Capítulo 6 Modelo de Requisitos
6.1. Descripción del problema
Descripción del Problema

La Asociación 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 prevención de estos. Su misión 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 física como síquica"
Dentro de esta empresa existe un departamento clínico, que es el encargado
de la atención de los pacientes que sufrieron algún accidente de trabajo en
alguna de las empresas asociadas, este se encarga de la atención mientras
se recuperan y puedan retornar a sus puestos de trabajo.
Se desea automatizar el sistema de atención al paciente y el sistema de fichas
médicas para mejorar la coordinación 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
atención más 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 médica, luego la secretaria del departamento clínico
registra al paciente y lo deriva a la atención médica.
El médico evalúa si el paciente necesita derivarse a un hospital o clínica
externa, al enviarlo a una entidad externa se debe enviar al paciente junto con
su historial médico, y si no lo envía, puede modificar su tratamiento. El médico
también evalúa 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 médica, y si no, puede modificar el
tratamiento que está siguiendo el paciente.
6.2. Modelo de Caso de Uso
Iniciaremos la obtención de los diferentes casos de uso del sistema, así como el
modelado conceptual y las demás etapas del modelado de requisitos y nos
ayudarán en la comprensión del funcionamiento del sistema de atención pacientes
de la ACOS.
Descripción de los casos de uso esenciales del sistema atención pacientes en
el cual se describirán las distintas actividades que son posibles realizar por el
sistema para los distintos actores.
Con su médico 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 alérgico, así como el de conocer el historial médico ( Datos
Históricos paciente).
Actor Principal: Secretaria Departamento Clínico.
Personal Involucrado:
Secretaria Departamento Clínico: Ingresa los exámenes del paciente a su historial
de atención (Ficha).
Precondiciones: El Paciente pertenece a la ACOS.

Poscondiciones: Actualización de Historial lista para otra actualización.
Flujo Básico:
1. La secretaria departamento clínico ingresa sus datos al sistema.
2. El Sistema verifica los datos ingresados.
3. La secretaria departamento clínico ingresa los datos del paciente.
4. El Sistema verifica los datos del paciente.
5. El Sistema pondrá a disposición el historial del paciente para ingresar los
exámenes.
6. La secretaria departamento clínico ingresa los exámenes del paciente.
7. Repetir 5 hasta terminar el ingreso de exámenes del paciente.
8. Fin ingreso de exámenes.
Requisitos Especiales:
- Los Datos de horario de atención deberán ser ordenados por fecha y hora.
Lista de Tecnologías y Variaciones de Datos:
Cuestiones Pendientes: Asignar a otro médico cuando el médico tratante no
este disponible.
Tabla 2 Modelo de requisitos Agregar exámenes
Resumen: La secretaria departamento clínico ingresa sus datos e ingresa los

exámenes hechos al paciente a su historial, para ello ingresa el identificador del
paciente y los anexa al Histórico de Pacientes (Datos Históricos Paciente).
Recepcionista ACOS: Realizar consulta historial paciente, para poder imprimir
alguna parte de la ficha para ser enviado hacia una consulta externa.
Secretaría Departamento Clínico: 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.
Clínica Externa: Realiza consulta historial paciente, para ver antecedentes de
alergias u enfermedades preexistentes, o si se encuentra bajo algún tratamiento.
Precondiciones: El paciente debe estar registrado en la ACOS.
Poscondiciones: Impresión ficha paciente, consulta cerrada historial paciente.
Flujo Básico:
1. El Usuario ingresa sus datos al sistema.
3. El Usuario ingresa los datos del paciente.
5. El Sistema pondrá a disposición el historial del paciente.
6. El Usuario podrá imprimir historial médico paciente, cómo 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 válidos.
2.1.2 Ir al paso 1 o salir del sistema paso 8.
4.1 Si los datos del paciente no son validos
- Los exámenes deberán ser ordenados por fecha más reciente.
Cuestiones Pendientes: Crear un historial paciente cuando sea paciente
nuevo...
Tabla 3 Modelo de requisitos Emitir exámenes
Resumen: La secretaria departamento clínico ingresa sus datos y entrega los

exámenes (impresos) al paciente ingresando para ello el identificador del
paciente, estos son realizados por el laboratorio clínico (Datos Exámenes Lab.).
Actor Principal: Secretaria Departamento Clínico: Busca los exámenes del
paciente para su entrega y los imprime.
Laboratorio Clínico: Ingresa los resultados de los exámenes al sistema.
Secretaria Departamento Clínico: Ingresa los exámenes del paciente a su
historial de atención (Ficha).
Precondiciones: Al Paciente le ingresan exámenes al laboratorio clínico.

Poscondiciones: El sistema está listo para emitir nuevos exámenes
Flujo Básico:
1. La secretaria departamento clínico ingresa sus datos al sistema.
3. La secretaria departamento clínico ingresa los datos del paciente.
5. El Sistema pondrá a disposición los exámenes realizados al paciente para
imprimirlos.
6. La secretaria departamento clínico selecciona exámenes a imprimir.
7. Repetir 5 hasta terminar de imprimir los exámenes del paciente.
8. Fin emisión de exámenes.
Flujo Alternativo:
2.1 Si los datos del usuario no son válidos.
- Los exámenes deberán ser ordenados por fecha más reciente.
Cuestiones Pendientes:
Tabla 4 Modelo de requisitos Eliminar reserva hora
Resumen: La secretaria departamento clínico ingresa sus datos y solicita el

horario de consulta del médico, ingresando para ello la identificación del médico,
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
(Reservación Horario de Atención).
determinado ingresando para ello el rut del paciente, donde podrá agregar los
exámenes hechos al pacientes, los medicamentos aplicados y el tratamiento
(Personal
Datos Históricos paciente).
Involucrado:
Actor Principal: Doctor
Secretaria Departamento Clínico: Realizar consulta hora de atención médico
pedida por el paciente para eliminarla.
Doctor: EsInvolucrado:
Personal quien fija el horario de atención que tiene disponible
Precondiciones:
Doctor: El Paciente debe
Realiza modificaciones haber pedido
al historial hora de
del paciente atenciónlos
agregando médico.
Poscondiciones: La reservación
tratamientos realizados luego del accidente. del doctor en el bloque eliminado está
disponible.
Precondiciones: El paciente debe estar registrado en la ACOS.
Flujo Básico:
Poscondiciones: El sistema está listo para actualizar historial paciente
1. La secretaria
Flujo Básico: departamento clínico ingresa sus datos al sistema.
2. ElDoctor
1El Sistema verifica
ingresa suslos datos
datos al ingresados.
sistema.
3. El
2. La Sistema
secretaria departamento
verifica los datosclínico ingresa los datos del médico.
ingresados.
4. El Doctor
3. Sistemaingresa
verificalos
losdatos
datosdeldelpaciente.
médico.
5. El Sistema verifica
4. pondrá a losdisposición el horario de atención del médico.
datos del paciente.
6. El
5. La Sistema
secretaria departamento
pondrá clínico
a disposición podrá eliminar
el historial el bloque asignado al
del paciente.
paciente
6. El Médicoy podrá actualizar el historial médico paciente.
Dejarlo
7. Repetirlibre para otro
3 hasta paciente
terminar que lo solicite.
actualización de historial pacientes.
7. Fin
8. Repetir 6 hasta
consulta terminar eliminación de horario médico.
paciente.
8. Fin eliminación reserva hora.
Flujo
Flujo Alternativo:
Alternativo:
2.1 Si
2.1 Si los
los datos
datos del
del usuario
usuario nono son
son válidos.
válidos.
2.1.2
4.1 SiIrlos
al datos
paso 1delo salir del no
médico sistema paso 8.
son validos
4.1 SiIrlos
4.1.1 al datos
paso 3del paciente
o salir no son paso
del sistema validos8. 8.
Requisitos
- Los Datos Especiales:
de horario de atención deberán ser ordenados por fecha y hora.
-Lista de Tecnologías
Los Datos del paciente y Variaciones de Datos:
deberán ordenarse por fecha de exámenes más
recientes.
- Se deberá ingresar al lado del examen una breve descripción

Tabla 5 Modelo de requisitos cambiar historial del paciente
Tabla 6 Modelo de requisitos Solicitar exámenes

Resumen: El doctor ingresa sus datos e ingresa los datos del paciente (Datos
Resumen: El para
Beneficiario) doctor ingresa
poder sus datos
seleccionar enelaingresa
receta los datos del los
desplegada paciente y se le
medicamentos
despliega
para la solicitud
el tratamiento de exámenes.
a seguir El doctor selecciona los exámenes que
por el paciente.
debe realizar
Actor el paciente
Principal: Doctor en el laboratorio clínico o externamente.
Actor Principal:
Personal Doctor
Involucrado:
Personal Involucrado: Doctor: Solicita
Doctor: Registra los medicamentos en larealización de los exámenes
receta desplegada que debe
para el tratamiento
hacer
del el paciente.
paciente.
Precondiciones: El
Precondiciones: El paciente
paciente debe
debe estar
estar en
en el
el sistema
sistema dede atención
atención.
Poscondiciones: El sistema está listo para solicitar
Poscondiciones: El sistema está listo para emitir nueva receta. nuevos exámenes.
Flujo Básico:
Flujo Básico:
. El doctor
1El doctor ingresa
ingresa sussus datos
datos al
al sistema.
sistema.
2. El
2. El Sistema
Sistema verifica
verifica los
los datos
datos ingresados.
ingresados.
3. El
3. El doctor
doctor ingresa
ingresa los
los datos
datos del
del paciente.
paciente.
4. El
4. El Sistema
Sistema verifica
verifica los
los datos
datos del
del paciente.
paciente.
5. El
5. El Sistema
Sistema pondrá
pondrá a a disposición
disposición la la receta
solicitud de exámenes
a rellenar por losque ha de realizar
distintos
el paciente.
medicamentos.
6. El
6. El doctor
doctor selecciona
selecciona losexámenes a realizar
medicamentos el paciente.
para el paciente.
7. Repetir 5 hasta terminar la solicitud de exámenes
7. Repetir 4 hasta terminar de registrar las recetas médicas. al paciente.
8. Fin
8. Fin emisión
solicitar exámenes.
receta.
Flujo Alternativo:
Flujo Alternativo:
2.1 Si
2.1 Si los
los datos
datos del
del doctor
usuariono noson
sonválidos.
válidos.
2.1.1 Ir
2.1.1 Ir al
al paso
paso 1
1oo salir
salir del
del sistema
sistema paso
paso 8.8.
4.1 Si
4.1 Si los
los datos
datos del
del paciente
paciente nono son
son validos
validos
4.1.1 Ir
4.1.1 Ir al
al paso
paso 3
3oo salir
salir del
del sistema
sistema paso
paso 8.8
- Losmedicamentos
Los exámenes deberán indicar
deberán si son realizados
ser ordenados en alfabético.
en orden el laboratorio clínico de la
ACOS.
Lista de Tecnologías
Cuestiones y Variaciones
Pendientes: de Datos:
Se deberá ingresar a cada receta la firma digital del
Cuestiones
doctor. Pendientes: Registro de exámenes pendientes del paciente.
Tabla 7 Modelo de requisitos Emitir receta

Resumen:
Resumen: El El laboratorio clínico
doctor ingresa susingresa
datos esus datosa elaingresa
ingresa la orden
Reservación de de solicitud
Horarios
de atención,
de exámenes, registrando los datos del paciente, como los exámenes a realizar.
Actor
DondePrincipal: Laboratorio
podrá marcar Clínico.
su horario de disponibilidad de atención para los pacientes
que están en tratamiento con él (Reservación Horario de Atención).
Laboratorio Clínico:
Actor Principal: Ingresa
Doctor: Es los datos
quien fija del paciente
el horario deyatención
exámenesquesolicitados.
tiene
Precondiciones:
disponible. El usuario debe estar en el sistema de atención.
Poscondiciones:
Doctor: Es quien fija Existen exámenes
el horario a efectuar
de atención por eldisponible.
que tiene laboratorio.
Flujo Básico:
Precondiciones: El doctor dispone de bloques disponibles para fijar.
1. El laboratorio clínico
Poscondiciones: ingresa sus
Los pacientes datos elegir
pueden al sistema.
algún bloque disponible del
2. El Sistema verifica los
doctor para solicitar atención. datos ingresados.
3. El laboratorio
Flujo Básico: clínico ingresa los datos del paciente.
4.
1. El
El Sistema verificasus
doctor ingresa losdatos
datosaldel paciente.
sistema.
5.
2. El
El Sistema
Sistema pondrá
verifica a disposición
los la solicitud de exámenes para que el
datos ingresados.
laboratorio
3. El Sistema registre
pondrá cuales debe hacérseles
a disposición el horarioalde
paciente.
atención del médico.
6. Repetir 3 hasta terminar ingreso de los exámenes
4. El doctor podrá asignar los bloques que tiene disponible a pacientes.
para la atención de
7.
losFin Ingreso de exámenes solicitados.
Pacientes que lo solicitan.
Flujo Alternativo:
5.
2.1Repetir 3 hasta
Si los datos delterminar asignación
laboratorio clínico nohorario médico.
son válidos.
6. FinIrfijar
2.1.1 horario
al paso 1 ode atención
salir médico.
del sistema paso 7.
4.1 Si Alternativo:
Flujo los datos del paciente no son validos
4.1.1
2.1 SiIrlos
al datos
paso 3del
o salir delno
doctor sistema paso 7.
son válidos.
2.1.1 Ir al paso
Requisitos 1 o salir del sistema paso 6.
Especiales:
Los exámenes
Requisitos deben estar disponibles para su selección por el laboratorio
Especiales:
clínico.
Los Datos de horario de atención deberán ser desplegados como un calendario
Lista de Tecnologías
de programación dondey el
Variaciones de Datos:los bloques en los que dispone
doctor seleccionará
de tiempo disponible.
Cuestiones Pendientes: El doctor podrá eliminar algún bloque si no puede
atender.
Tabla 8 Modelo de requisitos Fijar horario disponible
Tabla 9 Modelo de requisitos Ingresar exámenes solicitados
Tabla 10 Modelo de requisitos Ingresar resultados exámenes
Resumen: El laboratorio clínico ingresa sus datos, e ingresa los resultados de

los exámenes efectuados a algún paciente al sistema de atención médica
(Datos Exámenes).
Actor Principal: Laboratorio Clínico.
Laboratorio Clínico: Ingresa los datos del paciente determinado al sistema.
Precondiciones: Existe la solicitud de exámenes para el paciente.
Poscondiciones: Se pueden Emitir los exámenes hechos al paciente.

Flujo Básico:
1. El laboratorio clínico ingresa sus datos al sistema.
3. El laboratorio clínico ingresa los datos del paciente.
5. El Sistema pondrá a disposición el registro de datos de exámenes del
laboratorio.
6. El laboratorio clínico ingresa los resultados de los exámenes hechos al
paciente.
7. Repetir 3 hasta terminar ingreso de los exámenes a pacientes.
8. Fin Ingreso de Resultados de exámenes.
Flujo Alternativo:
2.1 Si los datos del laboratorio clínico no son válidos.
Los exámenes deben estar ordenados por fecha de resultados.
6.3. Modelo de Interfaces
Imagen 1 Modelo Interfaces

Proyecto de Investigación Curso Académico de Programación Orientada a Objetos
Imagen 2 Interfaz de usuario
Imagen 3 Interfaz Ficha médica (Medico o doctor)
Imagen 4 Interfaz Pedir horas Medicas (Secretaria)
Página 88
6.4. Actores y Caso de Uso
Se describen en total 2 actores en el sistema de transacciones electrónicas. El

Usuario interactúa con todos los casos de uso. En el que con el programa el usuario
realizara sus conversiones dependiendo de la base numérica de su país y de la del
país de donde se le hace él envió.
Tabla 11 Actores
Actor Usuario
Casos de Consultar su valor
uso
Tipo Primario
Descripción Es el actor principal y representa a la persona que desee utilizar
el sistema.
Diagrama casos de uso
Imagen 5 Diagramas casos de uso.
Página 89
6 Modelo de Dominio del Problema
 La interfaz para cada usuario estará determinada por la función que ocupa en
el sistema, este le permitirá acceder a toda la gama de opciones que le son
propias en la interacción con el sistema de atención al paciente.
 La interfaz debe ser lo más acorde al procedimiento típico de atención, 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 atención.
 Se requiere identificar y entregar privilegios a los distintos usuarios del sistema

de atención (nombre de usuario y contraseña).
 Se requiere que la empresa que inscriba al trabajador ingrese sus

antecedentes médicos para almacenarlos en el sistema de atención.
 El paciente debe pedir hora de atención solo a la secretaria del departamento

clínico.
Página 90
Capítulo 7 Modelo de Análisis
7.1. Arquitectura de clases
Consulta Historial Medico
Imagen 6 Arquitectura de clases_Consultar historial medico
Diagrama Ingresar Paciente Accidentado
Página 91
Imagen 7 Arquitectura de clases_Diagrama Ingresar paciente accidentado

Imagen 8 Arquitectura de clases_Diagrama ingresar paciente accidentado
Diagrama Consulta Hora Atención Paciente
Página 92
Imagen 9 Arquitectura de clases_Diagrama Consultar hora de atención del
paciente
Ingresar
Examen solicitado
Imagen 10 Arquitectura de clases_Diagrama Examen solicitado
Página 93
Ingresar Resultado Examen
Imagen 11 Arquitectura de clases_Diagrama Ingresar resultado examen

7.2. Identificación de clases según 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 Atención Paciente
 Consultar_Hora_Pedida( rut_paciente)
 Consultar_Hora_Disponible( rut_médico, Fecha)
 Solicitar Hora Atención Paciente
 Solicitar_Hora( rut_paciente, nombre_medico, fecha, hora)
Página 94
 Agregar Exámenes
 Agregar_examenes( rut_paciente, Nombre_examen, tipo_Examen,
Fecha_Examen, resultados)
 Eliminar Reserva Hora
 Eliminar_Hora( rut_paciente, nombre_medico, fecha, hora)
 Emitir Exámenes
 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
 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 según casos de Uso
Solicitar Historial Paciente
Página 95
Imagen 12 Clases según caso de uso_Diagrama solicitar historial del paciente
Ingresar Datos Paciente Accidentado
Imagen 13 Clases según caso de uso_Diagrama Ingresar datos paciente
accidentado
Consultar Hora Pedida:
Página 96
Imagen 14 Clases según caso de uso_Diagrama Consultar hora pedida
7.4. Diagramas de Secuencia
Solicitar Historial Paciente
Imagen 15 Diagrama de secuencia_ Solicitar Historial Paciente
Imagen 16 Diagrama de secuencia_ Ingresar Datos Paciente Accidentado
Consulta Hora Atención Paciente
Página 97
Imagen 17 Diagrama de secuencia_ Consulta Hora Atención Paciente
Consulta Hora Disponible
Imagen 18 Diagrama de secuencia_ Consulta Hora Disponible
Solicitar Hora Atención Paciente
Página 98
Imagen 19 Diagrama de secuencia_ Solicitar Hora Atención Paciente
Agregar Exámenes
Imagen 20 Diagrama de secuencia_ Agregar Exámenes
Eliminar Reserva Hora
Imagen 21 Diagrama de secuencia_ Eliminar Reserva Hora
Emitir Exámenes
Página 99
Imagen 22 Diagrama de secuencia_ Emitir Exámenes
Cambiar Historial Paciente
Imagen 23 Diagrama de secuencia_ Emitir Exámenes
Eliminar historial del paciente
Imagen 24 Diagrama de secuencia_ Eliminar historial del paciente
Página 100
Emitir Receta
Imagen 25 Diagrama de secuencia_ Emitir Receta
Fijar Horario Disponible
Imagen 26 Diagrama de secuencia_ Fijar Horario Disponible
Ingresar resultado examen
Imagen 27 Diagrama de secuencia_ Ingresar resultado examen
Página 101
Ingresar Examen solicitado
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 Validar Usuario(rut_usuario, clave)

Responsabilidad Permite verificar si el usuario es un
usuario autorizado, además permite
discriminar entre los distintos tipos de
usuarios para proporcionarles a estos
la interfaz apropiada.
Tipo Sistemas
Caso de Uso Todos
Notas
Excepciones Al estar incorrecto el RUT o la clave
Salida Despliega menú de usuario
Precondiciones Exista el rut y la clave en la base de
datos
Pos condiciones Usuario ingresado a Sistema
Página 102
Nombre Solicitar_Historial( rut_paciente)

Responsabilidad Permite obtener los datos del historial o
ficha del paciente, además de los
exámenes de esos.
Tipo Sistemas
Caso de Uso Solicitar Historial Paciente
Notas
Excepciones El rut del paciente no existe o es
erróneo, que el historial no exista.
Salida Despliega la ficha médica por pantalla
Precondiciones Que exista el rut del paciente en la
base de datos
Pos condiciones El historial médico 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

erróneo, la fecha de inicio y/o la de
termino no existen en el historial, la
fecha de inicio debe ser menor que la
Página 103
Nombre Solicitar_Historial( rut_paciente)

de termine.
Responsabilidad Permite obtener los datos del historial o
ficha del paciente, además de los
Salida Imprime el historial o la parte del
exámenes de esos.
historial solicitada
Precondiciones
Tipo Que exista el rut del paciente en la
Sistemas
Caso de Uso base de datos,
Solicitar que
Historial existan
Paciente
Notas las fechas dentro del historial
Pos condiciones: El historial impreso
erróneo, que el historial no exista.
Salida Despliega la ficha médica por pantalla
Precondiciones Que exista el rut del paciente en la base
de datos
Pos condiciones El historial médico desplegado por
pantalla
Tabla 15 Casos de uso para el sistema _Historial de los exámenes
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
estén disponibles para el médico o
cualquiera que lo solicite
Tipo: Sistema
Caso de uso Ingresar Datos Paciente Accidentado
Notas:
Excepciones: No exista el rut del paciente o ese esta

equivocado
Página 104
Salida: Una confirmación de que los datos se

ingresaron a la ficha
Precondiciones: Rut del paciente accidentado se
encuentre registrado
Pues condiciones: Datos guardados en la ficha o historial

médico Sistemas de Información
Tabla 17 Casos de uso para el sistema _Consultar Hora Pedida
Nombre: Consultar_Hora_Pedida( rut_paciente)

Responsabilidad: Permite verificar las horas pedidas por
un paciente.
Tipo: Sistema
Caso de uso: Consulta Hora Atención Paciente
Notas: En caso de que el usuario no tenga
horas perdida la lista saldrá vacía.
Excepciones: Rut paciente no existe o está
equivocado, no existan horas pedidas
Salida: Una lista con las horas pedidas por el
paciente
Precondiciones: Que exista el rut del paciente en la
base de datos
Pos condiciones: Una lista es desplegada con el nombre
del médico y la fecha
Tabla 18 Casos de uso para el sistema _Hora Disponible
Nombre: Consultar_Hora_Disponible( rut_médic

o, Fecha)
Responsabilidad: Permite obtener las horas disponibles
de un médico para una determinada
fecha, esto es indispensable para poder
pedir hora.
Tipo: Sistema
Página 105
Caso de uso: Consulta Hora Atención Paciente

Notas: El medico se elige desde una lista por
lo que puede ocurrir un error con su rut
Excepciones: La fecha no tiene ninguna hora
disponible.
Salida: Despliega una lista con las horas
disponibles para su posterior selección.
Precondiciones: Existan médicas en registro y fechas
disponibles
Pos condiciones Una lista con las horas disponibles.
Llenado de las horas para selección del
paciente
Tabla 19 Casos de uso para el sistema _Solicitar Hora
Nombre: Solicitar_Hora( rut_paciente,

nombre_medico, fecha, hora)
Responsabilidad: Asigna una hora a un paciente
Tipo: Sistema
Caso de uso: Solicitar Hora Atención Paciente
Notas: 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.
Excepciones: El rut del paciente es erróneo o no
existe en registro.
Salida: Confirmación de operación 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 Exámenes
Página 106
Nombre Agregar_examenes( rut_paciente,

Nombre_examen,
tipo_Examen, Fecha_Examen,
resultados)
Responsabilidad: Agregar exámenes realizados en
laboratorios externos
Tipo: Sistema
Caso de uso: Agregar Exámenes
Notas:
Excepciones: Rut de paciente no existe o es errado
Salida: Confirmación de operación exitosa
Precondiciones: Exista el rut del paciente en la base de
datos
Pos condiciones: El examen almacenado en la base de
datos
Tabla 21 Casos de uso para el sistema _Eliminar Hora
Nombre: Eliminar_Hora( rut_paciente,

nombre_medico, fecha, hora)
Responsabilidad: Permite liberar una hora médica, para
que otro paciente pueda hacer uso de
ella.
Tipo Sistema
Caso de uso: Eliminar Reserva Hora
Excepciones: Rut del paciente no existe o es

incorrecto, el paciente no tiene hora
asignada
Salida: Confirmación de que la operación fue
llevada a cabo con
Precondiciones: Exista el rut y exista la hora
Pos condiciones La eliminación de la hora de la base de

datos
Página 107
Tabla 22 Casos de uso para el sistema _Emitir examen
Nombre Emitir_examen( rut_paciente, nombre_examen,

tipo_examen)
Responsabilidad Imprime los exámenes de un paciente
Tipo Sistema
Caso de Uso Emitir Exámenes
Notas
Excepciones El rut del paciente no existe o es erróneo, el
paciente no
posee exámenes registrados
salida Impresión de la exámenes
precondiciones Exista el paciente, existan exámenes
pos condiciones 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 Sistema
Caso de Uso Cambiar Historial Paciente
Notas Los datos son guardados por fecha y se ordenan desde el
más
Excepciones El rut del paciente no existe o esta errado
salida Confirmación de que los datos se agregaron al historial, el
historial es desplegado por pantalla
precondiciones Exista el rut del paciente, exista el historial
pos condiciones Los datos son ingresados al historial, guardados en la base
de
datos y desplegados por pantalla
Página 108
Tabla 24 Casos de uso para el sistema _Eliminar del Historial Paciente
Nombre Eliminar_del_Historial_Paciente(rut_paciente,Nombre_medico
,
fecha_a_eliminar)
Responsabilidad Elimina una parte del historial que se encuentre errado
Tipo Sistema
Notas
Excepciones No existe datos registrados en el historial solo los básicos
salida Confirmación de la eliminación exitosa y despliegue del
historial modificado
precondiciones Exista el rut del paciente, exista el historial
pos condiciones 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 Emitir_Receta(rut_paciente, datos receta

Responsabilidad Permite guardar los datos de la receta en el
historial y los
pone a disposición para imprimirlos con
posterioridad
Tipo Sistema
Caso de Uso Emitir Receta
Notas
Excepciones Rut del paciente no existe o esta errado, no
existen datos
salida Confirmación de que los datos fueron guardados
precondiciones Rut y datos existan
pos condiciones Datos guardados y disponibles para imprimir.
Página 109
Tabla 26 Casos de uso para el sistema _Imprimir Receta
Nombre Imprimir_Receta(rut_paciente, datos receta)

Responsabilidad Permite imprimir la receta.
Tipo Sistema
Notas
Excepciones No existe datos registrados en el historial solo los
básicos
salida Confirmación de la eliminación exitosa y
despliegue del
historial modificado
precondiciones Que exista la receta (este emitida)
pos condiciones 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 atención de pacientes.
Tipo Sistema
Caso de Uso Fijar Horario Disponible
Notas
Excepciones Rut médico no valido o no existe, no se eligió
horario
salida Una tabla con las fechas y horas disponibles
precondiciones Exista el rut del médico, y los datos de los
horarios
pos condiciones : Horario fijado guardado el la base de datos.
Tabla 28 Casos de uso para el sistema _Resultado Examen
Página 110
Nombre Ingresar_Resultado_Examen( rut_paciente,

nombre_examen,
tipo_examen, fecha_examen, resultado)
Responsabilidad Ingresa los resultados de los exámenes emitidos

por el laboratorio interno.
Tipo Sistema
Caso de Uso Ingresar Resultado Examen
Notas
Excepciones Los resultados no son válidos, el Rut del paciente
no existe o
es errado
precondiciones Datos guardados en base de datos y el historial.
pos condiciones : 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 Ingresa la solicitud de examen

Tipo Sistema
Caso de Uso Ingresar Examen solicitado
Notas
Excepciones El rut del paciente no es válido o no existe, el
nombre del examen es no valido.

precondiciones Rut existe y nombre examen existe
pos condiciones Los datos se encuentran guardados en la base
de datos.
Página 111
Capítulo 8 Modelo de Diseño
8.1. Estrategias de Diseño
Consulta Historial Medico
Imagen 29 Estrategias de Diseño_Diagrama Consulta Historial Medico
Página 112
Imagen 30 Estrategias de Diseño_Diagrama Ingresar Paciente Accidentado
Diagrama Consulta hora atención paciente
Imagen 31 Estrategias de Diseño_Diagrama Consulta hora atención paciente
Ingresar Examen solicitado
Página 113
Imagen 32 Estrategias de Diseño_Diagrama Ingresar Examen solicitado
Imagen 33 Estrategias de Diseño_Diagrama Ingresar Resultado Examen
Página 114
8.2. Diseño de Objetos
Para un buen diseño de objetos se debe pensar en términos 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 interacción de estos objetos para la resolución del
problema identificado en el análisis orientado a objetos.
Un objeto contiene toda la información que permite definirlo e identificarlo, dispone
de mecanismos de interacción que ayudan a la comunicación entre objetos, estos son
como unidades invisibles en las que no se separan información y procesamiento.
Continuando con el proceso de diseño se debe determinar las clases, atributos y
asociaciones del modelo de análisis, aunque también se pueden modificar o eliminar
clases.
Para el diseño de un objeto se sigue el diseño por responsabilidades con el modelo
cliente – servidor donde las clases pueden ser de ambos tipos dependiendo si generan
una petición (Cliente) o reciben una petición (Servidor).
Paquetes del Dominio
Imagen 34 Diseño Paquetes del Dominio
Paquete del Recepcionista
Página 115
Imagen 35 Diseño Paquete del Recepcionista
Paquetes de Secretaria
Imagen 36 diseño Paquetes de Secretaria
Paquete de Funcionario_Clinica_Externa
Imagen 37 Diseño Paquete de Funcionario_Clinica_Externa
Paquete de Medico
Imagen 38 Diseño Paquete de Medico
Paquete de Laboratorio Clínico
Página 116
Imagen 39 Diseño Paquete de Laboratorio Clínico
Paquete ACOS
Imagen 40 Diseño Paquete ACOS
8.3. Diseño de Sistema
Imagen 41 Diseño del sistema

La aplicación posee una arquitectura cliente-servidor de tipo cliente delgado, el cual
consta de tres capas, contiene código de presentación, código de procesamiento de
datos y código de almacenamiento de datos.
Capa de Presentación
Página 117
Los servicios de presentación proporcionan la interfaz necesaria para presentar

información y reunir datos. También aseguran los servicios de negocio necesarios para
ofrecer las operaciones requeridas e integran al usuario con la aplicación para ejecutar
un proceso de negocio.
Los servicios de presentación generalmente son identificados con la interfaz de

usuario, y normalmente residen en un programa ejecutable localizado en la estación de
trabajo del usuario final.
Se separa la programación que da acceso a los datos en las bases de datos y

aplicaciones desde el diseño y otros contenidos de la página Web. Esto ayuda a
asegurar que durante el proceso de desarrollo se pue da enfocarse en escribir la
aplicación en componentes sin preocuparse acerca de cómo se muestra la salida.
Recíprocamente, esto da libertad a los diseñadores de usar herramientas familiares
para modificar la interfaz.
La capa de servicios de presentación es responsable de:
 Obtener información del usuario (tipo usuario y clave).

 Obtener información de pacientes y/o médicos (horas médicas, fichas,
exámenes).
 Enviar la información del paciente y/o médico 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 interacción 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 aísla al usuario de la
interacción directa con la base de datos.
Capa de Datos
Página 118
El nivel de servicios de datos es responsable de:
 Almacenar los datos.

 Recuperar los datos.
 Mantener los datos.
 La integridad de los datos.
Página 119
8.4. Revisión del Diseño
Tabla 30 Revisión del diseño
Objetivo de información: Actividad:

“Registro paciente accidentado” Ingreso al sistema paciente
Atributos: accidentado
rut_paciente.
nombre Origen: Solicitud paciente.
empresa Agente: Recepcionista ACOS.
fecha_ingreso Precondiciones:
datos_accidente Poscondiciones:
Restricciones:
 Para cada ingreso de pacientes
 El rut de paciente es único para se ingresa al sistema de
el sistema, por lo que permitirá atención.
identificar completamente.
 El paciente está activo en el
 El accidentado es solo sistema hasta que se le dé el
ingresado al sistema por la alta.
recepcionista ACOS

Se puede atender en un bloque
 El paciente debe estar de horario con el médico
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
Página 120
Objetivo de información: Actividad: Asignación de hora de

“Atención Médico” atención.
Atributos: Origen: Solicitud paciente.
rut_paciente. Agente: Secretaria Departamento
nombre médico Clínico.
fecha
hora Precondiciones:
 El paciente debe haber sido
Restricciones: ingresado por la recepcionista
 El usuario debe haber sido 
ingresado al sistema de Poscondiciones:
atención.  El paciente pude ser atendido
 El paciente debe estar por el médico tratante.
registrado previamente en el  El pude seguir pidiendo horas
sistema. médico.
 El paciente tiene al menos  Se puede atender en un bloque
registrado su historial de de horario con el médico
enfermedades preexistentes, tratante.
como los medicamentos que no Caso de uso del sistema: Solicitar
pueden ser aplicados, así como hora atención paciente.
sus alergias. Actividad: El paciente es atendido
 El paciente para ser atendido por el médico.
debe solicitar hora. Origen: verifica si el paciente ha
Clase del dominio: Funcionario solicitado hora de atención que le
corresponde.
Agente:
Secretaría Departamento Clínico
Precondiciones:
 Existe disponibilidad de hora de
atención con el médico
tratante.
Pos condición: El paciente se le

solicitan exámenes.
 El paciente se le emite una
receta médica.
 El paciente es dado de alta
Caso de uso del sistema:
Página 121
Pendiente.
Actividad: Al paciente se le deben
realizar exámenes.
Origen: Solicita exámenes a
paciente.
Agente: Doctor.
Precondiciones:
 El doctor tiene una lista de
exámenes a solicitar al
paciente.
Poscondiciones:
Poscondiciones:
 El paciente obtiene el listado de

exámenes a realizar.
Caso de uso del sistema: Solicitar
exámenes.
Actividad: El doctor emite receta.
Origen: verifica si el paciente tiene
alguna contraindicación de algún
medicamento.
Agente: Doctor
Precondiciones:
 El doctor tiene una lista
medicamentos a recetar al
paciente.
Poscondición:
 El paciente se le indican los
medicamentos a tomar.
receta médica.
Caso de uso del sistema: Emitir
receta.
Página 122
Actividad: El doctor actualiza el

historial médico del paciente.
Origen: verifica el historial médico
del paciente para ser actualizado
Agente: Doctor
Precondiciones:
 El doctor tiene una lista de los
exámenes solicitado al
paciente
Poscondición:
 Se ha actualizado el historial
clínico del paciente
 El sistema está listo para
ingresar más actualizaciones
del historial clínico de los
pacientes.
Cambiar Historial Paciente.

“Exámenes hechos al paciente” Ingreso examen al Laboratorio.
rut_paciente. Agente: Laboratorio Clínico.
nombre_examen
tipo_de_examen Precondiciones:
fecha_examen  El doctor debe haber emitido
resultado una lista de exámenes.
Restricciones: ingresado por la recepcionista
 El rut de paciente es único para ACOS.
el sistema, por lo que permitirá
identificar completamente. Poscondiciones:
 El accidentado es solo  Los exámenes son ingresados
ingresado al sistema por la al sistema de atención
recepcionista ACOS paciente.
 El paciente debe estar  El médico tiene acceso al
resultado de los exámenes por
Página 123
ingresado previamente en el medio del historial clínico del

sistema. paciente
 El sistema de atención contiene Caso de uso del sistema: Ingresar
todos los exámenes hechos a examen solicitado.
los pacientes. Actividad: Ingreso resultado de
exámenes al sistema.
Clase del dominio: Laboratorio Origen: Verifica si existen
Clínico. exámenes hechos al paciente.
Agente: Laboratorio Clínico.
Precondiciones:
 Los exámenes del paciente
debe haber sido ingresado al
laboratorio.
Poscondiciones:
 El médico tiene acceso al
medio del historial clínico del
paciente.
 Se actualiza el historial Clínico
del paciente.
Caso de uso del sistema: Ingresar
Resultado exámenes.
Objetivo de información: Actividad: Solicitud al sistema

“Solicita historial de paciente paciente Historial clínico de paciente
clínica externa” .
Atributos: Origen: Se verifica que el paciente
rut_paciente. Solicitado este registrado en el
id_clinica sistema.
clave Agente: Clínica externa atención.
Restricciones:
 El rut de paciente es único para Precondiciones:
el sistema, por lo que permitirá  El paciente tiene un historial
identificar completamente. clínico
 El paciente debe estar Poscondiciones:
ingresado previamente en el  El sistema está listo para una
sistema. nueva consulta.
 El paciente tiene al menos Caso de uso del sistema:
Página 124
registrado su historial de Solicitud historial paciente.

enfermedades preexistentes,
como los medicamentos que no
sus alergias.

 La clínica externa está
registrada en el sistema.

Clase del dominio:
Clinica_Externa
8.5. Diagrama de Secuencia del Diseño
Solicitar Historial del Paciente
Imagen 42 Secuencia de diseño Historial del paciente
Página 125
Imagen 43 Secuencia de diseño Ingresar Datos Paciente Accidentado
Consulta Hora Atención Paciente
Imagen 44 Secuencia de diseño Consulta Hora pedida Atención Paciente
Consulta Hora pedida disponible Paciente
Imagen 45 Secuencia de diseño Consulta Hora Disponible Atención Paciente
Página 126
Solicitar Hora Atención Paciente
Imagen 46 Secuencia de diseño Solicitud hora de atención
Agregar Exámenes
Imagen 47 Secuencia de diseño Agregar exámenes
Eliminar Reserva Hora
Imagen 48 Secuencia de diseño Eliminar reserva hora
Página 127
Emitir Exámenes
Imagen 49 Secuencia de diseño Emitir exámenes
Imagen 50 Secuencia de diseño Cambiar historial paciente
Imagen 51 Secuencia de diseño Cambiar historial
Emitir paciente Receta
Página 128
Imagen 52 Secuencia de diseño Emitir receta
Fijar Horario Disponible
Imagen 53 Secuencia de diseño Fijar hora disponible
Imagen 54 Secuencia de diseño Ingresar resultado examen
Ingresar Examen Solicitado
Imagen 55 Secuencia de diseño Ingresar examen solicitado
Página 129
Capítulo 9 Modelo de Diseño
9.1. Programación en java
Página 130
Tabla 31 Clases del dominio funcionario
Página 131

fecha
hora Precondiciones:

ingresado por la recepcionista
Restricciones:

Poscondiciones:
 El usuario debe haber sido

 El paciente pude ser atendido por
el médico tratante.
ingresado al sistema de atención.
 El paciente debe estar registrado
 El pude seguir pidiendo horas
médico.
previamente en el sistema.
 El paciente tiene al menos
 Se puede atender en un bloque de
horario con el médico tratante.
registrado su historial de
enfermedades preexistentes, como los
medicamentos que no pueden ser
hora atención paciente.
aplicados, así como sus alergias.
 El paciente para ser atendido debe Actividad: El paciente es atendido por
solicitar hora.
Clase del dominio: Funcionario el médico.
Origen: verifica si el paciente ha
solicitado hora de atención que le
corresponde.
Agente:
Precondiciones:

atención con el médico tratante.
Poscondición: El paciente se le
solicita exámenes.
 El paciente se le emite una receta

médica.
Caso de uso del sistema: Pendiente.
Página 132
realizar exámenes.
Origen: Solicita exámenes a paciente.

Objetivo de información:
“Registro paciente accidentado”
Atributos:
Actividad:
rut_paciente.
Ingreso al sistema paciente
nombre
accidentado
empresa
fecha_ingreso
Origen: Solicitud paciente.
datos_accidente
Agente: Recepcionista ACOS.
Restricciones:
Precondiciones:
 El rut de paciente es único para el Poscondiciones:
sistema, por lo que permitirá identificar
completamente.
 Para cada ingreso de pacientes se
 El accidentado es solo ingresado al ingresa al sistema de atención.
sistema por la recepcionista ACOS
 El paciente está activo en el
 El paciente debe estar ingresado sistema hasta que se le dé el alta.
 Se puede atender en un bloque de
 El paciente tiene al menos horario con el médico tratante.
registrado su historial de enfermedades Caso de uso del sistema:
preexistentes, como los medicamentos
que no pueden ser aplicados, así como sus Ingresa datos paciente accidentado.
alergias.
Clase del dominio: Funcionario
Página 133
fecha
hora Preconiciones:

Restricciones: 
Poscondiciones:
 El usuario debe haber sido
ingresado al sistema de atención.  El paciente pude ser atendido por
 El paciente debe estar registrado el médico tratante.
previamente en el sistema.  El pude seguir pidiendo horas
 El paciente tiene al menos médico.
registrado su historial de  Se puede atender en un bloque
enfermedades preexistentes, de horario con el médico
como los medicamentos que no tratante.
pueden ser aplicados, así como Caso de uso del sistema: Solicitar
sus alergias.
 El paciente para ser atendido hora atención paciente.
debe solicitar hora.
Clase del dominio:Funcionario Actividad: El paciente es atendido
por el médico.
Origen: verifica si el paciente ha
solicitado hora de atención que le
corresponde.
Agente:
Precondiciones:

atención con el médico tratante.
Poscondición: El paciente se le
solicitan exámenes.

receta médica.
Pendiente.
Página 134
realizar exámenes.
Origen: Solicita exámenes a
paciente.
Agente: Doctor.
Precondiciones:
 El doctor tiene una lista de

exámenes a solicitar al paciente.
Poscondiciones:
Poscondiciones:
 El paciente obtiene el listado de

exámenes a realizar.
exámenes.
Actividad: El doctor emite receta.
Origen: verifica si el paciente tiene
alguna contraindicación de algún
medicamento.
Agente: Doctor
Precondiciones:
 El doctor tiene una lista

medicamentos a recetar al
paciente.
Poscondición:
 El paciente se le indican los

medicamentos a tomar.
receta médica.
Caso de uso del sistema: Emitir
Página 135
receta.
Actividad: El doctor actualiza el
historial médico del paciente.
Origen: verifica el historial médico
del paciente para ser actualizado
Agente: Doctor
Precondiciones:
 El doctor tiene una lista de los

exámenes solicitado al paciente
Poscondición:
 Se ha actualizado el historial
clínico del paciente
 El sistema está listo para
ingresar más actualizaciones del
historial clínico de los pacientes.
Caso de uso del sistema: Cambiar
Historial Paciente.
“Exámenes hechos al paciente” Ingreso examen al Laboratorio.
rut_paciente. Agente: Laboratorio Clínico.
nombre_examen
tipo_de_examen Precondiciones:
fecha_examen  El doctor debe haber emitido una

lista de exámenes.
resultado  El paciente debe haber sido
ACOS.
Página 136
Restricciones: Poscondiciones:
 El rut de paciente es único para 

Los exámenes son ingresados al
el sistema, por lo que permitirá sistema de atención paciente.
identificar completamente.  El médico tiene acceso al
 El accidentado es solo ingresado resultado de los exámenes por
al sistema por la recepcionista medio del historial clínico del
ACOS paciente
 El paciente debe estar ingresado Caso de uso del sistema: Ingresar
 El sistema de atención contiene examen solicitado.
todos los exámenes hechos a los
pacientes. Actividad: Ingreso resultado de
exámenes al sistema.
Clase del dominio: Laboratorio
Origen: Verifica si existen exámenes
Clínico.
hechos al paciente.
Agente: Laboratorio Clínico.
Precondiciones:

Los exámenes del paciente debe
haber sido ingresado al
laboratorio.
Poscondiciones:

El médico tiene acceso al
medio del historial clínico del
paciente.
 Se actualiza el historial Clínico
del paciente.
Caso de uso del sistema: Ingresar
Resultado exámenes.
Objetivo de información: Actividad:Solicitud al sistema
“Solicita historial de paciente paciente Historial clínico de paciente
clínica externa” .
Atributos: Origen: Se verifica que el paciente
rut_paciente. Solicitado este registrado en el
Página 137
id_clinica sistema.
clave Agente: Clínica externa atención.
Restricciones:
 El rut de paciente es único para Precondiciones:

el sistema, por lo que permitirá
identificar completamente.  El paciente tiene un historial
 El paciente debe estar ingresado clínico
previamente en el sistema. Poscondiciones:
 El paciente tiene al menos
registrado su historial de  El sistema está listo para una
enfermedades preexistentes, nueva consulta.
como los medicamentos que no Caso de uso del sistema: Solicitud
sus alergias. historial paciente.
 La clínica externa está registrada
en el sistema.

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/Orígenes de datos ODBC.
dBASE Files y agregar
Página 138
Imagen 56 Administrador de origenes de datos
Después 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
Página 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
Página 140
Imagen 60 Configuracion de ODBC
Imagen 61 Administrador de origenes de datos ODBC
Página 141
9.2. Diagrama de clases
Interaccion del sistema
Imagen 62 Interacción del sistema

Capítulo 10 Modelo de Prueba
10.1. Definición de conceptos
Página 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
información de los mismos.
Se presenta información general relacionada con cada área involucrada en la

atención 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 serán de verificación y validación, 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 cumpliría
las expectativas requeridas por el usuario:
Ingresar paciente, Tratamiento del paciente, Gestionar Citas médicas, Alta Paciente
Requisitos de Interfaces:
Interfaces de Usuario, Hardware, Comunicación, Rendimiento, Desarrollo,

Tecnológicos
TÉCNICA DE PRUEBAS
Para este modelo la técnica de pruebas a implementar será:
Prueba de Casos de Uso: se probara por medio de modelos de casos de uso como
por ejemplo
Página 143
Descripción de los casos de uso esenciales del sistema atención pacientes en el cual
se describirán las distintas actividades que son posibles realizar por el sistema para los
distintos actores.
PROCESO DE PRUEBAS
Página 144
Se considera tomar como estrategia de prueba el Orden de Pruebas lo que nos

refiere a los diagramas de secuencia del diseño, esto nos ayudara a definir en qué
momento y en qué orden se aplicaran las pruebas:
A su vez esto aplica también a las técnicas de pruebas como guía para las pruebas
de Casos de Uso.
Página 145
Capítulo 11 Conclusiones
 A través 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
 Descripción y reconocimiento de los actores involucrados en un ejemplo práctico

para el desarrollo de una solución de software.
Página 146
Capítulo 12 Recomendaciones
 Como se expone al inicio de este trabajo, se brinda una breve orientación para el
desarrollo de software con la Programación Orientada a Objetos, no se busca
implementar esta guía si no al contrario se da un abrebocas para que el lector se
pueda orientar.
 Se recomienda utilizar muchas más fuentes de información que puedan aclarar

temas o que su limitación sea más amplia que la que se ofrece.
 Se debe aplicar este conocimiento brindado en la práctica, es decir realizar

varios ejercicios donde se aplique el conocimiento adquirido en la teoría.
Página 147
Capítulo 13 Bibliografía
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, Ingeniería 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.
Pérez Menor, J. Carretero Pérez, F.
García Carballeira, & J. M. Pérez Lobato, Problemas resueltos de

programación 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
Página 148
Página 149

Trabajo Teoorico Final 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Teoorico Final 1

Cargado por

Copyright:

Formatos disponibles

Título del Proyecto de Investigación

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Richard Alexander Muñoz Castro

Elkin David Aguilar Llanos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Capítulo 4 Marco Teórico............................................................................................

Capítulo 6 Modelo de Requisitos.................................................................................

6.1. Descripción 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

Capítulo 7 Modelo de Análisis......................................................................................

7.1. Arquitectura de clases.......................................................................................29

7.2. Identificación de clases según Estereotipos..................................................32

7.3. Clases según casos de Uso.....................................................................................33

7.4. Diagramas de Secuencia..................................................................................34

7.5. Casos de uso para el sistema..........................................................................39

8.1. Estrategias de Diseño.......................................................................................50

8.2. Diseño de Objetos..............................................................................................52

8.3. Diseño de Sistema.............................................................................................55

8.4. Revisión del Diseño...........................................................................................57

8.5. Diagrama de Secuencia del Diseño................................................................62

Capítulo 9 Modelo de Diseño.......................................................................................

9.1. Programación en java........................................................................................68

9.2. Diagrama de clases..........................................................................................80

10.1. Definición de conceptos..................................................................................81

10.1. Tipo de pruebas................................................................................................81

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

Tabla 2 Modelo de requisitos Agregar exámenes....................................................16

Tabla 3 Modelo de requisitos Emitir exámenes........................................................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 exámenes....................................................20

Tabla 7 Modelo de requisitos Emitir receta...............................................................21

Tabla 8 Modelo de requisitos Fijar horario disponible.............................................22

Tabla 9 Modelo de requisitos Ingresar exámenes solicitados................................23

Tabla 10 Modelo de requisitos Ingresar resultados exámenes..............................24

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 exámenes....................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 Exámenes...............................44

Tabla 21 Casos de uso para el sistema _Eliminar Hora.........................................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 Revisión del diseño.......................................................................................57

Tabla 31 Clases del dominio funcionario...................................................................68

Tabla 32 Clases del dominio funcionario...................................................................71

Tabla 33 Clases del dominio funcionario...................................................................72

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

Imagen 2 Interfaz de usuario.......................................................................................26

Imagen 3 Interfaz Ficha médica (Medico o doctor)..................................................26

Imagen 4 Interfaz Pedir horas Medicas (Secretaria)...............................................26