bases de datos

Es un conjunto de datos pertenecientes a un mismo contexto y que se almacenan sistemticamente para su posterior uso. Actualmente debido al desarrollo tecnológico de campos como la informática y la electrónica, en su mayoría las bases de datos están en formato digital, y ofrecen un amplio rango de soluciones al problema de almacenar datos.
Existen algunos programas denominados a sistemas gestores de bases de datos (SGBD), esto permite almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de estos SGBD, así como la utilización y administración, se estudia dentro del ámbito de la informática.

the bezth famiily!

miizh niiniiOzh...
enrealiidha lozh amOh azhii azhii
xtremadamenth demazhiiaO...
mOrezh grax!
x ezthar prezhente en lozh mejorez
mOmenthoz dh mii lifeh....
lo uniiqo... ezh q zhon lozh mejorezh!!!
grax exiizthiir!!!
...
wiiniiwh poOh --> wendy
thiigger --> iiOhp
piigleth --> alejah
burrOh --> briian (bernii)
qOnejo --> boliiwar

lozh amOh!!!

qarthel 8.... lozh qiierOh demaziiaiizhiimO

DIAGRAMA DE OBJETOS

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.
Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma, Nombre de objeto: Nombre de clase.

DIAGRAMA DE CLASES DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento.
El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

CASOS DE USO UML

El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema.
El valor verdadero de un caso de uso reposa en dos áreas:
La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
Es práctica común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están representados por las figuras humanas. El actor Crítico de comidas puede Probar la comida, Pagar la comida, o Beber vino. Sólo el actor Chef puede Preparar la comida. Podría ser que ambos Patrón y Cajero estén involucrados en el caso de uso Pagar la comida. El marco define los limites del sistema Restaurante, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.