Tutorial UML

UML 2.1 avanza el xito de UML 2.0, y se est convirtiendo en el estndar aceptado para la especificacin, documentacin y visualizacin de sistemas de software. El Lenguaje Unificado de Modelado (UML) tambin se utiliza para el modelado de sistemas no-software, y es ampliamente realizado en los sectores ms industria, incluyendo finanzas, militar y de ingeniera. Si eres nuevo en el Lenguaje de Modelado Unificado, nuestra Introduccin a UML es un punto de partida recomendado. UML 2 define trece tipos de diagramas de base, dividido en dos grupos generales: 1. Diagramas de Modelado Estructural diagramas de estructura esttica definir la arquitectura de un modelo. Se utilizan para modelar las "cosas" que conforman un modelo - las clases, objetos, interfaces y componentes fsicos. Adems, se utilizan para modelar las relaciones y dependencias entre los elementos. - diagramas de paquetes se utilizan para dividir el modelo en contenedores lgicos, o "paquetes", y describir las interacciones entre ellos a un alto nivel. - Clase o diagramas estructurales definir los elementos bsicos de un modelo: los tipos, clases y materiales generales utilizados para construir un modelo completo. - Los diagramas de objetos muestran cmo las instancias de los elementos estructurales se relacionan y se utiliza en tiempo de ejecucin. - Estructura compuesta diagramas proporcionan un medio de capas elemento estructura y centrarse en un detalle interior, la construccin y las relaciones. - diagramas de componentes se utilizan para modelar un nivel ms alto o ms estructuras complejas, generalmente se construyen con una o ms clases, y proporcionando una interfaz bien definida. - diagramas de despliegue muestran la disposicin fsica de artefactos significativos dentro de un entorno real en el mundo. 2. Comportamiento Diagramas de Modelado diagramas de comportamiento de captura de las variedades de interaccin y de estados instantneos dentro de un modelo, ya que "ejecuta" a travs del tiempo; el seguimiento de cmo el sistema va a actuar en un entorno real, y observando los efectos de una accin o evento, incluyendo sus resultados. - Utilice diagramas de casos se utilizan para modelar usuario / interacciones del sistema. Ellos definen el comportamiento, los requisitos y obstculos en forma de guiones o escenarios. - Los diagramas de actividades tienen un amplio nmero de usos, desde la definicin de flujo de los programas de base, para capturar los puntos de decisin y acciones dentro de un proceso generalizado. - Estado diagramas de mquinas son esenciales para comprender el momento a la condicin instantnea, o "estado de ejecucin" de un modelo cuando se ejecuta. - diagramas de comunicacin muestran la red, y la secuencia de mensajes y la comunicacin entre objetos en tiempo de ejecucin, durante una instancia de colaboracin. - Los diagramas de secuencia estn estrechamente relacionados con los diagramas de comunicacin y muestran la secuencia de los mensajes cursados entre los objetos utilizando una lnea de tiempo vertical. - Calendario diagramas de secuencia y diagramas de estado del fusible para proporcionar una visin del objeto del estado de un tiempo, y los mensajes que modifican ese estado. - Interaccin general diagramas de actividad fusible y diagramas de secuencia para permitir que los fragmentos de la interaccin que se pueden combinar fcilmente con los puntos de decisin y de los flujos.

El Lenguaje Unificado de Modelado (UML) ha convertido rpidamente en el estndar de facto para la construccin de software orientado a objetos. Este tutorial ofrece una visin tcnica de los 13 diagramas de UML con el apoyo de Enterprise Architect. UML 2 semntica se explican en detalle en el nuevo tutorial de UML 2.0. En primer lugar ... Qu es UML? El OMG especificacin establece lo siguiente: "El Lenguaje de Modelado Unificado (UML) es un lenguaje grfico para visualizar, especificar, construir y documentar los artefactos de un sistema de software de obra. El UML ofrece una forma estndar para escribir planos de un sistema, incluyendo conceptual cosas tales como los procesos de negocio y funciones del sistema, as como cosas concretas, como las declaraciones lenguaje de programacin, esquemas de base de datos y de software reutilizables componentes ". El punto importante a sealar aqu es que UML es un lenguaje "para especificar y no un mtodo o procedimiento. El UML se usa para definir un sistema de software, para detallar los artefactos en el sistema, para documentar y construir - es el idioma que el plan est escrito pulg El UML se puede utilizar en una variedad de maneras de apoyar un desarrollo de software metodologa (como el Proceso Unificado de Rational) -, pero ella misma no se especifica que la metodologa o proceso.

UML define la notacin y la semntica de los siguientes dominios: - La interaccin del usuario o de casos de uso Modelo - describe la frontera y la interaccin entre el sistema y los usuarios.Corresponde en algunos aspectos a un modelo de requisitos. - La interaccin o el modelo de comunicacin - describe cmo los objetos en el sistema va a interactuar unos con otros para realizar su trabajo. - El Estado o Modelo Dinmico - Listas de Estado describen los estados o condiciones que las clases de asumir con el tiempo.Actividad grficos describen los flujos de trabajo del sistema llevar a cabo. - La lgica o el modelo de clase - se describen las clases y los objetos que componen el sistema. - La fsica de componentes Modelo - describe el software (y en ocasiones componentes de hardware) que componen el sistema. - El Modelo de Despliegue Fsico - describe la arquitectura fsica y el despliegue de los componentes en que la arquitectura de hardware. El UML tambin define mecanismos de extensin para extender el UML para satisfacer las necesidades especializadas (por ejemploBusiness Process Modeling extensiones). Parte 2 de este tutorial se expande sobre cmo se utiliza el UML para definir y construir los sistemas actuales. Vase tambin Business Process Modeling (pdf).

Tutorial UML - Parte 2

Hemos establecido en la Parte 1 que el UML es un lenguaje para especificar los artefactos y las interacciones de un sistema de software. Tambin hemos visto que se trata de 6 dominios principales - de utilizar modelos de la sentencia, a travs de modelos dinmicos y lgico para el modelo de implementacin fsica final - y que los mecanismos de extensin se han incluido para permitir adiciones especializados para la notacin del modelo. As que ... Cmo se utiliza el UML? El UML se usa normalmente como parte de un desarrollo de software proceso, con el apoyo de una adecuada herramienta CASE, para definir los requisitos, las interacciones y los elementos de un sistema informtico propuesto. La naturaleza exacta del proceso depende de la metodologa de desarrollo utilizada. Un proceso de ejemplo podra ser algo como lo siguiente: 1. Captura de un Modelo de Procesos de Negocio. Esto se utiliza para definir el negocio de las actividades a nivel alto y los procesos que ocurren en una organizacin y proporcionar una base para el caso modelo de uso. El modelo de procesos de negocio normalmente se hacen con ms un sistema de software implementar (es decir, que incluye los procesos manuales y otros). 2. Mapa de un Modelo de Casos de Uso del Modelo de Procesos de Negocios para definir exactamente qu funcionalidad tiene la intencin de proveer desde la perspectiva de los usuarios de negocios. A medida que cada caso de uso se agrega, crea un vnculo trazable desde los procesos de negocios apropiados para el caso de uso (es decir, una conexin de realizacin). Este trazado claramente establece que la funcionalidad del nuevo sistema proporcionar para cumplir los requisitos empresariales incluidas en el modelo de proceso. Tambin asegura que no existen casos de uso sin un propsito. 3. Filtrar los Casos de Uso - incluir los requisitos, limitaciones, rango de complejidad, notas y escenarios. Esta informacin sin ambigedades describe lo que el caso de uso hace, cmo se ejecuta y las limitaciones para su ejecucin. Asegrese de que el caso de uso sigue cumpliendo los requisitos de procesos de negocio. Incluir la definicin de las pruebas del sistema para cada caso de uso para definir los criterios de ACEPTACIN para cada caso de uso. Tambin incluye algunos scripts de prueba de aceptacin de los usuarios para definir cmo el usuario va a probar esta funcionalidad y lo que los criterios de aceptacin. 4. De las entradas y salidas del Modelo de Procesos de Negocios y los detalles de los casos de uso, empezar a construir un modelo de dominio (objetos de negocio de alto nivel), diagramas de secuencia, diagramas de colaboracin y una interfaz de modelos de usuario. En ellas se describen las "cosas" en el nuevo sistema, la forma en que esas partes interactan y la interfaz de un usuario va a utilizar para ejecutar caso escenarios de uso. 5. A partir del modelo de dominio, el modelo de interfaz de usuario y los diagramas del escenario crear el modelo de la clase. Se trata de una especificacin precisa de los objetos en el sistema, sus datos o atributos y su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en las jerarquas de clase mediante la herencia. diagrama de mensajes escenario tpicamente se asignarn a las operaciones de clase. Si un marco existente o el diseo del patrn se va a utilizar, puede permitir la importacin de los elementos del modelo existente para su uso en el nuevo sistema. Para cada clase definir las pruebas unitarias y pruebas de integracin para probar completamente i) que las funciones de clase tal como se especifica internamente y que ii) la clase interacte con otras clases y componentes conexos como se esperaba. 6. Como el modelo de la clase se desarrolla, se puede fraccionar en paquetes discretos y componentes. Un componente representa una porcin de despliegue de software que recoge el comportamiento y los datos de una o ms clases y expone una interfaz estricta a otros consumidores de sus servicios. As que desde el modelo de la clase un modelo de componentesest diseado para definir el empaquetamiento lgica de clases. Para cada componente de definir las pruebas de integracin para confirmar que los componentes de la interfaz cumple con la especificacin dada en relacin con otros elementos del software. 7. Simultneamente con el trabajo que han hecho, los requisitos adicionales deberan haber sido capturados y documentados. Por ejemplo - los requisitos funcionales, requisitos funcionales, requisitos de seguridad, las responsabilidades, los planes de lanzamientos y etc Colecta estos dentro del modelo y mantener al da el modelo madura. 8. El modo de implementacin del define la arquitectura fsica del sistema. Este trabajo puede comenzar temprano para capturar las caractersticas de despliegue fsico - el hardware, sistemas operativos, capacidades de red, interfaces y software de soporte conformarn el nuevo sistema, donde se desplegar y qu parmetros se aplican a la recuperacin de desastres, la confiabilidad, la espalda- seguridad y soporte. A medida que el modelo se desarrolla la arquitectura fsica se actualizar para reflejar el actual sistema que se propone. 9. Construir el sistema: Sacar todas las piezas discretas del modelo y asignar a uno o ms desarrolladores. En una acumulacin de casos de uso impulsada esto significar la asignacin de un caso de uso para el equipo de desarrollo, hacer que ellos construyan las pantallas, los objetos de negocio, las tablas de bases de datos, y los componentes relacionados necesarios para ejecutar ese caso de uso. A

