Tutorial UML UML 2.1 avanza el éxito de UML 2.0, y se está convirtiendo en el estándar aceptado para la especificación, documentación y visualización de sistemas de software. El Lenguaje Unificado de Modelado (UML) también se utiliza para el modelado de sistemas no-software, y es ampliamente realizado en los sectores más industria, incluyendo finanzas, militar y de ingeniería. Si eres nuevo en el Lenguaje de Modelado Unificado, nuestra Introducción 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 estática definir la arquitectura de un modelo. Se utilizan para modelar las "cosas" que conforman un modelo - las clases, objetos, interfaces y componentes físicos. Además, se utilizan para modelar las relaciones y dependencias entre los elementos. - diagramas de paquetes se utilizan para dividir el modelo en contenedores lógicos, o "paquetes", y

describir las interacciones entre ellos a un alto nivel.

- Clase o diagramas estructurales definir los elementos básicos de un modelo: los tipos, clases y materiales generales utilizados para construir un modelo completo.

- Los diagramas de objetos muestran cómo las instancias de los elementos estructurales se relacionan y se utiliza en tiempo de ejecución.

- Estructura compuesta diagramas proporcionan un medio de capas elemento estructura y centrarse en un detalle interior, la construcción y las relaciones.

- diagramas de componentes se utilizan para modelar un nivel más alto o más estructuras complejas, generalmente se construyen con una o más clases, y proporcionando una interfaz bien definida.

- diagramas de despliegue muestran la disposición física 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 interacción y de estados instantáneos dentro de un modelo, ya que "ejecuta" a través del tiempo; el seguimiento de cómo el sistema va a actuar en un entorno real, y observando los efectos de una acción o evento, incluyendo sus resultados. - Utilice diagramas de casos se utilizan para modelar usuario / interacciones del sistema. Ellos definen el

comportamiento, los requisitos y obstáculos en forma de guiones o escenarios.

- Los diagramas de actividades tienen un amplio número de usos, desde la definición de flujo de los programas de base, para capturar los puntos de decisión y acciones dentro de un proceso generalizado.

- Estado diagramas de máquinas son esenciales para comprender el momento a la condición instantánea, o "estado de ejecución" de un modelo cuando se ejecuta.

- diagramas de comunicación muestran la red, y la secuencia de mensajes y la comunicación entre objetos en tiempo de ejecución, durante una instancia de colaboración.

- Los diagramas de secuencia están estrechamente relacionados con los diagramas de comunicación y muestran la secuencia de los mensajes cursados entre los objetos utilizando una línea de tiempo vertical.

- Calendario diagramas de secuencia y diagramas de estado del fusible para proporcionar una visión del objeto del estado de un tiempo, y los mensajes que modifican ese estado.

- Interacción general diagramas de actividad fusible y diagramas de secuencia para permitir que los fragmentos de la interacción que se pueden combinar fácilmente con los puntos de decisión y de los flujos.

El Lenguaje Unificado de Modelado (UML) ha convertido rápidamente en el estándar de facto para la construcción de software orientado a objetos. Este tutorial ofrece una visión técnica de los 13 diagramas de UML con el apoyo de Enterprise Architect. UML 2 semántica se explican en detalle en el nuevo tutorial de UML 2.0. En primer lugar ... ¿Qué es UML? El OMG especificación establece lo siguiente: "El Lenguaje de Modelado Unificado (UML) es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema de software de obra. El UML ofrece una forma estándar 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 programación, esquemas de base de datos y de software reutilizables componentes ". El punto importante a señalar aquí es que UML es un lenguaje "para especificar y no un método 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 metodología (como el Proceso Unificado de Rational) -, pero ella misma no se especifica que la metodología o proceso.

UML define la notación y la semántica de los siguientes dominios: - La interacción del usuario o de casos de uso Modelo - describe la frontera y la interacción entre el sistema y los

usuarios.Corresponde en algunos aspectos a un modelo de requisitos. - La interacción o el modelo de comunicación - describe cómo los objetos en el sistema va a interactuar unos con otros para realizar su

trabajo. - El Estado o Modelo Dinámico - Listas de Estado describen los estados o condiciones que las clases de asumir con el

tiempo.Actividad gráficos describen los flujos de trabajo del sistema llevará a cabo. - La lógica o el modelo de clase - se describen las clases y los objetos que componen el sistema. - La física de componentes Modelo - describe el software (y en ocasiones componentes de hardware) que componen el sistema. - El Modelo de Despliegue Físico - describe la arquitectura física y el despliegue de los componentes en que la arquitectura de

hardware. El UML también define mecanismos de extensión para extender el UML para satisfacer las necesidades especializadas (por ejemploBusiness Process Modeling extensiones). Parte 2 de este tutorial se expande sobre cómo se utiliza el UML para definir y construir los sistemas actuales. Véase también 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. También hemos visto que se trata de 6 dominios principales - de utilizar modelos de la sentencia, a través de modelos dinámicos y lógico para el modelo de implementación física final - y que los mecanismos de extensión se han incluido para permitir adiciones especializados para la notación del modelo. Así que ... ¿Cómo 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 informático propuesto. La naturaleza exacta del proceso depende de la metodología de desarrollo utilizada. Un proceso de ejemplo podría 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 organización y proporcionar una base para el caso modelo de uso. El modelo de procesos de negocio normalmente se hacen con más 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 intención de proveer desde la perspectiva de los usuarios de negocios. A medida que cada caso de uso se agrega, crea un vínculo trazable desde los procesos de negocios apropiados para el caso de uso (es decir, una conexión de realización). Este trazado claramente establece que la funcionalidad del nuevo sistema proporcionará para cumplir los requisitos empresariales incluidas en el modelo de proceso. También asegura que no existen casos de uso sin un propósito.

3. Filtrar los Casos de Uso - incluirá los requisitos, limitaciones, rango de complejidad, notas y escenarios. Esta información sin ambigüedades describe lo que el caso de uso hace, cómo se ejecuta y las limitaciones para su ejecución. Asegúrese de que el caso de uso sigue cumpliendo los requisitos de procesos de negocio. Incluir la definición de las pruebas del sistema para cada caso de uso para definir los criterios de ACEPTACIÓN para cada caso de uso. También incluye algunos scripts de prueba de aceptación de los usuarios para definir cómo el usuario va a probar esta funcionalidad y lo que los criterios de aceptación.

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 colaboración y una interfaz de modelos de usuario. En ellas se describen las "cosas" en el nuevo sistema, la forma en que esas partes interactúan 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 especificación 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 jerarquías de clase mediante la herencia. diagrama de mensajes escenario típicamente se asignarán a las operaciones de clase. Si un marco existente o el diseño del patrón se va a utilizar, puede permitir la importación de los elementos del modelo existente para su uso en el nuevo sistema. Para cada clase definir las pruebas unitarias y pruebas de integración para probar completamente i) que las funciones de clase tal como se especifica internamente y que ii) la clase interactúe 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 porción de despliegue de software que recoge el comportamiento y los datos de una o más clases y expone una interfaz estricta a otros consumidores de sus servicios. Así que desde el modelo de la clase un modelo de componentesestá diseñado para definir el empaquetamiento lógica de clases. Para cada componente de definir las pruebas de integración para confirmar que los componentes de la interfaz cumple con la especificación dada en relación con otros elementos del software.

7. Simultáneamente con el trabajo que han hecho, los requisitos adicionales deberían 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 día el modelo madura.

8. El modo de implementación del define la arquitectura física del sistema. Este trabajo puede comenzar temprano para capturar las características de despliegue físico - el hardware, sistemas operativos, capacidades de red, interfaces y software de soporte conformarán el nuevo sistema, donde se desplegará y qué parámetros se aplican a la recuperación de desastres, la confiabilidad, la espalda- seguridad y soporte. A medida que el modelo se desarrolla la arquitectura física 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 más desarrolladores. En una acumulación de casos de uso impulsada esto significará la asignación 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 acompañada de la unidad terminada, la integración y pruebas del sistema. Una construcción dirigida del componente puede ver los componentes discretos de software asignados a los equipos de desarrollo para la construcción.

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 gestión 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 través del diseño en bloques discretos, siempre evaluando la construcción 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 producción. Si una entrega por etapas se lleva a cabo, a continuación, esta migración de software de construcción desde la prueba a la producción pueden ocurrir varias veces durante la vida útil del proyecto.

Tenga en cuenta que el proceso anterior es necesariamente breve en la descripción, 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 cómo el UML puede ser utilizado para apoyar un proyecto de desarrollo de software.

El proceso de modelo de negocio Descargar versión PDF

Introducción Tradicionalmente, el UML se ha asociado más con la ingeniería de software y diseño de sistemas que con el análisis y modelado de procesos de negocio. Sin embargo, el estándar UML 2.x proporciona un rico conjunto de modelos de comportamiento que son muy útiles en la modelización de los procesos, actividades, personas e información crítica para cada negocio. Más allá de la notación estándar UML, dos respetados y probada UML "extensiones" que existan más

estrictas para la captación 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 estándar para el modelado y diseño de procesos de negocio. El segundo es el perfil-Ericsson Penker que tiene menos popularidad, pero todavía proporciona un medio poderoso y único de visualizar y comunicar los procesos empresariales y el necesario flujo de información dentro de una organización. Este artículo ofrece una introducción muy alto nivel tanto de estas extensiones ", mostrando cómo 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 técnica de diagramas de flujo a medida para la creación de modelos gráficos de las operaciones de proceso de negocio. Es una notación que sea fácilmente comprensible por todos los usuarios de negocios, de los analistas de negocio que crean los borradores iniciales de los procesos, a los desarrolladores técnicos responsables de la aplicación de la tecnología 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 pequeño conjunto de elementos gráficos. Elementos de flujo

1. Actividades. Una actividad es el trabajo que se realiza dentro de un proceso de negocio y está

representada por un rectángulo redondeado. 2. 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 pequeños círculos con límites distintos para diferenciar los eventos de partida (línea fina negro), los eventos intermedios (doble línea) y los eventos finales (línea grueso de color negro). Los eventos pueden mostrar iconos dentro de su forma de identificar el gatillo o el resultado del evento.

