Unidad Ii - Interpretar Modelos Conceptuales - Parte I

Unidad II:
Elementos para Interpretar

Modelos Conceptuales de Datos
Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

¿Cómo Diseñar una BD?
Para diseñar una base de manera eficiente y correcta, primero debemos

saber que necesitamos llevar el orden de las siguientes fases:
Requerimiento de Información
Modelo Conceptual
Modelo Lógico
Modelo Físico
Implementación y Optimización

Requerimiento de Información
Lo primero que debes tener muy bien documentados son tus

requerimientos. Debes saber muy bien cuál es la necesidad que vas a resolver o
solucionar. Con los requerimientos podrás ir diseñando cada uno de los
componentes de tu aplicación. Generalmente, los requerimientos bien
documentados es el punto esencial que necesitas para comenzar a diseñar tu BD
Modelo Conceptual
Representa la fase inicial del desarrollo del diseño de los datos y el

almacenamiento de los mismos para el sistema y en muchos casos, los datos
permanentes para el sistema los gestiona un SGBD. La importancia de este modelado
radica, en que permite abstraer un problema e identificar como interactúa el sistema en
el cual se desenvuelve la solución. Al modelar un problema se identifica su
funcionamiento, y es realizado para solucionar problemas.

Modelo Lógico
En esta fase, partimos de los diagramas o modelos anteriores. Este
proceso es más utilizado por ser de manera tabular haciendo más rápido de
realizar y vemos resultados más rápidamente. En esta fase, debemos tocar
temas como NORMALIZACIÓN DE LA BASES DE DATOS y MODELOS
RELACIONALES para evitar duplicidad de información y para ahorrar
espacio de almacenamiento.
Esto último (ahorrar espacio) ya no es tan importante como hace algunos años, incluso hoy
en día hablamos de inteligencia de negocios, minería de datos, entre otros términos que nos
exigen eliminar la normalización, (de eso hablaremos más adelante y es conocido como BD
NoSQL o BD Relacionales).
Modelo Físico
En esta última fase dentro de los modelo, ya
debemos revisar a detalle los tipos de datos que
utilizaremos, sus dominios (qué valores va a permitir),
cuales índices debemos crear para optimizar las
consultas, entre otros. Aquí ya escribimos nuestro
CÓDIGO para plasmar todo nuestro diseño en el SGBD
elegido, el cual en este punto es muy importante.
Implementación y Optimización
Una vez diseñada la BD, sólo nos queda implementarla, a lo que nos referimos a la
ejecución de la misma con datos cargados para su manipulación, uso, y a medida que se usa
llevar a optimizarla. Para ello, te pueden resultar útiles las siguientes recomendaciones.
● No uses nombres
l a s en
Elim i na r ta b complejos en las
a ello
●
desuso, Par r los Evitar almacén de

claves y campos
miza de las tablas.
puedes opti edes
●
u imágenes,
índices así p na sólo referencias a la
¡Simplifica!
e
tener una bu ces ruta en la que se
Cuanto más
índi sencillos sean los
relación de ra las encuentran y
pa nombres, más
entre tablas ionales metadatos para
elac rápido se ejecuta la
búsquedas r en identificarlas. Así la
funcion consulta.
te. BD estará en forma
correctamen
para devolverte los
procesos mas
rápidamente

¿Cuales con las Abstracciones más Usadas en el Modelo Conceptual?
Clasificación Generalización
Representada en Define relaciones
clase (nodo padre) y Agregación de subconjuntos
subclases (nodos entre dos o más
Todos los nodos son
hijos), estableciendo clases, donde todos
clases y se crea una
criterios de son nodos
nueva clase
clasificación
generadora a través
de la asociación
Veamos un ejemplo, para entender mejor..!!

Ejemplo

¿Estrategias de Diseño de una BD?
En síntesis el diseño de una BD es un proceso complejo (dado que es

estructurado) el cual amerita que se desglose en partes o fases como pudimos
apreciar en la explicación anterior. Centrando la misma en la importancia de definir
MUY BIEN cada uno de los modelos que se desean diseñar.
Dentro de los MODELOS CONCEPTUALES estudiaremos los siguientes

modelos:
Orientadas a Objetos Lenguaje Unificado de Modelado

(UML en ingles)
Esquemas Conceptuales Modelo Entidad-Relación y Modelo

Relacionales Entidad-Relación-Extendido

Lenguaje Unificado de Modelado (UML en ingles)
Diagrama de Casos de Uso Diagrama de Clases
Están clasificado dentro del grupo de Es un diagrama puramente

diagramas de comportamiento, son orientado al modelo de
herramientas útiles para entender la programación orientado a objetos,
capacidad que tiene un sistema para permitiendo representar
satisfacer las necesidades de los gráficamente y de manera estática la
usuarios finales. Dicho de otra estructura general de un sistema,
manera, muestra de manera visual las mostrando cada una de las clases y
distintas funciones que puede realizar sus interacciones (como herencias,
un usuario (más bien un tipo de asociaciones, etc), es decir, visualiza
usuario) de un Sistema de las relaciones entre las clases que
Información involucran el sistema.
Estos también pueden ser eficaces a
los fines de marketing de productos

Es algo o alguien externo al sistema que interactúa de forma directa con
el sistema. Cuando decimos que interactúa nos referimos a que aporta
información, recibe información, inicia una acción. El nombre del actor
debe indicar claramente el papel del actor. Se representan con una imagen
de un “muñeco de palo” con el nombre del actor debajo.
Elementos Existen dos tipos de actores: Los usuarios, pero no

para Hacer hay que entender los usuarios como personas singulares,
un sino como “perfiles o roles” que identifican a un tipo de
usuario, pero no al usuario en sí. Y los sistemas que
Diagrama también interactúan con nuestro propio sistema.
de Casos de
Uso Actor
<<communicates>> Emitir Nómina
<<communicates>>
Firmar Nómina
Gestor de Nómina

Recomendaciones para Identificar Actores
Encontrar actores es uno de los primeros pasos para definir los casos de
uso del sistema. Las siguientes preguntas nos ayudarán a encontrar los actores
que interactuarán con el sistema:
¿Qué grupos de usuarios requieren ayuda

del sistema para realizar sus tareas?
¿Qué grupos de usuarios se necesitan para ejecutar

las funciones principales más obvias del sistema?
¿Qué grupos de usuarios están obligados a

realizar funciones secundarias, como el
mantenimiento y la administración del sistema?
¿El sistema interactuará con cualquier

hardware externo o sistema de software?
Cualquier individuo, grupo o fenómeno que se ajuste a una o más de estas

categorías es un candidato para un actor.

Se utiliza para representar cualquier acción que realice la

aplicación. Es una secuencia de acciones que hace el sistema y que
producen un resultado que puede percibir un usuario
Se representan con una elipse que incluye en

Casos de usos su interior el nombre del caso de uso
Elementos
para Hacer Formalmente hablando, un caso de uso es una clasificación
un de comportamiento que especifica una unidad de funcionalidad
Diagrama completa y que está realizada por uno o más sujetos que se
de Casos de relacionan con el caso de uso colaborando para ello con uno o
Uso más actores y que produce un resultado que tiene alguna utilidad
para cualquier de esos actores.
Imprimir factura
Crear pedido
Enviar correo

Recomendaciones para Identificar Casos de Usos
Los primeros casos de uso son muy preliminares, debe estar preparado para
agregar, eliminar, combinar y dividir los casos de uso antes de llegar a una versión
final. Si la visión o los requisitos del sistema son deficientes, o si el análisis del
sistema es impreciso, la funcionalidad del sistema no será clara.
La mejor forma es considerar lo que cada actor requiere del sistema. Cada
actor, sea humano o no, hay que hacer las siguientes preguntas:
¿Cuáles son las tareas principales que
el actor quiere que realice el sistema?
¿El actor creará, almacenará, cambiará,
eliminará o leerá datos en el sistema?
¿El actor realizará un arranque o
apagado del sistema?
¿El actor necesitará informar al sistema
sobre cambios repentinos y externos?
¿El actor necesita ser informado sobre
ciertas ocurrencias en el sistema?
Las respuestas a estas preguntas representan los flujos de eventos que
identifican casos de uso candidatos.
Se utiliza para representar todas las acciones o actividades que se

