BASES DE DATOS

QUE ES?

El término base de datos fue acuñado por primera vez en 1963, en un simposio celebrado en California.
De forma sencilla podemos indicar que una base de datos no es más que un conjunto de información relacionada que se encuentra agrupada o estructurada.
Desde el punto de vista informático, una 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 manipulan ese conjunto de datos.
Desde el punto de vista más formal, podríamos definir una base de datos como un conjunto de datos estructurados, fiables y homogéneos, organizados independientemente en máquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de información diferente y no predecibles en el tiempo.
La idea general es que estamos tratando con una colección de datos que cumplen las siguientes propiedades:
o Están estructurados independientemente de las aplicaciones y del soporte de almacenamiento que los contiene.
o Presentan la menor redundancia posible.
Son compartidos por varios usuarios y/o aplicaciones

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 las bases 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.

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

· 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.
http://www.ecapra.org/wiki/images/8/8f/Estructura_de_la_base_de_datos_twb.jpeg

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.

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.

En el primer tipo se dice que existe una relación de uno a uno si el padre de la estructura de información tiene un solo hijo y viceversa, si el hijo tiene solamente un padre. En el segundo tipo se dice que la relación es de uno a muchos si el padre tiene más de un hijo, aunque cada hijo tenga un solo padre.

Inconveniente del modelo jerárquico

Relació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.

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.

La dificultad surge al manejar las conexiones o ligas entre los registros y sus correspondientes registros conectores.

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)

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.

Algunas Bases de Datos

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

DIAGRAMA DE COMPONENTES

QUE ES ?



Un diagrama de Componentes ilustra los fragmentos de software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel de abstracción más elevado que un diagrama de clase - usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como así eventualmente un componente puede comprender una gran porción de un sistema.


SUS PARTES SON:


paquetes :

Agrupación de elementos que pueden ser casos de usos clases o componentes es posible anidar paquetes entre si se representan mediante un símbolo en forma de carpeta el nombre se coloca en la pestaña y el contenido dentro de la carpeta.


componentes:

Un componente es una parte modular de un sistema, cuyo comportamiento es definido por sus interfaces proporcionadas y requeridas. Un componente se puede componer de clases múltiples, o de componentes ensamblados. Mientras que componentes más pequeños vienen juntos para crear componentes más grandes, el sistema eventualmente se puede modelar, con el estilo bloque de edificio. Construyendo el sistema en componentes discretos, la localización de datos y el comportamiento permite una menor dependencia entre las clases y los objetos, proporcionando un diseño más robusto y más sencillo de mantener.



intefaz:

Una interfaz es una especificación de comportamiento que los implementadores acordaron. Es un contrato. Implementando una interfaz las clases garantizan soportar un comportamiento requerido, lo cual permite al sistema tratar elementos no relacionados de la misma manera, a través de una interfaz común.



Exponer la interfaz :

es un método gráfico de describir las interfaces requeridas y provistas de un Componente, Clase o Parte, en un diagrama de Componente o Estructura compuesta. Este sólo identifica el hecho de que el elemento provee o requiere una interfaz; para describir el hecho de que la interfaz provista se use, o la interfaz requerida provista por otro elemento.



ensambel:

es la union mediante la interfas de un dos componentes

conector:

Un conector delegar define el ensamble interno de los puertos e interfaces externos de un componente. Al usar un conector delegar se conectan los trabajos internos del sistema con el mundo exterior, por una delegación de las conexiones de las interfaces externas

PROGRAMACION ORIENTADA A OBJETOS (POO)

QUE ES?

Programación Orientada a Objetos (POO u OOP según sus siglas en ingles) es un paradigma de programacion 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.



Los objetos son entidades que combinan estado, comportamiento e identidad:
El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
El comportamiento está definido por los procedimientos o metodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variabe o una constante ).
La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener, reutilizar y volver a utilizar.



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).los pbjetos estan compuestos por atributos identidades relaciones y metodos.


estados de objetos:



Cuando tenemos un objeto sus propiedades toman valores. Por ejemplo, cuando tenemos un coche la propiedad color tomará un valor en concreto, como por ejemplo rojo o gris metalizado. El valor concreto de una propiedad de un objeto se llama estado.


clases :



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


metodos :



Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.es lo que el objeto puede acer las acciones que puede realisar los eventos y mensajes que puede mandar.
pripiedades de las clases : Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.
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.


Evento:



un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. 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ó.



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 (para más información, seguir los enlaces respectivos):


* Abstracción: 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.

DIAGRAMAS DE COLABORACION

Diagramas de Colaboración 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. Este tipo de diagramas se utilizan más frecuentemente en la fase de dise no, es decir, cuando estamos dise nando la implementación de las relaciones. Se toma como ejemplo el caso de uso PedirProducto ya descrito como diagrama de secuencia.

diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de colaboración. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por ésto que los diagramas de colaboración se deben crear en paralelo con los diagramas de clases. Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboración numerando los mensajes, no se suele hacer, ya que para este propósito son mejores los diagramas de secuencia.
A continuación se enumeran los conceptos fundamentales de un diagrama de colaboración:
Objeto:

Se representa con un rectángulo que contiene el nombre y la clase del objeto en un formato nombreObjeto : nombreClase.
Enlaces:

Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una línea continua que une a dos objetos, acompa nada por un número que indica el orden dentro de la interacción. Pueden darse varios niveles de subíndices para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el objeto que recibe el mensaje es un atributo, un parámetro de un mensaje anterior, si es un objeto local o global.
Flujo de mensajes:

Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cerca de un enlace.
Marcadores de creación y destrucción de objetos: Puede mostrarse en la gráfica qué objetos son creados y destruidos, agregando una restricción con la palabra new o delete respectivamente.
Objeto compuesto:

Es una representación alternativa de un objeto y sus atributos. En esta representación se muestran los objetos contenidos dentro del rectángulo que representa al objeto que los contiene. Un ejemplo es el objeto Window .

Patrón de dise no:

Un diagrama de colaboración puede especificar un contrato entre objetos, parte esencial para la descripción de un patrón de dise no. Este diagrama contiene todos los elementos citados de un diagrama de colaboración, dejando libres posiblemente los tipos exactos de algunos objetos o con nombres genéricos para los mensajes. Una ``instanciación'' del patrón se representa como una elipse unida mediante flechas punteadas a los objetos o clases que participan realmente en el patrón. Estas flechas pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón.
Contexto:

Un contexto es una vista de uno o más elementos dentro del modelo que colaboran en el desarrollo de una acción. Se usa para separar los demás elementos en el modelo de este problema en particular y darle énfasis. Puede mostrar sólo los detalles relevantes de las clases u objetos que contiene, para resaltar su utilidad

Objeto activo:

Un objeto activo es el que contiene su propio flujo de control, a diferencia de un objeto pasivo que encapsula datos y sólo reacciona al enviarle mensajes. Un objeto activo se representa con un rectángulo de bordes gruesos. Puede contener otros objetos pasivos o activo

Usos
Un uso de un diagrama de comunicación es mostrar la implementación de una operación. La comunicación muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.
Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales están menos claras.

Tipos
Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones.

Mensajes
Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un número de secuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explícita.

Flujos
Generalmente, un diagrama de comunicación contiene un símbolo para un objeto durante una operación completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explícitos. Por ejemplo, un objeto pudo cambiar de localización o sus asociaciones pudieron diferenciarse.
Los diferentes símbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transición, a partir de un estado de un objeto a otro. Se dibuja como una flecha de línea discontinua con el estereotipo "become" o "conversión" y puede ser etiquetado con un número de serie para mostrar cuando ocurre. Un flujo de conversión también se utiliza para mostrar la migración de un objeto a partir de una localización a otra distinta para otro lugar.

DIAGRAMAS DE CASOS DE USO

Diagramas de Casos de Uso
Un diagrama de casos de uso (Use Case Diagram) es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mínimo un diagrama Main Use Case, que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).
Un diagrama de casos de uso muestra, por tanto, los distintos requisitos funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Se muestra como ejemplo los casos de uso de una máquina de café.
Un caso de uso, denotando un requisito funcional exigido al sistema, se representa en el diagrama por una elipse y un nombre significativo, . En el caso del ejemplo se tienen como casos de uso de la máquina de café RecibirDinero, PedirAzucar, PedirProducto, DarVueltas y Cancelar.

Figura: Representación de un actor: stickman

Un actor es una entidad que utiliza alguno de los casos de uso del sistema. Se representa mediante el símbolo de la figura acompa nado de un nombre significativo, si es necesario. En el ejemplo observamos un único actor representando al usuario de la máquina de café, aunque en un modelo de casos de uso más detallado se podría incluir otro actor para responsable del mantenimiento de la máquina. Un actor en un caso de uso representa un rol que alguien o algo podría desempe nar y no un alguien o algo específico.

Figura: Ejemplo de casos de uso de una máquina de café

Entre los elementos de un diagrama de casos de uso se pueden presentar tres tipos de relaciones, representadas por líneas dirigidas o no entre ellos:
``comunica'' (<>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. En el diagrama del ejemplo de la figura todas las líneas que salen del actor denotan este tipo de asociación (en realidad estereotipada como <>).
``usa'' ( <>) (o <> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. En el caso del ejemplo el caso de uso Cancelar incluye en su comportamiento al de DarVueltas y PedirProducto incluye también DarVueltas.
``extiende'' (<<>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas).

DIAGRAMAS DE ESTADO

Diagramas de Estado Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro.Los Diagramas de Estado representan autómatas de estados finitos, desde el p.d.v. de los estados y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento.

Estado:

Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente).

Eventos:

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:· Condición que toma el valor de verdadero o falso · Recepción de una señal de otro objeto en el modelo · Recepción de un mensaje · Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.
Envío de mensajesAdemás de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

Transición simple:

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acompañada de un texto con el siguiente formato:event-signature "[" guard-condition] "/" action-expression "^"send-clauseevent-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.