3. Gateways. Gateways se utilizan para controlar los flujos de secuencia de cómo convergen y divergen en un proceso.Gateways pueden representar las decisiones, cuando uno o más caminos no están permitidos, o bien pueden representar a tenedores concurrentes.

1. 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 línea con una punta de flecha sólida.

2. 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 línea discontinua con un círculo de color claro en el origen y punta de flecha en el blanco.

3. Asociaciones. Una asociación se utiliza para asociar la información y los artefactos con los objetos de flujo. Una asociación está representada por una línea discontinua que puede o no puede tener una línea de punta de flecha en el extremo de destino si no hay una razón para mostrar la direccionalidad.

Swimlanes (Particiones)

1. 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 partición del proceso. 2. Lanes. Una vía es una sub-división de una piscina y se utiliza para organizar y clasificar las

actividades dentro de la piscina.

Artefactos

1. Datos objetos. Un objeto de datos no tiene un efecto directo sobre un proceso, pero no proporciona

información relevante para el proceso. Se representa como un rectángulo con la esquina superior doblada.

2. Grupos. Un grupo es un medio informal para agrupar elementos de un proceso. Se representa como un rectángulo con un borde de línea discontinua.

3. Las anotaciones. Una anotación es un mecanismo para el modelador BPMN para proporcionar información adicional a la audiencia de un diagrama BPMN. Está representada por un rectángulo abierto que contiene el texto de la anotación.

Ejemplos BPMN Ejemplo 1:

El diagrama anterior muestra una serie de características clave de BPMN, específicamente la capacidad de crear descomposición jerárquica de los procesos en tareas más pequeñas, 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 vínculo, es decir, los conectores fuera de página. "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 límite 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 también muestra un bucle de ser controlado por un evento de temporizador, y muestra una puerta de enlace la decisión (en este caso, una puerta de enlace la decisión XOR) el control cuando el bucle se termina. Ejemplo 3:

Este diagrama ilustra el uso de las piscinas para mostrar los procesos de interacción 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 sección proporciona una introducción a la terminología e iconos utilizados en el Modelo de Procesos de Negocio, y le da una rápida introducción a algunos Lenguaje Unificado de Modelado (UML) conceptos y su aplicación en el Modelo de Negocios de Enterprise Architect de Proceso. Un proceso de negocio:

1. Tiene un objetivo

2. Tiene entradas específicas 3. Tiene productos específicos 4. Utiliza los recursos de 5. Tiene una serie de actividades que se realizan en un poco de orden 6. Puede afectar a más de una unidad organizativa. De organización horizontal de impacto 7. Crea valor de algún tipo para el cliente. El cliente puede ser interno o externo.

Modelos de Procesos Un proceso de negocios es un conjunto de actividades diseñadas para producir un producto específico para un determinado cliente o mercado. Implica un fuerte énfasis en cómo el trabajo se realiza dentro de una organización, a diferencia de enfoque de un producto en lo que es un proceso. Así, una ordenación específica de las actividades laborales a través del tiempo y lugar, con un comienzo, un final, y claramente definidas las entradas y salidas: una estructura para la acción. Suministro vínculo de objeto de información. Un enlace de suministro indica que la información 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 régimen de perfeccionamiento. Como un ejemplo, como pedidos de los clientes son procesados que se hayan completado y firmado, y por lo general se utilizan sólo una vez al recurso único (orden).

vínculo objetivo de oponerse Meta. Un vínculo objetivo indica el objeto unido al proceso de negocio describe el objetivo del proceso. Una meta es la justificación 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 algún objeto

se pasa a un proceso de negocio. Captura el paso de control a otra entidad o proceso, con el paso implícita de Estado o información de una actividad a otra.

Objetivo Un proceso de negocio tiene bien definido el objetivo. Esta es la razón por la que la organización hace este trabajo, y debe ser definida en términos de los beneficios que este proceso tiene para la organización en su conjunto y en la satisfacción 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 justificación de negocio para el ejercicio de la actividad. Información Los procesos de negocio utilizar la información para adaptar o completar sus actividades. La información, a diferencia de los recursos, no se consume en el proceso - sino que se utiliza como parte del proceso de transformación. La información puede provenir de fuentes externas, de clientes, desde las unidades internas de la organización e incluso puede ser el producto de otros procesos. productos Información enlace a los Procesos de Negocios. Un enlace de la fuente indica que la información 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 más salidas de valor para el negocio, ya sea para uso interno de satisfacer las exigencias externas. Una salida puede ser un objeto físico (como un informe o factura), una transformación 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 aportación a un proceso de negocio, y, a diferencia de la información, 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 régimen de perfeccionamiento. Como un ejemplo, como pedidos de los clientes son procesados que se hayan completado y firmado, y por lo general se utilizan sólo 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 traídos de otros proyectos y vendedores de tercera parte. Los componentes son agregaciones de alto nivel de piezas de software más pequeñas, y proporcionar un enfoque de "recuadro negro" bloques de construcción para la construcción de software.

