Modelos Diagramas Elementos UML 01

Universidad Nacional de Ingeniería

Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language

medi@NERO P á g i n a | 1

Modelamiento de Sistemas Informáticos Diagramas & Elementos UML

Bases Teóricas.

Lenguaje Unificado de Modelado se ha convertido rápidamente en el estándar de facto para construir software orientado a objetos. Este documento provee una introducción

técnica a los diagramas UML soportados por Sybase PowerDesigner. Pruebe a usar

otras herramientas CASE si tiene preferencias. La semántica de UML es explicada en

detalles para que se familiarice con estos conceptos.

¿Qué es UML? La especificación del OMG:

"El Lenguaje de Modelado Unificado (UML) es un lenguaje

gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema de software.

EL UML ofrece una forma estándar para escribir un plano del

sistema, incluyendo cosas conceptuales tales como procesos

de negocios y funciones del sistema, como así también cosas

concretas tales como expresiones de lenguajes de

programación, esquemas de bases de datos y componentes de

software reutilizables"

El punto importante a notar aquí es que el UML es un

"lenguaje" para especificar y definir un sistema de software,

para detallar los artefactos en el sistema, para documentar y

construir -es el lenguaje en el que está escrito el plano-.

El UML se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software (tal como por ejemplo el Proceso Unificado de Desarrollo de Software

USDP y extensiones de Modelado de Procesos de Negocios.), pero no especifica en sí mismo

qué metodología o proceso.

UML es un lenguaje para especificar los artefactos y las interacciones de un sistema de software.

DOMINIOS de UML. UML

trata con 6 dominios principales – desde modelos de Casos Uso, a través de modelos dinámicos y lógicos hasta el modelo de

despliegue físico final –

http://www.sparxsystems.com.ar/resources/tutorial/business_process_model.html




El UML define la notación y las semánticas para los siguientes dominios:

El Modelo de Interacción del Usuario o Modelo de Casos de Uso.- Describe el

límite y la interacción entre el sistema y los usuarios-. Se corresponde en cierta

manera a un modelo de análisis de requisitos.

El Modelo de Interacción o de Colaboración.- Describe cómo

interactuará los objetos en el sistema entre sí para realizar el trabajo.

EL Modelo de Estado o Modelo Dinámico.- Las cartas de estados

describen los estados o condiciones que las clases asumen a través del tiempo-. Los grafos de actividad describen los flujos de trabajo que

implementará el sistema.

El Modelo Lógico o de Clases.-Describe las clases y los objetos que conformarán el sistema.

El Modelo de Componentes Físicos.- Describe el software (y algunas

veces los componentes de hardware) que conforman el sistema.

EL Modelo de Despliegue Físico.- Describe la arquitectura física y el despliegue de componentes en esa arquitectura de hardware.

Análisis & Diseño /OO: ¿Cómo debe usar UML? El UML se usa normalmente como una parte de un proceso de desarrollo de software, con

el soporte de la herramienta CASE apropiada, para definir los requisitos, las

interacciones y los elementos del sistema de software propuesto. La naturaleza

exacta del proceso depende de la metodología del desarrollo usada.

El siguiente es un ejemplo del siguiente proceso:

1. Captura del Proceso de Negocio. Este se usará para definir las actividades y

procesos de alto nivel que ocurren en una organización y proveen una base para el

modelo de Casos de Uso. El Proceso de Negocios normalmente capturará más de

lo que implementaría un sistema de software. Es decir, la meta-data de la

empresa, el Modelo de Negocio analiza la estructura y dinámica de la organización

que albergará el sistema.

2. Traza un Modelo de Casos de Uso del Proceso de Negocio para definir

exactamente que funcionalidad intenta proveer desde la perspectiva del usuario.

Mientras cada Caso de Uso se agrega, crea un vínculo trazable desde los procesos de

negocios apropiados al Caso de Uso (es decir, una conexión de realización). Este

trazado claramente establece que funcionalidad proveerá el nuevo sistema para

cumplir con los requisitos del negocio establecido en el proceso. Este también asegura

que no existe ningún Caso de Uso sin un propósito.

http://www.sparxsystems.com.ar/resources/tutorial/logical_model.html




3. Refine los Casos de Uso – incluye requisitos, restricciones, clasificación de

complejidad, notas y escenarios. Esta información describe lo que hace el Caso de

Uso, como se ejecuta y las restricciones en esta ejecución. Se asegura de que el

