LENGUAJE DE MODELADO

ESTUDIANTE:

PAULO CÉSAR OSPINA LOZANO

UNIVERSIDAD SANTO TOMÁS

CIENCIAS Y TECNOLOGÍA

INGENIERÍA EN INFORMÁTICA

CENTRO DE ATENCIÓN UNIVERSITARIA CALI

SANTIAGO DE CALI, JUNIO 06 DE 2015

LENGUAJE DE MODELADO

EVALUACION DISTANCIA

ESTUDIANTE:

PAULO CÉSAR OSPINA LOZANO

DOCENTE:

LUIS ALFONSO BARRIOS

UNIVERSIDAD SANTO TOMÁS

CIENCIAS Y TECNOLOGÍA

INGENIERÍA EN INFORMÁTICA

CENTRO DE ATENCIÓN UNIVERSITARIA CALI

SANTIAGO DE CALI, JUNIO 06 DE 2015

Tabla de contenido

Introducción..................................................................................................1

Objetivos.......................................................................................................2

- Objetivo General:.................................................................................2

- Objetivos Específicos:..........................................................................2

Clínica Veterinaria........................................................................................3

Lista de Requerimientos Funcionales........................................................4

Descripción Detallada de Los Casos de Uso..............................................5

Caso de Uso RF01..................................................................................5

Caso de Uso RF02..................................................................................7

Caso de Uso RF03..................................................................................9

Caso de Uso RF04................................................................................11

Caso de Uso RF05................................................................................12

Caso de Uso RF06................................................................................13

Caso de Uso RF07................................................................................14

Diagramas...............................................................................................16

Diagrama de Dominio:.........................................................................16

Diagrama Casos de Uso:......................................................................16

Diagrama Proceso de Negocio:............................................................17

Conclusiones...............................................................................................18

Bibliografía.................................................................................................19

Anexos........................................................................................................20

Introducción

El presente trabajo se basa en Lenguaje de Modelado y su importancia dentro del desarrollo de software. Por medio de este proceso, se pretende mostrar de manera detallada como a través del Modelado, los desarrolladores de aplicaciones establecen requerimientos Funcionales y No Funcionales exponiendo los requisitos base para que el sistema se comporte de acuerdo a las expectativas del cliente.

Es así que por medio de una documentación clara y una arquitectura bien definida, el equipo de trabajo es capaz de cumplir con un proyecto dentro de los márgenes de tiempos y costos establecidos. .

1

Objetivos

- Objetivo General:

Por medio del presente trabajo se pretende familiarizar con los principales conceptos del Lenguaje de Modelado y así brindar un punto inicial para llevar a cabo de manera organizada y exitosa el diseño y planeación de un proyecto de desarrollo de Software.

- Objetivos Específicos:

1. Aprender las metodologías para la modelado de los requerimientos de acuerdo a las necesidades de la empresa.

2. Conocer las actividades que componen la gestión de Diseño.3. Familiarizarse con los objetivos de la Modelación de Requerimientos. 4. Manejar los principales conceptos asociados a las técnicas para la

organización, dirección y control del proceso de desarrollo por medio de requerimientos funcionales y no funcionales.

-

2

Clínica Veterinaria.

Aplicar el material de apoyo y la asistencia a tutoría para realizar los siguientesDiagramas de un contexto real de trabajo para definir:

Modelo de Negocio: Diagramas de Proceso Modelo de Requisitos: Modelo de Dominio Modelo de Análisis: Diagramas de Secuencia, de Contratos,

Colaboración, Clases

Los modelos se deben presentar en un informe utilizando diversos software para el Diseño de dichos diagramas como edraw, cacoo, mindomo, argouml, visio, etc.Trabajados en las tutorías presenciales de formación.

EJEMPLO DE CONTEXTO:

Un veterinario tiene como pacientes animales y como clientes familias. Un cliente es un conjunto de personas que suele corresponderse con una familia. Cada cliente tiene un código, el primer apellido del cabeza de familia, un número de cuenta bancaria, una dirección, un teléfono y los nombres y NIF de las personas correspondientes. No existe límite en el número de personas asociadas a una entidad cliente. Además, una persona puede estar dada de alta en varios clientes (por ejemplo, un hombre que vive con su esposa tiene un gato y como tal pertenece a un cliente, pero también está dado de alta en el cliente asociado con el perro de sus padres).Los clientes pueden tener varias mascotas, cada mascota tiene un código, un alias, una especie, una raza, color de pelo, fecha de nacimiento aproximada, peso medio del animal en las últimas 10 visitas y el peso actual del animal. Asimismo se guardará un historial médico con cada enfermedad que tuvo y la fecha en la que enfermó. Adicionalmente cada mascota tiene un calendario de vacunación, en el que se registrará la fecha de cada vacuna, la enfermedad de la que se vacuna.

3

Lista de Requerimientos Funcionales

Código Requerimiento Caso de Uso AutorRF01 El sistema de permitir al

Veterinario mantener los datos relacionados con los Clientes.

Mantener datos de los Clientes (Añadir, Modificar, Eliminar)

Veterinario

RF02 El sistema de permitir al Veterinario mantener los datos relacionados con las Personas.

Mantener datos de las Personas (Añadir, Modificar, Eliminar)

Veterinario

RF03 El sistema de permitir al Veterinario mantener los datos relacionados con los Pacientes.

Mantener datos de los Pacientes (Añadir, Modificar, Eliminar)

Veterinario

RF04 El Sistema debe permitir Registrar las visitas de los pacientes en historia clínica incluyendo la fecha y enfermedad atendida.

Registrar Visitas de los Pacientes.

Veterinario

RF05 El sistema debe permitir registrar en Calendario de Vacunación la fecha y enfermedad de la Vacuna aplicada al paciente.

Registrar las vacunas de los pacientes.

Veterinario

RF06 El sistema debe permitir Consulta Historia Veterinario

4

consultar la historia clínica con cada enfermedad y visita del paciente.

Clínica del Paciente

RF07 El sistema debe permitir consultar el Calendario de Vacunación la fecha y enfermedad de la Vacuna aplicada al paciente.

Consulta Historia Vacunas del Paciente

Veterinario

5

Descripción Detallada de Los Casos de Uso

Caso de Uso RF01

Caso de Uso: Mantener datos de los Clientes (Añadir, Modificar, Eliminar)

Actor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion: Se ha agregado en el sistema los datos del cliente, es

decir que se ha añadido, modificado o eliminado un registro existente.

Flujo de Eventos:

Flujo Básico – Añadir:

1. El caso de uso comienza cuando el Veterinario indica que desea añadir.

2. El sistema muestra un formulario vacío para diligenciar los datos asociados al cliente.

3. El Veterinario Ingresa los datos del Cliente: Código, Apellido, Cuenta Bancaria, Dirección, Teléfono, NIF y Nombre de las Personas.

4. Veterinario Indica Guardar.5. El Sistema valida datos ingresados.6. El Sistema guarda nuevo registro.7. Caso de Uso finaliza.

Flujo Básico – Modificar:

1. El caso de uso comienza cuando el Veterinario indica que desea Modificar.

2. El sistema solicita código del cliente a modificar.3. Veterinario Ingresa el código del cliente a modificar.4. El Sistema muestra formulario con los datos del cliente.5. Veterinario modifica los datos del cliente.6. Veterinario indica Guardar.7. El sistema valida los datos.

6

8. El Sistema guarda la modificación.9. Caso de uso finaliza.

Flujo Básico – Eliminar:

1. El caso de uso comienza cuando el Veterinario indica que desea Eliminar.

2. El sistema solicita el código del cliente a Eliminar.3. Veterinario ingresa el código de cliente cuyos datos eliminara.4. El sistema muestra formulario con los datos del cliente a eliminar.5. Veterinario Indica Eliminar.6. El sistema solicita confirmación.7. Veterinario confirma eliminación del cliente.8. El sistema registra la eliminación del cliente.9. El Caso de uso finaliza.

Flujo de Eventos Alternativos:

Datos Incorrectos:

1. En el Paso 5 del Flujo básico de añadir o en el paso 7 de Modificar, si el sistema encuentra error en algún tipo de dato, mostrará mensaje de error y solicitara rectificar la información.

Registro ya Existente:

1. En el Paso 5 del Flujo básico de añadir, si el sistema encuentra que el registro ya existe, mostrará mensaje de error y solicitara de nuevo Código de Cliente.

Registro Inexistente:

1. En el Paso 4 del Flujo básico de modificar o en el paso 4 de Eliminar, si el sistema no encuentra el código de cliente, mostrará mensaje de error y solicitara de nuevo Código de Cliente.

7

Cancelar:

1. En cualquier instancia, si el Veterinario indica Cancelar, el sistema limpia el formulario y el caso de uso finaliza.

8

Caso de Uso RF02

Caso de Uso: Mantener datos de las Personas (Añadir, Modificar, Eliminar)

Actor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion: Se ha agregado en el sistema los datos de la persona,

es decir que se ha añadido, modificado o eliminado un registro existente.

Flujo de Eventos:

Flujo Básico – Añadir:

1. El caso de uso comienza cuando el Veterinario indica que desea añadir.

2. El sistema muestra un formulario vacío para diligenciar los datos asociados a la Persona.

3. El Veterinario Ingresa los datos de la Persona: NIF y Nombre de la Persona.

4. Veterinario Indica Guardar.5. El Sistema valida datos ingresados.6. El Sistema guarda nuevo registro.7. Caso de Uso finaliza.

Flujo Básico – Modificar:

1. El caso de uso comienza cuando el Veterinario indica que desea Modificar.

2. El sistema solicita el NIF de la Persona a modificar.3. Veterinario Ingresa el NIF de la Persona a modificar.4. El Sistema muestra formulario con los datos de la Persona.5. Veterinario modifica los datos de la Persona.6. Veterinario indica Guardar.7. El sistema valida los datos.8. El Sistema guarda la modificación.9. Caso de uso finaliza.

9

Flujo Básico – Eliminar:

1. El caso de uso comienza cuando el Veterinario indica que desea Eliminar.

2. El sistema solicita el NIF de la Persona a Eliminar.3. Veterinario ingresa el NIF de la Persona cuyos datos eliminara.4. El sistema muestra formulario con los datos de la Persona a eliminar.5. Veterinario Indica Eliminar.6. El sistema solicita confirmación.7. Veterinario confirma eliminación de la Persona.8. El sistema registra la eliminación de la persona.9. El Caso de uso finaliza.

Flujo de Eventos Alternativos:

Datos Incorrectos:

1. En el Paso 5 del Flujo básico de añadir o en el paso 7 de Modificar, si el sistema encuentra error en algún tipo de dato, mostrará mensaje de error y solicitara rectificar la información.

Registro ya Existente:

1. En el Paso 5 del Flujo básico de añadir, si el sistema encuentra que el registro ya existe, mostrará mensaje de error y solicitara de nuevo NIF de la Persona.

Registro Inexistente:

1. En el Paso 4 del Flujo básico de modificar o en el paso 4 de Eliminar, si el sistema no encuentra el NIF de la Persona, mostrará mensaje de error y solicitara de nuevo el NIF de la Persona.

Cancelar:

1. En cualquier instancia, si el Veterinario indica Cancelar, el sistema limpia el formulario y el caso de uso finaliza.

10

11

Caso de Uso RF03

Caso de Uso: Mantener datos de los Pacientes (Añadir, Modificar, Eliminar)

Actor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion: Se ha agregado en el sistema los datos del paciente, es

decir que se ha añadido, modificado o eliminado un registro existente.

Flujo de Eventos:

Flujo Básico – Añadir:

1. El caso de uso comienza cuando el Veterinario indica que desea añadir.

2. El sistema muestra un formulario vacío para diligenciar los datos asociados al paciente.

3. El Veterinario Ingresa los datos del Paciente: Código, Especie, Alias, Raza, Color de Pelo, Fecha de Nacimiento, Peso Actual.

4. Veterinario Indica Guardar.5. El Sistema valida datos ingresados.6. El Sistema guarda nuevo registro.7. Caso de Uso finaliza.

Flujo Básico – Modificar:

1. El caso de uso comienza cuando el Veterinario indica que desea Modificar.

2. El sistema solicita el Código del Paciente a modificar.3. Veterinario Ingresa el Código del Paciente a modificar.4. El Sistema muestra formulario con los datos del Paciente.5. Veterinario modifica los datos del Paciente.6. Veterinario indica Guardar.7. El sistema valida los datos.8. El Sistema guarda la modificación.9. Caso de uso finaliza.

12

Flujo Básico – Eliminar:

1. El caso de uso comienza cuando el Veterinario indica que desea Eliminar.

2. El sistema solicita el Código del Paciente a Eliminar.3. Veterinario ingresa el Código del Paciente cuyos datos eliminara.4. El sistema muestra formulario con los datos del Paciente a eliminar.5. Veterinario Indica Eliminar.6. El sistema solicita confirmación.7. Veterinario confirma eliminación del Paciente.8. El sistema registra la eliminación del Paciente.9. El Caso de uso finaliza.

Flujo de Eventos Alternativos:

Datos Incorrectos:

1. En el Paso 5 del Flujo básico de añadir o en el paso 7 de Modificar, si el sistema encuentra error en algún tipo de dato, mostrará mensaje de error y solicitara rectificar la información.

Registro ya Existente:

1. En el Paso 5 del Flujo básico de añadir, si el sistema encuentra que el registro ya existe, mostrará mensaje de error y solicitara de nuevo el Código del Paciente.

Registro Inexistente:

1. En el Paso 4 del Flujo básico de modificar o en el paso 4 de Eliminar, si el sistema no encuentra el Código del Paciente, mostrará mensaje de error y solicitara de nuevo el Código del Paciente.

Cancelar:

1. En cualquier instancia, si el Veterinario indica Cancelar, el sistema limpia el formulario y el caso de uso finaliza.

13

14

Caso de Uso RF04

Caso de Uso: Registrar Visitas de los Pacientes.Actor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion:Flujo de Eventos:

1.2.3.4.

Flujo de Eventos Alternativos:

15

Caso de Uso RF05

Caso de Uso:Actor:Precondicion:Poscondicion:Flujo de Eventos:

1.2.3.4.

Flujo de Eventos Alternativos:

16

Caso de Uso RF06

Caso de Uso: Consulta Historia Clínica del PacienteActor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion: Se ha realizado la consulta de la historia clínica por

paciente.

Flujo de Eventos:

Flujo Básico – Consulta Historia Clínica del Paciente:

1. El caso de uso comienza cuando el Veterinario indica que desea Consultar la Historia Clínica por Paciente.

2. El sistema solicita el Código del Paciente a Consultar.3. Veterinario Ingresa el Código del Paciente a Consultar.4. El Sistema solicita Rango de Fechas.5. Veterinario selecciona Fecha Inicial y Fecha Final.6. Veterinario indica Consultar.7. El Sistema muestra las visitas realizadas por el paciente dentro del

rango de fechas ingresadas.8. Veterinario selecciona el registro de la visita del paciente.9. El sistema muestra formulario con la información del Paciente y la

enfermedad por la cual fue atendido.10. Caso de uso finaliza.

Flujo de Eventos Alternativos:

No Existen Visitas en el Rango de Fechas:

1. En el Paso 7 del Flujo básico, si el sistema no encuentra visitas del paciente en el rango de fechas, muestra mensaje de notificación y vuelve a solicitar los datos de consulta.

Registro Inexistente:

1. En el Paso 7 del Flujo básico, si el sistema no encuentra el Código del

17

Paciente, mostrará mensaje de error y solicitara de nuevo el Código del Paciente.

Cancelar:

1. En cualquier instancia, si el Veterinario indica Cancelar, el sistema limpia el formulario y el caso de uso finaliza.

Caso de Uso RF07

Caso de Uso: Consulta Historia Vacunas del PacienteActor: VeterinarioPrecondicion: El usuario se ha autenticado en el sistema con el rol de

Veterinario.Poscondicion: Se ha realizado la consulta de la historia de vacunas

por paciente.

Flujo de Eventos:

1. El caso de uso comienza cuando el Veterinario indica que desea Consultar la Historia de Vacunas por Paciente.

2. El sistema solicita el Código del Paciente a Consultar.3. Veterinario Ingresa el Código del Paciente a Consultar.4. El Sistema solicita Rango de Fechas.5. Veterinario selecciona Fecha Inicial y Fecha Final.6. Veterinario indica Consultar.7. El Sistema Lista los registros de vacunación del paciente dentro del

rango de fechas ingresadas.8. Veterinario selecciona el registro de la visita del paciente a consultar.9. El sistema muestra formulario con la información del Paciente, las

vacunas suministradas y las enfermedades relacionadas..10. Caso de uso finaliza.

Flujo de Eventos Alternativos:

No Existen registro de Vacunas en el Rango de Fechas:

18

1. En el Paso 7 del Flujo básico, si el sistema no encuentra Registros de Vacunas del paciente en el rango de fechas, muestra mensaje de notificación y vuelve a solicitar los datos de consulta.

Registro Inexistente:

1. En el Paso 7 del Flujo básico, si el sistema no encuentra el Código del Paciente, mostrará mensaje de error y solicitara de nuevo el Código del Paciente.

Cancelar:

1. En cualquier instancia, si el Veterinario indica Cancelar, el sistema limpia el formulario y el caso de uso finaliza.

19

Diagramas

Diagrama de Dominio:

Diagrama Casos de Uso:

20

Diagrama Proceso de Negocio:

21

Conclusiones

El UML es una de las diversas metodologías que se pueden utilizar para el modelado relacional y tabular.

Los Lenguajes de Modelado permiten expresar en diagramas los sistemas o subsistemas a desarrollar.

El UML permite que diferentes colaboradores de un proyecto interpreten un diseño sin ambigüedades.

LA mayoría de las herramientas CASE y de Desarrollo han adaptado el UML como lenguaje de Modelado.

22

Bibliografía

Jacobson, Ivan; UML LENGUAJE DE MODELADO UNIFICADO, Addison Wesley, ISBN: 8478290281 ISBN-13: 9788478290284

23

AnexosUNIVERSIDAD SANTO TOMAS

VICERRECTORIA GENERAL DE UNIVERSIDAD ABIERTA Y A DISTANCIA

FACULTAD DE CIENCIAS Y TECNOLOGIASIngeniería en Informática – Administración de Sistemas

InformáticosELECTIVA PROFESIONAL IV - LENGUAJE DE MODELACIÓN

(código SAC 16840)PRÁCTICA

EVALUACIÓN DISTANCIA I-2015Nombre: ___________________________________ Cédula: __________

CAU:__________

INTRODUCCIÓNEste espacio académico busca la formación de un profesional en Ingeniería en Informática enun lenguaje estándar que visualiza, especifica, construye y documenta los elementos de unsistema software.OBJETIVOS DE LA EVALUACIÓNReconocer, diferenciar y aplicar los diferentes diagramas de comportamiento y estructura, a suvez los objetivos específicos son: Utilizar un software libre(ArgoUML) para modelar un sistema software Reconocer las diferentes notaciones de UML Aplicar diagramas de comportamiento Aplicar diagramas de estructuraVALORACIÓN DE LA ASIGNATURA1La evaluación presencial tiene un valor de 50%, la evaluación distancia tiene un valor de 50%.El supletorio vale 50%. La habilitación tiene un valor de 100%.Fragmento tomado del Reglamento Particular Estudiantil de Pregrado de la VUADFragmento tomado del Reglamento Particular Estudiantil de Pregrado de la VUAD (2013)(*). La Primera Actividad tiene una nota de 2.0 La Segunda Actividad tiene una nota de 1.0 La Tercera Actividad tiene una nota de 2.0

24

El trabajo de práctica o proyecto se debe ENTREGAR EN EL CAU en las fechas establecidasen el calendario académico para la evaluación de la asignatura.Por favor no hacer copiar literal de textos, páginas de la internet, etc. Si las respuestasson copiadas literalmente o parafraseadas de textos impresos o publicados en la red elpunto se anula.“Artículo 33. Evaluación total de las asignaturas. En los programas de la Facultad deCiencias y Tecnologías la evaluación total de una asignatura se obtendrá de la siguiente manera:

Asignaturas Teóricas. Tendrán evaluación presencial o Virtual con un valor del 50 % yevaluación distancia con un valor del 50%.- Asignaturas Teórico-Prácticas. Tendrán evaluación presencial o virtual con un valordel 50%, evaluación virtual que tiene un valor del 25% y evaluación práctica que tiene unvalor del 25%.- Asignaturas Prácticas. Tendrán una evaluación práctica con un valor del 100%.PARÁGRAFO. En las evaluaciones a distancia de las asignaturas teóricas y teóricoprácticas,así como en las asignaturas prácticas se tendrá en cuenta la participación en elforo virtual (5%) y en el Chat (5%); sin detrimento de las actividades de aprendizaje que elprograma determine deban hacer parte del proceso de evaluación total de las asignaturas.ARTÍCULO 37. Exámenes Supletorios. Los exámenes supletorios son evaluacionesaplicadas por la Universidad y autorizadas por los respectivos programas de la VUAD,previa solicitud debidamente justificada del estudiante, cuando éste no haya podidopresentar un examen en la fecha programada. Se deberá presentar la solicitud por escrito ala Secretaría Académica, a través del CAU, quince (15) días antes de la fecha establecidapara la presentación del respectivo examen supletorio, acompañada de la autorización quela fundamenta. Si el estudiante requiere un certificado de estudios antes de la fecha de