Componente de la notación

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 relación entre componentes de software, sus dependencias, la comunicación, localización y otras condiciones.

Interfaces

Los componentes también pueden exponer a las interfaces. Estos son los puntos de entrada visibles o servicios que un componente es la publicidad y la puesta a disposición 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 colección de componentes más pequeños.

Componentes y Nodos

Un diagrama de despliegue muestra el despliegue físico del sistema en una producción (o prueba) medio ambiente. Muestra dónde se ubicarán los componentes, lo que en los servidores, máquinas o hardware. Se puede ilustrar los vínculos 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. Pre-condiciones especifican lo que debe darse antes de un componente puede realizar alguna función; post-condiciones indican lo que va a ser cierto después de que un componente ha realizado un trabajo e invariantes especifican lo que debe seguir siendo válido para el periodo de vigencia componentes.

Escenarios

Los escenarios son textuales y descripciones procesal de las demandas de un objeto a través del tiempo y describir la forma en que un componente de las obras. Múltiples escenarios puede ser creado para describir la ruta de acceso básico (una carrera perfecta a través), así como las excepciones, errores y otras condiciones.

Trazabilidad

Usted puede indicar la trazabilidad a través de enlaces realización. 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 vínculos a la realización y de componentes que se pueden asignar las dependencias entre los elementos del modelo y la trazabilidad desde los requisitos iniciales hasta la ejecución final.

Un ejemplo

El siguiente ejemplo muestra cómo los componentes pueden estar vinculados a proporcionar un marco conceptual / vista lógica de una construcción 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 páginas ASP y etc Componentes de servidor Este diagrama ilustra la disposición de los componentes del lado del servidor principal que requerirá la construcción de una tienda de libros on-line. Estos componentes son una mezcla de la costumbre construido y comprado artículos que se ensamblará para proporcionar la funcionalidad requerida.

Componentes de seguridad

El diagrama muestra cómo 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 provisión de seguridad en el sistema propuesto.

El Modelo Dinámico El modelo dinámico 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 interacción 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 - cómo un usuario interactúa 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 cómo diferentes flujos de trabajo en el sistema se construyen, cómo se inician y los caminos, posiblemente, muchas decisiones que se pueden tomar de principio a fin. También pueden ilustrar el procesamiento en paralelo donde se puede producir en la ejecución 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

través del sistema.Muestran cómo 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 condición final.

Modelo de Procesos

Un modelo de proceso es una extensión 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 información que están involucradas en el proceso.

El Modelo Lógico Un modelo lógico es una visión estática de los objetos y las clases que componen el diseño y análisis 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 diseño más riguroso y centrado modelo. Esta discusión se refiere principalmente a la clase del modelo

El modelo de la clase Una clase es un estándar de UML que se usa para detalles de la pauta de que los objetos serán producidos en tiempo de ejecución.Una clase es una especificación - 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 añadir 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 diseño - 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 diseño 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 ocultación de datos y de servicios asegura la exposición de actualización de datos se realiza sólo en un lugar y de acuerdo a normas específicas - para sistemas grandes de la carga de mantenimiento de código 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 públicos

Atributos y métodos 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 niños de la clase

- Pública, que son visibles para todos

herencia de clases se muestra a continuación: una clase abstracta en este caso, es el padre de dos hijos, cada uno de ellos hereda características 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 Físico La física y la implementación del modelo proporciona un modelo detallado de los componentes de la forma en que se desplegó a través de la infraestructura del sistema. La capacidad de la red de detalles, las especificaciones del servidor, los requisitos de hardware y otra información relacionada con la implementación del sistema propuesto. Ver Despliegue

PM01: Modelo Físico El modelo físico muestra dónde y cómo los componentes del sistema será implementado. Es un mapa que de la disposición física del sistema. Un diagrama de despliegue muestra el despliegue físico del sistema en una producción (o prueba) medio ambiente.Muestra dónde se ubicarán los componentes, lo que en los servidores, máquinas o hardware. Se puede ilustrar los vínculos de red, ancho de banda LAN y etc

Un nodo se utiliza para describir cualquier servidor, estación de trabajo o la acogida de hardware que se utilice para desplegar componentes en el entorno de producción. También puede especificar los enlaces entre nodos y asignar los estereotipos (como TCP / IP) y los requisitos para ellos. Los nodos también pueden tener características de funcionamiento, estándares mínimos 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 interacción entre un usuario (humano o máquina) y el sistema. Esta interacción 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 descripción 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 metodologías estructuradas, y la forma de un contrato que el caso de uso realiza alguna acción o preste algún valor para el sistema.

Limitaciones - Las reglas formales y las limitaciones de un caso de uso opera bajo, la definición 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 número 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 múltiples, para hacer frente a circunstancias excepcionales y distintas alternativas de tratamiento. Estos normalmente se crean en el texto y corresponden a una representación textual del diagrama de secuencia.

diagramas de Escenario - Los diagramas de secuencia para describir el flujo de trabajo; similares a

los Escenarios pero descrito gráficamente.