medida que cada caso de uso se construya debe ir acompaada de la unidad terminada, la integracin y pruebas del sistema. Una construccin dirigida del componente puede ver los componentes discretos de software asignados a los equipos de desarrollo para la construccin. 10. Pista de defectos que surgen en la fase de pruebas contra los elementos del modelo relacionados - por ejemplo. defectos del sistema de prueba en contra de casos de uso, defectos de prueba de unidad contra las clases y Seguimiento de los cambios, etc contra los elementos del modelo relacionados con la gestin de "scope creep". 11. Actualizar y perfeccionar el modelo a medida que avanza el trabajo - siempre evaluando el impacto de los cambios y mejoras del modelo en la obra posterior. Utilice un enfoque iterativo para trabajar a travs del diseo en bloques discretos, siempre evaluando la construccin actual, los requisitos posteriores y los descubrimientos que salen a la luz durante el desarrollo. 12. Entrega del software completo y probado en un test, entorno de produccin. Si una entrega por etapas se lleva a cabo, a continuacin, esta migracin de software de construccin desde la prueba a la produccin pueden ocurrir varias veces durante la vida til del proyecto. Tenga en cuenta que el proceso anterior es necesariamente breve en la descripcin, deja mucho sin decir y no puede ser la manera de trabajar o seguir el proceso que ha adoptado. Se da como un ejemplo de cmo el UML puede ser utilizado para apoyar un proyecto de desarrollo de software.

El proceso de modelo de negocio

Descargar versin PDF

Introduccin

Tradicionalmente, el UML se ha asociado ms con la ingeniera de software y diseo de sistemas que con el anlisis y modelado de procesos de negocio. Sin embargo, el estndar UML 2.x proporciona un rico conjunto de modelos de comportamiento que son muy tiles en la modelizacin de los procesos, actividades, personas e informacin crtica para cada negocio. Ms all de la notacin estndar UML, dos respetados y probada UML "extensiones" que existan ms estrictas para la captacin de procesos de negocio y constructos relacionados. La primera es Business Process Modeling Notation (BPMN), que ha ganado enorme popularidad y se est convirtiendo en un nuevo estndar para el modelado y diseo de procesos de negocio. El segundo es el perfil-Ericsson Penker que tiene menos popularidad, pero todava proporciona un medio poderoso y nico de visualizar y comunicar los procesos empresariales y el necesario flujo de informacin dentro de una organizacin. Este artculo ofrece una introduccin muy alto nivel tanto de estas extensiones ", mostrando cmo se pueden utilizar en Enterprise Architect y algunos de los modelos comunes de las construcciones que utilizan.

Business Process Modeling Notation (BPMN)

BPMN define un Diagrama de Procesos de Negocio (BPD), que se basa en una tcnica de diagramas de flujo a medida para la creacin de modelos grficos de las operaciones de proceso de negocio. Es una notacin que sea fcilmente comprensible por todos los usuarios de negocios, de los analistas de negocio que crean los borradores iniciales de los procesos, a los desarrolladores tcnicos responsables de la aplicacin de la tecnologa que llevar a cabo los procesos y, finalmente, a la gente de negocios que se gestionar y supervisar estos procesos. Un modelo consiste en diagramas de BPMN simple con un pequeo conjunto de elementos grficos.
Elementos de flujo

1. 2.

3.

Actividades. Una actividad es el trabajo que se realiza dentro de un proceso de negocio y est representada por un rectngulo redondeado. Eventos. Un evento es algo que sucede durante el curso de un proceso de negocio que afecta a la secuencia o el calendario de actividades de un proceso. Los eventos son representados como pequeos crculos con lmites distintos para diferenciar los eventos de partida (lnea fina negro), los eventos intermedios (doble lnea) y los eventos finales (lnea grueso de color negro). Los eventos pueden mostrar iconos dentro de su forma de identificar el gatillo o el resultado del evento. Gateways. Gateways se utilizan para controlar los flujos de secuencia de cmo convergen y divergen en un proceso.Gateways pueden representar las decisiones, cuando uno o ms caminos no estn permitidos, o bien pueden representar a tenedores concurrentes. Secuencia de los flujos. Un flujo de secuencia se usa para mostrar el orden en que las actividades se realizan dentro de un proceso. Un flujo de secuencia se representa por una lnea con una punta de flecha slida. los flujos de mensajes. Un flujo de mensajes se utiliza para mostrar el flujo de mensajes entre dos entidades, donde las piscinas se utilizan para representar entidades. Un flujo de mensajes se representa mediante una lnea discontinua con un crculo de color claro en el origen y punta de flecha en el blanco. Asociaciones. Una asociacin se utiliza para asociar la informacin y los artefactos con los objetos de flujo. Una asociacin est representada por una lnea discontinua que puede o no puede tener una lnea de punta de flecha en el extremo de destino si no hay una razn para mostrar la direccionalidad.

1. 2.

3.

Swimlanes (Particiones)

1. 2.

Piscinas. Una piscina representa un participante en un proceso, en que un participante puede ser una entidad de negocios o papel. Se representa como una particin del proceso. Lanes. Una va es una sub-divisin de una piscina y se utiliza para organizar y clasificar las actividades dentro de la piscina.

Artefactos

1. 2.

Datos objetos. Un objeto de datos no tiene un efecto directo sobre un proceso, pero no proporciona informacin relevante para el proceso. Se representa como un rectngulo con la esquina superior doblada. Grupos. Un grupo es un medio informal para agrupar elementos de un proceso. Se representa como un rectngulo con un borde de lnea discontinua.

3.

Las anotaciones. Una anotacin es un mecanismo para el modelador BPMN para proporcionar informacin adicional a la audiencia de un diagrama BPMN. Est representada por un rectngulo abierto que contiene el texto de la anotacin.

Ejemplos BPMN

Ejemplo 1:

El diagrama anterior muestra una serie de caractersticas clave de BPMN, especficamente la capacidad de crear descomposicin jerrquica de los procesos en tareas ms pequeas, la capacidad de representar y construcciones de la capacidad de tener eventos externos interrumpir el flujo del proceso normal. "Actividades" aguas arriba "y" actividades "aguas abajo" son eventos intermedios disparado vnculo, es decir, los conectores fuera de pgina. "Repetir para cada proveedor" es una actividad de bucle, que repite sus tres actividades que figuran ya sea de una vez por cada proveedor o hasta un lmite de tiempo se supera. El evento intermedio montado en el borde inferior de la actividad es un evento de tiempo-ha disparado. Ejemplo 2:

El diagrama anterior muestra un proceso que se inicia por un evento - en este caso un evento de inicio de mensajes ha disparado la cual notifica el proceso que el grupo de trabajo est activo. El diagrama tambin muestra un bucle de ser controlado por un evento de temporizador, y muestra una puerta de enlace la decisin (en este caso, una puerta de enlace la decisin XOR) el control cuando el bucle se termina. Ejemplo 3:

Este diagrama ilustra el uso de las piscinas para mostrar los procesos de interaccin y la forma en que los mensajes se transmiten entre los consorcios utilizar los conectores de flujo de mensajes.

Negocio Eriksson-Penker Modelado perfil

Esta seccin proporciona una introduccin a la terminologa e iconos utilizados en el Modelo de Procesos de Negocio, y le da una rpida introduccin a algunos Lenguaje Unificado de Modelado (UML) conceptos y su aplicacin en el Modelo de Negocios de Enterprise Architect de Proceso. Un proceso de negocio: 1. 2. 3. 4. 5. 6. 7. Tiene un objetivo Tiene entradas especficas Tiene productos especficos Utiliza los recursos de Tiene una serie de actividades que se realizan en un poco de orden Puede afectar a ms de una unidad organizativa. De organizacin horizontal de impacto Crea valor de algn tipo para el cliente. El cliente puede ser interno o externo.

Modelos de Procesos

Un proceso de negocios es un conjunto de actividades diseadas para producir un producto especfico para un determinado cliente o mercado. Implica un fuerte nfasis en cmo el trabajo se realiza dentro de una organizacin, a diferencia de enfoque de un producto en lo que es un proceso. As, una ordenacin especfica de las actividades laborales a travs del tiempo y lugar, con un comienzo, un final, y claramente definidas las entradas y salidas: una estructura para la accin. Suministro vnculo de objeto de informacin. Un enlace de suministro indica que la informacin u objeto vinculado al proceso no se utiliza en la fase de procesamiento. Por ejemplo, para las plantillas puede ser utilizado muchas veces para dar nuevas rdenes de un cierto estilo - las plantillas no se modifican o agotado en el marco de esta actividad.

Enlace desde la fuente objeto de recursos. Un enlace de entrada indica que el objeto o recurso adjunto se consume en el rgimen de perfeccionamiento. Como un ejemplo, como pedidos de los clientes son procesados que se hayan completado y firmado, y por lo general se utilizan slo una vez al recurso nico (orden). vnculo objetivo de oponerse Meta. Un vnculo objetivo indica el objeto unido al proceso de negocio describe el objetivo del proceso. Una meta es la justificacin de negocio para el ejercicio de la actividad. flujo de un objeto a otro enlace de salida Objeto de enlace de flujo de eventos de eventos. Un enlace de flujo del objeto indica algn objeto se pasa a un proceso de negocio. Captura el paso de control a otra entidad o proceso, con el paso implcita de Estado o informacin de una actividad a otra.

Objetivo

Un proceso de negocio tiene bien definido el objetivo. Esta es la razn por la que la organizacin hace este trabajo, y debe ser definida en trminos de los beneficios que este proceso tiene para la organizacin en su conjunto y en la satisfaccin de las necesidades del negocio. Objetivos de enlace a los procesos. Un enlace Meta indica el objeto unido al proceso de negocio describe el objetivo del proceso.Una meta es la justificacin de negocio para el ejercicio de la actividad.
Informacin

Los procesos de negocio utilizar la informacin para adaptar o completar sus actividades. La informacin, a diferencia de los recursos, no se consume en el proceso - sino que se utiliza como parte del proceso de transformacin. La informacin puede provenir de fuentes externas, de clientes, desde las unidades internas de la organizacin e incluso puede ser el producto de otros procesos. productos Informacin enlace a los Procesos de Negocios. Un enlace de la fuente indica que la informacin u objeto vinculado al proceso no se utiliza en la fase de procesamiento. Por ejemplo, para plantillas pueden ser utilizados una y otra vez para proporcionar los nuevos pedidos de un cierto estilo - las plantillas no se modifican o se agotan en el marco de esta actividad.
Salida

Un proceso de negocio normalmente se producen una o ms salidas de valor para el negocio, ya sea para uso interno de satisfacer las exigencias externas. Una salida puede ser un objeto fsico (como un informe o factura), una transformacin de los recursos brutos en un nuevo acuerdo (un horario diario o lista) o un resultado global de las empresas tales como completar un pedido del cliente. Una salida de un proceso de negocio pueden incluirse en el otro proceso, ya sea como un elemento solicitado o un disparador para iniciar nuevas actividades.
Recurso

Un recurso es una aportacin a un proceso de negocio, y, a diferencia de la informacin, normalmente se consume durante el procesamiento. Por ejemplo, ya que cada tren diario se ejecuta y los datos reales registrados, los servicios de recursos es "consumido" por lo que el proceso de registrar las horas reales de trenes se refiere. Recursos enlace a los Procesos de Negocios. Un enlace de entrada indica que el objeto o recurso adjunto se consume en el rgimen de perfeccionamiento. Como un ejemplo, como pedidos de los clientes son procesados que se hayan completado y firmado, y por lo general se utilizan slo una vez al recurso nico (orden).

El Modelo de Componentes
El modelo de componentes muestra los componentes de software que se utilizar para construir el sistema. Estos pueden ser construidos a partir del modelo de clases y escrito desde cero para el nuevo sistema, o pueden ser trados de otros proyectos y vendedores de tercera parte. Los componentes son agregaciones de alto nivel de piezas de software ms pequeas, y proporcionar un enfoque de "recuadro negro" bloques de construccin para la construccin de software.

Componente de la notacin

Un componente puede ser algo as como un control ActiveX - ya sea un control de interfaz de usuario o un servidor de reglas de negocio. Los componentes se dibujan como muestra el siguiente diagrama:

El diagrama de componentes
El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, la comunicacin, localizacin y otras condiciones.

Interfaces

Los componentes tambin pueden exponer a las interfaces. Estos son los puntos de entrada visibles o servicios que un componente es la publicidad y la puesta a disposicin de otros componentes de software y clases. Normalmente, un componente est formado por muchas clases internas y paquetes de clases. Incluso puede ser ensamblado a partir de una coleccin de componentes ms pequeos.

Componentes y Nodos
Un diagrama de despliegue muestra el despliegue fsico del sistema en una produccin (o prueba) medio ambiente. Muestra dnde se ubicarn los componentes, lo que en los servidores, mquinas o hardware. Se puede ilustrar los vnculos de red, ancho de banda LAN y etc

Requerimientos
Los componentes pueden requisitos han unido para indicar sus obligaciones contractuales - esto es, qu servicio que prestan en el modelo. Requisitos documento de ayuda en el comportamiento funcional de los elementos de software.

Restricciones

Los componentes pueden tener restricciones adjunto, que indican el medio ambiente en el que operan. Precondiciones especifican lo que debe darse antes de un componente puede realizar alguna funcin; postcondiciones indican lo que va a ser cierto despus de que un componente ha realizado un trabajo e invariantes especifican lo que debe seguir siendo vlido para el periodo de vigencia componentes.

Escenarios

Los escenarios son textuales y descripciones procesal de las demandas de un objeto a travs del tiempo y describir la forma en que un componente de las obras. Mltiples escenarios puede ser creado para describir la ruta de acceso bsico (una carrera perfecta a travs), as como las excepciones, errores y otras condiciones.

Trazabilidad

Usted puede indicar la trazabilidad a travs de enlaces realizacin. Un componente puede implementar otro elemento del modelo (por ejemplo, un caso de uso) o un componente puede ser ejecutado por otro elemento (por ejemplo, un paquete de clases). Al ofrecer vnculos a la realizacin y de componentes que se pueden asignar las dependencias entre los elementos del modelo y la trazabilidad desde los requisitos iniciales hasta la ejecucin final.

Un ejemplo

El siguiente ejemplo muestra cmo los componentes pueden estar vinculados a proporcionar un marco conceptual / vista lgica de una construccin de sistemas. Este ejemplo tiene que ver con el servidor y los elementos de seguridad de una tienda de libros on-line. Incluye elementos como el servidor web, servidor de seguridad, las pginas ASP y etc Componentes de servidor Este diagrama ilustra la disposicin de los componentes del lado del servidor principal que requerir la construccin de una tienda de libros on-line. Estos componentes son una mezcla de la costumbre construido y comprado artculos que se ensamblar para proporcionar la funcionalidad requerida.