representan dentro del sistema o aplicación. Estos deben de estar
dentro de un recuadro especificando que son los movimientos internos
que dan vida al sistema.
Se representan con un cuadrado que

Elementos incluye en su interior todos los elementos
para Hacer menos los actores que estos son externos
un
Diagrama Limite del Sistema
de Casos de
Uso
Veamos un ejemplo

Relaciones
Las relaciones conectan los casos de uso con los actores o

los casos de uso entre sí.
Cuando conectan un actor con un caso de uso representa

Elementos que ese actor interactúa de alguna manera con ese caso de uso y
para Hacer se representa con una linea continua con la identificación
un <<communicates>>
Diagrama
de Casos de
Uso
<<communicates>>
Caso de Uso
Actor
Cuando conectan casos de uso entre sí se pueden diferenciar

dos tipos de relaciones: <<include>> y <<extends>>.
En español a veces se usa la nomenclatura <<usa>> y
<<extiende>>
Relaciones
<<include>>
Se utiliza para representar que un caso de uso utiliza siempre a otro
caso de uso. Es decir, un caso de uso se ejecutará obligatoriamente (lo
incluye, lo usa). Se representa con una flecha discontinua que va desde el
caso de uso de origen al caso de uso que se incluye
Elementos
para Hacer <<include>>
Caso de uso 1 Caso de uso 2
un
Diagrama
de Casos de Un uso típico de este tipo de relaciones se produce cuando dos casos
Uso de uso comparten una funcionalidad. Esa funcionalidad es extraída de los
dos y se crea un caso de uso nuevo que se relaciona con los anteriores
con un include
Emitir factura <<include>>
Autenticación
Enviar pedido <<include>>

Relaciones
<<extend>>
Este tipo de relaciones se utilizan cuando un caso de uso tiene un
comportamiento opcional, reflejado en otro caso de uso. Es decir, un
caso de uso puede ejecutar, normalmente dependiendo de alguna
condición o flujo del programa, otro caso de uso. Se representa con una
flecha discontinua que va desde el caso de uso opcional al original.
Elementos
para Hacer <<extend>>
un Caso de uso 1 Caso de uso 2
Diagrama
de Casos de
Uso Veamos un ejemplo
Enviar notificación
<<extend>> por SMS
Hacer pedido
Enviar notificación
<<extend>> por Email

Relaciones
<<Generalización>>
Consiste en hacer que un elemento herede el comportamiento
de otro. Aunque se puede utilizar entre casos de uso, es más común
utilizarlo entre actores, haciendo que uno de los actores tenga acceso
a las funcionalidades de otro.
Elementos Se representa con una flecha con la punta hueca que va desde el
para Hacer elemento que hereda al elemento heredado
un
Diagrama
de Casos de
Uso Veamos un ejemplo
Generalización entre
dos actores
Actor 1
Actor 2
Cómo Dibujar un Diagrama de Casos de Uso
Recopilar
fuentes de
información Identificar
actores
potenciales Identificar
posibles casos
de uso
Para ello responde la
siguiente pregunta:
¿cómo se supone que Para ello responde la
debo saber eso? siguiente pregunta:
¿qué usuarios utilizan Para ello responde la
los bienes y servicios siguiente pregunta:
del sistema ¿a qué bienes y
empresarial? servicios pueden
recurrir los actores?

Conectar los
casos de uso
Describir
actores
Buscar
más casos
Para ello responde la de uso
siguiente pregunta:
¿quién puede hacer Para ello responde la
uso de los bienes y siguiente pregunta:
servicios del sistema ¿a quién o qué
empresarial? representan los Para ello responde la
actores? siguiente pregunta:
¿Qué más debe hacer
el sistema?

Documentar Relacionar
casos de uso modelos
entre casos
de uso
empresarial Verificar
la vista
Para ello responde la
siguiente pregunta:
¿qué sucede
exactamente en cada
caso de uso? Para ello responde la
siguiente pregunta:
¿qué actividades se Para ello responde la
realizan siguiente pregunta:
repetidamente? ¿todo es correcto?

