Normalizacion...

¿Qué es normalización?

Normalización es un proceso que clasifica relaciones, objetos, formas de relación y demás elementos en grupos, en base a las características que cada uno posee. Si se identifican ciertas reglas, se aplica un categoría; si se definen otras reglas, se aplicará otra categoría.
Estamos interesados en particular en la clasificación de las relaciones BDR. La forma de efectuar esto es a través de los tipos de dependencias que podemos determinar dentro de la relación. Cuando las reglas de clasificación sean más y más restrictivas, diremos que la relación está en una forma normal más elevada. La relación que está en la forma normal más elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de importancia para nosotros:

• La cantidad de espacio requerido para almacenar los datos es la menor posible;
• La facilidad para actualizar la relación es la mayor posible;
• La explicación de la base de datos es la más sencilla posible.

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.

Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1

Primera Forma Normal (1FN)
Una tabla está en Primera Forma Normal sólo si
• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria.
• La tabla no contiene atributos nulos.
• Si no posee ciclos repetitivos.
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN)
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser removidos de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y .
Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente dado que ni SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN, PNUMBER} ENAME es parcialmente dependiente dado que SSN ENAME mantiene la dependencia.

Tercera Forma Normal (3FN)
La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos +son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Forma Normal de Boyce-Codd (FNBC)
La tabla se encuentra en BCNF si cada determinante, atributo que determina completamente a otro, es clave candidata.

Cuarta Forma Normal (4FN)
Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN)
Una tabla se encuentra en 5FN si:
• La tabla esta en 4FN
• No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.

Base De Datos...

¿Que es Base 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.

Conceptos:
es la colección de datos aparentes usados por el sistema de aplicaciones de una determinada empresa.
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.
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.

Objetos de la base 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 básicos 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.

Propiedades generales de los campos:
PROPIEDAD DESCRIPCIÓN TIPO DE CAMPO
Tamaño del campo Permite establecer la longitud máxima de un campo de texto numérico. Texto, numérico, contador
Formato Permite determinar la apariencia de presentación de los datos, utilizando los formatos predefinidos o nuestros propios formatos Todos, excepto OLE y Memo
Lugares decimales Permite especificar el número de cifras decimales para mostrar los números. Numérico y moneda
Máscara de entrada Permite controlar y filtrar los caracteres o valores que los usuarios introducen en un control de cuadro de texto, evitando errores y facilitando su escritura. Texto, numérico, fecha/hora, moneda
Título Permite definir una etiqueta de campo predeterminada para un formularios o informe Todos
Valor predeterminado Introduce en el campo un valor cuando se agregan nuevos registros (long. Máx. 255 caracteres) Todos, excepto OLE y contador
Regla de validación Permite escribir la condición que deben satisfacer los datos introducidos para ser aceptados Todos, excepto OLE y contador
Texto de validación Define el texto del mensaje que se visualiza cuando los datos no cumplen las condiciones enumeradas en la regla de validación Todos excepto OLE y contador
Requerido Permite especificar si es necesario que exista un valor en un campo. Todos excepto contador
Permitir longitud cero Permite especificar si una cadena de longitud cero ("") es una entrada válida para el campo Texto, memo
Indexado Define un campo como índice o campo clave. Texto, numérico, contador, fecha/hora.
Las propiedades de un campo, se establecen seleccionando el campo y haciendo clic en la propiedad deseada del cuadro PROPIEDADES DEL CAMPO situado en la parte inferior de la ventana DISEÑO DE TABLA.
Access tiene una configuración predeterminada para las propiedades de cada uno de los tipos de campo. Sin duda la más importante es el tamaño del campo, ya que este nos permitirá hacer una estimación del espacio ocupado por nuestra base de datos en el disco fijo.

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.

Creación 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.
Componentes principales:
Datos. Los datos son la Base de Datos propiamente dicha.
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
1. El programador de aplicaciones, quien crea programas de aplicación que utilizan la base de datos.
2. El usuario final, quien accesa la Base de Datos por medio de un lenguaje de consulta o de programas de aplicación.
3. El administrador de la Base de Datos (DBA: Data Base Administrator), quien se encarga del control general del Sistema de Base de Datos.

Administración de la 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 datos.
Responsabilidades
1.- Apoyo y asesoría en el proceso de dbms
2.- Definición de Información de la base de datos
3.- Mantener la Relación y Comunicación
4.- Diseñar la Estructura y Estrategia
5.- Atender y Servir como punto de enlace entre usuarios y la Organización.
6.- Definir estándares y procedimientos para respaldos y recuperación de la información que contienen la base de datos.

El sistema organizador de Base de Datos (DBMS):
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 administrador de la Base de Datos (DBA):
El DBA es la persona encargada de definir y controlar las bases de datos corporativas, además proporciona asesoría a los usuarios y ejecutivos que la requieran.

Tipos de modelos de Datos:
Existen fundamentalmente tres alternativas disponibles para diseñar las bases de datos: el modelo jerárquico, el modelo de red y el modelo relacional.
a)._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.
b)._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.
c)._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)

Relación Entre Los Datos:
Sistema de administración de bases de datos, que almacena información en tablas (filas y columnas de datos) y realiza búsquedas utilizando los datos de columnas especificadas de una tabla para encontrar datos adicionales en otra tabla. En una base de datos relacional, las filas representan registros (conjunto de datos acerca de elementos separados) y las columnas representan campos (atributos particulares de un registro).

