Clase XLX - 13112019 - Cierre de cuatarimestre / Guía de estudio

Fechas de exámenes finales

22/11/2019 (1er. Llamado) / 06/12/2019 (2do. Llamado) - 18:30 hs. - Sala de Informática 3

Guía de estudio / Temario

Arquitectura de Sistemas (Modelo 4+1)
Herramientas de Software para UML - StarUML

Diagramas de Casos de Uso
 • Actores
 • Pre-Condiciones y Post-Condiciones
 • Inclusiones
 • Extensiones
 • Generalización

Diagramas de Clases
 • Clases y Objetos
 • Estereotipos
 • Asociación
 • Agregación y Composición
 • Generalización
 • Realización
 • Dependencias
 • Restricciones 
 • Clases Abstractas e Interfaces

Diagramas de Estado
 • Estados y Transiciones
 • Iniciación y Terminación
 • Unión, División, Selección, Entrada y Salida
 • Estados Compuestos

Diagrama de Actividades
 • Flujo de control, nodo inicial y final
 • Nodos de Decisión y Combinación

 • Nodos de Bifurcación y Unión

 • Partición / calles / canales

Diagrama de Secuencia
 • Objetos, Mensajes, Línea de vida
 • Creación y Destrucción de Objetos
 • Ciclos

Diagrama de Comunicación / Colaboración
 • Objetos y Mensajes
 • Mensajes Condicionales 
 • Diagrama de Secuencia vs. Diagrama de Comunicación - Colaboración

Diagrama de Componentes
 • Componentes
 • Interfaces, Realización y Dependencias
 • Caja Abierta y Caja Cerrada 

Diagramas de Distribución o despliegue
 • Nodos
 • Artefactos
 • Rutas de Comunicación
 • Especificaciones

Gestión del Software II - Auto evaluación

1. ¿Para el desarrollo de un proyecto, por qué es necesario contar con un modelo?

2. ¿Cuál es la fuente de información para el desarrollo de las tareas del analista?

3. ¿Cuál es la herramienta de modelado propuesta para el desarrollo del sistema – caso de estudio?

4. ¿Para qué se utilizó UML? ¿Documentar? ¿Detallar los artefactos del sistema?

5. ¿Quiénes intervienen en el plan de diseño a convenir durante el desarrollo de un sistema?

6. ¿Por qué es necesario contar con diversos diagramas en el modelo de un sistema?

7. ¿Cuáles diagramas dan una perspectiva estática del sistema?

8. ¿Cuáles diagramas dan una perspectiva dinámica / de cambio del sistema? 

9. Clases:

a. ¿Cómo representa una clase en UML?

b. ¿Qué información puede mostrar en un símbolo de clase?

c. ¿Qué es una restricción? Cómo se indica?

d. ¿Para qué adjuntaría una nota a un símbolo de clase?

e. ¿Cómo se relacionan las clases para formar un modelo?

f. ¿Cómo representaría la multiplicidad?

g. ¿Cómo se aplica en concepto de herencia entre clases?

h. ¿Puede aplicarse este concepto a los componentes de otros diagramas?

i. ¿Cuál es la diferencia entre agregación y composición?

j. ¿Mencione los tres niveles de visibilidad y describa lo que cada uno de ellos significa. 

10. Casos de uso:

a. ¿Con qué fin se modelan los casos de uso?

b. Dé un ejemplo de cuándo emplear diagramas de clase y de casos de uso.

c. ¿Cómo se llama la entidad que inicia un caso de uso?

d. Inclusión y extensión delos casos de uso.

e. ¿Equivale un caso de uso a un escenario?

f. ¿Se aplica el concepto de generalización / herencia a los casos de uso? … a los actores?

g. De la lista de etapas del CVS, ¿dónde se utiliza este recurso? 

h. ¿Qué es lo que describe un modelo de casos de uso?

i.  ¿Describiría un modelo de casos de uso como un modelo lógico o físico del sistema? 

j.  Defina qué es un actor en un diagrama de casos de uso.