Ejemplos de un Diagrama de Casos de Uso
La clínica veterinaria almacena datos de contacto de todos sus clientes como pueden ser:
Nombre, Apellidos, DNI, Fecha de nacimiento, Teléfono o Email. Estos datos son introducidos y
gestionados por los auxiliares, que ejercen las funciones administrativas. Además se almacena
información de cada uno de las mascotas de las que es dueño cada cliente. Obviamente, cada
cliente puede tener más de una mascota, pero cada mascota solo puede pertenecer a un único
cliente. Se permite, además, cambiar el dueño de una mascota por otro. Al dar de alta un nuevo
animal, se comprobará en el registro del REIAC (Red Española de Identificación de Animales de
Compañía) si el animal está correctamente dado de alta. Este proceso unicamente se hará en
animales que tengan la obligación de estar identificados. Cada vez que un veterinario realiza una
consulta sobre un animal, esta queda almacenada incluyendo datos básicos como: Tiempo de
consulta, Identificación de la persona que lo ha tratado, Animal tratado, Importe total, Resolución,
Recetas… Para calcular el tiempo de la consulta el veterinario tendrá un botón en la aplicación
donde pueda pulsar cuando comienza la consulta para calcular el tiempo a modo de cronómetro y
otro botón para finalizar. En caso de que el animal se quede ingresado en la clínica, el cliente debe
ser capaz de acceder al estado en tiempo real del animal. Además podrá comunicarse con una
cámara que tendrá el animal colocada, donde podrá ver su situación actual. La gestión de estas
cámaras no corresponde al sistema, sino que se utilizará una aplicación ya presente en el
veterinario. Las recetas y otros documentos relacionados con el servicio se incluirán en un gestor
de contenidos que ya está en funcionamiento en la clínica veterinaria. Una vez terminado el
servicio, el cliente no tiene porque realizar inmediatamente el pago, sino que puede identificarse
posteriormente en la aplicación vía web y realizar el pago. Si el cliente tarda más de una semana
se efectuará un recargo sobre el precio inicial. Además, el cliente debe ser capaz de obtener un
histórico de todas las consultas que ha recibido cualquiera de sus mascotas.

Ejemplo Diagrama de casos de uso del actor “auxiliar”
<<extend>> Alta cliente
<<extend>>
Gestión de cliente Baja cliente
<<extend>>
Modificar cliente
<<include>>
Identificación y Autenticación
Comprobar registro
Auxiliar
<<include>> <<extend>>
Alta mascota REIAC

<<extend>>
Gestión de mascota Baja mascota
<<extend>>
Cambiar cliente
<<extend>> de mascota

Ejemplo Diagrama de casos de uso del actor “Cliente”
Calcular recargo
<<extend>>
Hacer pago
<<include>>
Identificación y Autenticación
<<include>> Sistema
Obtener histórico de
<<include>> Cámaras
Cliente
<<extend>>
Filtrar datos
Ver estado de mascota Ver informe actual

ingresada <<extend>>
<<extend>> Visualizar animal

Ejemplo Diagrama de casos de uso del actor “veterinario”
<<include>> Identificación y Autenticación
Comenzar Consulta <<include>>

Seleccionar mascota
<<include>> Calcular pago

Veterinario
Finalizar consulta
Añadir Resolución
<<include>> Gestor
Documental
<<include>>
Añadir documento

Ventajas Vs Desventajas de Casos de Usos
Facilidad para interpretarlos, y útiles

en la comunicación con el cliente. En sistemas grandes toman mucho
tiempo para definir todos los casos
El lenguaje que utilizan es común y de uso
entendible para el usuario
No establecen los requisitos funcionales
Extraer los requerimientos
del usuario y del sistema
El análisis de calidad
Centrar al analista en las depende de como se haya
tareas principales de usuario realizado la descripción
(describiendo los casos de inicial del caso de uso
mayor importancia)
Deben complementarse con información
Tener en cuenta todos los usuarios adicional como: Reglas de negocio,
evitando que las personas especializadas Requisitos no funcionales y Diccionario
en informática dirijan la funcionalidad del de datos que complementen los
nuevo sistema basándose solamente en requerimientos del sistema
criterios tecnológicos