Al realizar las búsquedas, una base de datos relacional hace coincidir la información de un campo de una tabla con información en el campo correspondiente de otra tabla y con ello produce una tercera tabla que combina los datos solicitados de ambas tablas. Por ejemplo si una tabla contiene los campos NÚM-EMPLEADO, APELLIDO, NOMBRE Y ANTIGÜEDAD y otra tabla contiene los campos DEPARTAMENTO, NÚM-EMPLEADO y SALARIOS, una base de datos relacional hace coincidir el campo NÜM-EMPLEADO de las dos tablas para encontrar información, como por ejemplo los nombres de los empleados que ganan un cierto salario o los departamentos de todos los empleados contratados a partir de un día determinado.

En otras palabras, una base de datos relacional utiliza los valores coincidentes de dos tablas para relacionar información de ambas. Por lo general, los productos de base de datos para microcomputadoras o microordenadores son base de datos relaciónales.

Árboles Binarios
Los árboles de grado 2 tienen una especial importancia. Se le conoce con el nombre de Árboles binarios. Se define un árbol binario como un conjunto finito de elementos (nodos) que bien está vació o está formado por una raíz con dos árboles binarios disjuntos, llamados subárbol izquierdo y derecho de la raíz.
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. Mas adelante explicaremos que son las tablas.

Las bases de datos relacionales están constituidas por una o más tablas que contienen la información ordenada de una forma organizada. Cumplen las siguientes leyes básicas:
a. Generalmente, contendrá muchas tablas.
b. Una tabla sólo contiene un número fijo de campos.
c. El nombre de los campos de una tabla es distinto.
d. Cada registro y de la es único.
e. El orden de los registros y de los campos no está determinado
f. Para cada campo existe un conjunto de valores posible.

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.

Tendencias futuras:
La explotación efectiva de la información dará ventaja competitiva a las organizaciones.
Las bases de datos orientadas a objetos empleadas para diseño y manufactura asistida por computadora CAD/CAM serán utilizados a un mismo nivel que las Bases se Datos relacionales de la actualidad.
Los lenguajes de consulta (SQL) permitirán el uso del lenguaje natural para solicitar información de la Base de Datos, haciendo más rápido y fácil su manejo.

Algunas Bases de Datos:
• SQL
• ORACLE
• DBASE
• IV
• FOXPRO
• FOXBASE
• PARADOS
• ACCES
• APPROACH.

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.

Base de datos relacionales:
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 sistemas relacionales son importantes porque ofrecen muchos 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.

Creación De Una Tabla:
1. En la ventana de base de datos, realice un clic en la ficha Tablas.
2. Elija el botón "Diseño".
3. Esto creará una tabla vacía en el modo de presentación de diseño.

Diagrama de (POO)

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.

Conceptos fundamentales
La programación orientada a objetos es una nueva forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
Herencia: (por ejemplo, herencia de la clase D a la clase C) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D.
Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto).
También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
Componentes de un objeto:atributos, identidad, relaciones y métodos.
Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Diagrama de Casos de Uso

Los casos de uso son los óvalos y las figuras con forma "humana" son los actores.
La OMG define una notación gráfica para los casos de uso, pero se abstiene de definir algún formato escrito para describir la funcionalidad de los casos de uso en detalle; debido a esto algunas personas tienen el concepto erróneo acerca de que un caso de uso es su notación gráfica, cuando es la descripción escrita de escenarios la que da el verdadero valor al caso de uso.

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.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones.

Inclusión (include o use) Es una forma de interacción, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de retorno.

Extensión (Extend) Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión. La extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."

Generalización En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea solida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intensión y extensión."

Diagrama de Objetos

Un diagrama de objeto está hecho para las instancias de tiempo real de los diagramas de clase o partes de los diagramas de clase. Como tal, un diagrama de objeto puede ser visto para ser un ejemplo de un diagrama de clase. Los diagramas de objetos pueden ser dibujados para explicar los diagramas de clase o para capturar ciertos escenarios de la vida real como ejemplos para demostrar conceptos y/o ciertos estados de los diagramas de clase como un punto de tiempo.

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, Miguel: Persona.

Diagrama de Despliegue

El modelo de despliegue describe cómo una aplicación se despliega a través de una infraestructura. La intención del modelo de despliegue no es para describir la infraestructura, pero mejor dicho el camino en cual los componentes específicos deben corresponder a una aplicación que despliega a través de él.

En el ejemplo, un despliegue físico de una aplicación financiera es mostrado. Las múltiples computadoras del cliente/usuario con el "runtime" de componentes Windows 2000 y el componente del cliente de la aplicación financiera puede conectarse por vía TCP/IP a cualquier aplicación del servidor, ya que estos son múltiples. La aplicación Server/s- corriendo SCO – Unix y la aplicación financiera –conectados por vía TCP/IP hacia el servidor de la base de datos central- corriendo HP-UX –Oracle y tiene la base de datos maestra de la financiera sobre este.
Mensaje ando y flujo de trabajo entre el cliente- PC’s y entre la aplicación del servidor son ejecutados usando MS-Outlook y MS-Exchange. MS-Exchange soporte de flujo de trabajo y mensaje ando.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Usos
Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.

Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Diagrama de Paquetes

Los paquetes son usados para organizar y manipular la complejidad de los modelos largos. Un grupo de paquetes modelan elementos y los diagramas semejantes como el uso de casos, clases, actividades, procesos, estados, etc., y sus diagramas asociados; en tal camino que eso puede ser remitido como uno entero. Los paquetes pueden ser representados en un diagrama, remitido como Diagrama de Paquete.
Un paquete es representado por un rectángulo con una pequeña lengüeta donde el nombre del paquete es marcado.

Los paquetes pueden tener relación con otros paquetes para mostrar que las dependencias están entre los paquetes. Las Relaciones de Dependencia son usadas qué paquetes están dependiendo sobre cada otro.

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.