atributos adicionales, como la fase de ejecución, número de versión, rango de complejidad, estereotipo y estado.

Actores Los casos de uso suelen deberse a que "actores", que son humanos o de máquinas 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 acción.

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 llamarán 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 incluiría cada vez que el <modificar pedido> de casos de uso se ejecute. Un Caso de Uso puede ser incluido por uno o más casos de uso, por lo que ayuda a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces. Un Caso de Uso puede extender el comportamiento de otro, típicamente cuando ocurren situaciones excepcionales. Por ejemplo, si un usuario debe obtener la aprobación de alguna autoridad superior antes de modificar un determinado tipo de pedido del cliente, entonces el <obtener aprobación> de casos de uso opcional, podría ampliar el <modificar orden> de casos de uso.

Los diagramas de secuencia Los diagramas de secuencia proporcionan una representación gráfica de la interacción entre los objetos en el tiempo. Éstos muestran típicamente a un usuario oa un actor y los objetos y los componentes que interactúan en la ejecución de un caso de uso.Un diagrama de secuencia representa típicamente 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 análisis y verificar la utilización por los objetos más tarde en el diseño. Los diagramas muestran el flujo de mensajes desde un objeto a otro, y como tales, representan los métodos 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 aplicación Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo, componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto proporciona un alto nivel de trazabilidad al diseñador, 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 mínima que debe ser implementada por el componente.

El ejemplo anterior muestra que el caso de uso 'Login' implementa el requisito formal '1 .01 iniciar sesión en el sitio web ". También muestra que el «componente de lógica de negocios" y "componente de páginas ASP"

aplicar algunas o todas las 'funcionalidad Login'. Un refinamiento adicional es mostrar la pantalla 'Login' (una página web) como la aplicación del "caso Login 'uso. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos formales, a través de casos de uso de los componentes y pantallas.

Base de datos de modelado en UML Introducción Cuando se trata de abastecimiento confiable, persistencia de los objetos flexibles y eficientes para los sistemas de software, diseñadores y arquitectos de hoy en día se enfrentan a muchas opciones. Desde el punto de vista tecnológico, la elección es por lo general entre puro orientado a objetos, los híbridos Objeto-Relacionales, 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 artículo 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 más simple solución, pero pragmáticamente es una de las más comunes, y uno que tiene el potencial para la mayoría de mal uso. Empezaremos con un rápido recorrido por los dos dominios de diseño 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 sólo en las características principales que afectan a nuestra tarea. A continuación, se verá en las técnicas y cuestiones relacionadas con la asignación 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 revisión del perfil UML de datos (como se propone por Rational Software). Cierta familiaridad con el diseño 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 lógica 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 técnicas para el descubrimiento y la elaboración de ese modelo están fuera del alcance de este artículo, así que vamos a suponer la existencia de un modelo bien diseñado clase que requiere asignación a una base de datos relacional. El modelo de la clase La clase es la entidad de base lógica 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 ejecución. Cuando desarrollamos un modelo lógico como una estructura jerárquica en UML se tratan de manera explícita las clases. Cuando trabajamos con diagramas dinámicos, como los diagramas de secuencia y colaboración, se trabaja con objetos o instancias de clases y sus interacciones en tiempo de ejecución. El director de ocultamiento de datos o la encapsulación se basa en la localización del efecto. Una clase tiene elementos de datos interna que es responsable. El acceso a estos elementos de datos deben ser expuestos a través del comportamiento de la clase o interfaz. La adhesión a este principales resultados en más código 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 (público), visible a los niños (protegido) o se oculte (privado). Mediante la combinación de datos ocultos con una interfaz de acceso público y ocultos o protegidos de manipulación de datos, un diseñador de la clase puede crear unidades estructurales muy fácil de mantener que el apoyo en vez de obstaculizar el cambio.

Las relaciones y la identidad Asociación es una relación entre dos clases que indica que al menos uno de los lados de la relación conoce y utiliza o manipula de alguna manera al otro lado. Esta relación puede, mediante funcionales (hacer algo por mí) o estructural (algo para mí). Para este artículo es la relación estructural que es más interesante: por

ejemplo puede ser una clase de dirección asociada a una clase de persona. La asignación de esta relación en el espacio de datos relacionales requiere cierto cuidado.

