B3-T5_UML Flashcards
¿En qué se diferencian el diagrama de ACTIVIDAD del de SECUENCIA?
SECUENCIA: simplemente representa la interacción entre objetos en orden secuencial, es decir, en el orden en el que tiene lugar dichas interacciones.
Un diagrama de Secuencia por CASOS DE USO.
ACTIVIDAD: es, básicamente, un diagrama de flujo que muestra actividades ejecutadas por un sistema.
Son los equivalentes en POO a los diagramas de flujo DFD.
¿Qué 4 tipos de relaciones existen en los diagramas de CASOS DE USO?
- COMUNICACIÓN: Relación (asociación) entre un actor y un caso de uso, que se enlazan mediante líneas continua sin puntas. El estereotipo de la relación de comunicación es: «communicate».
- INCLUSIÓN: Un caso de uso base incorpora EXPLÍCITAMENTE el comportamiento de otro en algún lugar de su secuencia, para enriquecer un caso de uso con otro y compartir funcionalidades.
«include» - EXTENSIÓN: Un caso de uso base incorpora IMPLÍCITAMENTE el comportamiento de otro caso de uso en una serie de puntos concretos y previstos en el momento del diseño, llamados puntos de extensión, los cuáles no son parte del flujo principal.
«extend»
MNEMOTECNIA: Inclusión/Explícitamente => I/E
Extensión/Implícitamente => E/I
NOTA: Implícito, es algo que está incluido en otra cosa sin que esta lo exprese o lo manifieste de manera directa, es decir, habría que interpretarlo.
El término es el antónimo de explícito, que refiere a lo que expresa clara y determinadamente una cosa, NO habría que interpretarlo.
- ESPECIALIZACIÓN y GENERALIZACIÓN: Un caso de uso , subcaso o hijo, hereda el comportamiento y significado de un super-caso o padre (hereda las relaciones de COMUNICACIÓN, INCLUSIÓN y EXTENSIÓN del super-caso).
Los casos de uso “hijo” (sub-caso) son una especialización del caso de uso “padre” (super-caso).
Es decir, la ESPECIALIZACIÓN es cada parte (hijo) en la que hereda el super-caso (padre). En el diagrama se aprecia, depende de si lo miras desde arriba o desde abajo, como podemos comprobar en la foto:
Sabemos que hay 2 tipos de diagramas UML (Estructurales y de Comportamiento), define los ESTRUCTURALES:
*CLASES: representa los diferentes tipos de objetos (diagrama de objetos) y los tipos de relaciones ESTÁTICAS que existen entre ellos.
*OBJETOS: muestra una vista completa o parcial de los objetos de un sistema en un instante de ejecución específico. Muestra las asociaciones del Diagrama de CLASES uno a uno.
*COMPONENTES: representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes.
*ESTRUCTURA COMPUESTA: para poder meternos dentro del componente u objeto (Zoom in).
*DESPLIEGUE: muestra la disposición física de los artefactos software en nodos (plataforma de hardware), es decir, en que nodos vamos a desplegar los componentes.
*PAQUETES: muestra cómo un sistema está dividido en agrupaciones lógicas (paquetes) y las dependencias entre esas agrupaciones.
*PERFIL: (PROFILE) perfiles que creamos para extender la semántica UML (lenguaje extensible). Es decir, permite el uso de perfiles creados para un metamodelo dado.
NOTA: UML persigue que en un mismo diagrama tengas la parte de alto nivel y la de detalle JUNTAS.
Sabemos que hay 2 tipos de diagramas UML (Estructurales y de Comportamiento), define los De COMPORTAMIENTO:
*ACTIVIDAD: es un diagrama de flujo que representa gráficamente un algoritmo o proceso. Son los equivalentes a los diagramas de flujo DFD.
*CASOS DE USO: es una descripción de las actividades que deberá realizar alguien o algo para llevar a cabo algún proceso.
*ESTADOS: (también llamado diagrama de máquina de estados) muestra los estados por los que pasa una máquina de estados finitos.
*INTERACCIÓN:diagrama UML que se emplea para captar el comportamiento interactivo de un sistema. Hay 4 tipos:
- SECUENCIA: muestra cómo interactúa un conjunto de objetos en un proceso a lo largo del tiempo. Muestra los mensajes que pasan entre los participantes y los objetos del sistema y el orden en que se producen. Junto al de COMUNICACIÓN son las 2 manera de representar las relaciones entre objetos en UML (POO).
- COMUNICACIÓN: forma de representar interacción entre objetos, alterna al diagrama de secuencia, aunque aquí si se ven los enlaces entre objetos (árbol de objetos) y las secuencias están numeradas, en lugar de mediante una línea temporal.
- TIEMPOS: para modelar el comportamiento del sistema dando especial importancia al tiempo.
- INTERACTION OVERVIEW: (también llamado Diagrama Global de Interacción) hace una visualización “Zoom in” (como el de Estructura Compuesta) para poder ver una actividad concreta dentro de un diagrama de Actividad con otro de Interacción (ej: Diagrama de Secuencia)
NOTA: UML persigue que en un mismo diagrama tengas la parte de alto nivel y la de detalle JUNTAS.
Resume la biografía de UML:
1º UML fue creado en la empresa “Rational”, donde también se creó RUP (Rational Unified Process).
*RUP: es un proceso “Interactivo” e “Incremental”, donde en cada interacción se toma un conjunto de casos de uso y se desarrollan las 3 fases: diseño, implementación y pruebas.
Otros procesos unificados (UP): OpenUP y AgileUP.
NOTA: estos UP, dirigidos por los casos de uso, están centrados en sobre que ARQUITECTURA vamos a trabajar y tienen enfoque en la Gestión de Riesgos lo + pronto posible (enseñar cuanto antes el producto al cliente para que nos informe de posibles modificaciones).
2º Luego fue gobernado por la organización de empresas OMG, que también tiene el estándar CORBA.
3º AHORA ES UN ESTÁNDAR DE:
ISO-IEC 19505
Define UML, CORE y CASE:
*UML: es un POO para hacer diagramas que especifiquen sistemas tanto su parte estructural como dinámica.
Es un lenguaje EXTENSIBLE, es decir, si quisiéramos modelar un determinado dominio y no fuera suficiente con la semántica de UML, tiene mecanismos para ampliar dicha semántica (PROFILE).
*CORE: paquete que se considera el núcleo de UML.
*CASE: herramienta informática para hacer diagramas.
NOTA: un POO es un conjunto de objetos que colaboran entre sí.
¿En qué se diferencian SUPERESTRUCTURA (notación y semántica de los diagramas) de INFRAESTRUCTURA (metamodelo de soporte) en UML?
*SUPERESTRUCTURA: se definen los diagramas (modelos) a través de los elementos especificados en la INFRAESTRUCTURA.
*INFRAESTRUCTURA: donde se definen los metamodelos, que van a dar soporte a los diagramas (SUPERESTRUCTURA).
CORE, METAMODELOS (M3 -> M2 -> M1 -> M0) y PROFILE (estereotipos, restricciones y valores etiquetados).
NOTA: son dos PDFs o capas que componen la estructura de UML.
¿Qué es OCL (Lenguaje para definir restricciones/reglas)?
Es un mini-lenguaje o sintaxis para establecer condiciones, invariantes (condición que se cumple siempre), reglas, postcondiciones, estados, … en UML.
¿Cómo se intercambian los datos (diagramas/modelos) en UML?
Con la herramienta XMI (XML Metadata Interchange), para el intercambio de diagramas y compartir modelos UML basados en XML, entre diferentes herramientas de modelado.
Define mecanismos de EXTENSIÓN de UML:
*«ESTEREOTIPOS»: para indicar de que tipo es una clase.
Ej: «UI»
*{RESTRICCIONES}: limita los valores que las entidades pueden tomar. Las delimita con llaves, que coloca cerca de la entidad restringida.
Ej: {ordered} => condiciona que una colección de objetos este ordenada.
*VALORES ETIQUETADOS: cuando queremos que un campo (atributo o columna) tenga un valor determinado.
Ej: {procesadores=3}
*PERFILES (PROFILE): paquete o conjunto de mecanismos de EXTENSIÓN (estereotipos, restricciones y valores etiquetados), que creamos sobre un tema. Con nuevos elementos (otros lenguajes orientados a objetos), para complementar el lenguaje tradicional o base de UML.
Ej: crear un paquete con métodos Java para completar nuestro diagrama:
«JSP» ESTEREOTIPO creado por PROFILE, porque no existia en UML (aporta la especificación de la clase).
Otro ejemplo en la FOTO ADJUNTADA (EJB)
¿Qué son JSP y EJB?
*JSP: JavaServer Pages es una tecnología para crear páginas web dinámicas basadas en HTML y XML. JSP es similar a PHP, pero usa el lenguaje de programación Java.
*EJB: la API Enterprise JavaBeans de J2EE, como su propio nombre indica (APIinterface), es una interface que dota al programador de un modelo basado en componentes (flexibles y reutilizables), que le permite abstraerse de los problemas generales de una aplicación empresarial (transacciones, persistencia, seguridad, …) y poderse centrar en el desarrollo de la lógica de negocio.
Esquematiza la jerarquía FOUR-LAYER de los metamodelos definidos en la INFRAESTRUCTURA UML:
M3 (MOF): clases de cosas en general.
^
M2 (UML Metamodelo): están todos los atributos y clases a utilizar.
^
M1: (User Metamodelo): relación de clases (atributos y métodos) con los objetos de “M0”.
^
M0 (Runtime Instance): los objetos (instancias=objetos) que estamos manejando, NO hay clases.
Sabemos que la filosofía para desarrollo MDA (Model Driven Architecture), dirigida por modelos tan detallados para evitar programar, cayó en saco roto, pero ¿cuáles son las fases en las que se divide?
El proceso de desarrollo de software con MDA se puede dividir en las siguientes fases:
1º CIM (Computationally-Independent Model): describe conceptualmente un sistema.
2º PIM (Plataform Independient Model): construcción de un modelo de alto nivel del sistema, independiente de cualquier tecnología o PLATAFORMA.
3º PSM (Plataform Specific Model): transformación del modelo anterior a uno especifico de plataforma, describiendo el sistema con una tecnología determinada.
4º Generación de CÓDIGO a partir del modelo PSM (este proceso puede automatizarse).
IMPORTANTE: para el paso de PIM a PSM y de PSM a código se usan herramientas de transformación, como MOF (Meta Object Facility), que es un estándar OMG ( Object Management Group) y para definir e intercambiar modelos. Y también define el formato de intercambio de modelos M1 basado en XML, llamado XMI (XML Metadata Interchange).
UML usa el paradigma “orientado a objetos” (POO y ADOO= Análisis y Diseño Orientado a Objetos), define algunos conceptos de dicho paradigma:
*CLASES: estructura de programación que define ATRIBUTOS (estructura) y MÉTODOS (comportamiento) de un OBJETO. Es decir, es la plantilla o esqueleto para crear objetos.
*OBJETO: (Estado o Identidad) elemento donde almacenar la información. Es cada una de las partes de una clase, se crean a partir de estas y sirven para guardar información.
*ATRIBUTO: datos de negocio o referencias a otros objetos, es decir, cada uno de los campos definidos en una clase.
*MÉTODO: implementación de un determinado comportamiento. Es decir, son cada una de las funciones / operaciones de una clase. (SOBRECARGA: cuando tenemos muchos métodos con el mismo nombre, pero distintos parámetros en una clase concreta).
*MENSAJE: llamada a un método.
UML usa el paradigma “orientado a objetos” (POO y ADOO= Análisis y Diseño Orientado a Objetos), define algunos conceptos de dicho paradigma:
*ABSTRACCIÓN: capturar los detalles del negocio a modelar => 1º objetos y 2º clases. Es decir, es el proceso mental para pasar lo particular (objetos) a lo general (clases).
*ENCAPSULAMIENTO: ocultación de los detalles internos del objeto => reducir acoplamiento. Es decir,aislar un objeto para ocultar sus detalles internos.
*POLIMORFISMO: (ES LA BASE DE LA TECNOLOGÍA DE LA PROGRAMACIÓN) capacidad para que objetos de distintas clases se hagan pasar por el mismo tipo. Es decir, es la técnica mediante la cual un mismo tipo de objetos tiene comportamientos diferentes frente a un mismo mensaje.
(LIGADURA DINÁMICA: capacidad que tiene el programa cuando se usa poliformismo para, en tiempo de ejecución, decidir cual es el objeto concreto que hay que llamar).
*HERENCIA: capacidad para definir una clase en términos de otra. Es decir, es la relación entre clases que define una clase dentro de otra, identificando los grupos de clases.
¿Qué son los Patrones de Análisis y pon un ejemplo?
Técnica de análisis que se repite tantas veces en los proyectos, que lo catalogan como patrón.
EJEMPLO: Patrón QUANTITY: refleja la parte monetaria (amount) y unidad (ej: double), es decir, en vez de:
double peso => quantity peso
*En resumen, QUANTITY refleja 2 partes:
“numérica y la unidad”
20 euros
100 kilogramos
Define el Diagrama de CLASES de UML (Diagrama Estructural):
Diagrama de la estructura ESTÁTICA (NO incluye la forma en la que se comportan los elementos a lo largo de la ejecución) de un sistema, mostrando las clases del sistema, sus atributos, métodos, y las RELACIONES entre los objetos.
Tipos de relaciones:
*Relación de ASOCIACIÓN: en el extremo de una asociación podemos definir: CARDINALIDAD y ROLE.
AUTOR———LIBRO (linea continua)
*Relación de HERENCIA: cuando una clase hereda de otra.
Book Item —–>BOOK ( (linea continua+ punta cerrada)
*Relación de AGREGACIÓN: un cierto objeto agrega elementos de otro, pero si eliminas el principal NO eliminas los asociados (Relación LÓGICA).
se representa con un rombo vacío
*Relación de COMPOSICIÓN: si se borra el objeto principal SI se borran los asociados. (Relación FÍSICA). Todo/parte.
se representa con un rombo relleno
*Relación de DEPENDENCIA: tiene que ir «estereotipada» para tener sentido, sino no existiría la dependencia entre las clases.
Un cambio en la especificación del elemento independiente puede afectar al elemento dependiente:
MOSTRAR FORMULARIO - - - - > FORMULARIO
(Clase DEPENDIENTE - - - - > Clase INDEPENDIENTE)
- - - - -> (linea discontinua+ punta abierta)
¿Cómo se indica una “implementación” y en qué se diferencia de la Relación de Dependencia?
SE INDICA: linea de flecha discontinua y punta CERRADA.
SE DIFERENCIAN: en la Relación de DEPENDENCIA la punta de la flecha es ABIERTA, aunque la linea también es discontinua.
¿Cómo se indica la visibilidad en los elementos de una clase (atributos y métodos) en UML?
VISIBILIDAD:
(+) PÚBLICO: se puede acceder desde cualquier lugar de la aplicación.
(-) PRIVADO: sólo se accede desde la misma clase.
(#) PROTEGIDO: sólo se puede acceder desde las misma clase o desde las clases que heredan de ella.
(/) DERIVADO
(~) PAQUETE
NOTA: el Diagrama de CLASES es una estructura ESTÁTICA, que define las clases que se utilizarán cuando se pase a la fase de construcción y la manera en que se relacionan.
Define el Diagrama de OBJETOS de UML (Diagrama Estructural):
Muestra las asociaciones del Diagrama de Clases una a una y poderlas analizar. Por lo tanto, UN DIAGRAMA DE OBJETOS PARTE DE UN DIAGRAMA DE CLASES.
Los objetos están enlazados independientemente por un LINK (enlace), normalmente a la derecha de la clase => “en este diagrama de objetos TODO son enlaces”.
NOTA: representa objetos y enlaces en lugar de clases y relaciones (Diagrama de Clases).
Define el Diagrama de COMPONENTES de UML (Diagrama Estructural):
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes.
SIMBOLOGÍA:
*Con el símbolo de media luna, estamos representando el interface que necesita el componente y con la bolita vacía, representamos el interface que ofrece el componente a otros => encajando un componente con otro.
*En el dibujo podemos apreciar la forma de la caja que representa a un componente. Y, los cuadraditos pequeños de donde salen las lineas, son los PUERTOS.
NOTA: a diferencia de los demás diagramas, el de componentes muestra las RELACIONES FÍSICAS entre los componentes => REPRESENTA OBJETOS Y EL CABLEADO QUE LOS CONECTA.
Está muy relacionado con el Diagrama de ESTRUCTURA COMPUESTA, pues este se usa para poder ver dentro de un componente concreto.
Define el Diagrama de ESTRUCTURA COMPUESTA de UML (Diagrama Estructural):
Muestra la estructura interna de una clase, componente u objeto y las colaboraciones que esta estructura hace posibles.
Normalmente se usa para meternos dentro (Zoom in) de cierto COMPONENTE y poder ver los interfaces o componente que ofrece o demanda. También vemos que clases están conectadas para cumplir con el cometido del diagrama.
*ZOOM IN: mirada al interior del diagrama, para poder definir clases, interfaces, paquetes, … y las relaciones entre ellos a un micronivel.
Define el Diagrama de PAQUETES de UML (Diagrama Estructural):
Muestran la organización y disposición de diversos elementos de un modelo en forma de paquete.
NOTA: un paquete es una agrupación de elementos UML relacionados: diagramas, documentos, clases o, incluso, paquetes.
Es decir, un diagrama de paquetes en el Lenguaje Unificado de Modelado representa las dependencias entre los paquetes que componen un modelo. Es decir, muestra cómo un sistema está dividido en agrupaciones lógicas y las dependencias (- - - - >) entre esas agrupaciones.
*En la foto adjuntada podemos ver la forma con que se representa un paquete.
Define el Diagrama de PERFILES (Profile) de UML (Diagrama Estructural):
Conjunto de mecanismos (paquete) de extensión (estereotipos, restricciones y valores etiquetados), que creamos sobre un tema, con otros elementos nuevos (lenguajes orientados a objetos) para complementar o ampliar el lenguaje UML (POO).
El diagrama de PERFIL permite el uso de perfiles para un metamodelo dado => proporcionando una representación de los conceptos utilizados en la definición de perfiles (paquetes, estereotipos, …).
Es decir, el diagrama de perfil es donde puede aplicar un perfil a un paquete. Por ejemplo:
1. aplique un perfil Java para obtener estereotipos y bases de datos de Java.
2. Aplique el estereotipo “namespace” (espacio de nombres) para definir un espacio de nobres de Java.
ADJUNTO FOTO CON 2 EJEMPLOS.
Define el Diagrama de DESPLIEGUE (Deployment) de UML (Diagrama Estructural):
Es utilizado para representar la distribución física (estática) de los componentes software en los distintos nodos físicos de la red.
Suele ser utilizado junto con el diagrama de componentes (incluso a veces con el diagrama de paquetes) de forma que, juntos, dan una visión general de como estará desplegado el sistema de información => El diagrama de COMPONENTES muestra que componentes existen y como se relacionan, mientras que el diagrama de DESPLIEGUE es utilizado para ver como se sitúan estos componentes lógicos en los distintos nodos físicos.
NOTA: también conocido como diagrama de Implementación, porque modela la implementación física de los artefactos en los nodos.
Para describir un sitio web, por ejemplo, un diagrama de implementación (DESPLIEGUE) mostraría qué componentes de hardware (“nodos”) existen (por ejemplo, un servidor web, un servidor de aplicaciones y un servidor de base de datos), qué componentes de software (“artefactos”) se ejecutan en cada nodo (p. ej., aplicación web, base de datos) y cómo se conectan las diferentes piezas (ej., JDBC, REST, RMI).
*RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota.
FOTO: La foto adjuntada muestra un ejemplo sobre este tipo de diagrama donde se muestran un total de 6 nodos y algunos de sus componentes.
Define el Diagrama de ACTIVIDAD de UML (Diagrama de Comportamiento):
Es el típico diagrama de flujo, pues representa la secuencia de las actividades o parte funcional del sistema.
Es decir, representa un flujo de objetos y datos.
Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad.
En resumen,el Diagrama de Actividad es la representación gráfica de un algoritmo o proceso.
Define el Diagrama de ESTADO de UML (Diagrama de Comportamiento):
Se usan para definir los estados por los que pasan los objetos de una clase.
De cada clase que identifiquemos con un comportamiento dinámico, tenemos que plasmar los estados por los que va pasando y cuales son esos eventos que hacen que los objetos de esa clase transiten de un estado a otro.
En definitiva, muestra los estados por los que pasa una máquina de estados finitos.
SINTAXIS DE EVENTO:
(parámetro de entrada)[condición]/acción
Ej: abonar
(cant)[cant>importe]/dar cambio
Define el Diagrama de CASOS de USO de UML (Diagrama de Comportamiento):
Un diagrama de casos de uso es una representación gráfica de las posibles interacciones de un usuario con un sistema. Un diagrama de casos de uso muestra varios casos de uso y diferentes tipos de usuarios que tiene el sistema.
Los casos de uso se representan mediante círculos o elipses (burbujas).
Las lineas continuas indican una asociación de COMUNICACIÓN.
Los actores son los roles de quienes van a usar el sistema:
a) A la Izquierda: se colocan los actores PRINCIPALES, que son los que desencadenan el caso de uso (CLIENTE).
b) A la Derecha: van los actores secundarios, son de los que se puede necesitar algún servicio (VENDEDOR).
Ej: cuando el empleado recibe una solicitud que firmar de un ciudadano:
Actor PRINCIPAL: ciudadano
Actor SECUNDARIO: sistema o servicio de firmas.
*Un caso de uso es un artefacto que define una secuencia de acciones que da lugar a un resultado de valor observable.
Define el Diagrama de CASOS de USO de UML (Diagrama de Comportamiento):
El Diagrama de Casos de Uso captura esas pequeñas transacciones que el usuario identifica como cosas que puede hacer en el sistema, es decir, este diagrama contiene una DESCRIPCIÓN TEXTUAL de todas las maneras que los actores previstos (usuarios) podrían trabajar con el software del sistema.
Los casos de uso NO describen ninguna funcionalidad interna (oculta al exterior) del sistema.
Un Caso de Uso se presenta en el diagrama dentro de una burbuja.
Hay 2 tipos de relaciones entre casos de uso:
1. «include» un caso de uso incluye la funcionalidad de otro.
2. «extend» indica un comportamiento opcional. Es decir, ocurre si primero pasa el caso al que esta relacionado.
Los Diagramas de COMUNICACIÓN y SECUENCIA son equivalentes y ambos están dentro del diagrama de Interacción (Comportamiento), pero ¿en qué se diferencian?
En general, el de COMUNICACIÓN es más complejo, porque vemos los enlaces entre objetos.
Diagrama de COMUNICACIÓN:
*La relación o secuencia entre objetos se muestra poniendo números entre dichos objetos.
*En el de COMUNICACIÓN se puede apreciar el “Árbol de Objetos”, sobre el que se realizan las llamadas a los métodos ó internaciones de objetos.
Diagrama de SECUENCIA;
*Aquí, la relación o secuencia entre objetos se muestra con un línea temporal (el tiempo discurre hace abajo).
*El de SECUENCIA representa un FLUJO DE LLAMADAS entre objetos dentro de un Caso de Uso.
Sabemos que el Diagrama de COMUNICACIÓN es algo más complejo que el de SECUENCIA porque muestra los enlaces entre objetos, aunque ambos están dentro del diagrama de Interacción (Comportamiento), pero ¿en qué se diferencian?
UML (Lenguaje Unificado de Modelado), al ser un programa orientado a objetos, trabaja con objetos relacionados entre sí. Y, hay 2 maneras de representar dicha relación:
Diagrama de Interacción- COMUNICACIÓN: parecido al de secuencia, pero las llamadas a los métodos se representan usando el Árbol de Objetos, donde vemos las interacciones entre objetos y las secuencias numeradas.
Diagrama de Interacción-SECUENCIA: representa como colaboran entre sí los objetos de la aplicación a través del tiempo, para poder cumplir un determinado escenario de un caso de uso.
a) NO representa bifurcaciones.
b) TAMPOCO representa los “enlaces” entre objetos.
Define el Diagrama de Interaction OVERVIEW de UML (Diagrama de Comportamiento-> Interacción):
*Es una mezcla del diagrama de ACTIVIDAD con otros diagramas de interacción, es decir, se usa para poder ver dentro de un Diagrama de ACTIVIDAD una actividad concreta a través de otro Diagrama de Interacción (Secuencia, Comunicación o Tiempo).
*Es interesante, porque muestra que ocurre internamente en una determinada actividad que nos interese.
NOTA: el Diagrama de ESTRUCTURA COMPUESTA (Diagrama Estructural) hace una función parecida, pero para ver componentes en lugar de actividades.
ADJUNTO FOTO CON 2 DIAGRAMAS OVERVIEW.
Si vemos una barra inclinada en el nombre de un atributo en UML, ¿qué quiere decir?
Que es un atributo DERIVADO.
*Otros signos: + (público) - (privado) # (protegido) ~ (paquete)
¿Cómo se denomina a la relación entre objetos entres los cuales se establece una dependencia vital?
Relación de COMPOSICIÓN (rombo relleno) => relación física. Por lo cual, si se elimina el objeto principal, se eliminan los asociados. A diferencia de la relación AGREGACIÓN o relación lógica (rombo vacío).
En UML, ¿cómo se denomina a la relación entre dos objetos conectados debido a que sus clases están asociadas también?
Enlace o link (están enlazados por medio de una linea continua sin puntas).
NOTA: predominan en el Diagrama de Objetos:
Sabemos que las dos relaciones que se pueden dar entre casos de uso fundamentalmente son: «include» y «extend», pero ¿sabrías definirlas?
- «include» un caso de uso INCLUYE la funcionalidad de otro.
- «extend» indica un comportamiento OPCIONAL. Es decir, ocurre si primero pasa el caso al que esta relacionado.
EJEMPLO: en la foto vemos que el caso de uso extendido (VALIDA INFORMACIÓN DE USUARIO), conlleva cierta opcionabilidad, pues para que se cumpla primero tiene que ocurrir algún caso de uso principal de la relación.
¿Que representa un diagrama de secuencia?
Un flujo de llamadas entre objetos a través de una línea temporal para un determinado escenario dentro del ámbito de un caso de uso.
A diferencia del otro diagrama en el que se representan las relaciones de objetos, Diagrama de COMUNICACIÓN, donde se aprecia el árbol de objetos (objetos enlazados) sobre el que se realizan las llamadas a los métodos.
¿Qué aporta el diagrama de comunicación respecto del de secuencia?
Que en el de comunicación se puede apreciar el árbol de objetos sobre los que se realizan las distintas llamadas o interacciones de objetos y se aprecian los objetos enlazados.
En cambio, en el de secuencia no se aprecian los objetos enlazados ni árbol, pues representa un flujo de llamadas entre objetos a través de una línea temporal para un caso de uso.
*Además, en el de COMUNICACIÓN las el flujo de las secuencias se refleja numéricamente, y en el de SECUENCIA a través de una línea temporal en sentido descendente.
Dentro de un diagrama de actividad, ¿cómo se llama al elemento que van entre corchetes y nos sirve para especificar una determinada condición?
GUARDA
En UML, ¿cuál es la mayor utilidad de un diagrama de interaction OVERVIEW?
En un diagrama de actividad poder ver con otro de interacción (comunicación, tiempo o secuencia) que es lo que ocurre en una actividad concreta (zoom in).
*Función parecida a la del Diagrama de Estructura Compuesta, pero este hace el zoom in sobre componentes u objetos.