Componentes de seguridad
El diagrama muestra cmo los componentes de seguridad de software de seguridad como la entidad emisora de certificados, navegador, servidor web y otros elementos de modelo de trabajo en conjunto para asegurar la provisin de seguridad en el sistema propuesto.

El Modelo Dinmico
El modelo dinmico se utiliza para expresar y modelar el comportamiento del sistema con el tiempo. Incluye soporte para diagramas de actividad, diagramas de estado, diagramas de secuencia y extensiones incluyendo modelado de procesos de negocios.

Los diagramas de secuencia

Los diagramas de secuencia se usan para mostrar la interaccin entre los usuarios, las pantallas, los objetos y entidades dentro del sistema. Proporciona un mapa secuencial de paso de mensajes entre los objetos en el tiempo. Frecuentemente, estos diagramas se colocan debajo de casos de uso en el modelo para ilustrar el escenario de caso de uso - cmo un usuario interacta con el sistema y lo que sucede internamente para hacer el trabajo. A menudo, los objetos se representan utilizando iconos estereotipados especiales, como en el ejemplo siguiente. El objeto etiquetado pantalla de entrada se muestra mediante el icono de la interfaz de usuario. El objeto etiquetado SecurityManager se muestra mediante el icono del controlador. El objeto etiquetado usuarios se muestra mediante el icono de la entidad.

Los diagramas de actividad

Los diagramas de actividades se utilizan para mostrar cmo diferentes flujos de trabajo en el sistema se construyen, cmo se inician y los caminos, posiblemente, muchas decisiones que se pueden tomar de principio a fin. Tambin pueden ilustrar el procesamiento en paralelo donde se puede producir en la ejecucin de algunas actividades.

Listas de Estado
Listas de Estado se utilizan para detalles de las transiciones o cambios de estado de un objeto puede ir a travs del sistema.Muestran cmo un objeto se mueve de un estado a otro y las normas que rigen ese cambio. Listas de Estado suele tener un comienzo y la condicin final.

Modelo de Procesos
Un modelo de proceso es una extensin de UML de un diagrama de actividad para modelar procesos de negocio - este diagrama muestra lo que el objetivo del proceso, las entradas, salidas, eventos e informacin que estn involucradas en el proceso.

El Modelo Lgico
Un modelo lgico es una visin esttica de los objetos y las clases que componen el diseo y anlisis espacial. Por lo general, un modelo de dominio es un perdedor, vista de alto nivel de Business Objects y entidades, mientras que el modelo de clases es un diseo ms riguroso y centrado modelo. Esta discusin se refiere principalmente a la clase del modelo

El modelo de la clase

Una clase es un estndar de UML que se usa para detalles de la pauta de que los objetos sern producidos en tiempo de ejecucin.Una clase es una especificacin - un objeto una instancia de una clase. Las clases se pueden heredar de otras clases (es decir, heredan todo el comportamiento y estado de sus padres y aadir nuevas funcionalidades propias), tiene otras clases como atributos, delegar responsabilidades a otras clases e implementar interfaces abstractas. El modelo de la clase est en el centro de desarrollo orientado a objetos y diseo - que expresa el estado persistente del sistema y el comportamiento del sistema. Una clase encapsula el estado (atributos) y ofrece servicios para manipular ese estado (comportamiento). Un buen diseo orientado a objetos limita el acceso directo a los atributos de clase y ofrece servicios que manipulan los atributos en nombre de la persona que llama. La ocultacin de datos y de servicios asegura la exposicin de actualizacin de datos se realiza slo en un lugar y de acuerdo a normas especficas - para sistemas grandes de la carga de mantenimiento de cdigo que tiene acceso directo a los elementos de datos en muchos lugares es extremadamente alta. La clase est representada de la siguiente manera:

Tenga en cuenta que la clase tiene tres reas distintas: 1. El nombre de clase (y el estereotipo, si se aplica) 2. Los atributos de clase de rea (que es interno elementos de datos) 3. El comportamiento - tanto privados como pblicos Atributos y mtodos pueden ser marcados como - Privado, indicando que no son visibles a los que llaman fuera de la clase - Protegidas, que son accesibles solamente a los nios de la clase - Pblica, que son visibles para todos herencia de clases se muestra a continuacin: una clase abstracta en este caso, es el padre de dos hijos, cada uno de ellos hereda caractersticas de la clase base y se extiende con su propio comportamiento.

modelos de la Clase puede ser recogida en paquetes de comportamiento que hace referencia y el estado. El siguiente diagrama ilustra esto.

El Modelo Fsico
La fsica y la implementacin del modelo proporciona un modelo detallado de los componentes de la forma en que se despleg a travs de la infraestructura del sistema. La capacidad de la red de detalles, las especificaciones del servidor, los requisitos de hardware y otra informacin relacionada con la implementacin del sistema propuesto. Ver Despliegue

PM01: Modelo Fsico El modelo fsico muestra dnde y cmo los componentes del sistema ser implementado. Es un mapa que de la disposicin fsica del sistema. Un diagrama de despliegue muestra el despliegue fsico del sistema en una produccin (o prueba) medio ambiente.Muestra dnde se ubicarn los componentes, lo que en los servidores, mquinas o hardware. Se puede ilustrar los vnculos de red, ancho de banda LAN y etc

Un nodo se utiliza para describir cualquier servidor, estacin de trabajo o la acogida de hardware que se utilice para desplegar componentes en el entorno de produccin. Tambin puede especificar los enlaces entre nodos y asignar los estereotipos (como TCP / IP) y los requisitos para ellos. Los nodos tambin pueden tener caractersticas de funcionamiento, estndares mnimos de hardware, sistema operativo y los niveles documentados etc. La pantalla de abajo ilustra las propiedades comunes que puede establecer para un nodo.

El Modelo de Casos de Uso

Un Modelo de casos de uso describe la funcionalidad propuesta de un nuevo sistema. Un caso de uso representa una unidad discreta de interaccin entre un usuario (humano o mquina) y el sistema. Esta interaccin es una sola unidad de trabajo significativo, como Crear cuenta o Detalles Ver cuenta. Cada caso de uso describe la funcionalidad que se construir en el sistema propuesto, que puede incluir la funcionalidad de otro caso de uso o ampliar otro caso de uso con su propio comportamiento.

Una descripcin de casos de uso general incluye:

Comentarios generales y notas describiendo el caso de uso. Requisitos - Los requisitos de forma funcional de las cosas que un caso de uso debe proporcionar al usuario final, tales como <ability para actualizar pedido>. Estos corresponden a las especificaciones funcionales que se encuentran en las metodologas estructuradas, y la forma de un contrato que el caso de uso realiza alguna accin o preste algn valor para el sistema. Limitaciones - Las reglas formales y las limitaciones de un caso de uso opera bajo, la definicin de lo que puede y no se puede hacer. Estos incluyen: o Pre-condiciones que deben haberse producido ya o estar en su lugar antes que el caso de uso se ejecute, por ejemplo, pedido> <Crear debe preceder <modificar pedido> o Post-condiciones que deben cumplirse una vez que el caso de uso est completa, por ejemplo, <el pedido est modificado y consistente> o Invariantes que siempre tiene que ser verdad lo largo del tiempo el caso de uso opera, por ejemplo, un orden siempre debe tener un nmero de cliente. Escenarios - formal, las descripciones secuenciales de los pasos dados para llevar a cabo el caso de uso, o el flujo de los acontecimientos que ocurren durante un ejemplo de casos de uso. Estos pueden incluir escenarios mltiples, para hacer frente a circunstancias excepcionales y distintas alternativas de tratamiento. Estos normalmente se crean en el texto y corresponden a una representacin textual del diagrama de secuencia. diagramas de Escenario - Los diagramas de secuencia para describir el flujo de trabajo; similares a los Escenarios pero descrito grficamente. atributos adicionales, como la fase de ejecucin, nmero de versin, rango de complejidad, estereotipo y estado.

Actores
Los casos de uso suelen deberse a que "actores", que son humanos o de mquinas entidades que utilicen o interactuar con el sistema para realizar un trabajo significativo que les ayuda a alcanzar una meta. El

conjunto de casos de uso que un actor tiene acceso define su rol global en el sistema y el alcance de su accin.

