View
40
Download
4
Category
Preview:
Citation preview
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 –
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 2
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 3
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 4
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 5
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 6
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».
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 7
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 8
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 9
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
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 10
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 11
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 12
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 13
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 14
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
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 15
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 16
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 17
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 18
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 19
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 20
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.
Universidad Nacional de Ingeniería
Facultad de Ingeniería Industrial y Sistemas Unified Modeling Language
medi@NERO P á g i n a | 21
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.
Recommended