UNIDAD II. EL PARADIGMA DE ORIENTACIÓN A OBJETOS
ACTIVIDAD 1 Realice la lectura de la hora 1 y hora 2 del libro Aprendiendo UML en 24 horas
Actividad 2. Documente los temas 2.1, 2.2, 2.3 , 2.4.
TEMA:2.1 COMPONENTES DE LA PROGRAMACIÓN ORIENTADA A OBJETOS.
Un componente es una clase de uso específico, lista para usar, que puede ser configurada o utilizada de forma visual, desde el entorno de desarrollo.
La principal diferencia, respecto a una clase normal, es que la mayor parte del trabajo lo podemos hacer de forma visual, con el ratón y ajustando las opciones que se nos ofrece en nuestro entorno.
2.1.1 clases
Las Clases
En el mundo real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo, nuestro teléfono celular es sólo uno de los miles que hay en el mundo. Si hablamos en términos de la programación orientada a objetos, podemos decir que nuestro objeto celular es una instancia de una clase conocida como "celular". Los celulares tienen características (marca, modelo, sistema operativo, pantalla, teclado, etc.) y comportamientos (hacer y recibir llamadas, enviar mensajes multimedia, transmisión de datos, etc.).
Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que los celulares comparten esas características comunes y construyen modelos o plantillas comunes, para que a partir de esas se puedan crear muchos equipos celulares del mismo modelo. A ese modelo o plantilla le llamamos CLASE, y a los equipos que sacamos a partir de ella la llamamos OBJETOS.
Esto mismo se aplica a los objetos de software, se puede tener muchos objetos del mismo tipo y mismas características.
Definición teórica: La clase es un modelo o prototipo que define las variables y métodos comunes a todos los objetos de cierta clase. También se puede decir que una clase es una plantilla genérica para un conjunto de objetos de similares características.
Por otro lado, una instancia de una clase es otra forma de llamar a un objeto. En realidad no existe diferencia entre un objeto y una instancia. Sólo que el objeto es un término más general, pero los objetos y las instancias son ambas representación de una clase.
Definición Teórica: Una instancia es un objeto de una clase en particular.
Clases en POO
Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablábamos de las clases coche o fracción porque sólo estuvimos definiendo, aunque por encima, sus formas.
¿Qué es una Clase?
Cuando decimos “ave”, sabemos que nos referimos a “algo” con plumas, pico, dos patas, etc. No importa realmente si hemos visto un ave o no, o si tenemos un ave frente a nosotros; entendemos claramente que la palabra “ave” se refiere a alguna cosa que cumple con unas características específicas, se comporta de una forma concreta, etc, etc. No es más que una palabra, pero nos permite clasificar las cosas. Por ejemplo, sabemos que una gallina es un ave y que un perro no es un ave.
La clasificación es algo que hacemos todos los días, a cada momento (entre otras cosas, nos libra de utilizar medias como guantes o bañarnos en el comedor en vez de en la ducha). Cada vez que decimos que algo esalguna cosa, estamos clasificándolo, asociándolo a una clase.
2.1.2 objetos
En el paradigma de programación orientada a objetos (POO, o bien OOP en inglés), un objeto se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase.
Estos objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas(funciones o procedimientos), o simplemente una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio.
- Un objeto es una cosa tangible, algo a que se puede aprehender intelectualmente o algo hacia lo que se puede dirigir una acción o pensamiento.
- Un objeto representa un item individual e identificable, o una entidad real o abstracta, con un papel definido en el dominio del problema
- Un objeto tiene:
- Estado
- Comportamiento
- Identidad
La estructura y el comportamiento de objetos similares se definen en sus clases comunes. El término objeto y ejemplo (instance) de una clase son intercambiables.
2.1.3 variables de instancia
Cuando se define una clase en POO, las variables que se definen dentro de ella son variables que tendrán diferentes valores con cada una de las instancias que se generan al crear objetos nuevos de la clase.
Una variable de instancia normalmente se define como privada, para que no se pueda modificar desde otra clase, solo a través de los métodos (como lo vimos en la clase Punto con el obtenX() y el cambiaX()), pero puede ser definida como pública y en ese caso no se requiere de hacer uso de algún método para tomar su valor o modificarla (no es recomendable por el control de la variable por la misma clase).
Las variables son localidades de memoria en las que pueden almacenarse datos. Cada una tiene un nombre, un tipo y valor. Java tiene tres tipos de variables: de instancia, de clase y locales.
- Variables de instancia.
2.1.4 métodos
- Métodos de claseLos métodos de clase al igual que las variables de clase, se aplican a la clase como un todo y no a sus instancias.
Se utiliza de igual manera la palabra clave static para indicar que un método es un método de clase:static valorRetorno nombreMetodo( <lista argumentos opcionales> ) { /* cuerpo del método */ }
Métodos
Como se ha señalado, los métodos corresponden al comportamiento o protocolo que se encarga de ejecutar las acciones que se requieren para que un objeto realice su trabajo.
Pensemos en un objetos real, una pelota, la cual posee características propias, tener color, ser redonda o estar inflada. Ahora consideremos cada método como una forma en podemos manipularla: lanzarla, hacerla rodar, inflarla etc.
Clases
Una clase es una descripción que agrupa a un conjunto de objetos que comparten una estructura y un comportamiento. Considere el sgte. Ejemplo :
class Perro{
int peso;
char nombre[20];
char raza[15];
void dormir (int tiempo){delay(tiempo);}
void comer (int cantidad){peso +=cantidad;}
};
2.2 Definiciones de Clases y objetos.
Una clase es la definición de las características concretas de un determinado tipo de objetos. Es decir, de cuáles son los datos y los métodos de los que van a disponer todos los objetos de ese tipo. Por esta razón, se suele decir que el tipo de dato de un objeto es la clase que define las características del mismo[7].
El elemento básico de la programación orientada a objetos en Java es la clase. Una clase define la forma y comportamiento de un objeto.
Para crear una clase sólo se necesita un archivo fuente que contenga la palabra clave reservada class seguida de un identificador legal y un bloque delimitado por dos llaves para el cuerpo de la clase.
class MiPunto {}
Un archivo de Java debe tener el mismo nombre que la clase que contiene, y se les suele asignar la extensión ".java". Por ejemplo la clase MiPunto se guardaría en un fichero que se llamase MiPunto.java. Hay que tener presente que en Java se diferencia entre mayúsculas y minúsculas; el nombre de la clase y el de archivo fuente han de ser exactamente iguales.
Aunque la clase MiPunto es sintácticamente correcta, es lo que se viene a llamar una clase vacía, es decir, una clase que no hace nada. Las clases típicas de Java incluirán variables y métodos de instancia. Los programas en Java completos constarán por lo general de varias clases de Java en distintos archivos fuente.
Una clase es una plantilla para un objeto. Por lo tanto define la estructura de un objeto y su interfaz funcional, en forma de métodos. Cuando se ejecuta un programa en Java, el sistema utiliza definiciones de clase para crear instancias de las clases, que son los objetos reales. Los términos instancia y objeto se utilizan de manera indistinta. La forma general de una definición de clase es:
class Nombre_De_Clase {
2.3 Encapsulaciòn.
Encapsulamiento
Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.(4)
La encapsulación: Se refiere a la capacidad de agrupar y condensar en un entorno con límites bien-definidos distintos elementos. Cuando hablemos de encapsulación en general siempre nos referiremos, pues, a encapsulación abstracta. De manera informal, primero generalizamos (la abstracción) y luego decimos: la generalización está bien, pero dentro de un cierto orden: hay que poner límites (la encapsulación), y dentro de esos límites vamos a meter, a saco, todo lo relacionado con lo abstraído: no sólo datos, sino también métodos, comportamientos, etc.
Encapsulación:
También conocida como ocultamiento. Cuando me acuesto a ver televisión no me preocupo del modo como éste funciona, o lo que hace para cambiar de canal o aumentar el volumen. A menos que seas experto en electrónica o técnico en televisores, te pasará lo mismo: no lo sabes y no te importa; sólo sabes que al presionar un botón ocurre la magia.
La encapsulación se encarga de mantener ocultos los procesos internos que necesita para hacer lo que sea que haga, dándole al programador acceso sólo a lo que necesita. Esto da dos ventajas iniciales: Lo que hace el usuario puede ser controlado internamente (incluso sus errores), evitando que todo colapse por una intervenciónindeseada (tú no quieres que tu mamá, que no tiene ni idea de electrónica, abra tu televisor y empiece a jugar con los circuitos para cambiar los canales manualmente ¿verdad?). La segunda ventaja es que, al hacer que la mayor parte del código esté oculto, puedes hacer cambios y/o mejoras sin que eso afecte el modo como los usuarios van a utilizar tu código. Sólo tienes que mantener igual la forma de acceder a él (en el caso del control de la tele, que los botones sigan siendo los mismos y que el botón de “apagado” no cambie el volumen). Por cierto, estas puertas de acceso que das a los usuarios son lo que se conoce como interfaz
2.4 Herencia.
herencia (P.O.O)
HERENCIA:
-CONCEPTOS:
herncia:Es una propiedad que permite que los objetos sean creados a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes. Es la relación entre una clase general y otra clase mas especifica. Es un mecanismo que nos permite crear clases derivadas a partir de clase base, Nos permite compartir automáticamente métodos y datos entre clases subclases y objetos. Por ejemplo: Si declaramos una clase párrafo derivada de un clase texto todos los métodos y variables asociadas con la clase texto son automáticamente heredados por la subclase párrafo.[1]
herencia:Este quizas es el tema que mas problemas causa al estudiante; sin embargo, no es dificil en su concepción.
El objeto Persona es un objeto muy generico y limitado en si; asi que se puede considerar como un objeto Abstracto; ya que por si mismo no puede crear una persona completa; sin embargo, sus funciones basicas son las mismas en todos los seres humanos, con diferencias puntuales, asi que podemos crear dos objetos Hombre y Mujer, que hereden todas sus caracteristicas genericas como respirar, hablar, nombre, etc, del objeto Persona, y sea en la implementación de cada objeto donde empiezen las diferencias.
Concepto de herencia
El mecanismo de herencia es uno de los pilares fundamentales en los que se basa la programación orientada a objetos. Es un mecanismo que permite definir nuevas clases a partir de otras ya definidas de modo que si en la definición de una clase indicamos que ésta deriva de otra, entonces la primera -a la que se le suele llamar clase hija- será tratada por el compilador automáticamente como si su definición incluyese la definición de la segunda –a la que se le suele llamar clase padre o clase base.
UML
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.
Umbrello UML Modeller mostrar un diagrama de casos de uso
Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas:
- Cada caso de uso está relacionado como mínimo con un actor
- Cada caso de uso es un iniciador (es decir, un actor)
- Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son:
- <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso
- <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.
- Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por otro actor «representante de ventas».
Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.
Umbrello UML Modeller mostrando un diagrama de clases
Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.
En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.
Representación visual de una clase en UML
En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente:
+Indica atributos públicos#Indica atributos protegidos-Indica atributos privados
Las operaciones (métodos) también se muestan al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:
+Indica operaciones públicas#Indica operaciones protegidas-Indica operaciones privadas
Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:
La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias.
En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.
Representación visual de una generalización en UML
Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de «conexiones» entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace).
Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.
En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (
*) representando el infinito en el lado máximo.
Representación visual de una asociación en UML
Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación «completa». Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno.
En UML, las acumulaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa.
Representación visual de una relación de acumulación en UML
Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son.
En UML, las composiciones están representadas por un rombo sólido al lado del conjunto.
Los diagramas de clases pueden contener más componentes aparte de clases.
Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredarse de las interfaces pudiendo así realizarse instancias a partir de estos diagramas.
Los tipos de datos son primitivas incluidas en algunos lenguajes de programación. Algunos ejemplos son: bool y float. No pueden tener relación con clases, pero las clases sí pueden relacionarse con ellos.
Las enumeraciones son simples listas de valores. Un ejemplo típico de esto sería una enumeración de los días de la semana. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases sí pueden hacerlo con ellos.
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.
Umbrello UML Modeller mostrando un diagrama de secuencia
Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.
Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.
Umbrello UML Modeller mostrando un diagrama de colaboración
Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.
Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:
- Listo
- Escuchando
- Trabajando
- Detenido
y los eventos que pueden producir que el objeto cambie de estado son
- Se crea el objeto
- El objeto recibe un mensaje de escucha
- Un cliente solicita una conexión a través de la red
- Un cliente finaliza una solicitud
- La solicitud se ejecuta y ser termina
- El objeto recibe un mensaje de detención
- etc
Umbrello UML Modeller mostrando un diagrama de estado
Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe el estado interno de un objeto de una clase particular
Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados por estados, sino únicamente aquellos cambios que pueden afectar significativamente a la forma de funcionamiento del objeto
Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningún evento que pueda sacar a un objeto de su estado de fin.
Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades.
Umbrello UML Modeller mostrando un diagrama de actividad
Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades están claramente unidas a objetos.
Los diagramas de actividad siempre están asociados a una clase, a una operación o a un caso de uso.
Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas simultáneamente o una detrás de otra).
Una actividad es un único paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transición saliente. Las actividades también pueden tener más de una transición saliente, si tienen diferentes condiciones.
Las actividades pueden formar jerarquías, lo que significa que una actividad puede estar formada de varias actividades «de detalle», en cuyo caso las transiciones entrantes y salientes deberían coincidir con las del diagrama de detalle.
Existen unos pocos elementos en UML que no tiene un valor semántico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son
- Línea de texto
- Notas de texto y enlaces
- Cajas
Las líneas de texto son útiles para añadir información textual a un diagrama. Es texto es libre y no tiene ningún significado para la maqueta.
Las notas son útiles para añadir información más detallada de un objeto o una situación específica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota «pertenece» a un objeto o situación específicos.
Las cajas son rectángulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas más legibles. No tienen significado lógico en la maqueta.
Los diagramas de componentes muestran los componentes del software (ya sea las tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que está compuesto como los archivos de código fuente, las librerías o las tablas de una base de datos.
Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes.
Los diagramas de implementación muestran las instancias existentes al ejecutarse así como sus relaciones. También se representan los nodos que identifican recursos físicos, típicamente un ordenador así como interfaces y objetos (instancias de las clases).
Los diagramas de relaciones de entidad (diagramas ER) muestran el diseño conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de información y las relaciones y restricciones existentes entre ellas. Una extensión de los diagramas de relaciones de entidad llamado «diagramas de relaciones de entidad extendida» o «diagramas de relaciones de entidad mejoradas» (EER), se utiliza para incorporar las técnicas de diseño orientadas a objetos en los diagramas ER.
Umbrello mostrando un diagrama de relaciones de entidad
Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un objeto con una existencia física (ejemplo, máquina, robot) o puede ser un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad.
Nota: No existen notaciones estándar para representar los diagramas ER. Los diferentes textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of Database Systems 4ª ed. Addison Wesley (Fundamentos de los sistemas de bases de datos)
En un diagrama ER, las entidades se representan como rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.
Representación visual de una entidad en un diagrama ER
En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento diferente de la entidad a la que pertenecen.
Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de información.
Existen cuatro tipos de restricciones soportadas por Umbrello:
- Clave primaria: El conjunto de atributos declarados como clave primaria es única para la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que la componen puede ser NULL.
- Clave única: El conjunto de atributos declarados como única son únicos para la entidad. Pueden haber muchas restricciones únicas en una entidad. Los atributos que lo componen pueden tener el valor NULL. Las claves únicas y primarias identifican de forma única una fila de una tabla (entidad)
- Clave externa: Una clave externa es una restricción referencia entre dos tablas. La clave externa identifica una columna o un conjunto de columnas en un tabla (referenciada) que referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en la tabla referenciada deben formar una clave primaria o una clave única.
- Restricción de comprobación: Una restricción de comprobación (también conocida como restricción de comprobación de tabla) es una condición que define los datos válidos cuando se añaden o actualizan datos en una tabla de la base de datos relacional. Se aplicará una restricción a cada fila de la tabla. La restricción debe ser un predicado. Puede referirse a una o varias columnas de la tabla.Ejemplo: precio >= 0
La especialización es una manera de formar nuevas entidades utilizando entidades que ya se hayan definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o heredar) atributos de las entidades que ya existían, y que se refieren a las entidades base. Se pretende ayudar a reutilizar datos con pequeñas o ninguna modificacione.
En Umbrello, se puede especificar la especialización de separación y de solapamiento
Una especialización disjunta especifica que las subclases de una especialización deben ser disjuntas, es decir, una entidad puede ser miembro, como máximo, de una de las derivadas en la especialización.
Representación visual de una especialización disjunta en un diagrama ER
Cuando las entidades derivadas no son obligatoriamente disjuntas, el conjunto de entidades se denomina una «especialización por solapamiento», lo que significa que una entidad puede pertenecer a más de una entidad derivada de la especialización.
Representación visual de una especialización de solapamiento en un diagrama ER
Una entidad derivada se considera una Categoría cuando representa una colección de objetos que es un subconjunto de la unión de varios tipos de entidades. Una categoría se modela cuando se necesita una relación única superclase/subclase con más de una superclase, donde la superclase representa diferentes tipos de entidades (similar a la herencia múltiple en Programación Orientada a Objetos).