k. ¿Cuáles son las tres cosas que un caso de uso siempre debe describir?

11. Diagramas de estados:

a. ¿De qué forma difiere un diagrama de estados de uno de clases, o de casos de uso?

b. ¿De qué depende un diagrama de estados?

c. Defina sub estados. Enumere tipos de sub estados.

12. Diagramas de secuencias:

a. ¿Qué modela un diagrama de secuencias que no puede realizarse por ninguno de los otros diagramas UML?

b. Defina mensaje sincrónico y asincrónico.

c. En ocasiones un objeto cuenta con una operación que se invoca a sí misma. ¿Cómo se llama a esta operación? ¿Cómo se grafica?

d. ¿Cómo representaría el control de flujo en una instrucción de ciclo mientras (condición)?

e. … Y en una instrucción condicional?

13. Generalidades:

a. ¿Qué es lo que describe un diagrama de actividad?

b. Describa el uso de los carriles en los diagramas de actividad.

c. ¿Qué se puede describir en un diagrama de secuencia o de comunicación?

d. ¿Qué se puede mostrar en un diagrama de clases?

e. ¿Cuáles son los pasos para crear un diagrama de secuencia?

f. ¿Cuáles son las dos categorías de relaciones entre clases?

g. ¿Para qué se utilizan los diagramas de generalización/especialización?

h.¿Qué diagramas se utilizan para modelar el software y el hardware utilizados para implementar el diseño?

i. ¿Qué se describe mediante un diagrama de estados?

j. ¿Qué es un paquete en la metodología del UML?

k. ¿Por qué es importante usar el UML para el modelado?

l. ¿Qué vistas de un sistema permite modelar UML?

ll. Si decidiera utilizar UML para documentar, en la etapa de análisis del CVS, los requerimientos funcionales del nuevo sistema, ¿qué diagramas utilizaría?

m. Por cada requerimiento de sistemas ¿Qué o cuántos escenarios pueden modelarse?

n. Si decidiera utilizar UML para documentar, en la etapa de análisis del CVS, los requerimientos de hardware y software del sistema en uso, ¿qué diagramas utilizaría?

ñ. Si decidiera utilizar UML para documentar, en la etapa de análisis del CVS, las estructuras de datos y sus relaciones del sistema en uso, ¿qué diagramas utilizaría?

14. Determine qué recursos UML usaría para desarrollar:
a. Un modelo de comportamiento sobre el RF1 del sistema XX.
b. Un modelo estructural sobre el RF1 del sistema XX.


Requerimientos funcionales de XX

RF1 El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente.

RF2 Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.

RF3 Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema.

RFn ...

Clase XLIX - 08112019 - Proyecto integrador

Uso de UML en los requerimientos de software 

El lenguaje unificado de modelado es el lenguaje de modelado más conocido y utilizado en la actualidad, ya que su maleabilidad para representar las definiciones de los requerimientos de software es mucha, además de que es de fácil comprensión para no sólo los ingenieros de software involucrados en el proyecto. 

Cada uno delos diagramas UML  tiene como propósito fundamental entender y comunicar los requerimientos que tenga el cliente o el sistema que se va a desarrollar. 

• Modelo de casos de uso: El modelo de casos de uso depende de los actores, los cuales son entidades externas al sistema los cuales no son afectados por el proceso actual de diseño del mismo, pero tienen una fuerte interacción posterior con el. El modelo de caso de uso es una explicación detallada de cómo se llevará a cabo esa interacción entre el sistema y los actores. 
• Diagramas de clases: Muestran las entidades que necesitan trabajar juntas para asegurarse que el sistema realiza cada uno de los requerimientos especificados en los casos de uso. Los diagramas de clases contiene los requerimientos funcionales de sistema, 
• Diagramas de secuencia: El diagrama de secuencia muestra cómo los objetos en el diagrama de clases colaboran entre sí para llevar a cabo los casos de uso; cada caso de uso está relacionado con uno o más diagramas de secuencia. 
• Diagramas de actividad: Son utilizados para visualizar el comportamiento dinámico de una parte del sistema. 
• Diagramas de estados: Pueden ser utilizados para representar el comportamiento de una clase, un caso de uso o un sistema. Los componentes clave de los diagramas de transición de estrados son los estados, los cuales interactúan por medio de eventos que pueden llevar de un estado a otro mediante una transición o que permanezca en el mismo estado como resultado del evento.