La agregación es una forma de asociación que implica el cobro de una clase de objetos dentro de otra. La composición es una forma más fuerte de agregación que implica un objeto se compone realmente de los demás. Al igual que la relación de asociación, esto implica un atributo de clase compleja que requiere una cuidadosa consideración en el proceso de asignación 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 ejecución requiere de algún medio de identificarse de tal manera que los objetos asociados pueden actuar sobre la instancia de objeto correcto. En un lenguaje de programación 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 común en clases generalizadas que luego actúan como los antepasados de muchas variaciones sobre un tema común. La herencia es un medio para controlar tanto la reutilización 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 asignación de un modelo de objetos en un marco relacional. Navegación de un objeto en tiempo de ejecución a otro se basa en referencias absolutas. Un objeto tiene algún 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 años 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 más" columnas ", cada uno de los cuales contiene un elemento de dato. Tablas y columnas: una tabla relacional es una colección de una o más 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 básicos, tales como un número, texto o datos binarios. Una definición 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 sólo ofrece un modelo de datos de acceso público. Todos los datos están igualmente expuestos y abiertos a cualquier proceso de actualización, consulta o manipularla. El ocultamiento de información es desconocida. Comportamiento El comportamiento asociado a una tabla se basa generalmente en el negocio o lógica 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 después de actualizaciones, inserciones y eliminaciones. procedimientos almacenados de base de datos proporcionan un medio para extender la funcionalidad de base de datos a través de extensiones de lenguaje propio que se utiliza para la construcción de unidades funcionales (scripts). Estos procedimientos funcionales no se asignan directamente a las entidades, ni tener una relación lógica con ellos. Navegación a través 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 identificación ú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 después. Una tabla puede contener

columnas que se asignan a la clave principal de otra tabla. Esta relación entre las tablas define una clave externa e implica una relación estructural o de asociación entre las dos tablas. Resumen Desde la visión 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

