base de datos

QUE ES BASE DE DATOS

El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California –USA.Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.Desde el punto de vista de la informático, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos.Este trabajo se realizara con la finalidad de aprender un poco más sobre una base de datos, sus características, usos, estructuras, diseños, entre otros.Una base de datos tiene mucha importancia en el ritmo de vida que llevamos en los actuales momentos, ya que, está acelera el ritmo en el momento realizar una búsqueda de información.
Algunos conceptos de bases de datos:Base de Datos: es la colección de datos aparentes usados por el sistema de aplicaciones de una determinada empresa.Base de Datos: es un conjunto de información relacionada que se encuentra agrupada o estructurada. Un archivo por sí mismo no constituye una base de datos, sino más bien la forma en que está organizada la información es la que da origen a la base de datos.Base de Datos: colección de datos organizada para dar servicio a muchas aplicaciones al mismo tiempo al combinar los datos de manera que aparezcan estar en una sola ubicación.

REQUERIMIENTOS DE UNA BASE DE DATOS

El análisis de requerimientos para una base de datos incorpora las mismas tareas que el análisis de requerimientos del software. Es necesario un contacto estrecho con el cliente; es esencial la identificación de las funciones e interfaces; se requiere la especificación del flujo, estructura y asociatividad de la información y debe desarrollarse un documento formal de los requerimientos.Requerimientos administrativos: se requiere mucho más para el desarrollo de sistemas de bases de datos que únicamente seleccionan un modelo lógico de base de datos. La bases de datos es una disciplina organizacional, un método, más que una herramienta o una tecnología. Requiere de un cambio conceptual y organizacional.

CARACTERISTICAS DE LAS BASES DE DATOS