Descargar Caso práctico

Clase XLVIII - 06112019 - Proyecto integrador

Ser capaz de diseñar sistemas y sus interacciones, de forma que puedan ser entendidos por varios miembros de un equipo, es crucial en el ámbito de la tecnología.

Pasamos nuestras vidas interactuando con sistemas, aunque estamos tan acostumbrados a ello que muchas veces ni nos damos cuenta. Los periódicos online que miramos mientras tomamos un café de la máquina del trabajo, cuando tomamos un micro... Todos ellos son sistemas que usamos a diario. Y por algún motivo pasan desapercibidos: un sistema bien diseñado es invisible. Tienen vida propia, para que nosotros podamos seguir con las nuestra.

Todos estos sistemas se diseñaron con una forma de pensar propia de la ingeniería: el pensamiento de sistemas.

El pensamiento de sistemas permite analizar un problema como una combinación de elementos separados que interactúan entre ellos para formar un todo coherente. Esto puede aplicarse a varios aspectos de un sistema. Por ejemplo, la experiencia de usuario, o la arquitectura del código, así como el plan de comunicación de un producto, pueden beneficiarse de esta forma de acercarse a un problema.

Con el Lenguaje de Modelado Unificado, se pueden mapear casos de uso, definir interacciones de usuario, o representar necesidades técnicas antes de empezar a construir proyectos.

A través del modelado se consiguen cuatro objetivos:
- Los modelos ayudan a visualizar un sistema.
- Los modelos permiten especificar la estructura o el comportamiento del sistema.
- Los modelos proporcionan una plantilla que guía en la construcción del sistema.
- Los modelos documentan las decisiones tomadas.

UML ofrece las siguientes características:
- Proporciona un modelo explícito que facilita la comunicación.
- Es un lenguaje gráfico con una semántica bien definida.
- Aborda la especificación de todas las decisiones importantes de análisis, diseño e implementación que deben tomarse al desarrollar y desplegar un sistema de software.
- Aborda la documentación de la arquitectura de un sistema y proporciona un lenguaje para expresar requisitos y pruebas.
- Está pensado, principalmente, para sistemas de software, aunque no está limitado a ello.

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

• Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y casos de uso son descritos en un diagrama de casos de uso. Cada diagrama es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.

• Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, etc.

• Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

• Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

• Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración, integran componentes y clases en orden, para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

Ejemplo I - Caso de estudio: Crear Blog

Recursos

Web: https://siemprendes.com/como-crear-un-blog-en-blogger-paso-a-paso/
Material: https://drive.google.com/file/d/1r7B3kmtp881uuWRUBKac01_3v9N2ckID/view?usp=sharing

Clase XLVII - 01112019 - Diagrama de despliegue

Diagramas de despliegue

El diagrama de despliegue describe el hardware como un diagrama de la clases con iconos ligeramente diferentes. Sin embargo, el enfoque del diagrama de despliegue esta en los procesadores o nodos en los que su software correrá, en lugar de las clases lógicas.

Nodos

Cada nodo es la ubicación de un procesador. Cada nodo contiene componentes de software. Los componentes de software en los nodos diferentes pueden comunicar por medio de conexiones físicas entre los nodos.

Así como los componentes del software, los nodos en un diagrama de despliegue pueden tener interfaces. Estas interfaces mapean hacia interfaces físicas de los dispositivos como los puertos paralelos, sensores, y otras conexiones de entrada/salida.



Una Vista Estática

El propósito de un diagrama de despliegue es presentar una vista estática del ambiente de aplicación. Una descripción completa del sistema probablemente contendrá varios diagramas de despliegue diferentes, cada diagrama enfocado en un aspecto diferente del manejo del sistema.