Clases
Las clases representan entidades o conceptos. Normalmente cada
vez que aparece un sustantivo en un documento de descripción de un
sistema ese sustantivo es una clase. En cada clase se definen los
atributos y métodos que tendrán los objetos de esa clase.
Se representan por rectángulos que muestran el
nombre de la clase y opcionalmente el nombre de las
Elementos para operaciones y atributos. Los compartimientos se usan
Hacer un para dividir el nombre de la clase, atributos y
Diagrama de operaciones. Adicionalmente las restricciones, valores
Clases iniciales y parámetros se pueden asignar a clases.
La primera de las zonas se utiliza

para el nombre de la clase.
Nombre de la Clase La segunda de las zonas se
utiliza para escribir los atributos
+ Atributos
de la clase, uno por línea
+ Funciones ( )
La última de las zonas incluye cada una
de las funciones que ofrece la clase.
Clases
Los atributos de la clase, aunque es común simplificando
únicamente poniendo el nombre y el tipo o únicamente el nombre.
utilizan el siguiente formato:
visibilidad nombre_atributo : tipo = valor-inicial { propiedades}
Elementos
para Nombre de la Clase
Hacer un
Diagrama + Atributos
de Clases + Funciones ( )
Las funciones o métodos de la clase, de la misma manera que con los

atributos, se suele simplificar indicando únicamente el nombre de la función
y, en ocasiones, el tipo devuelto. Pero sigue el siguiente formato:
visibilidad nombre_funcion {parametros} : tipo-devuelto {propiedades}