25

presentación del examen supletorio de la asignatura correspondiente, esta se consideracomo pendiente y así figurará en el certificado.La autorización de todo examen supletorio implica el pago del derecho fijado por laautoridad administrativa competente. La nota obtenida corresponde al 100% de laevaluación total de la asignatura de acuerdo con su naturaleza.Recuerde que: En el evento de presentación de examen supletorio, se hace necesario quehaga entrega de la evaluación distancia y evaluación práctica (según sean las condicionesde entrega: en el Aula Virtual o en forma escrita), el día de la presentación de dichoexamen.Artículo 42. Calificación. Las calificaciones de las asignaturas serán de 0.0 (cero puntocero) a 5.0 (cinco punto cero). Las calificaciones se expresan en unidades y décimas. Lanota mínima aprobatoria para cualquier asignatura será de 3.0 (tres punto cero),exceptuando el examen de suficiencia y validación que tendrá una nota mínima aprobatoriade 3.5 (tres punto cinco).”Habilitaciones: Ver normatividad en el Artículo 41 del Reglamento citado.(*) Tomado de: REGLAMENTO ESTUDIANTIL Versión digital final.pdf Octubre 24 de 2013.CRITERIOS DE EVALUACIÓN: Claridad y nivel de argumentación de cada una de las respuestas. Manejo y aplicación de los conocimientos básicos en el desarrollo de las actividadespropuestas. Aporte personal en cada uno de los puntos de la evaluación.BIBLIOGRAFÍA DE APOYOJacobson, Ivan; UML LENGUAJE DE MODELADO UNIFICADO, Addison Wesley, ISBN:8478290281 ISBN-13: 9788478290284

WEBGRAFÍA DE APOYO http://www.monografias.com/trabajos16/lenguaje-modelado-unificado/lenguaje-modeladounificado.shtml http://argouml.tigris.org/

26

ACTIVIDADES A REALIZAR

Aplicar el material de apoyo y la asistencia a tutoría para realizar los siguientesdiagramas de un contexto real de trabajo para definir: Modelo de Negocio: Diagramas de Proceso Modelo de Requisitos: Modelo de Dominio Modelo de Análisis: Diagramas de Secuencia, de Contratos, Colaboración, ClasesLos modelos se deben presentar en un informe utilizando diversos software para eldiseño de dichos diagramas como edraw, cacoo, mindomo, argouml, visio, etc.Trabajados en las tutorías presenciales de formación.

MATERIAL DE APOYO.EJEMPLO DE CONTEXTO.

Clínica Veterinaria.

Un veterinario tiene como pacientes animales y como clientes familias. Un cliente es un conjunto de personas que suele corresponderse con una familia. Cada cliente tiene un código, el primer apellido del cabeza de familia, un número de cuenta bancaria, una dirección, un teléfono y los nombres y NIF de las personas correspondientes. No existe límite en el número de personas asociadas a una entidad cliente. Además, una persona puede estar dada de alta en varios clientes (por ejemplo, un hombre que vive con su esposa tiene un gato y como tal pertenece a un cliente, pero también está dado de alta en el cliente asociado con el perro de sus padres).Los clientes pueden tener varias mascotas, cada mascota tiene un código, un alias, una especie, una raza, color de pelo, fecha de nacimiento aproximada, peso medio del animal en las últimas 10 visitas y el peso actual del animal. Asimismo se guardará un historial médico con cada enfermedad que tuvo y la fecha en la que enfermó. Adicionalmente cada mascota tiene un calendario de vacunación, en el que se registrará la fecha de cada vacuna, la enfermedad de la que se vacuna.

ACTIVIDADES A REALIZAR.

27

28