Por ejemplo, un diagrama podría enfocarse en cómo los componentes de software están distribuidos, tal como dónde reside el código fuente y donde se envía para la implementación. Otro diagrama podría modelar cómo el ejecutable es cargado de un nodo a otro nodo dónde realmente se ejecuta.

Para una aplicación multitiered, el diagrama de despliegue modelaría la distribución de las capas de la aplicación, sus conexiones físicas, y sus caminos lógicos de comunicación.

El diagrama de despliegue tiene dos tipos de elementos, nodos y dependencias.

El icono del nodo es dibujado como un rectángulo 3D. Las conexiones entre los nodos son las asociaciones físicas. Dibuje una línea sólida de un nodo a otro. Use la anotación de multiplicidad para definir el número de nodos en cada extremo. Pueden usarse los estereotipos también.


Diagrama de despliegue a nivel de clase

El nodo puede trabajar como una clase en el sentido de que puede tener atributos y puede especificar conductas en términos de los ejecutables que despliega. El próximo ejemplo muestra una vista nivel de objetos de un diagrama del despliegue. Considerando que un diagrama del despliegue a nivel de clase especifica una configuración general, el diagrama a nivel de objetos modela instancias de cada nodo así como un diagrama de objetos modela las entidades reales.

Diagrama de despliegue a nivel de objetos

Dibuje el diagrama de despliegue como si cada nodo en su arquitectura f¡sica fuera una clase en un diagrama de clases. Cada nodo cumple un propósito específico. Cada nodo tiene las asociaciones con otros nodos para conseguir hacer su trabajo.

Los diagramas del despliegue pueden funcionar como los diagramas de red para ilustrar la distribución de su red. El diagrama del despliegue a nivel de objetos puede funcionar como una especificación de requerimientos para cada nodo, definiendo la memoria, procesador, y requerimientos de almacenamiento.

Notación combinada

Una alternativa para modelar los componentes en un nodo es combinar las dos notaciones de diagrama físicas para los componentes y nodos.

Modele los iconos del componente dentro del nodo extendido para mostrar la contención. Para mostrar la comunicación lógica entre los componentes, dibuje una flecha discontinua de dependencia tal como lo hizo en el diagrama de componentes.

En este ejemplo, orderentry.exe reside en el servidor pero es cargado en el cliente en tiempo de ejecución.

El el estereotipo << becomes >> especifica esta migración en tiempo de ejecución. Una vez el ejecutable está cargado, depende de orderproc.exe para ayuda. Nota que se pudo haber dibujado a nivel de clase fácilmente.

Recursos


Descargar DOCx Hora 13
Descargar PPTx Hora 13

Clase XLVI - 30102019 - Diagrama de despliegue

Diagrama de Despliegue 

Es un tipo de diagrama del Lenguaje Unificado de Modelado que muestran las relaciones físicas de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

Definición

Los diagramas de despliegue son los complementos de los diagramas de componentes que, unidos, proveen la vista de implementación del sistema. Describen la topología del sistema la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.

Representan a los nodos y sus relaciones. Los nodos son conectados por asociaciones de comunicación.

Muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el tráfico de la red, el tiempo de respuesta.

El Diagrama de despliegue es un diagrama estructurado que muestra la arquitectura del
sistema desde el punto de vista del despliegue (distribución) de los los artefactos del
software en los destinos de despliegue.

Los artefactos representan elementos concretos en el mundo físico que son el resultado de un proceso de desarrollo. Ejemplos de artefactos son archivos ejecutables, bibliotecas, archivos, esquemas de bases de datos, archivos de configuración, etc. .



El destino de despliegue está generalmente representado por un nodo que es o bien de los dispositivos de hardware o bien algún entorno de ejecución de software. Los nodos pueden ser conectados a través de vías de comunicación para crear sistemas en red.

Ventajas

•     Muestra un conjunto de nodos y sus relaciones.
•     Se utilizan para describir la vista de despliegue estática de un sistema.
•     Se relacionan con los diagramas de componentes, ya que un nodo  normalmente incluye uno o más componentes.

Desventajas

•     La posible falla en la modelación de un hardware.
•     Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro.El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

Componentes

Nodo

Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento.Un Nodo es un elemento de hardware o software.

Instancia de nodo

Una instancia se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los dos puntos.

Estereotipo de nodo

Estereotipo, son cosas u objetos q se repiten sin variación.El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se esta observando.

Artefactos

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (modelos de Caso de uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario etc. Donde un artefacto es un conjunto de componentes.

Asociación

Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación va incluida con misma dependencia del diagrama de componentes.

Estándares  

•     Ejecutable: especifica un artefacto que se puede ejecutar en un nodo.
•     Librería: Biblioteca de objetos estática o dinámica.
•     Archivo: artefacto que representa un documento que contiene condigo fuente o datos.
•     Documento: artefacto que representa un documentos.

Antecedentes

•      Diagrama de Componentes: permiten modelar sistemas de software de cualquier tamaño y complejidad. Permite especificar un componente como unidad modular con interfaces bien definidas.

•      Diagrama de Paquetes: más que un diagrama constituyen una herramienta para mostrar los elementos que se integran en un sistema, aplicación o módulos. Muestra como el sistema esta dividido en agrupaciones lógicas mostrando las dependencias entre agrupaciones.

Recursos

Descargar DOCx Hora 13
Descargar PPTx Hora 13

Clase XLV - 25102019 - Diagrama de componentes

 Cómo dibujar un diagrama de componentes

Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre componentes software, sean éstos componentes de código fuente, binarios o ejecutables. 

Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán componentes y paquetes.

Dado que los diagramas de componentes muestran los componentes software que constituyen una parte reusable, sus interfaces, y sus interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama de clases a gran escala. 

Cada componente en el diagrama debe ser documentado con un diagrama de componentes más detallado, un diagrama de clases, o un diagrama de casos de uso.

Un paquete en un diagrama de componentes representa una división física del sistema.

Los paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida. Un ejemplo típico de una jerarquía en capas de este tipo es: Interfaz de usuario; Paquetes específicos de la aplicación; Paquetes reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo.

Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilación). Puede mostrar también que un componente software contiene una interfaz, es decir, la soporta.

Contar con un diagrama de componentes colabora en tener una idea de la futura implementación del sistema. 

Los siguientes son los pasos que pueden servir de guía al dibujar un diagrama de componentes.

·         Paso 1: Determina el propósito del diagrama e identifica los artefactos como los archivos, documentos, etc. en tu sistema o aplicación que necesitas representar en su diagrama.

·         Paso 2: A medida que descubres las relaciones entre los elementos que identificaste anteriormente, crea un diseño mental de tu diagrama de componentes.

·         Paso 3: Al dibujar el diagrama, agrega primero los componentes, agrupándolos dentro de otros componentes como mejor te parezca.

·         Paso 4: El siguiente paso es agregar otros elementos, como interfaces, clases, objetos, dependencias, etc. al diagrama de componentes y completarlo.

·         Paso 5: Puede adjuntar notas en diferentes partes de su diagrama de componentes para aclarar ciertos detalles a otros usuarios.

Diagramas de componentes, ejemplos

Clínica Veterinaria

Diagrama de componentes de una tienda online

Diagrama de componentes de un cajero automático

Diagrama de componentes de gestión de biblioteca

Recursos

Descargar DOCx Hora 12
Descargar PPTx Hora 12

Clase XLIV - 23102019 - Diagrama de componentes

Diagrama de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes.

Está clasificado como diagrama de estructura y, como tal, representa de forma estática el sistema de información. Habitualmente se utiliza después de haber creado el diagrama de clases, pues necesita información de este diagrama como pueden ser las propias clases.

 Este diagrama proporciona una vista de alto nivel de los componentes dentro de un sistema. Los componentes pueden ser un componente de software, como una base de datos o una interfaz de usuario; o un componente de hardware como un circuito, microchip o dispositivo; o una unidad de negocio como un proveedor, nómina o envío.

Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Algunos usos de este tipo de diagrama es el siguiente:

·         Se utilizan en desarrollo basado en componentes para describir sistemas con arquitectura orientada a servicios.

·         Mostrar la estructura del propio código.

·         Se puede utilizar para centrarse en la relación entre los componentes mientras se ocultan los detalles de las especificaciones.

·         Ayudar a comunicar y explicar las funciones del sistema que se está construyendo a los interesados o stakeholders.

Para su construcción se debe plantear en primer lugar identificar los componentes que utilizará el sistema de información, así como las distintas interfaces. Una forma típica y común para una primera aproximación en sistemas sencillos es utilizar un componente central al que los demás componentes se unen, y que se utiliza como componente gestor del sistema.

Elementos del diagrama de componentes

El diagrama de componentes está formado por tres elementos: Componente, Interfaz y Relación de dependencia.

Componente

Un componente es un bloque de unidades lógicas del sistema, una abstracción ligeramente más alta que las clases. Se representa como un rectángulo con un rectángulo más pequeño en la esquina superior derecha con pestañas o la palabra escrita encima del nombre del componente para ayudar a distinguirlo de una clase.

Un componente puede representar dos tipos de elementos: componentes lógicos (como por ejemplo componentes de negocio o proceso) o componentes físicos (como componentes .NET, EJB…). Por ejemplo, en una aplicación desarrollada en java habrá, con total seguridad, varios componentes “.java”, que son componentes lógicos del sistema.

Es representado a través de un rectángulo que tiene, a su vez, dos rectángulos a la izquierda, tal y como se muestra en la siguiente imagen:

  

Otra notación, utilizada en las últimas versiones de UML consiste en un rectángulo con un rectángulo más pequeño en la esquina superior derecha con pestañas.

Otra notación de componente

También es posible utilizar el diagrama de paquetes para hacer un conjunto de varios módulos. Con esto se consigue representar la unión de esos módulos para un fin concreto.

Paquete con varios componentes

Ejemplos de componentes podrían ser los siguientes: Gestión de E/S, Animal, Persona, Gestión de incidencias, Gestor de workflow,… Como ves son conceptos muy amplios y que pueden ser más o menos específicos dependiendo de la profundidad que se puede dar al diagrama.

Lo ideal es que los componentes estén diseñados de forma que tengan una gran cohesión y un bajo acoplamiento, para favorecer su reutilización.

Diagrama de componentes

Mientras que otros diagramas UML describen la funcionalidad de un sistema, los diagramas de componentes se utilizan para modelar los componentes que ayudan a hacer esas funcionalidades, representando la forma en la que estos se organizan y sus dependencias.

Una relación de dependencia se representa mediante una flecha discontinua que va desde el componente que requiere de otro componente hasta el requerido.

Notación de una relación de dependencia

Las relaciones de dependencia pueden unir, además de componentes con otros componentes, componentes con interfaces.

Interfaz

La interfaz está siempre asociada a un componente y se utiliza para representar la zona del módulo que es utilizada para la comunicación con otro de los componentes.

Se representa con una línea que tiene al final un circulo no relleno:

Otros módulos pueden conectarse a una interfaz. Esto se hace cuando un componente requiere o utiliza al otro componente mediante su interfaz, que son las operaciones externas que ofrece el componente. Se representa con un linea que termina en un semicírculo que rodea la interfaz del otro componente. En el diagrama se vería de la siguiente manera:

Relación de dependencia

Aunque puedes mostrar más detalles sobre la relación entre dos componentes utilizando la notación de interfaces (interfaz proporcionada y la interfaz requerida), también puedes usar una flecha de dependencia para mostrar la relación entre dos componentes. Es una relación más general.

La relación de dependencia representa que un componente requiere de otro para ejecutar su trabajo. Es diferente a la interfaz, pues esta identifica que un componente ofrece una serie de operaciones. En cualquier caso, en ocasiones para simplificar el diagrama no se usan las interfaces sino que solamente se utilizan relaciones de dependencia.

Recursos

Descargar DOCx Hora 12
Descargar PPTx Hora 12