Caso de Uso reúna los requisitos del sistema. También incluye algunos scripts de

pruebas de aceptación del usuario para definir como el usuario probará esta

funcionalidad y cuáles son los criterios de aceptación: Prototipado.

4. Modelo de Dominio. El análisis del modelo de casos de uso, es el punto de inicio

para estructurar el modelo de dominio. O bjetos de negocio de alto nivel,

principalmente diagramas conceptuales, diagrama de secuencia, diagrama de

colaboración y los modelos de la interfaz de usuario. Estos describen las ―cosas en

el nuevo sistema, la manera en que esas partes interactúan y la interfaz que un

usuario usará para ejecutar los escenarios de los casos de uso.

5. Desde el modelo de dominio, el modelo de la interfaz de usuario y los diagramas del

escenario crean el Modelo de Diseño de Software. Esta es una especificación

precisa de los objetos en el sistema, sus datos o atributos y su comportamiento u

operaciones. Los objetos que conforman el software se pueden abstraer en las

jerarquías de la clase usando herencias. Los mensajes del diagrama del escenario

normalmente trazarán las operaciones de la clase. Si se usa un marco existente o

patrón del diseño, es posible importar elementos del modelo existentes para

usarlos en el nuevo sistema.

6. Mientras la clase del modelo se desarrolla, se puede fraccionar en paquetes y

componentes discretos. Un componente representa una porción despegable del

software que recolecta el comportamiento y datos de una o más clases, y expone

una interfaz estricta a otros consumidores de sus servicios. Así un Modelo del

Componente se compila para definir el empaquetamiento lógico de las clases. Para

cada componente define pruebas de integración para confirmar que la interfaz del

componente reúne la especificación dada en relación con otros elementos del

software.

7. Concurrentemente con el trabajo que ya realizó, se deberían capturar y documentar

requisitos adicionales. Por ejemplo – los requisitos funcionales, requisitos de

desempeño, requisitos de seguridad, responsabilidades, y más. Colecta estos dentro

del modelo y los mantiene al día mientras madura el modelo.

8. El Modelo de Despliegue define la arquitectura física del sistema. Este trabajo puede

comenzar tempranamente para capturar las características de despliegue físico – que

hardware, sistemas operativos, capacidades de la red, software de interfaces y

soporte conformarán el nuevo sistema, donde se desplegará y que parámetros aplica

para recuperarse de los desastres, confiabilidad, copias de seguridad y soporte.

Mientras el modelo se desarrolla la arquitectura física se actualizará para reflejar el

sistema actual propuesto.

9. Construye el sistema: Toma piezas discretas del modelo y asigna uno o más

desarrolladores. En una compilación dirigida por Casos de Uso, esto significará

asignar un Caso de Uso a un equipo de desarrollo, y hacer que ellos construyan

pantallas, objetos de negocio, tablas de base de datos, y los componentes

relacionados necesarios para ejecutar ese Caso de Uso. Mientras cada Caso de Uso se

construye, éste debería estar acompañado por pruebas de sistema, integración y

unidad completas.




10. Rastrea los defectos que emergen en la fase de pruebas contra los elementos del

modelo relacionados – ej. Defectos de prueba del sistema contra los Casos de Uso,

defectos de prueba de unidad contra las clases etc. Rastrea cualquier cambio contra

los elementos del modelo relacionado para administrar -scope creep- (ámbito de

arrastre).

11. Actualiza y refine el modelo mientras procede el trabajo – siempre evaluando el

impacto de cambios y mejoras del modelo en trabajos posteriores. Usa una

aproximación iterativa para trabajar a través del diseño en fragmentos discretos,

siempre evaluando la compilación actual, los requisitos posteriores y cualquier

descubrimiento que aparece durante el desarrollo.

12. Entrega del software completo a un proceso de prueba y al entorno de producción. Si

se realiza una entrega en fases, luego ésta migración del software de construcción

desde la prueba a la producción puede ocurrir varias veces en la vida del producto.

IMPORTANTE . Tener en cuenta que el proceso anterior es necesariamente corto en

descripción, deja mucho sin decir y puede ser que no corresponda a su forma de

trabajo y que no siga el proceso que ha adoptado. Esto se ha proporcionado como un

ejemplo de cómo se puede usar UML para soportar un proyecto de desarrollo de

software.




Diagramas y Elementos UML 1. Diagrama de casos de uso Los diagramas de casos de uso describen las relaciones y las dependencias entre un

grupo de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso están pensados para

representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros

usuarios del sistema, y con el cliente, y resultan especialmente útiles para

determinar las características necesarias que tendrá el sistema. En otras palabras,

los diagramas de casos de uso describen qué es lo que debe hacer el sistema,

pero no cómo.

UML Model: Modelo un diagrama de casos de uso.

<<extend>>

<<extend>> <<include>>

Cliente

Cliente remoto

ClientePersonal

Call Center

Counter

Paquete de turismo

Reservas

Agente de viaje

Pago de paquete

UC-01: Diagrama de Caso de Uso y relaciones de Asociacion, Generalizacion y Dependencia.




Elementos de los Diagramas de Use Case. 1.1. Caso de uso.

Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son requisitos, ante todo son requisitos funcionales.

Los casos de uso son descriptores de las interacciones típicas entre los usuarios

de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y

especifican qué requisitos de funcionamiento debe tener este (recuerde,

únicamente el qué, nunca el cómo).

1.2. Relaciones de Casos de Uso.

1. Relaciones de Asociación.- Se establecen entre Actores – Use Case. Los

actores definen roles que disparan acciones asociaciones. 2. Relaciones de Dependencia.- Se establecen entre Use Case – Use Case. Los

casos de uso pueden tener relaciones con otros casos de uso. Los dos tipos de relaciones de dependencia comunes entre casos de uso son:

<<include>> que especifica una situación en la que un caso de uso

tiene lugar dentro de otro caso de uso llamado base. Para que el caso de

uso base se realice o tenga éxito – obligatoriedad -, es necesario que

el caso de uso incluido se cumpla.

<<extend>> que especifica que en ciertas situaciones –alternativo-, o en algún punto (llamado punto de extensión) un caso de uso base

será extendido por otro.

3. Relaciones de Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar

algunas o todas ellas de una forma muy similar a las herencias entre clases.

1.3. Actores

Un actor es una entidad externa que interacciona con el sistema participando y

normalmente iniciando, un caso de uso. Un actor es algo con comportamiento, los

actores pueden ser gente real (identificada por un rol. Por ejemplo, cliente, cajero de TPDV), otro sistema informatizado u organización (por ejemplo, un dispensador

de productos, un ATM o cajero de Bco.).

Los actores no representan a personas físicas o a sistemas, sino su papel

(Roles). Esto significa que cuando una persona interacciones con el sistema de

diferentes maneras (asumiendo diferentes papeles), estará representado por varios

actores. Por ejemplo, una persona que proporciona servicios de atención al cliente

telefónicamente y realiza pedidos para los clientes estaría representada por un

actor «equipo de soporte» y por otro actor «Representante de ventas».




1.4. Narrativas o Descripción de casos de uso.

Las descripciones de casos de uso son reseñas textuales del

caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el

caso de uso, y explica los procesos o actividades que tienen

lugar en el caso de uso.

Los casos de uso son un mecanismo para ayudar a mantenerlo simple y entendible para todo el personal involucrado.

De manera informal, son historias del uso de un sistema

para alcanzar los objetivos. (Un Escenario o instancia de

caso de uso). Es una historia particular del uso de un sistema

o un camino a través del caso de uso.

Por ejemplo, El escenario de éxito de compra de artículos con

pago en efectivo. O el escenario de fallo de compra debido al

rechazo de la transacción de pago con la tarjeta de crédito (no

tiene suficiente crédito, clave de validación no valida, etc.).

Claramente entonces un caso de uso es una colección de escenarios con éxito y fallos relacionados, que describe a los

actores utilizando un sistema para satisfacer un objetivo.

IMPORTANTE. Un escenario es una secuencia específica de acciones e interacciones entre los

actores y el sistema objeto de estudio, también se denomina instancia de caso de uso.

2. Tipos de formalidad de las Narrativas. Los casos de uso de escriben con varios

grados de formalidad:

Breve: Resumen conciso de un párrafo, normalmente del escenario principal de éxito.

Informal: Múltiples párrafos que comprenden varios escenarios, éxito (flujo normal) y fallo (flujo alternativo).

Completo: el más elaborado. Se escriben con más detalle los pasos y variaciones. Hay secciones de apoyo como pre-condiciones, post-

condiciones, excepciones, etc.

ANTECEDENTES

UML Use Case. La idea de utilizar los Casos de Uso para describir los requisitos funcionales fue introducida en 1986 por Ivar Jacobson, uno de los contribuidores principales de UML y UP. La idea de caso de uso de Jacobson ha tenido una gran influencia y ha sido ampliamente reconocida, siendo sus principales virtudes la simplicidad y utilidad. Sin embargo la definición de que son los casos de uso y como escribirlos, procede de Alistar Cockburn.




Narrativa de Caso de Uso - Formato completo

Use Case Name :

Description : - a brief summary of what the use case is about -

Scenario

A quick summary of what is going to happen in the use case – exclude actor

Triggering event

What the actor does in relation to the system – should be first in flow of events

Actors

List the primary actors – the ones with their hands on the keyboard

Related use cases

Comma separated list of related use cases

Stakeholders

Who is interested in the result of this use case and their role in it

Pre-condition

What needs to be in place before this use case can execute

Post-condition

How will the system have changed as a result of this use case

Flow of events

Actor

System

1. The first event should be the triggering event

Exception

A list of things that could go wrong and how the system responds

3. Diagrama de clases.

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas

de clases son diagramas «estáticos» porque muestran las clases, junto con

sus métodos y atributos, así como las relaciones estáticas entre ellas.




UML Model: Modelo de un diagrama de clases.

4.1. Clase. Una clase define los atributos y los métodos de una serie de objetos. Todos los

objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el

mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se

utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo,

y que el término tipo tiene un significado más general.

En UML, las clases están representadas por rectángulos, con el nombre de la clase,

y también pueden mostrar atributos y operaciones de la clase en otros dos

«compartimentos» dentro del rectángulo.

Representación visual de

una clase en UML

gestiona

CD-01: Diagrama de Clases y relaciones entre clases

1..1

realiza

0..*

es realizado por

1..1

0..*

1..1

supervisa

0..*

es supervisado por

Cliente

ClienteCorporativo ClientePersonal

Pedido GestionDeCredito

EjecutivoDeVenta




Atributos de clase. En UML, los atributos se muestran al menos con su nombre, y también pueden

mostrar su tipo, valor inicial y otras propiedades.

Visibilidad: Los atributos también pueden ser mostrados

visualmente:

+ Indica atributos públicos # Indica atributos protegidos

- Indica atributos privados

Operaciones de clase. Las operaciones (métodos) también se muestran al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno.

Visibilidad: Las operaciones, al igual que los atributos, se pueden mostrar

visualmente:

+ Indica operaciones públicas # Indica operaciones protegidas

- Indica operaciones privadas

Relaciones entre clases. Las clases se pueden relacionar (estar asociadas) con otras de diferentes maneras:

Generalización

La herencia es uno de los conceptos fundamentales de la

programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y

operaciones propias.

En UML, una asociación de generalización entre dos clases, coloca a

estas en una jerarquía que representa el concepto de herencia de una

clase derivada de la clase base. En UML, las generalizaciones se

representan por medio de una línea que conecta las dos clases, con

una flecha en el lado de la clase base.




UML Model: Representación visual de una generalización en UML.

Asociaciones.

Una asociación representa una relación entre clases, y aporta la semántica común y

la estructura de muchos tipos de «conexiones» entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí.

Describe la conexión entre diferentes clases.

Las asociaciones pueden tener una papel que especifica el propósito de la asociación

y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos

participantes en la relación pueden intercambiar mensajes entre sí, o es

únicamente uno de ellos el que recibe información del otro). Cada extremo de la

asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese

lado de la asociación están relacionados con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de líneas que conectan las clases

participantes en la relación, y también pueden mostrar el papel o Rol y la

multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el

infinito en el lado máximo.

Representación visual de una asociación en UML

FiguraPlana

FiguraGeometrica

FiguraSolida

EsferaCilindroConoToro

CD-02: Diagrama de Clases y relaciones de Generalizacion.




Estereotipos: relaciones de Composición / Agregación. Agregación

Las Agregaciones son tipos especiales de asociaciones en las que las dos clases

participantes no tienen un estado igual, pero constituyen una relación

«completa». Una Agregación describe cómo se compone la clase que asume el rol

completo de otras clases que se encargan de las partes. En las Agregaciones, la clase que actúa como completa, tiene una multiplicidad de uno.

En UML, las Agregaciones están representadas por una asociación que muestra un

rombo vacío en uno de los lados de la clase completa.

Representación visual de una relación de Agregación en UML.

Composición

Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones

completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las

partes también lo son.

En UML, las composiciones están representadas por un rombo sólido al lado del

conjunto.

Representación visual de una relación de Composición en UML

1..1

1..*

1..1

1..*

1..1

1..*

MainboardMicroprocesador Core

Memoria

CD-04: Diagrama de Clases y relaciones de Agregacion y Composicion.




Otros componentes de los diagrama de clases. Los diagramas de clases pueden contener más componentes aparte de clases.

Interfaces

Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas

directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las

clases pueden heredarse de las interfaces pudiendo así realizarse instancias a partir

de estos diagramas.

Paquetes

Los paquetes, en lenguajes de programación, representan un espacio de nombres

en un diagrama se emplean para representar partes del sistema que contienen más de una clase, incluso cientos de ellas.




6. Diagramas de secuencia. Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma

en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial

énfasis en el orden y el momento en que se envían los mensajes a los objetos.

En los diagramas de secuencia, los objetos están representados por líneas

intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los

mensajes son enviados de un objeto a otro en forma de flechas con los nombres de

la operación y los parámetros.

UML Model mostrando un diagrama de secuencia.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalize, o asíncronos

donde se devuelve el control directamente al objeto que realiza la llamada.

Diagraga de secuencia: Manufactura e Inventario

seleccionar(prototipo)

test = controlCalidad(articulo)

ordenCompra(articulo, vendedor)

despachar(articulo, vendedor)

registroVenta(articulo, vendedor)

Trabajador2

Manufactura de Articulo Almacen




7. Diagramas de colaboración. Los diagramas de colaboración muestran las interacciones que ocurren entre los

objetos que participan en una situación determinada. Esta es más o menos la misma

información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas

de colaboración fijan el interés en las relaciones entre los objetos y su topología.

En los diagramas de

colaboración los mensajes

enviados de un objeto a otro

se representan mediante flechas,

mostrando el nombre del

mensaje, los parámetros y la

secuencia del mensaje. Los

diagramas de colaboración están

indicados para mostrar una

situación o flujo programa

específicos y son unos de los

mejores tipos de diagramas para

demostrar o explicar

rápidamente un proceso dentro

de la lógica del programa.

UML Model mostrando un diagrama de comunicación.




8. Diagrama de estado. Los diagramas de estado muestran los diferentes estados de un objeto durante su

vida, y los estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas

finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar

su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo,

un objeto de tipo NetServer puede tener durante su vida uno de los siguientes

estados:

Listo

Escuchando

Trabajando

Detenido

y los eventos que pueden producir que el objeto cambie de estado son

Se crea el objeto

El objeto recibe un mensaje de escucha

Un cliente solicita una conexión a través de la red

Un cliente finaliza una solicitud

La solicitud se ejecuta y ser termina

El objeto recibe un mensaje de detención

etc

UML Model. Mostrando un

diagrama de estado.




Estado. Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe el estado interno de un

objeto de una clase particular

Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar

representados por estados, sino únicamente aquellos cambios que pueden afectar

significativamente a la forma de funcionamiento del objeto

Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que

no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningún evento que pueda sacar a un objeto de su estado de fin.

9. Diagrama de actividad. Los diagramas de actividad describen la secuencia de las actividades en un sistema.

Los diagramas de actividad son una forma especial de los diagramas de estado, que

únicamente o mayormente contienen actividades.

UML Model. Mostrando un diagrama de actividad.




Los diagramas de actividad son similares a los diagramas de flujo procesales, con la

diferencia de que todas las actividades están claramente unidas a objetos.

Los diagramas de actividad soportan actividades tanto secuenciales como

paralelas. La ejecución paralela se representa por medio de iconos de fork/espera,

en el caso de las actividades paralelas, no importa en qué orden sean invocadas

(pueden ser ejecutadas simultáneamente o una detrás de otra).

Actividad Una actividad es un único paso de un

proceso. Una actividad es un estado del

sistema que al menos tiene, unas

transiciones entrantes, salientes o ambas. Las actividades también pueden

tener más de una transición saliente, si

transitan hacia condiciones que deben

ser evaluadas (Condición de guardia).

Las actividades pueden formar jerarquías, lo que significa que una actividad puede estar formada de