Transición interna:

Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones:

Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.

Generalización de Estados:

· Podemos reducir la complejidad de estos diagramas usando la generalización de estados. · Distinguimos así entre superestado y subestados. · Un estado puede contener varios subestados disjuntos. · Los subestados heredan las variables de estado y las transiciones externas. · La agregación de estados es la composición de un estado a partir de varios estados independientes. La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

Subestados:

Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.

Transacción Compleja:

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.

Transición a estados anidados:

Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).

Transiciones temporizadas:

Las esperas son actividades que tienen asociada cierta duración. · La actividad de espera se interrumpe cuando el evento esperado tiene lugar. · Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

DIAGRAMAS DE OBJETOS

Diagramas de objetos
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.

se representa un conjunto de objetos extraídos de la implementación de un robot. Como indica la figura, un objeto representa al propio robot, (r es una instancia de Robot), y r se encuentra actualmente en estado movimiento. Este objeto tiene un enlace con m, una instancia de Mundo, que representa una abstracción del modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un conjunto de instancias de Elemento, que representan entidades que el robot ha identificado, pero aún no ha asignado en su vista del mundo.
En este instante, m está enlazado a dos instancias de Area. Una de ellas (a2)se muestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cada una de estas paredes está etiquetada con su anchura actual, y cada una se muestra enlazada a sus paredes vecinas. Como sugiere este diagrama de objetos, el robot ha reconocido el área que lo contiene, que tiene paredes en tres lados y una puerta en el cuarto.
Como vemos los diagramas de objetos son especialmente útiles para modelar estructuras de datos complejas. Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un conjunto de clases con t relaciones entre ellas, pueden existir muchas más configuraciones posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototípicos.

DIAGRAMA DE PAQUETES

Diagrama de paquetes
Saltar a navegacion, busqueda 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.
Los Diagramas de Paquetes se usan para reflejar la organización de los paquetes y sus elementos, y para proveer una visualización de sus correspondientes nombres de espacio.

Diagrama de ejemplo
El ejemplo siguiente muestra un diagrama de Paquetes básico. El conector anidado entre ConnSeq y Controller refleja lo que revela el contenido del paquete. El contenido del Paquete se puede listar accediendo en el fondo del diagrama par amostrar la

ventana propiedades del programa, seleccionando la pestaña Elementos y seleccionando la Casilla de contenidos del paquete.

El conector «import» indica que los elementos en el paquete Entero destino, que en este ejemplo es una única clase, Entero, se importará en el paquete Controlador. El nombre de espacio del Controlador obtendrá acceso a la clase Entero; el nombre de espacio de Entero no se afecta.

El conector «merge» indica que los elementos del paquete Controlador se importarán en GenApply, incluyendo los contenidos anidados e importados de Controlador. Si un elemento ya existe en GenApply, tal como Cargador y Tiempo, las definiciones de estos elementos se expandirán por aquellas que se incluyen en el paquete Controlador. Todos los elementos agregados o actualizados por la mezcla son representados por una relación de generalización de vuelta a este paquete.

Tenga en cuenta: Los elementos privados de un paquete no se pueden importar o mezclar.

DIAGRAMA DE DESPLIEGUE

Diagrama 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).

Un ejemplo de diagrama de ejecución . En este caso se tienen dos nodos, AdminServer y Joe'sMachine. AdminServer contiene la instancia del componente Scheduler y un objeto activo (proceso) denominado meetingsDB. En Joe'sMachine se encuentra la instancia del componente software Planner, que depende de la interfaz reservations, definida por Scheduler.
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos que se representa como un cubo 3D en los diagramas de implementación.
Las instancias de componentes de software muestran unidades de software en tiempo de ejecución y generalmente ayudan a identificar sus dependencias y su localización en nodos. Pueden mostrar también qué interfaces implementan y qué objetos contienen. Su representación es un rectángulo atravesado por una elipse y dos rectángulos más peque nos. Un ejemplo de componente que implementa dos interfaces .
Los diagramas de despliegue muestran la configuración en funcionamiento del sistema, incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de respuesta requerido, etc.
La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha dise nado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificarla plataforma sobre la que se ejecuta el software del sistema y para que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se trata de la relación entre hardware y software se utilizan los diagramas de despliegue para razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software.
Esta vista cubre principalmente la distribución, entrega e instalación de las partes que configuran un sistema físico. Los diagramas de despliegue se suelen utilizar para modelar:
Sistemas empotrados: Un sistema empotrado es un colección de hardware con una gran cantidad de software que interactúXa con el mundo físico. Los sistemas empotrados involucran software que controla dispositivo (motores,actuadores) que a su ves están controlados por estímulos externos como sensores.
Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremos 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 sistemas a 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 no de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.