Incluye y extiende las relaciones entre casos de uso

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento normal. En general, se supone que el casos de uso incluidos se llamarn cada vez que se ejecute el camino base. Por ejemplo, al enumerar una serie de pedidos de clientes a elegir antes de modificar una orden seleccionada, el <listar rdenes> de casos de uso se incluira cada vez que el <modificar pedido> de casos de uso se ejecute. Un Caso de Uso puede ser incluido por uno o ms casos de uso, por lo que ayuda a reducir la duplicacin de funcionalidad al factorizar el comportamiento comn en los casos de uso que se reutilizan muchas veces. Un Caso de Uso puede extender el comportamiento de otro, tpicamente cuando ocurren situaciones excepcionales. Por ejemplo, si un usuario debe obtener la aprobacin de alguna autoridad superior antes de modificar un determinado tipo de pedido del cliente, entonces el <obtener aprobacin> de casos de uso opcional, podra ampliar el <modificar orden> de casos de uso.

Los diagramas de secuencia

Los diagramas de secuencia proporcionan una representacin grfica de la interaccin entre los objetos en el tiempo. stos muestran tpicamente a un usuario oa un actor y los objetos y los componentes que interactan en la ejecucin de un caso de uso.Un diagrama de secuencia representa tpicamente un nico escenario de Caso de Uso "o flujo de los acontecimientos. Los diagramas son una excelente manera de documentar los escenarios de uso y tanto la captura de los objetos necesarios a principios de anlisis y verificar la utilizacin por los objetos ms tarde en el diseo. Los diagramas muestran el flujo de mensajes desde un objeto a otro, y como tales, representan los mtodos y los actos patrocinados por una clase / objeto. El siguiente ejemplo de un diagrama de secuencia que el usuario o actor a la izquierda iniciando un flujo de eventos y mensajes que corresponden al escenario de casos de uso. Los mensajes que pasan entre objetos se convierten en operaciones de clases en el modelo final.

Diagrama de aplicacin
Un Caso de Uso es una descripcin formal de la funcionalidad que el sistema tendr cuando se construya. Un diagrama de implementacin se asocia tpicamente con un caso de uso para documentar qu elementos de diseo (por ejemplo, componentes y clases) implementar la funcionalidad del Caso de Uso en el nuevo sistema. Esto proporciona un alto nivel de trazabilidad al diseador, al cliente y el equipo que construir el sistema. La lista de casos de uso que un componente o una clase est ligada a los documentos de la funcionalidad mnima que debe ser implementada por el componente.

El ejemplo anterior muestra que el caso de uso 'Login' implementa el requisito formal '1 .01 iniciar sesin en el sitio web ". Tambin muestra que el componente de lgica de negocios" y "componente de pginas ASP"

aplicar algunas o todas las 'funcionalidad Login'. Un refinamiento adicional es mostrar la pantalla 'Login' (una pgina web) como la aplicacin del "caso Login 'uso. Estos enlaces de implementacin o realizacin definen la trazabilidad desde los requisitos formales, a travs de casos de uso de los componentes y pantallas.

Base de datos de modelado en UML

Introduccin Cuando se trata de abastecimiento confiable, persistencia de los objetos flexibles y eficientes para los sistemas de software, diseadores y arquitectos de hoy en da se enfrentan a muchas opciones. Desde el punto de vista tecnolgico, la eleccin es por lo general entre puro orientado a objetos, los hbridos ObjetoRelacionales, pura soluciones relacionales y personalizada basada en abierto o de propiedad formatos de archivo (por ejemplo, XML, el almacenamiento OLE estructurado). Desde el aspecto proveedor de Oracle, IBM, Microsoft, poeta y otros ofrecen soluciones similares pero a menudo incompatibles. Este artculo est sobre una sola de estas opciones, es decir, las capas de un modelo de clase orientada a objetos en la parte superior de una base de datos puramente relacional. Esto no quiere decir este es el nico, el mejor o ms simple solucin, pero pragmticamente es una de las ms comunes, y uno que tiene el potencial para la mayora de mal uso. Empezaremos con un rpido recorrido por los dos dominios de diseo que estamos tratando de puente: en primer lugar, el modelo de clase orientada a objetos representados en el UML, y en segundo lugar el modelo de base de datos relacional. Para cada dominio que busque slo en las caractersticas principales que afectan a nuestra tarea. A continuacin, se ver en las tcnicas y cuestiones relacionadas con la asignacin del modelo de clase para el modelo de base de datos, incluyendo la persistencia de objetos, el comportamiento de objetos, las relaciones entre los objetos y la identidad del objeto. Concluiremos con una revisin del perfil UML de datos (como se propone por Rational Software). Cierta familiaridad con el diseo orientado a objetos, UML y el modelado de bases de datos relacionales se supone. El modelo de la clase en UML es el artefacto principal producido para representar la estructura lgica de un sistema de software.Captura el tanto de las condiciones de datos y el comportamiento de los objetos dentro del dominio del modelo. Las tcnicas para el descubrimiento y la elaboracin de ese modelo estn fuera del alcance de este artculo, as que vamos a suponer la existencia de un modelo bien diseado clase que requiere asignacin a una base de datos relacional. El modelo de la clase La clase es la entidad de base lgica en el UML. Define los datos y el comportamiento de una unidad estructural. Una clase es una plantilla o modelo a partir de qu instancias u objetos se crean en tiempo de ejecucin. Cuando desarrollamos un modelo lgico como una estructura jerrquica en UML se tratan de manera explcita las clases. Cuando trabajamos con diagramas dinmicos, como los diagramas de secuencia y colaboracin, se trabaja con objetos o instancias de clases y sus interacciones en tiempo de ejecucin. El director de ocultamiento de datos o la encapsulacin se basa en la localizacin del efecto. Una clase tiene elementos de datos interna que es responsable. El acceso a estos elementos de datos deben ser expuestos a travs del comportamiento de la clase o interfaz. La adhesin a este principales resultados en ms cdigo mantenible.

Comportamiento El comportamiento es capturado en el modelo de la clase usando las operaciones que se definen para la clase. Las operaciones pueden ser visibles desde el exterior (pblico), visible a los nios (protegido) o se oculte (privado). Mediante la combinacin de datos ocultos con una interfaz de acceso pblico y ocultos o protegidos de manipulacin de datos, un diseador de la clase puede crear unidades estructurales muy fcil de mantener que el apoyo en vez de obstaculizar el cambio.

Las relaciones y la identidad Asociacin es una relacin entre dos clases que indica que al menos uno de los lados de la relacin conoce y utiliza o manipula de alguna manera al otro lado. Esta relacin puede, mediante funcionales (hacer algo por m) o estructural (algo para m). Para este artculo es la relacin estructural que es ms interesante: por ejemplo puede ser una clase de direccin asociada a una clase de persona. La asignacin de esta relacin en el espacio de datos relacionales requiere cierto cuidado.

La agregacin es una forma de asociacin que implica el cobro de una clase de objetos dentro de otra. La composicin es una forma ms fuerte de agregacin que implica un objeto se compone realmente de los dems. Al igual que la relacin de asociacin, esto implica un atributo de clase compleja que requiere una cuidadosa consideracin en el proceso de asignacin al dominio relacional. Mientras que una clase representa el modelo o modelo de la que muchos casos se pueden crear objetos, un objeto en tiempo de ejecucin requiere de algn medio de identificarse de tal manera que los objetos asociados pueden actuar sobre la instancia de objeto correcto. En un lenguaje de programacin como C + +, punteros de objeto puede ser circular y se celebr para permitir el acceso a objetos de una instancia de objeto nico. A menudo, sin embargo, un objeto ser destruido y requiere que se vuelve a crear como lo fue durante su instancia activo de ltimo. Estos objetos requieren un mecanismo de almacenamiento para guardar su estado interno y las asociaciones de entrada y para recuperar ese estado cuando sea necesario. La herencia proporciona el modelo de clase con un medio de factorizar el comportamiento comn en clases generalizadas que luego actan como los antepasados de muchas variaciones sobre un tema comn. La herencia es un medio para controlar tanto la reutilizacin y la complejidad. Como veremos, el modelo relacional no tiene contrapartida directa de la herencia, lo cual crea un dilema para el modelista datos de asignacin de un modelo de objetos en un marco relacional. Navegacin de un objeto en tiempo de ejecucin a otro se basa en referencias absolutas. Un objeto tiene algn tipo de enlace (puntero o un identificador de objeto nico) con el que localizar o volver a crear el objeto requerido.

El Modelo Relacional El modelo de datos relacional ha sido de alrededor durante muchos aos y tiene un historial demostrado de que proporciona un rendimiento y flexibilidad. Se trata esencialmente de conjunto basado y tiene como unidad fundamental de la mesa ", que se compone de un conjunto de uno o ms" columnas ", cada uno de los cuales contiene un elemento de dato. Tablas y columnas: una tabla relacional es una coleccin de una o ms columnas, cada una de las cuales tiene un nombre nico dentro de la tabla construir. Cada columna se define como de un cierto tipo de datos bsicos, tales como un nmero, texto o datos binarios. Una definicin de la tabla es una plantilla de la que se crean filas de la tabla, cada fila de ser una instancia de una instancia de cuadro posible. El modelo relacional slo ofrece un modelo de datos de acceso pblico. Todos los datos estn igualmente expuestos y abiertos a cualquier proceso de actualizacin, consulta o manipularla. El ocultamiento de informacin es desconocida. Comportamiento El comportamiento asociado a una tabla se basa generalmente en el negocio o lgica normas que se aplican a dicha entidad. Las restricciones pueden ser aplicadas a las columnas en forma de requisitos de singularidad, las restricciones de integridad relacional con otras tablas / registros, los valores admisibles y los tipos de datos. Los desencadenantes proporcionar un comportamiento adicional que puede estar asociada con una entidad. Habitualmente esto se usa para hacer cumplir la integridad de los datos antes o despus de actualizaciones, inserciones y eliminaciones. procedimientos almacenados de base de datos proporcionan un medio para extender la funcionalidad de base de datos a travs de extensiones de lenguaje propio que se utiliza para la construccin de unidades funcionales (scripts). Estos procedimientos funcionales no se asignan directamente a las entidades, ni tener una relacin lgica con ellos. Navegacin a travs de conjuntos de datos relacional se basa en el recorrido de filas y uniones de tablas. SQL es el lenguaje principal utilizado para seleccionar filas y localizar los casos de un cuadro. Las relaciones y la identidad La clave principal de una tabla proporciona el valor de identificacin nico para una fila determinada. Hay dos tipos de clave principal que nos interesa: en primer lugar la tecla significativa, formado por columnas de datos que tienen un significado en el mbito empresarial, y el segundo el identificador nico y separado, como un valor de contador, que no tienen sentido de negocios pero identifican de forma nica una fila. Vamos a discutir esto y las consecuencias de las claves significativas despus. Una tabla puede contener columnas que se asignan a la clave principal de otra tabla. Esta relacin entre las tablas define una clave externa e implica una relacin estructural o de asociacin entre las dos tablas. Resumen Desde la visin de conjunto podemos ver que el modelo de objetos se basa en entidades discretas con los atributos del estado (/ datos) y el comportamiento, con acceso a los datos encapsulados generalmente a

travs de la interfaz pblica nica clase. El modelo relacional de datos expone todos por igual, con un apoyo limitado para asociar el comportamiento con los elementos de datos a travs de disparadores, ndices y restricciones. Usted navega a la informacin diferenciada en el modelo de objetos moviendo de un objeto a la utilizacin de identificadores nicos de objetos y relaciones que se establecen objeto (similar a un modelo de red de datos). En el modelo relacional a encontrar al unirse a las filas y filtrar los resultados que estn utilizando SQL utilizando criterios de bsqueda generalizada. Identidad en el modelo de objetos puede ser una referencia de tiempo de ejecucin o persistente identificador nico (llamado un OID). En el mundo de relaciones, claves primarias definen la singularidad de un conjunto de datos en el espacio global de los datos. En el modelo de objetos que tienen un rico conjunto de relaciones: la herencia, agregacin, asociacin, la composicin, la dependencia y otros. En el modelo relacional realmente slo podemos indicar una relacin con las claves externas. Habiendo visto los dos dominios de inters y comparamos algunas de las caractersticas importantes de cada uno, vamos a una breve digresin para examinar la propuesta de notacin para representar los modelos de datos relacional en el UML. Los Datos de Perfil UML Modelo El modelo de datos del perfil es un proyecto de extensin de UML (y actualmente en revisin - enero de 2001) para apoyar el modelado de bases de datos relacionales en UML. Incluye extensiones personalizadas para las cosas tales como tablas, esquemas de bases de datos, las claves de la tabla, los disparadores y las limitaciones. Si bien esto no es una extensin ratificado, an muestra una posible tcnica para el modelado de una base de datos relacional en el UML. Tablas y columnas en una tabla los datos del perfil UML es una clase con el cuadro estereotipo aparecer en pantalla como por encima de la mesa con un icono en la esquina superior derecha. columnas de base de datos se modelan como atributos de la tabla de clase.

Por ejemplo, por encima de la figura muestra algunos atributos asociados a la tabla de clientes. En el ejemplo, un identificador de objeto se ha definido como la clave principal, as como otras dos columnas, nombre y direccin. Tenga en cuenta que el ejemplo anterior define el tipo de columna en trminos de los tipos de datos nativos DBMS. Comportamiento Hasta ahora slo hemos define la lgica (esttica) estructura de la tabla y, adems, debemos describir el comportamiento asociado con columnas, incluidos los ndices, llaves, triggers, procedimientos y Comportamiento etc se representa como operaciones estereotipadas. La siguiente figura muestra nuestra tabla de arriba con una restriccin de clave principal y el ndice, ambos definidos como operaciones de patrn:

Tenga en cuenta que la bandera de PK en la columna "OID" define la clave principal lgica, mientras que la operacin estereotipada " PK idx_customer00" define las obligaciones y de comportamiento asociados con la aplicacin de la clave principal (es decir, el comportamiento de la clave principal). Agregando a nuestro ejemplo, podemos ahora definir el comportamiento adicionales tales como disparadores, restricciones y procedimientos almacenados como en el ejemplo siguiente:

El ejemplo ilustra el posible comportamiento siguiente: 1. 2. 3. 4. 5. 6. 7. Una restriccin de clave principal (PK); Una restriccin de clave externa (FK); Una limitacin del ndice (Index); Un disparador (Trigger); Una restriccin de unicidad (nico); Un procedimiento almacenado (Proc) - no estn formalmente parte del perfil de datos, sino un ejemplo de una tcnica de modelado sea posible, y un Comprobacin de validez (cheque).

Usando la notacin contemplados anteriormente, es posible modelar estructuras complejas de datos y el comportamiento a nivel de DBMS. Adems de esto, el UML provee la notacin para expresar las relaciones entre las entidades lgicas. Relaciones Los datos de modelado UML perfil define una relacin como una dependencia de ningn tipo entre dos tablas. Se representa como una asociacin estereotipada e incluye un conjunto de claves primarias y externas. El perfil de datos va a exigir que una relacin siempre involucra a un padre y su hijo, el padre definir una clave principal y el nio la aplicacin de una clave externa sobre la base de la totalidad o parte de los padres de clave principal. La relacin que se denomina identificar si la tecla nio extranjero incluye todos los elementos de la matriz de clave principal y "la no identificacin 'si slo algunos elementos de la clave principal se incluyen. La relacin puede incluir restricciones de cardinalidad y ser modelado con la correspondiente PK - FK par nombrado como funciones de asociacin. La ilustracin de abajo ilustra este tipo de modelacin relacin con UML.

El Modelo Fsico UML tambin proporciona algunos mecanismos para representar la estructura fsica global de la base de datos, su contenido y ubicacin desplegado. Para representar una base de datos fsica en UML, utilice un componente estereotipado como en la figura siguiente:

Un componente representa una entidad discreta y desplegables dentro del modelo. En el modelo fsico, un componente puede ser asignada a una pieza fsica de hardware (un nodo UML). Para representar el

esquema dentro de la base de datos, utiliza el esquema estereotipo en un paquete. Una tabla puede ser colocado en una esquema para establecer su alcance y la ubicacin dentro de una base de datos.