Clases
Nombre de la Clase
Tanto los atributos como las funciones
+ Atributos incluyen al principio de su descripción la
+ Funciones ( ) visibilidad que tendrá. Esta visibilidad se
identifica escribiendo un símbolo y podrá ser:
Elementos
(#) Protegida
para (+) Pública (-) Privada.
Representa que el
Hacer un atributo o función puede
Diagrama Representa que se Representa que se ser accedida
puede acceder al puede acceder al únicamente desde la
de Clases atributo o función atributo o función misma clase o desde
desde cualquier lugar únicamente desde las clases que hereden
de la aplicación. la misma clase de ella (clases
derivadas).
No obstante, pueden incluirse otros en base al lenguaje de programación que

se esté usando (no es muy común).
Por ejemplo: (/) Derivado o (~) Paquete.

Clase
+ atributo1: int
Estructura de una Clases + atributo2: string
+ metodo1 (parametro : int) : double
+ metodo2( )
En caso de que un atributo o función sea estático, se representa en el

diagrama subrayando su nombre. Una característica estática se define como
aquella que es compartida por cada clase y no instanciada para cada uno de
los objetos de esa clase. Es un concepto muy común.
Camioneta
+ placa : string
+ carga : float
+ Camioneta ( ) Ejemplo de una Clases
+ Camioneta ( )
+ característica ( ) : void
+ carga ( kilo : float ) : void

Relaciones
Una relación identifica una dependencia. Esta dependencia puede ser
entre dos o más clases (más común) o una clase hacía sí misma (menos
común, pero existen), este último tipo de dependencia se denomina
dependencia reflexiva. Las relaciones se representan con una linea que une
las clases, esta línea variará dependiendo del tipo de relación
Elementos
Generalización
para Hacer
un Esta relación representa la herencia o la extensión de una
Diagrama clase de otra. En la siguiente imagen podemos ver un ejemplo
de Clases
Vehículo
Coche Moto Camión

Relaciones
Asociación
Representa una relación básica entre dos clases. Pueden ser unidireccionales
(sólo una de las clases conoce a la otra) o bidireccionales (ambas clases tienen
conocimiento de la otra).
Ejemplo Unidireccionales
Elementos Asignatura - profesor ProfesorResponsable
para Hacer 1
un
Diagrama Representa que una asignatura tiene un único profesor
de Clases responsable.
Ejemplo Bidireccionales
Curso - cursos - alumno Alumno

0..* 1..*
Representa que un curso tiene desde 1 hasta varios alumnos y que un
alumno puede estar en 0 o varios cursos

Relaciones
Es un tipo de asociación con la que se
representa que cada objeto de una de las clases
Agregación contiene objetos de la otra clase. El objeto
contenedor seguirá existiendo aunque los objetos
contenidos dejen de existir. Veamos un ejemplo:
Elementos
para Hacer
un
Diagrama Es un tipo de asociación, pero
de Clases podemos decir que son agregaciones
fuertes. La diferencia con las
agregaciones es que no tiene sentido Composición
que el objeto contenedor siga
existiendo si no existen los objetos
contenidos.

Relaciones
Vehículo - ruedas Rueda

4
Libro - capítulos Capitulo

1...*
Esta imagen representa la diferencia entre una agregación y una

composición. Un vehículo seguirá existiendo aunque no existan sus ruedas (otra
cosa es que pueda rodar). Sin embargo un libro no existirá si no existen sus
capítulos.

Ventajas Vs Desventajas de Diagrama de Clases
Genera un código automáticamente

Propone soluciones a algunos errores Los diagramas de clases especifican
Representa las relaciones qué clases hay y cómo están
entre las clases de sistema relacionadas, pero no cómo
interactúan para alcanzar
Se diseña los componentes comportamientos particulares
de los sistemas
Se protegen los datos

El método tiende hacer
Se posibilita una reducción muy lento
de acoplamiento
Mas fácil la comunicación entre los La instalación es

programadores, descubrimiento de muy costosa
fallas del sistema en el diseño
Mejor diseño del sistema ofrece
más documentación.

xiogle
nny s @
gmail.
co m
5
61 694
4 16) 5
(0

Unidad Ii - Interpretar Modelos Conceptuales - Parte I

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

Unidad Ii - Interpretar Modelos Conceptuales - Parte I

Cargado por

Copyright:

Formatos disponibles

Unidad II:

Elementos para Interpretar

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Para diseñar una base de manera eficiente y correcta, primero debemos

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lo primero que debes tener muy bien documentados son tus

Representa la fase inicial del desarrollo del diseño de los datos y el

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

desuso, Par r los Evitar almacén de

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

¿Cuales con las Abstracciones más Usadas en el Modelo Conceptual?

Veamos un ejemplo, para entender mejor..!!

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

En síntesis el diseño de una BD es un proceso complejo (dado que es

Dentro de los MODELOS CONCEPTUALES estudiaremos los siguientes

Orientadas a Objetos Lenguaje Unificado de Modelado

Esquemas Conceptuales Modelo Entidad-Relación y Modelo

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Diagrama de Casos de Uso Diagrama de Clases

Están clasificado dentro del grupo de Es un diagrama puramente

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Elementos Existen dos tipos de actores: Los usuarios, pero no

<<communicates>> Emitir Nómina

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

¿Qué grupos de usuarios requieren ayuda

¿Qué grupos de usuarios se necesitan para ejecutar

¿Qué grupos de usuarios están obligados a

¿El sistema interactuará con cualquier

Cualquier individuo, grupo o fenómeno que se ajuste a una o más de estas

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Se utiliza para representar cualquier acción que realice la

Se representan con una elipse que incluye en

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Se utiliza para representar todas las acciones o actividades que se

Se representan con un cuadrado que

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Las relaciones conectan los casos de uso con los actores o

Cuando conectan un actor con un caso de uso representa

Cuando conectan casos de uso entre sí se pueden diferenciar

Emitir factura <<include>>

Enviar pedido <<include>>

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

<<extend>> Alta cliente

Alta mascota REIAC

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Ver estado de mascota Ver informe actual

<<extend>> Visualizar animal

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

<<include>> Identificación y Autenticación

Comenzar Consulta <<include>>

<<include>> Calcular pago

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

Facilidad para interpretarlos, y útiles

Lcda. Depool Xioglennys (Msc.) (0416) 5616945 xioglennys@gmail.com

La primera de las zonas se utiliza

visibilidad nombre_atributo : tipo = valor-inicial { propiedades}

Las funciones o métodos de la clase, de la misma manera que con los