Una base de datos contiene entidades de información que están relacionadas vía organización y asociación. La arquitectura lógica de una base de datos se define mediante un esquema que representa las definiciones de las relaciones entre las entidades de información. La arquitectura física de una base de datos depende de la configuración del hardware residente. Sin embargo, tanto el esquema (descripción lógica como la organización (descripción física) deben adecuarse para satisfacer los requerimientos funcionales y de comportamiento para el acceso al análisis y creación de informes.

Las bases de datos proporcionan la infraestructura requerida para los sistemas de apoyo a la toma de decisiones y para los sistemas de información estratégicos, ya que estos sistemas explotan la información contenida en las bases de datos de la organización para apoyar el proceso de toma de decisiones o para lograr ventajas competitivas. Por este motivo es importante conocer la forma en que están estructuradas las bases de datos y su manejo.

OBJETOS DE LAS BASES DE DATOS

Tablas: unidad donde crearemos el conjunto de datos de nuestra base de datos. Estos datos estarán ordenados en columnas verticales. Aquí definiremos los campos y sus características. Más adelante veremos qué es un campo.
Consultas: aquí definiremos las preguntas que formularemos a la base de datos con el fin de extraer y presentar la información resultante de diferentes formas (pantalla, impresora...)
Formulario: elemento en forma de ficha que permite la gestión de los datos de una forma más cómoda y visiblemente más atractiva.
Informe: permite preparar los registros de la base de datos de forma personalizada para imprimirlos.
Macro: conjunto de instrucciones que se pueden almacenar para automatizar tareas repetitivas.
Módulo: programa o conjunto de instrucciones en lenguaje Visual Basic.

CONCEPTOS BASICOS DE UNA BASE DE DATOS

Campo: unidad básica de una base de datos. Un campo puede ser, por ejemplo, el nombre de una persona. Los nombres de los campos, no pueden empezar con espacios en blanco y caracteres especiales. No pueden llevar puntos, ni signos de exclamación o corchetes. Si pueden tener espacios en blanco en el medio. La descripción de un campo, permite aclarar información referida a los nombres del campo. El tipo de campo, permite especificar el tipo de información que cargáramos en dicho campo, esta puede ser:
· Texto: para introducir cadenas de caracteres hasta un máximo de 255
· Memo: para introducir un texto extenso. Hasta 65.535 caracteres
·Numérico: para introducir números
·Fecha/Hora: para introducir datos en formato fecha u hora
· Moneda: para introducir datos en formato número y con el signo monetario
·Auto numérico: en este tipo de campo, Access numera automáticamente el contenido
· Sí/No: campo lógico. Este tipo de campo es sólo si queremos un contenido del tipo Sí/No, Verdadero/Falso, etc.
·Objeto OLE: para introducir una foto, gráfico, hoja de cálculo, sonido, etc.
· Hipervínculo: podemos definir un enlace a una página Web
· Asistente para búsquedas: crea un campo que permite elegir un valor de otra tabla o de una lista de valores mediante un cuadro de lista o un cuadro combinado.
Registro: es el conjunto de información referida a una misma persona u objeto. Un registro vendría a ser algo así como una ficha.Campo clave: campo que permite identificar y localizar un registro de manera ágil y organizada.

DISEÑO DE UNA BASE DE DATOS

Existen distintos modos de organizar la información y representar las relaciones entre los datos en una base de datos. Los Sistemas administradores de bases de datos convencionales usan uno de los tres modelos lógicos de bases de datos para hacer seguimiento de las entidades, atributos y relaciones. Los tres modelos lógicos principalmente de bases de datos son el jerárquico, de redes y el relacional. Cada modelo lógico tiene ciertas ventajas de procesamiento y también ciertas ventajas de negocios.

CREACION DE UNA BASE DE DATOS

Para crear una base se deben realizar dos ejercicios de diseño: un diseño lógico y uno físico. El diseño lógico de una base de datos es un modelo abstracto de la base de datos desde una perspectiva de negocios, mientras que el diseño físico muestra como la base de datos se ordena en realidad en los dispositivos de almacenamiento de acceso directo. El diseño físico de la base de datos es llevado a cabo por los especialistas en bases de datos, mientras que el diseño lógico requiere de una descripción detallada de las necesidades de información del negocio de los negocios actuales usuarios finales de la base. Idealmente, el diseños de la base será una parte del esfuerzo global de la planeación de datos a nivel institucional.El diseño lógico de la base de datos describe como los elementos en la base de datos han de quedar agrupados. El proceso de diseño identifica las relaciones entre los elementos de datos y la manera más eficiente de agruparlos para cumplir con los requerimientos de información.

BASES DE DATOS ORIENTADA A OBJETOS

Estas son capaces de almacenar tanto procesos como datos. Por este motivo las bases orientadas al objeto deben poder almacenar información no convencional (como imágenes estáticas o en movimiento, colecciones de sonidos, entre otros). Este tipo de bases de datos deriva directamente de la llamada programación orientada a objetos, típica por ejemplo del lenguaje C/C++.Entre las ventajas de las bases de datos orientadas al objeto destaca la posibilidad de tratar los casos excepcionales, que suelen ser la mayoría en la práctica cotidiana, en lugar de tratar de insertar la realidad en unos patrones rígidos que violentan para hacerla coincidir con los esquemas utilizados. Además, nadie pone en duda que es más cómodo manejar objetos de entorno que no es familiar, que trabaja, por ejemplo, con tablas, esquemas, cuadros, muchos más.

COMPONENTES PRINCIPALES DE UNA BASE DE DATOS

Hardware. El hardware se refiere a los dispositivos de almacenamiento en donde reside la base de datos, así como a los dispositivos periféricos (unidad de control, canales de comunicación, etc.) necesarios para su uso.
Software. Está constituido por un conjunto de programas que se conoce como Sistema Manejador de Base de Datos (DMBS: Data Base Management System). Este sistema maneja todas las solicitudes formuladas por los usuarios a la base de datos.
Usuarios. Existen tres clases de usuarios relacionados con una Base de Datos:
El programador de aplicaciones, quien crea programas de aplicación que utilizan la base de datos.
El usuario final, quien accesa la Base de Datos por medio de un lenguaje de consulta o de programas de aplicación.
El administrador de la Base de Datos (DBA: Data Base Administrator), quien se encarga del control general del Sistema de Base de Datos.

ADMINISTRACION DE UNA BASE DE DATOS

Los sistemas de base de datos requieren que la institución reconozca el papel estratégico de la información y comience activamente a administrar y planear la información como recurso cooperativo. Esto significa que la institución debe desarrollar la función de administración de datos con el poder de definir los requerimientos de la información para toda la empresa y con acceso directo a la alta dirección. El director de la información (DI) o vicepresidentes de la información es el primero que aboga en la institución por sistemas de base de datosLa administración de la información es responsable las políticas y procedimientos específicos mediante los cuales los datos pueden ser administrados como recursos institucionales. Entre estas responsabilidades se incluye el desarrollo de la política de información, la planeación de los datos, contemplan un diseños lógico de la base de datos por los especialistas en sistemas de información y los grupos de usuario s finales.El principio fundamental de la administración de datos es que son propiedad de la institución de datos es que son propiedad de la institución como un todo.

EL SISTEMA ORGANIZADOR DE BASE DE DATOS

El DBMS es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos. Se compone de un lenguaje de definición de datos (DDL: Data Definition Language), de un lenguaje de manipulación de datos (DML: Data Manipulation Language) y de un lenguaje de consulta (SQL: Structured Query Language).
El lenguaje de definición de datos (DDL) es utilizado para describir todas las estructuras de información y los programas que se usan para construir, actualizar e introducir la información que contiene una base de datos.
El lenguaje de manipulación de datos (DML) es utilizado para escribir programas que crean, actualizan y extraen información de las bases de datos.
El lenguaje de consulta (SQL) es empleado por el usuario para extraer información de la base de datos. El lenguaje de consulta permite al usuario hacer requisiciones de datos sin tener que escribir un programa, usando instrucciones como el SELECT, el PROJECT y el JOIN.

La secuencia conceptual de operaciones que ocurren para acceder cierta información que contiene una base de datos es la siguiente:
1 El usuario solicita cierta información contenida en la base de datos.
El DBMS intercepta este requerimiento y lo interpreta.El DBMS realiza las operaciones necesarias para acceder y/o actualizar la información solicitada..

El modelo jerárquico:
La forma de esquematizar la información se realiza a través de representaciones jerárquicas o relaciones de padre/hijo, de manera similar a la estructura de un árbol. Así, el modelo jerárquico puede representar dos tipos de relaciones entre los datos: relaciones de uno a uno y relaciones de uno a muchos.

Inconveniente del modelo jerárquicoRelación maestro-alumno, donde un maestro tiene varios alumnos, pero un alumno también tiene varios maestros, uno para cada clase. En este caso, si la información estuviera representada en forma jerárquica donde el padre es el maestro y el alumno es el hijo, la información del alumno tendrá que duplicarse para cada uno de los maestros

Otra dificultad que presenta el modelo jerárquico de representación de datos es respecto a las bajas. En este caso, si se desea dar de baja a un padre, esto necesariamente implicará dar de baja a todos y cada uno de los hijos que dependen de este padre.

El modelo de red:
El modelo de red evita esta redundancia en la información, a través de la incorporación de un tipo de registro denominado el conector, que en este caso pueden ser las calificaciones que obtuvieron los alumnos de cada profesor.
La dificultad surge al manejar las conexiones o ligas entre los registros y sus correspondientes registros conectores.

El modelo relacional:
Se está empleando con más frecuencia en la práctica, debido el rápido entendimiento por parte de los usuarios que no tienen conocimientos profundos sobre Sistemas de Bases de Datos y a las ventajas que ofrece sobre los dos modelos anteriores.
En este modelo toda la información se representa a través de arreglos bidimensionales o tablas. Estas operaciones básicas son:
·Seleccionar renglones de alguna tabla (SELECT)
·Seleccionar columnas de alguna tabla (PROJECT)
·Unir o juntar información de varias tablas (JOIN)
Es importante mencionar que la mayoría de los paquetes que manejan bases de datos disponibles en el mercado poseen las instrucciones SELECT, PROJECT Y JOIN con diferentes nombres y modalidades.

Relación uno a uno

No son muy frecuentes en cualquier caso en prácticas. Estas se manejan exactamente en el mismo modo que las interrelaciones mucho a uno.

Relaciones mucho a mucho

Las interrelaciones de muchos a muchos (o de muchos a muchos a muchos, etc) mostradas en el ejemplo siguiente:PROY-TRABAJO (asocia empleados y proyectos)PROV-PARTE (asocia proveedores y partes)PROV_PARTE_PROY (asocia proveedores, partes y proyectos)ESTRUCTURA DE PARTES (asocia a partes a partes)Cada una de estas interrelaciones también corresponde a una relación base. Por tanto, introducimos otras cuatro relaciones base correspondientes a estas cuatro interrelaciones.

Enfoque jerarquizado

Una base de datos jerárquica se compone de un conjunto ordenado de árboles, dicho de manera más precisa, un conjunto ordenado formado por múltiples ocurrencias de un solo tipo de árbol.

Operaciones básicas

Una tarea muy común a realizar con un árbol es ejecutar una determinada operación con cada uno de los elementos del árbol. Esta operación se considera entonces como un parámetro de una tarea más general que es la visita de todos los nodos o, como se denomina usualmente, del recorrido del árbol.Si se considera la tarea como un proceso secuencial, entonces los nodos individuales se visitan en un orden especifico, y pueden considerarse como organizados según una estructura lineal. De hecho, se simplifica considerablemente la descripción de muchos algoritmos si puede hablarse del proceso del siguiente elemento en el árbol, según su cierto orden subyacente.Hay dos formas básicas de recorrer un árbol: El recorrido en amplitud y el recorrido en profundidad.

HOJA DE CALCULO

programa de aplicación utilizado normalmente en tareas de creación de presupuestos o previsiones, y en otras tareas financieras. En un programa de hoja de calculo, los datos y las formulas necesarios se introducen en formularios tabulares (hojas de cálculos u hojas de trabajo), y se utilizan para analizar, controlar, planificar o evaluar el impacto de los cambios reales o presupuesto sobre una estrategia económica.

ENFOQUE RELACIONAL

Casi todos los productos de base de datos desarrollados años recientes se basan en lo que se conoce como enfoque relacional. La cuestión es que ningún sistema actual maneja el modelo relacional en todos sus aspectos (varios se acercan, pero la mayor parte fallan en algún detalle u otro; en los dominios, o si no en alguna otra cosa)Bases de datos relaciónales, es decir, bases de datos percibidas por el usuario como tablas y solo como tablas.En una computadora existen diferentes formas de almacenar información. Esto da lugar a distintos modelos de organización de la base de datos: jerárquico, red, relacional y orientada a objeto. Los sistema relacionales son importantes porque ofrecen tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario final, períodos cortos de aprendizaje y las consultas de información se especifican de forma sencilla.Las tablas son un medio de representar la información de una forma más compacta y es posible acceder a la información contenida en dos o más tablas.

REQUISITOS QUE HA DE TENER LAS TABLAS

El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la información que necesitamos.La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los valores o datos que contendrá cada uno de esos campos.Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.Los registros constituyen la información que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este. Generalmente los diferentes tipos de campos que se pueden almacenar son los siguientes: texto (caracteres), Numérico (números), Fecha / Hora, Lógico (informaciones lógicas si / no, verdadero / falso, etc., imágenes.

BASES DE DATOS DISTRIBUIDAS

Son las Bases de Datos que no están almacenadas totalmente en un solo lugar físico, (esta segmentada) y se comunican por medio de enlaces de comunicaciones a través de una red de computadoras distribuidas geográficamente.

algunas bases de datos

SQL, ORACLE, DBASE, IV, FOXPRO, FOXBASE, PARADOS, ACCES, APPROACH.

Reserva Y Seguridad.
Reserva: Es la capacidad que tiene el programador para que sus datos se conserven al finalizar la ejecución de un proceso, de forma que se puedan reutilizar en otros procesos.Seguridad: la seguridad de las instalaciones, los datos y la información generada es parte de una conversión satisfactoria. La seguridad tiene tres aspectos interrelacionados, física, lógica y de comportamiento. Los tres tienen que trabajar juntos si se pretende que la calidad de la seguridad permanezca alta.Seguridad Física: Se refiere a la seguridad de las instalaciones de computación, su equipo y software por medios físicos (cámaras de televisión.Seguridad lógica: Se refiere a los controles lógicos dentro del mismo software (contraseñas).

Respaldo Y Recuperación
Cuando una empresa se decide a utilizar un sistema de base de datos, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de la base de datos por causa de un error humano, digamos, o una falla en el equipo o el sistema operativo que lo apoya, resulta esencial poder repara los datos implantados con un mínimo de retraso y afectando lo manos posible al resto del sistema. En teoría, por ejemplo, la disponibilidad de los datos no dañados no deberían verse afectada. El DBA debe definir y poner en práctica un plan de recuperación adecuado que incluya, por ejemplo, una descarga o vaciado "vaciado" periódico de la base de datos en un medio de alimentación de respaldo, y procedimientos para cargar otra vez la base de datos a partir del vaciado más reciente cuando sea necesario.

Normas Establecidas
Al tener un control centralizado de la base de datos, el DBA (siguiendo las indicaciones del administrador de datos) pueden garantizar la observancia de todas las normas aplicables para la representación de los datos. Estas normas pueden ser de la empresa, de la instalación, del departamento, de la industria, nacionales e internacionales, o de todos estos tipos. La normalización de formatos de los datos almacenados es deseable sobre todo como apoyo para el intercambio de información, o migración de datos entre sistemas; ( esta consideración ha cobrado especial importancia con el advenimiento de la tecnología de procedimiento distribuido. Del mismo modo, las normas para normar y documentar los datos son muy convenientes como ayuda parta el compartimiento y comprensibilidad de la información.

Administración de los datos:
Los sistemas de bases de datos requieren que la institución reconozca el papel estratégico de la información y comience activamente a administrar y planear la información como recurso corporativo. Esto significa que la institución debe desarrollar la función de administración de datos con el poder de definir los requerimientos de la información para toda la empresa y con acceso directo a la alta dirección. El director de la información (DI) o vicepresidentes de la información son el primero que aboga en la institución por los sistemas de bases de datos.La administración de la información es responsable de las políticas y procedimientos específicos mediante los cuales los datos pueden ser administrados como recursos institucionales. Entre estas responsabilidades se incluye el desarrollo de la política de información, la planeación de los datos, contemplan un diseño lógico de la base de datos por los especialistas en sistemas de información y los grupos de usuarios finales.El principio fundamental de la administración de datos es que es propiedad de la institución como un todo. Los datos pueden pertenecer en exclusiva a ninguna de las áreas de los negocios o unidades organizacionales.

Metodología para la planeación y el modelaje de datos:
Como los intereses institucionales servidos por el sistema de gestión de base de datos son muchos más amplios que aquellos del ambiente tradicional de archivos, la empresa requiere de una planeación en todo su ámbito para todos los datos. El análisis a nivel de empresa, que trata sobre el requerimiento de toda la institución (en contraposición con los requisitos de las aplicaciones individuales), es necesario para el desarrollo de bases de datos. El fin del análisis de la empresa es identificar las entidades, atributos y relaciones claves que conforman los datos de la institución.

DISEÑO DE LAS BASES DE DATOS RELACIONALES

El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la información que necesitamos.La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los valores o datos que contendrá cada uno de esos campos.Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.Los registros constituyen la información que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.

NORMALIZACION DE BASES DE DATOS

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
Cada columna debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.

Terminología relacional equivalente

Relación = tabla o archivo
Tupla = registro, fila o renglón
Atributo = columna o campo
Clave = llave o código de identificación
Clave Candidata = superclave mínima
Clave Primaria = clave candidata elegida
Clave Ajena = clave externa o clave foránea
Clave Alternativa = clave secundaria
Dependencia Multivaluada = dependencia multivalor
RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.

Relación = tabla o archivo
Tupla = registro, fila o renglón
Atributo = columna o campo
Clave = llave o código de identificación
Clave Candidata = superclave mínima
Clave Primaria = clave candidata elegida
Clave Ajena = clave externa o clave foránea
Clave Alternativa = clave secundaria
Dependencia Multivaluada = dependencia multivalor
RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.

Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.

diferiencia entre blog y wiki

WIKI

wiki es un sitio web cuyas paginas pueden ser editadas por multiples usuarios pueden crear, modificar o borrar un mismo texto que comparten.

BLOG

Un blog, es un sitio web periódicamente actualizado que recopila textos o artículos de uno o varios autores, apareciendo primero el más reciente, donde el autor conserva siempre la libertad de dejar publicado lo que crea pertinente.

diagramas

DIAGRAMAS DE CASOS DE USOS

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 confundido 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.

El diagrama anterior 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.

DIAGRAMAS DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases:

Ejemplo 1: Una persona tiene número de documento de identificación, nombres, apellidos, fecha de nacimiento, género, dirección postal, posiblemente también tenga número de teléfono de casa, del móvil, FAX y correo electrónico.

Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una persona, por lo que tendrá un número de cuenta, número de identificación del propietario de la cuenta, saldo actual, moneda en la que se maneja la cuenta.

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarán realizando diferentes operaciones que en el diagrama de clases sólo se representan como operaciones, que pueden ser:
Abrir
Cerrar
Depósito
Retiro
Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.

DIAGRAMAS 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.
Por ejemplo, Manuel: Persona.

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos estáticos del sistema y los diagramas de interacción se utilizan para ver los aspectos dinámicos del sistemas, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases, representando sólo la parte estática de un interacción, consistiendo en los objetos que colaborar pero sin ninguno de los mensajes intercambiados entre ellos.
Los diagramas de objetos se emplean para modelar la vista de dise no estática o la vista de procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estáticas,
En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantánea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena estática dentro de la historia representad a por un diagrama de interacción. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.

DIAGRAMAS DE ESTADO

Los Diagramas de Estados se usan para representar gráficamente máquinas de estados finitos. Las Tablas de Transiciones son otra posible representación.
Hay muchas formas de diagramas de estados que difieren levemente y tienen semánticas diferentes.

Una forma clásica de un diagrama de estados para una máquina de estados finitos es un grafo dirigido con los siguientes elementos:Estados Q: un conjunto finito de vertices representados normalmente por círculos y etiquetados con símbolos designadores únicos o palabras escritas dentro de ellos .

Lenguaje Unificado de Modelado (UML) especifica una notación estandarizada para diagramas de estado que puede utilizarse para describir clases, sistemas, subsistemas o incluso procesos de negocio. Los elementos básicos de notación que pueden usarse para componer un diagrama son:
Círculo lleno, apuntando a un estado inicial
Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final (si existiera)
Rectángulo redondeado, denotando un estado. En la parte superior del rectángulo está el nombre del estado. Puede contener una línea horizontal en la mitad, debajo de la cual se indican las actividades que se hacen en el estado
Flecha, denotando transición. El nombre del evento (si existiera) que causa esta transición etiqueta el cuerpo de la flecha. Se puede añadir una expresión de Guarda, encerrada en corchetes( [] ) denotando que esta expresión debe ser cierta para que la transición tenga lugar. Si se realiza una acción durante la transición, se añade a la etiqueta después de "/". NombreDeEvento[ExpresiónGuarda]/acción
Línea horizontal gruesa con x>1 líneas entrando y 1 línea saliendo o 1 línea entrando y x>1 líneas saliendo. Estas denotan Unión/Separación, respectivamente.

ademas :
El diagrama de estados y transiciones engloba todos los mensajes que un objeto puede enviar o recibir. En un diagrama de estados, un escenario representa un camino dentro del diagrama. Dado que generalmente el intervalo entre dos envíos de mensajes representa un estado, se pueden utilizar los diagramas de secuencia para buscar los diferentes estados de un objeto.
En todo diagrama de estados existen por lo menos dos estados especiales inicial y final: start y stop. Cada diagrama debe tener uno y sólo un estado start para que el objeto se encuentre en estado consistente. Por contra, un diagrama puede tener varios estados stop.

DIAGRAMAS DE SECUENCIA

Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario. En aplicaciones grandes además de los objetos se muestran también los componentes y casos de uso. El mostrar los componentes tiene sentido ya que se trata de objetos reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como objetos cuyo rol es encapsular lo definido en el caso de uso.
Para mostrar la interacción con el usuario o con otro sistema se introducen en los diagramas de secuencia las boundary classes. En las primeras fases de dise no el propósito de introducir estas clases es capturar y documentar los requisitos de interfaz, pero no el mostrar como se va a implementar dicha interfaz. Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interacción de objetos, se utilizan con frecuencia para validar los casos de uso.

Caminos alternativos de ejecución y concurrencia: En algunos casos sencillos los caminos alternativos pueden expresarse en un diagrama de secuencias alternativas de ejecución. Estas alternativas pueden representar condiciones en la ejecución o diferentes hilos de ejecución.

-Destrucción de un objeto: Se representa como una X al final de la línea de ejecución del objeto. Por ejemplo, en el diagrama anterior se muestra el final de ob2 y de ob1.

-Métodos recursivos: Un ejemplo de un método recursivo es el método more en ob1. Es un rectángulo adyacente a la activación principal y con líneas de llamada de mensajes, que indican la entrada y salida de la recursión.

El diagrama de secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

DIAGRAMA DE PAQUETES O COMPONENTES

Lo que distingue a un diagrama de componentes de otros tipos de diagramas es su contenido. Normalmente contienen componentes, interfaces y relaciones entre ellos. Y como todos los diagramas, también puede contener paquetes utilizados para agrupar elementos del modelo. Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre componentes software, sean éstos componentes de código fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de componentes, ya que las instancias específicas de cada tipo se encuentran en el diagrama de despliegue .

Así si tenemos en cuenta las dependencas asociadas al proceso de compilación un componente podría ser:

-Código fuente que depende de otros componentes (no necesariamente código fuente) que deben estar disponibles durante la compilación del componente.

-Código objeto binario, como por ejemplo una librería, que puede depender de algún código objeto con el que se linka.

-Código ejecutable que puede depender de otros programas ejecutables con los que interacciones en tiempo de ejecución.

DIAGRAMAS DE DESPLIEGUE

Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en ellos). Estarán formados por instancias de los componentes software que representan manifestaciones del código en tiempo de ejecución (los componentes que sólo sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes).

Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar

unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).

DIAGRAMAS DE COLABORACION

Este diagrama de UML es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace". Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones.

Un diagrama de colaboración es una forma alternativa al diagrama de secuencia de mostrar un escenario. Este tipo de diagrama muestra las interacciones entre objetos organizadas entorno a los objetos y los enlaces entre ellos. Los diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal - qué pasa primero, qué pasa después -. Los clientes entienden fácilmente este tipo de diagramas, por lo que resultan útiles en las primeras fases de análisis. Por contra los diagramas de colaboración proporcionan la representación principal de un escenario, ya que las colaboraciones se organizan entorno a los enlaces de unos objetos con otros.

DIAGRAMAS DE ACTIVIDADES

En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
En SysML el diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.

Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados acción (identifican una acción que se ejecuta al estar en él) y casi todas las transiciones evolucionan al término de dicha acción (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. En la figura 5.7 se presenta un ejemplo de diagrama de actividades para un mensaje de un objeto.
La interpretación de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificación o de implementación, la actividad es un método de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.

Un estado de acción representa un estado con acción interna, con por lo menos una transición que identifica la culminación de la acción (por medio de un evento implícito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representaría con un diagrama de estados. Los estados de acción se representan por un rect'angulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo.
Las flechas dirigidas entre estados de acción representan transiciones con evento implícito que, en el caso de decisiones, pueden tener una condición o guarda asociada (que al igual que en los diagramas de estado eval'ua a true o a false).
Las decisiones se representan mediante una transición m'ultiple que sale de un estado y donde cada camino tiene una etiqueta distinta.

PROGRAMACION ORIENTADA A OBJETOS

La Programación Orientada a Objetos (POO u OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de computadora. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de 1990. Actualmente son muchos los lenguajes de programación que soportan la orientación a objetos.

La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación.
Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita soltarnos un poco con este tipo de programación.

Con la programación orientada a objetos se pretende agrupar el código encapsulándolo y haciéndolo independiente, de manera que una modificación debida al crecimiento de la aplicación solo afecte a unas pocas líneas. La organización de una aplicación en POO se realiza mediante estructuras de código, también llamados objetos. Estos objetos contienen una serie de procedimientos e información destinados a resolver un grupo de tareas con un denominador común. Un procedimiento que este situado en un objeto no podrá ser usado por otro procedimiento perteneciente a otro objeto, si no es bajo una serie de reglas. Los datos que mantenga el objeto, permanecerán aislados del exterior y sólo se podrá acceder a ellos siguiendo ciertas normas. El objetivo de POO es catalogar y diferenciar el código, en base a estructuras jerárquicas dependientes, al estilo de un árbol genealógico. Los objetos se crean a partir de una serie de especificaciones o normas que definen como va a ser el objeto, esto es lo que en POO se conoce como una clase.

Características de la POO

Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más importantes:

Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.

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.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

Recolección de basura: la Recolección de basura o Garbage Collection es la técnica por la cual el ambiente de Objetos se encarga de destruir automáticamente, y por tanto desasignar de la memoria, los Objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo Objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.