Mapeo del Modelo de clases para el Modelo Relacional Despus de describir las dos reas de inters y la notacin que se utilizar, ahora podemos volver nuestra atencin sobre la forma de mapa o traducir de un dominio a otro. La estrategia y la secuencia se presenta a continuacin est destinado a ser sugestivo y no prescriptivo - adaptar los pasos y procedimientos a sus necesidades personales y el medio ambiente. 1. Modelo de Clases En primer lugar vamos a suponer que son la ingeniera de un nuevo esquema de base de datos relacional a partir de un modelo de clase que hemos creado. Esto es obviamente ms fcil la direccin como los modelos de permanecer bajo nuestro control y podemos optimizar el modelo de datos relacional para el modelo de clase. En el mundo real puede ser que usted necesita para la capa de un modelo de clase en la parte superior de un modelo de herencia de datos - una situacin ms difcil y que presenta sus propios desafos. Para el debate actual se centra en la primera situacin. Como mnimo, el modelo de su clase debe capturar las asociaciones, la herencia y agregacin entre los elementos. 2. Identificar los objetos persistentes Despus de haber construido nuestro modelo de clase tenemos que separarlo en aquellos elementos que requieren persistencia y los que no. Por ejemplo, si hemos diseado nuestra aplicacin utilizando el patrn de diseo Modelo-Vista-Controlador, a continuacin, las clases slo en la seccin de modelo requerira estado persistente. 3. Supngase que cada clase persistente mapas a una tabla relacional Un supuesto bastante grande, pero uno que funcione en la mayora de los casos (dejando de lado la cuestin de la herencia por el momento). En el modelo ms sencillo de una clase de los mapas modelo lgico a una tabla de relaciones, ya sea en su totalidad o en parte. La extensin lgica de esto es que un solo objeto (o instancia de una clase) se asigna a una fila de tabla nica.

4. Seleccione una estrategia de la herencia. La herencia es quizs la relacin ms problemtica y construccin lgica del modelo orientado a objetos que requiere que se traduce en el modelo relacional. El espacio relacional es esencialmente plana, cualquier entidad que est completo en su auto, mientras que el modelo de objetos es a menudo muy profunda con una jerarqua de clases bien desarrolladas. El modelo de clase profunda puede tener muchas capas de atributos heredados y el comportamiento, dando lugar a un objeto final, con todas las funciones en tiempo de ejecucin. Hay tres formas bsicas para manejar la traduccin de la herencia a un modelo relacional: a. Cada jerarqua de clases tiene una sola tabla correspondiente que contiene todos los atributos heredados para todos los elementos - esta tabla es por tanto la unin de todas las clases de la jerarqua. Por ejemplo, Una persona, padre, hijo y nieto todos pueden formar una jerarqua de clases individuales, y elementos de cada uno de ellos aparecen en la tabla de relaciones misma; Cada clase en la jerarqua tiene un correspondiente tabla de los atributos slo accesibles por esa clase (incluidos los atributos heredados). Por ejemplo, si el nio se hereda de la persona solamente, a continuacin, la tabla contendr los elementos de la persona y su nica hija; Cada generacin en la jerarqua de clases tiene una tabla que contiene slo que los atributos reales de generacin. Por ejemplo, nios que se asignarn a una sola tabla con el Nio atributos slo

b. c.

Hay casos en que se hizo para cada criterio, pero yo sugerira ms simple, ms fcil de mantener y menos propenso a errores, es la tercera opcin. La primera opcin proporciona el mejor rendimiento en tiempo de ejecucin y el segundo es un compromiso entre la primera y la ltima. La primera opcin se aplana la jerarqua y localiza todos los atributos de una tabla - conveniente para las actualizaciones y consultas de cualquier clase en la jerarqua, pero difcil para autenticar y mantener. Las reglas de negocio asociadas con una fila son difciles de aplicar, ya que cada fila puede crear una instancia como cualquier objeto en la jerarqua. Las dependencias entre las columnas pueden volverse muy complejos. Adems, una actualizacin de cualquier clase en la jerarqua potencialmente impactar todas las dems clases de la jerarqua, como las columnas se agregan, eliminan o modificada de la tabla. La segunda opcin es un compromiso que proporciona una mejor encapsulacin y elimina las columnas vacas. Sin embargo, un cambio en una clase padre puede necesitar para ser replicado en muchas tablas secundarias. Peor an, los datos de sus padres en las clases de dos o ms hijos puede ser redundante almacenada en muchas mesas, si los atributos de un padre se modifican, se realiza un esfuerzo considerable para localizar a los hijos a cargo y actualizacin de los registros afectados. La tercera opcin ms acordes con el modelo de objetos, y cada clase en la jerarqua asignada a su tabla independiente. Puesta al da de los padres o los nios se localizan en el lugar correcto. El mantenimiento es tambin relativamente sencilla, ya que cualquier modificacin de una entidad se limita a una sola tabla de relacin tambin. El lado negativo es la necesidad de reconstruir la jerarqua en tiempo de ejecucin con precisin volver a crear un estado de clase del nio. Un objeto hijo puede necesitar una variable miembro persona para representar a sus padres modelo. Como ambos requieren de carga, dos llamadas de base de datos se requieren para inicializar un objeto. Al intensificarse la jerarqua, con ms generaciones, el nmero de llamadas de base de datos necesaria para inicializar o actualizar un aumento de solo objeto. Es importante comprender los problemas que surgen cuando se asigna la herencia en un modelo relacional, para que pueda decidir cul es la mejor solucin para usted. 5. Para cada categora estn un identificador de objeto nico Tanto en el relacional y el objeto del mundo, existe la necesidad de identificar de forma nica un objeto o entidad. En el modelo de objetos, los objetos no persistentes en tiempo de ejecucin suelen ser identificados por referencia directa o mediante un puntero al objeto. Una vez que se crea un objeto, podemos referirnos a l por su identidad en tiempo de ejecucin. Sin embargo, si escribimos un objeto para el almacenamiento, el problema es cmo recuperar la instancia de exactamente la misma en la demanda. El mtodo ms conveniente es definir un OID (identificador de objeto) que se garantiza que sea nico en el espacio de nombres de inters. Esto puede ocurrir en la clase, embalaje o de nivel de sistema, en funcin de las necesidades reales. Un ejemplo de un nivel de sistema OID podra ser un GUID (identificador nico global) creado con guidgen de Microsoft "herramienta", por ejemplo. (A1A68E8E-CD92-420b-BDA7-118F847B71EB). A nivel de clase OID podra ser implementado usando un simple numrica (por ejemplo, contra 32 bits). Si un objeto contiene referencias a otros objetos, puede hacerlo a travs de su OID. Un escenario completo de tiempo de ejecucin se puede cargar desde el almacenamiento razonablemente eficiente. Un punto importante acerca de los valores OID anterior es que no tienen ningn significado inherente all de la identidad simple. Slo son punteros lgica y nada ms. En el modelo relacional, la situacin es a menudo muy diferentes. Identidad en el modelo relacional es normalmente implementado con una clave principal. Una clave principal es un conjunto de columnas de una tabla que identifican de manera nica una fila. Por ejemplo, el nombre y la direccin pueden identificar nicamente a un 'cliente'. En caso de otras entidades, tales como un 'vendedor', la referencia del cliente ", que aplican una llave exterior basada en la clave principal de la 'cliente'. El problema con este enfoque para nuestros propsitos es el impacto de contar con informacin de negocios (como el nombre y domicilio del cliente) incrustado en el identificador. Imagina tres o cuatro mesas tienen claves externas basadas en las llaves de su cliente principal, y un cambio de sistema requiere que el

cliente clave principal para el cambio (por ejemplo, para incluir tipo de cliente). El trabajo necesario para modificar tanto la tabla 'cliente' y las entidades relacionadas con la clave externa es bastante grande. Por otra parte, si un OID se implement como la clave principal y formaron la clave externa para otras tablas, el alcance del cambio se limita a la tabla principal y el impacto del cambio es por lo tanto mucho menos. Adems, en la prctica, una clave principal sobre la base de datos de negocio pueden estar sujetas a cambios. Por ejemplo, un cliente puede cambiar de direccin o el nombre. En este caso los cambios se deben propagar correctamente a todas las entidades relacionadas con otros, por no mencionar la dificultad de cambiar la informacin que forma parte de la clave principal. Un OID se refiere siempre a la misma entidad - no importa qu otros cambios de la informacin. En el ejemplo anterior, un cliente puede cambiar el nombre o la direccin y los cuadros relacionados requieren ningn cambio. Cuando la cartografa modelos de objetos a tablas relacionales, a menudo es ms conveniente para aplicar la identidad absoluta utilizando en lugar de negocio principal OID claves relacionadas. El OID como principales y externas enfoque clave suele dar mejores calculos y actualizar los tiempos para los objetos y el esfuerzo de minimizar el mantenimiento. En la prctica, un negocio relacionado clave principal podra ser sustituido por:

Una restriccin de unicidad o un ndice en las columnas que se trate; Las reglas de negocio integrado en el comportamiento de la clase; Una combinacin de 1 y 2.