varias actividades «de detalle», en cuyo caso las transiciones entrantes y

salientes deberían coincidir con las del diagrama de detalle.

Elementos de ayuda. Existen unos pocos elementos en UML que no tiene un valor semántico real en la

maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son

Línea de texto Notas de texto y enlaces

Las líneas de texto son útiles para añadir información textual a un diagrama. Es texto es libre y no tiene ningún significado para la maqueta.

Las notas son útiles para añadir información más detallada de un objeto o una

situación específica. Tienen la gran ventaja de que se pueden anclar a los elementos

UML para mostrar que una nota «pertenece» a un objeto o situación específica.




10. Diagramas de componentes. Los diagramas de componentes muestran los componentes del software (ya sea las

tecnologías que lo forman como componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que está compuesto

como los archivos de código fuente, las librerías o las tablas de una base de datos.

Los componentes pueden tener interfaces (es decir clases abstractas con

operaciones) que permiten asociaciones entre componentes.

Implementación de Componentes. Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá

cuando se construya. Un Modelo 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

provee un alto grado de trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un componente o una clase

documenta la funcionalidad mínima que debe ser implementada por el componente.

El ejemplo de arriba muestra que el caso de uso "Acceso" implementa el requisito formal "1.01

Acceder al sitio web". También establece que el componente de lógica de negocios y el

componente de páginas ASP implementan alguna parte o toda la funcionalidad de "Acceso". Un

refinamiento adicional es mostrar la pantalla de "Acceso" (una página web) como una

implementación de su interfaz. Estos enlaces de implementación o realización definen la

trazabilidad desde los requisitos formales, a través de casos de uso, a componentes y pantallas.




11. Componentes persistentes de información. Diagramas de relación de entidad

Los diagramas de relaciones de entidad (diagramas ER) muestran el diseño conceptual de las aplicaciones de bases de datos. Representan varias entidades

(conceptos) en el sistema de información y las relaciones y restricciones existentes

entre ellas. Una extensión de los diagramas de relaciones de entidad llamado

«diagramas de relaciones de entidad extendida» o «diagramas de relaciones de

entidad mejoradas» (EER), se utiliza para incorporar las técnicas de diseño orientadas

a objetos en los diagramas ER.

UML Model. Mostrando un diagrama de relaciones de entidad

Entidad

Una Entidad es cualquier concepto del mundo real con una existencia independiente.

Puede ser un objeto con una existencia física (ejemplo, máquina, robot) o puede ser

un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad.

En un diagrama ER, las entidades se representan como

rectángulos, con el nombre de la clase, y también pueden

mostrar atributos y operaciones de la clase en otros dos

«compartimentos» dentro del rectángulo.




Atributos de la entidad

En los diagramas ER, los atributos de la entidad se muestra con su nombre

en un compartimento diferente de la entidad a la que pertenecen.

Restricciones

Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de información.

Tipo de restricciones:

Clave primaria: El conjunto de atributos declarados como clave primaria es

única para la entidad. Solo puede haber una clave primaria en una entidad y

ninguno de los atributos que la componen puede ser NULL.

Clave única: El conjunto de atributos declarados como única son únicos para la entidad. Pueden haber muchas restricciones únicas en una entidad. Los atributos

que lo componen pueden tener el valor NULL. Las claves únicas y primarias

identifican de forma única una fila de una tabla (entidad)

Clave externa: Una clave externa es una restricción referencia entre dos tablas.

La clave externa identifica una columna o un conjunto de columnas en un tabla (referenciada) que referencia una columna o conjunto de columnas en otra

tabla (referenciada). Las columnas en la tabla referenciada deben formar una

clave primaria o una clave única.

Reglas de Negocio. Es una condición que define los datos válidos cuando se

añaden o actualizan datos en una tabla de la base de datos relacional. Se aplicará

una restricción a cada fila de la tabla. La restricción debe ser un predicado. Puede referirse a una o varias columnas de la tabla.

( 1 )Restricción de modelo de datos: Implementa la integridad de dominio.

( 2 )Restricción de Derivación: Implementa la independencia de campo.

( 3 )Restricción de Comprobacion: que refuerza el modelo de datos. Y ( 4 ) La restricción de Relación: que implementa la integridad relacional, también

conocida como restricción de comprobación de tabla.

Modelos Diagramas Elementos UML 01

Documents

Transcript of Modelos Diagramas Elementos UML 01