través de la interfaz pública ú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 través de disparadores, índices y restricciones. Usted navega a la información diferenciada en el modelo de objetos moviendo de un objeto a la utilización 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 están utilizando SQL utilizando criterios de búsqueda generalizada. Identidad en el modelo de objetos puede ser una referencia de tiempo de ejecución 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, agregación, asociación, la composición, la dependencia y otros. En el modelo relacional realmente sólo podemos indicar una relación con las claves externas. Habiendo visto los dos dominios de interés y comparamos algunas de las características importantes de cada uno, vamos a una breve digresión para examinar la propuesta de notación 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 extensión de UML (y actualmente en revisión - 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 extensión ratificado, aún muestra una posible técnica 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 dirección. Tenga en cuenta que el ejemplo anterior define el tipo de columna en términos de los tipos de datos nativos DBMS. Comportamiento Hasta ahora sólo hemos define la lógica (estática) estructura de la tabla y, además, 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 restricción de clave principal y el índice, ambos definidos como operaciones de patrón:

Tenga en cuenta que la bandera de PK en la columna "OID" define la clave principal lógica, mientras que la operación estereotipada "« PK »idx_customer00" define las obligaciones y de comportamiento asociados con la aplicación 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. Una restricción de clave principal (PK);

2. Una restricción de clave externa (FK); 3. Una limitación del índice (Index); 4. Un disparador (Trigger); 5. Una restricción de unicidad (único); 6. Un procedimiento almacenado (Proc) - no están formalmente parte del perfil de datos, sino un

ejemplo de una técnica de modelado sea posible, y un 7. Comprobación de validez (cheque).

Usando la notación contemplados anteriormente, es posible modelar estructuras complejas de datos y el comportamiento a nivel de DBMS. Además de esto, el UML provee la notación para expresar las relaciones entre las entidades lógicas.

Relaciones Los datos de modelado UML perfil define una relación como una dependencia de ningún tipo entre dos tablas. Se representa como una asociación estereotipada e incluye un conjunto de claves primarias y externas. El perfil de datos va a exigir que una relación siempre involucra a un padre y su hijo, el padre definir una clave principal y el niño la aplicación de una clave externa sobre la base de la totalidad o parte de los padres de clave principal. La relación que se denomina «identificar» si la tecla niño extranjero incluye todos los elementos de la matriz de clave principal y "la no identificación 'si sólo algunos elementos de la clave principal se incluyen. La relación puede incluir restricciones de cardinalidad y ser modelado con la correspondiente PK - FK par nombrado como funciones de asociación. La ilustración de abajo ilustra este tipo de modelación relación con UML.

El Modelo Físico UML también proporciona algunos mecanismos para representar la estructura física global de la base de datos, su contenido y ubicación desplegado. Para representar una base de datos física 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 físico, un componente puede ser asignada a una pieza física 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 ubicación dentro de una base de datos.

Mapeo del Modelo de clases para el Modelo Relacional Después de describir las dos áreas de interés y la notación que se utilizará, ahora podemos volver nuestra atención sobre la forma de mapa o traducir de un dominio a otro. La estrategia y la secuencia se presenta a continuación 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 ingeniería de un nuevo esquema de base de datos relacional a partir de un modelo de clase que hemos creado. Esto es obviamente más fácil la dirección 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 situación más difícil y que presenta sus propios desafíos. Para el debate actual se centra en la primera situación. Como mínimo, el modelo de su clase debe capturar las asociaciones, la herencia y agregación entre los elementos. 2. Identificar los objetos persistentes Después de haber construido nuestro modelo de clase tenemos que separarlo en aquellos elementos que requieren persistencia y los que no. Por ejemplo, si hemos diseñado nuestra aplicación utilizando el patrón de diseño Modelo-Vista-Controlador, a continuación, las clases sólo en la sección de modelo requeriría estado persistente. 3. Supóngase que cada clase persistente mapas a una tabla relacional Un supuesto bastante grande, pero uno que funcione en la mayoría de los casos (dejando de lado la cuestión de la herencia por el momento). En el modelo más sencillo de una clase de los mapas modelo lógico a una tabla de relaciones, ya sea en su totalidad o en parte. La extensión lógica 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 quizás la relación más problemática y construcción lógica 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 jerarquía 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 ejecución. Hay tres formas básicas para manejar la traducción de la herencia a un modelo relacional:

a. Cada jerarquía de clases tiene una sola tabla correspondiente que contiene todos los atributos heredados para todos los elementos - esta tabla es por tanto la unión de todas las clases de la jerarquía. Por ejemplo, Una persona, padre, hijo y nieto todos pueden formar una jerarquía de clases individuales, y elementos de cada uno de ellos aparecen en la tabla de relaciones misma;

b. Cada clase en la jerarquía tiene un correspondiente tabla de los atributos sólo accesibles por esa clase (incluidos los atributos heredados). Por ejemplo, si el niño se hereda de la persona solamente, a continuación, la tabla contendrá los elementos de la persona y su única hija;

c. Cada generación en la jerarquía de clases tiene una tabla que contiene sólo que los atributos reales de generación. Por ejemplo, niños que se asignarán a una sola tabla con el Niño atributos sólo

Hay casos en que se hizo para cada criterio, pero yo sugeriría más simple, más fácil de mantener y menos propenso a errores, es la tercera opción. La primera opción proporciona el mejor rendimiento en tiempo de ejecución y el segundo es un compromiso entre la primera y la última. La primera opción se aplana la jerarquía y localiza todos los atributos de una tabla - conveniente para las actualizaciones y consultas de cualquier clase en la jerarquía, pero difícil para autenticar y mantener. Las reglas de negocio asociadas con una fila son difíciles de aplicar, ya que cada fila puede crear una instancia como cualquier objeto en la jerarquía. Las dependencias entre las columnas pueden volverse muy complejos. Además, una actualización de cualquier clase en la jerarquía potencialmente impactará todas las demás clases de la jerarquía, como las columnas se agregan, eliminan o modificada de la tabla. La segunda opción es un compromiso que proporciona una mejor encapsulación y elimina las columnas vacías. Sin embargo, un cambio en una clase padre puede necesitar para ser replicado en muchas tablas secundarias. Peor aún, los datos de sus padres en las clases de dos o más 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 actualización de los registros afectados. La tercera opción más acordes con el modelo de objetos, y cada clase en la jerarquía asignada a su tabla independiente. Puesta al día de los padres o los niños se localizan en el lugar correcto. El mantenimiento es también relativamente sencilla, ya que cualquier modificación de una entidad se limita a una sola tabla de relación también. El lado negativo es la necesidad de reconstruir la jerarquía en tiempo de ejecución con

precisión volver a crear un estado de clase del niño. 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 jerarquía, con más generaciones, el número 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 cuál es la mejor solución para usted. 5. Para cada categoría están 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 ejecución 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 ejecución. Sin embargo, si escribimos un objeto para el almacenamiento, el problema es cómo recuperar la instancia de exactamente la misma en la demanda. El método más conveniente es definir un OID (identificador de objeto) que se garantiza que sea único en el espacio de nombres de interés. Esto puede ocurrir en la clase, embalaje o de nivel de sistema, en función de las necesidades reales. Un ejemplo de un nivel de sistema OID podría ser un GUID (identificador único global) creado con guidgen de Microsoft "herramienta", por ejemplo. (A1A68E8E-CD92-420b-BDA7-118F847B71EB). A nivel de clase OID podría ser implementado usando un simple numérica (por ejemplo, contra 32 bits). Si un objeto contiene referencias a otros objetos, puede hacerlo a través de su OID. Un escenario completo de tiempo de ejecución se puede cargar desde el almacenamiento razonablemente eficiente. Un punto importante acerca de los valores OID anterior es que no tienen ningún significado inherente allá de la identidad simple. Sólo son punteros lógica y nada más. En el modelo relacional, la situación 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 dirección 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 propósitos es el impacto de contar con información 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. Además, en la práctica, una clave principal sobre la base de datos de negocio pueden estar sujetas a cambios. Por ejemplo, un cliente puede cambiar de dirección 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 información que forma parte de la clave principal. Un OID se refiere siempre a la misma entidad - no importa qué otros cambios de la información. En el ejemplo anterior, un cliente puede cambiar el nombre o la dirección y los cuadros relacionados requieren ningún cambio. Cuando la cartografía modelos de objetos a tablas relacionales, a menudo es más 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 práctica, un negocio relacionado clave principal podría ser sustituido por:

Una restricción de unicidad o un índice en las columnas que se trate;

Las reglas de negocio integrado en el comportamiento de la clase;

Una combinación de 1 y 2.

Una vez más, la decisión 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 número puede representar el nombre de una persona y la edad respectivamente. Este tipo de asignación directa debería plantear ningún problema - sólo 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 continuación para el manejo de las asociaciones y agregación. 7. Mapa de las asociaciones con claves externas Más complejos atributos de clase (es decir, aquellas que representan a otras clases), suelen ser modeladas como las asociaciones.Una asociación es una relación estructural entre los objetos. Por ejemplo, una persona puede vivir en una dirección. Si bien esto puede ser modelado como una persona tiene la Ciudad, Calle y Código Postal atributos, tanto en el objeto y el mundo relacional nos inclinamos a la estructura de esta información como una entidad separada, de una dirección. En el ámbito objeto de una dirección representa un objeto físico único, posiblemente con un OID único. En lo relacional, una dirección puede ser una fila en una tabla de direcciones, con otras entidades con una clave externa a la tecla de dirección principal. En ambos modelos a continuación, está la tendencia a pasar la información de dirección en una entidad separada. Esto ayuda a evitar datos redundantes y mejora la mantenibilidad. Así, por cada asociación en el modelo de la clase, le recomendamos crear una clave externa de la niña a la tabla primaria.

8. Mapa de Agregación y Composición Agregación y composición de las relaciones son similares a la relación de asociación y el mapa a las tablas relacionadas por pares de clave principal de los extranjeros. Sin embargo, existen algunos puntos a tener en cuenta. agregación ordinaria (la forma débil) las relaciones de modelos como una persona reside en una o más direcciones. En este caso, más de una persona podría vivir en la misma dirección, y si la persona dejó de existir, las direcciones asociadas a ellos todavía existiría. Este ejemplo es paralela a la relación de muchos

a muchos en la terminología de relación, 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 débil de agregación 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 más 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 podría ser implementado como cada Acción de tener un "propietario" de la columna que almacena un identificador de la persona (o OID). La forma fuerte de agregación, sin embargo, tiene limitaciones importantes de integridad asociadas con ella. Composición, implica que una entidad se compone de partes, y las partes tienen una relación de dependencia con el todo. Por ejemplo, una persona puede presentar documentos de identificación tales como pasaporte, certificado de nacimiento, licencia de conducir y etc Una entidad persona puede estar compuesto por el conjunto de tales documentos de identificación. Si la persona se elimina del sistema, entonces el documento de identificación se debe eliminar también, ya que se asignan a un individuo único. Si dejamos de lado la cuestión OID por el momento, una agregación débil podría 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 relación de varios a varios, si el padre es eliminado, las entradas de la tabla intermedia de esa entidad también debe ser eliminado también. En el caso de la relación uno-a-muchos, si el padre es suprimido, la entrada de clave externa (es decir, "propietario") debe ser compensado. En el caso de la composición, el uso de una clave externa es obligatoria, con la restricción añadió que sobre la supresión de los padres la pieza debe ser eliminado también. Lógicamente también existe la implicación con la composición 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 identificación ID. En la práctica esto sería engorroso, pero la relación lógica es cierto. 9. Definir las funciones de relación Para cada tipo de relación de asociación, cada extremo de la relación, podrán especificarse más con información de las funciones.Normalmente, se incluirá el nombre de restricción PRIMARY KEY y el nombre de clave externa de restricción. Figura 6 ilustra este concepto. Esto, lógicamente, define la relación entre las dos clases. Además, 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 cuestión difícil: 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 llevaría a cabo todas las actuaciones necesarias en uno o varios lenguajes de programación (por ejemplo, Java o C + +). Cada clase se le dará su comportamiento y responsabilidades requeridas en forma de públicos, protegidos y privados métodos. Bases de datos relacionales de diferentes fabricantes suelen incluir alguna forma de lenguaje de scripting basado en SQL programables para aplicar la manipulación de datos. Los dos ejemplos más comunes son los disparadores y procedimientos almacenados. Cuando mezclamos el objeto y los modelos relacionales, la decisión es por lo general la posibilidad de aplicar toda la lógica de negocio en el modelo de clase, o para mover a algunos a la frecuencia más 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 diseño más limpio, simplifica el mantenimiento y ofrece una portabilidad buena relación 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 diseñado. Si la pureza del diseño, la portabilidad, el mantenimiento y la flexibilidad son los principales impulsores, localizar toda la conducta en los métodos del objeto. Si el rendimiento es una preocupación primordial, considerar el comportamiento de la delegación de algunas de las DBMS más 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 depuración, puede costar más en el tiempo de desarrollo que la simple implementación de hardware más 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:

restricción de clave principal (PK);

Restricción de clave externa (FK);

Índice de restricción (índices);

Trigger (gatillo);

Único restricción (únicos);

Comprobación de validez (cheque).

11. Producir un modelo físico En UML, el modelo físico describe cómo algo se desplegarán en el mundo real - la plataforma de hardware, conectividad de red, software, sistema operativo, los dll y otros componentes. Usted produce un modelo físico para completar el ciclo - de un caso de uso inicial o de modelo de dominio, a través del modelo de clases y modelos de datos y finalmente el modelo de implementación.Normalmente para este modelo va a crear uno o más nodos que hospedará la base de datos (s) y componentes de software DBMS lugar en ellos. Si la base de datos se divide en más de una instancia DBMS, puede asignar paquetes («esquema») de las tablas a un solo componente de DBMS para indicar dónde residen los datos.

Conclusión Así concluye este breve artículo 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 integración de ambos mundos.