Una vez ms, la decisin de utilizar las teclas de sentido y / o OID depender de los requisitos exactos del sistema en desarrollo. 6. Mapa de los atributos a columnas En general, se seguir de cerca los datos simples atributos de una clase a las columnas de la tabla relacional. Por ejemplo, un campo de texto y nmero puede representar el nombre de una persona y la edad respectivamente. Este tipo de asignacin directa debera plantear ningn problema - slo tiene que seleccionar el tipo de datos apropiados en el modelo relacional del proveedor para alojar su atributo class. Para los atributos complejos (es decir, los atributos que son objetos de otro tipo) utiliza el enfoque detallado a continuacin para el manejo de las asociaciones y agregacin. 7. Mapa de las asociaciones con claves externas Ms complejos atributos de clase (es decir, aquellas que representan a otras clases), suelen ser modeladas como las asociaciones.Una asociacin es una relacin estructural entre los objetos. Por ejemplo, una persona puede vivir en una direccin. Si bien esto puede ser modelado como una persona tiene la Ciudad, Calle y Cdigo Postal atributos, tanto en el objeto y el mundo relacional nos inclinamos a la estructura de esta informacin como una entidad separada, de una direccin. En el mbito objeto de una direccin representa un objeto fsico nico, posiblemente con un OID nico. En lo relacional, una direccin puede ser una fila en una tabla de direcciones, con otras entidades con una clave externa a la tecla de direccin principal. En ambos modelos a continuacin, est la tendencia a pasar la informacin de direccin en una entidad separada. Esto ayuda a evitar datos redundantes y mejora la mantenibilidad. As, por cada asociacin en el modelo de la clase, le recomendamos crear una clave externa de la nia a la tabla primaria.

8. Mapa de Agregacin y Composicin Agregacin y composicin de las relaciones son similares a la relacin de asociacin y el mapa a las tablas relacionadas por pares de clave principal de los extranjeros. Sin embargo, existen algunos puntos a tener en cuenta. agregacin ordinaria (la forma dbil) las relaciones de modelos como una persona reside en una o ms direcciones. En este caso, ms de una persona podra vivir en la misma direccin, y si la persona dej de existir, las direcciones asociadas a ellos todava existira. Este ejemplo es paralela a la relacin de muchos

a muchos en la terminologa de relacin, y generalmente se implementa como una tabla separada que contiene un mapeo de las claves principales de una tabla a las claves principales de otro. Un segundo ejemplo de la forma dbil de agregacin es donde la entidad tiene empleo o de propiedad exclusiva de otro. Por ejemplo, una entidad Persona agregados una serie de acciones. Esto implica que una persona puede estar asociada con cero o ms acciones de una tabla de Acciones, pero cada una de las acciones pueden estar asociados con ninguna o una persona. Si la persona deja de existir, las Acciones de las Naciones Unidas a ser de propiedad o se pasan a otra persona. En el mundo de relaciones, esto podra ser implementado como cada Accin de tener un "propietario" de la columna que almacena un identificador de la persona (o OID). La forma fuerte de agregacin, sin embargo, tiene limitaciones importantes de integridad asociadas con ella. Composicin, implica que una entidad se compone de partes, y las partes tienen una relacin de dependencia con el todo. Por ejemplo, una persona puede presentar documentos de identificacin tales como pasaporte, certificado de nacimiento, licencia de conducir y etc Una entidad persona puede estar compuesto por el conjunto de tales documentos de identificacin. Si la persona se elimina del sistema, entonces el documento de identificacin se debe eliminar tambin, ya que se asignan a un individuo nico. Si dejamos de lado la cuestin OID por el momento, una agregacin dbil podra aplicarse utilizando una tabla intermedia (para el caso de muchos a muchos) o con una clave externa en la clase de agregados / table (caso de uno a muchos) . En el caso de la relacin de varios a varios, si el padre es eliminado, las entradas de la tabla intermedia de esa entidad tambin debe ser eliminado tambin. En el caso de la relacin uno-a-muchos, si el padre es suprimido, la entrada de clave externa (es decir, "propietario") debe ser compensado. En el caso de la composicin, el uso de una clave externa es obligatoria, con la restriccin aadi que sobre la supresin de los padres la pieza debe ser eliminado tambin. Lgicamente tambin existe la implicacin con la composicin que la clave principal de la parte forma parte de la clave principal de un todo - por ejemplo, una clave principal de dicha persona pueda compuesto por sus documentos de identificacin ID. En la prctica esto sera engorroso, pero la relacin lgica es cierto. 9. Definir las funciones de relacin Para cada tipo de relacin de asociacin, cada extremo de la relacin, podrn especificarse ms con informacin de las funciones.Normalmente, se incluir el nombre de restriccin PRIMARY KEY y el nombre de clave externa de restriccin. Figura 6 ilustra este concepto. Esto, lgicamente, define la relacin entre las dos clases. Adems, puede especificar restricciones adicionales (por ejemplo, () no es NULL) sobre el papel y las restricciones de cardinalidad (por ejemplo, 0 .. n). 10. Modelo de comportamiento Pasemos ahora a otra cuestin difcil: la posibilidad de asignar algunos o todos los comportamientos de clase para las capacidades funcionales proporcionadas por los proveedores de bases de datos en forma de disparadores, procedimientos almacenados, la singularidad y restricciones de datos, y la integridad relacional. Un modelo de objetos no persistentes normalmente llevara a cabo todas las actuaciones necesarias en uno o varios lenguajes de programacin (por ejemplo, Java o C + +). Cada clase se le dar su comportamiento y responsabilidades requeridas en forma de pblicos, protegidos y privados mtodos. Bases de datos relacionales de diferentes fabricantes suelen incluir alguna forma de lenguaje de scripting basado en SQL programables para aplicar la manipulacin de datos. Los dos ejemplos ms comunes son los disparadores y procedimientos almacenados. Cuando mezclamos el objeto y los modelos relacionales, la decisin es por lo general la posibilidad de aplicar toda la lgica de negocio en el modelo de clase, o para mover a algunos a la frecuencia ms eficientes disparadores y procedimientos almacenados a cabo en el DBMS relacional. Desde un punto de vista puramente orientado a objetos de vista, la respuesta es, obviamente, a evitar los desencadenantes y procedimientos almacenados y el lugar todo el comportamiento en las clases. Este comportamiento se localiza, se prev un diseo ms limpio, simplifica el mantenimiento y ofrece una portabilidad buena relacin entre los vendedores de DBMS. En el mundo real, el resultado final puede ser escalado a 100 o 1000's de transacciones por segundo, algo que los procedimientos almacenados y disparadores son objeto diseado. Si la pureza del diseo, la portabilidad, el mantenimiento y la flexibilidad son los principales impulsores, localizar toda la conducta en los mtodos del objeto. Si el rendimiento es una preocupacin primordial, considerar el comportamiento de la delegacin de algunas de las DBMS ms eficiente lenguajes de script. Tenga en cuenta sin embargo que el tiempo adicional que lleva a integrar el modelo de objetos con los procedimientos almacenados de una manera segura, incluyendo problemas con efectos remotos y depuracin, puede costar ms en el tiempo de desarrollo que la simple implementacin de hardware ms capaz. Como se mencion anteriormente, los datos de perfil UML proporciona las siguientes extensiones (estereotipados operaciones) con la que se puede modelar el comportamiento de DBMS:

restriccin de clave principal (PK); Restriccin de clave externa (FK); ndice de restriccin (ndices); Trigger (gatillo); nico restriccin (nicos);

Comprobacin de validez (cheque).

11. Producir un modelo fsico En UML, el modelo fsico describe cmo algo se desplegarn en el mundo real - la plataforma de hardware, conectividad de red, software, sistema operativo, los dll y otros componentes. Usted produce un modelo fsico para completar el ciclo - de un caso de uso inicial o de modelo de dominio, a travs del modelo de clases y modelos de datos y finalmente el modelo de implementacin.Normalmente para este modelo va a crear uno o ms nodos que hospedar la base de datos (s) y componentes de software DBMS lugar en ellos. Si la base de datos se divide en ms de una instancia DBMS, puede asignar paquetes (esquema) de las tablas a un solo componente de DBMS para indicar dnde residen los datos.

Conclusin As concluye este breve artculo en el modelado de bases de datos utilizando el UML. Como puede ver, hay bastantes cuestiones a considerar para hacer el mapa del mundo de los objetos a la relacional. El UML proporciona apoyo para salvar la brecha entre ambos dominios, y junto con extensiones como el perfil UML de datos es un buen lenguaje para el xito de la integracin de ambos mundos.