martes, 15 de septiembre de 2009

bases de datos


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

martes, 8 de septiembre de 2009

the bezth famiily!

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

lozh amOh!!!

miércoles, 2 de septiembre de 2009

DIAGRAMA DE OBJETOS


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

DIAGRAMA DE CLASES DE USO


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


CASOS DE USO UML


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

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

DIAGRAMA DE COLABORACION


Este diagrama de UML 1 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. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.


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.

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


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 (Booth (1967) p. 69, Hopcroft y Ullman (1979) p. 16, Sipser (2006) p. 34).
Símbolos de Entrada Σ: una colección finita de "símbolos" de entrada o designadores Σ (Booth, Hopcroft y Ullman, Sipser). Para una
Autómata finito (AFD), Máquina de Estados Finitos no Determinista (AFN), Máquina de Estados Finita no Determinista Generalizada (GNFA), o una Máquina de Moore, la entrada está significada en cada arista, normalmente cerca del estado originador. Para una Máquina de Mealy, la entrada y la salida están significados sobre cada arista normalmente separados con una barra "/":
las etiquetas de entrada y salida Mealy sobre cada arista (flecha): "1/0" designa que el símbolo "1" causó el símbolo "0" como salida.
Símbolos de Salida Z: una colección finita de "símbolos" de salida o designadores (Booth, Hopcroft y Ullman, Sipser). Para una
Máquina de Mealy, la entrada y la salida están significados en cada arista como puede verse a continuación. Para una Máquina de Moore la salida del estado está escrita normalmente dentro del círculo del estado, separado del designador del estado con una barra "/".
Ejemplo: Si un estado tiene varias salidas el diagrama debe reflejar esto : e.g. "q5/1,0" designa que el estado q5 tiene salidas a=1, b=0. Este designador será escrito dentro del círculo del estado.
La "Función de Salida ω" representa el mapeado ω de símbolos de entrada I x estados Q en símbolos de salida Z (Booth).
Aristas δ: representa las "transiciones" entre dos estados causados por la entrada (identificados sus símbolos dibujados en los "aristas"). Un 'arista' está dibujado normalmente como una flecha dirigda desde el estado presente hacia el siguiente estado. δ representa el mapeado de los símbolos de entrada I x estados Q en los símbolos de salida Z (Booth, Hopcroft y Ullman, Sipser).
Estado inicial qo: (no visto en los ejemplos anteriores). El estado inicial qo está representado normalmente por una "flecha apuntándolo desde ninguna parte" (cf Sipser (2006) p. 34, Hopcroft y Ullman (1979) p. 16). En textos antiguos (e.g. Booth (1969), McCluskey (1965), Hill y Peterson (1974)) el estado inicial no se mostraba y era inferido del texto.
Estado(s) de Aceptación F: Si se usa -- una colección de círculos dobles usados para designar los estados de aceptación(Hopcroft y Ullman, Sipser). A veces la función de el/los estado/s de aceptación se entiende como estado/s"Final/es" (cf Hopcroft y Ullman (1979) Figure 2.15, p. 33).

DIAGRAMA DE DESPLIEGUE


El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.
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.


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.


DIAGRAMA DE SECUENCIAS


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.

UN EJEMPLO ES...


Existen dos tipos de mensajes: síncronos y asíncronos. Los mensajes síncronos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asíncronos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje