Analisis y Diseno de sistemas informáticos.pptx

Análisis y Diseño de Bases de Datos

1. Análisis y Diseño 2025 – 2025 DESARROLLO DE SOFTWARE

2. ¿Qué es el Análisis y Diseño? En una organización o empresa, es el proceso de estudiar su situación Es el arte de definir la arquitectura de hardware, software, componentes, módulos y datos de un sistema de cómputo Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio

3. Finalidad Observar como trabaja y decir si es necesario realizar una mejora Satisfacer los requerimientos. Definir la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación Analizar un problema y describirlo con el propósito de dar una solución mediante un sistema informático

4. Sistema Informático VS. Sistema de Información ¿Qué es un Sistema Informático? Es un sistema de información que está informatizado ¿Qué es un Sistema de Información? Es un conjunto de datos que interactúan entre sí con un fin común En informática: Ayudan a administrar, recolectar, recuperar, procesar, almacenar y distribuir información relevante para los procesos fundamentales y las particularidades de cada organización.

5. Importancia de un Sistema de Información Eficiencia en la correlación de una gran cantidad de datos ingresados a través de procesos diseñados para cada área Objetivo: Producir información válida para la posterior toma de decisiones.

6. Características de un Sistema de Información Eficiencia en el procesamiento de los datos en relación al área de acción Se alimentan de los procesos y herramientas de estadística, probabilidad, inteligencia de negocio, producción, marketing, entre otros para llegar a la mejor solución Se destaca por su diseño, facilidad de uso, flexibilidad, mantenimiento automático de los registros, apoyo en toma de decisiones críticas y mantener el anonimato en informaciones no relevantes.

7. Componentes de un Sistema de Información Permiten la entrada, el procesamiento, la salida y el almacenamiento de datos que son de interés general o de un público en particular Está conformado por un conjunto de elementos que trabajan de manera conjunta para lograr un objetivo común y están dirigidos al uso y administración de información.

8. Componentes de un Sistema de Información Implementación Para crear un SI es necesario hacer que todos sus componentes trabajen al cien por ciento Objetivo Brindar información completa y fiable al tiempo que satisface las necesidades de los usuarios

9. Componentes de un Sistema de Información Componente Físico: Se trata del hardware del sistema informático. Quienes lo conforman: Computadoras, sus componentes internos como memorias, CPU y demás, los periféricos de entrada y salida como módems, impresoras, monitores, y todo aquel dispositivo que se conecte a este hardware

10. Componentes de un Sistema de Información Componente lógico o Software: Encargado de almacenar, procesar y distribuir los datos que se ingresan al mismo Está conformado por: El firmware: Soporte lógico inalterable es un programa informático que establece la lógica de más bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier tipo El sistema operativo El sistema de gestión de datos propiamente dicho Además considerar: la documentación del mismo y los datos que procesa y gestiona .

11. Componentes de un Sistema de Información Componente humano: También llamado “Humanware” Quienes lo conforman? Los usuarios, es decir quienes utilizan los dos anteriores componentes Considerar a todos que han participado en el desarrollo del mismo (Ingenieros, programadores y analistas de sistemas) Componente importante, ya que a mas de operar el sistema, también son los encargados del soporte y mantenimiento técnico

12. Ciclo de Vida de un SI El ciclo de vida de un sistema de información es continuo y se compone de las siguientes fases: Investigación preliminar, identificación de fortalezas y amenazas Definición de las necesidades y requerimientos Diseño Desarrollo y documentación del software Pruebas Implementación y mantenimiento Identificación de debilidades y opotunidades

13. ¿Quién lo debe realizar? Un profesional especializado en el área de la informática El encargado del desarrollo de aplicaciones en lo que respecta a su diseño y obtención de los algoritmos El encargado de analizar las posibles utilidades y modificaciones necesarias de los sistemas operativos para una mayor eficacia de un sistema informático El encargado de dar apoyo técnico a los usuarios. El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático

14. Lenguaje UML Son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado” ¿Pero que es? Decir que UML es un lenguaje no es apropiado, ya que no es un lenguaje propiamente dicho Es un estándar que se ha adoptado a nivel internacional por numerosos empresas para crear esquemas, documentación relativa a los organismos y diagramas y desarrollos de software (programas informáticos)

15. Lenguaje UML para hacer modelos y es los métodos de análisis y Es un lenguaje independiente de diseño ¿Quienes la usan? Personas que tienen conocimientos relativamente avanzados de programación Por analistas funcionales: Definen qué debe hacer un programa sin entrar a escribir el código Analistas-programadores

16. Porque estandarizar El Centro del Conocimiento de IBM, determina que “La estandarización o el condicionamiento garantizan que los datos de origen son coherentes internamente, es decir, cada tipo de datos incluye el mismo tipo de contenido y está en el mismo formato. Cuando se utilizan datos coherentes, el sistema puede buscar coincidencias en los datos de direcciones con mayor precisión utilizando una de las etapas de coincidencia”

17. Porque estandarizar Según la Gestión de Procesos, la práctica de la estandarización, permite: El control El seguimiento La desagregación de los datos, etc., Siempre teniendo presente que la información le sea útil a quien desea utilizarla Los documentos se constituyen en: Una guía Emite las disposiciones en su uso común Procura obtener el grado óptimo de orden en un contexto dado Desagregación: Separar una cosa de otra de la que forma parte para que siga existiendo con independencia.

18. Beneficios UML Mejores tiempos totales de desarrollo (de 50 % o más) Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos Establecer conceptos y artefactos ejecutables Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas Mejor soporte a la planeación y al control de proyectos Alta reutilización y minimización de costos

19. MÉTODO LENGUAJE DE MODELADO

20. Método Manera explícita de estructurar el pensamiento y las acciones de cada individuo El método le dice al usuario Qué hacer Cómo hacerlo Cuándo hacerlo y Por qué hacerlo

21. LENGUAJE DE MODELADO Carece de las instrucciones antes indicadas Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. Un modelo es expresado en un modelado Un lenguaje de modelado consiste de: lenguaje de Vistas Diagramas Elementos de modelo Símbolos utilizados en los modelos Un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos

22. COMPOSICIÓN LENGUAJE DE MODELADO

23. Vistas Definición: Muestran diferentes aspectos del sistema modelado Una vista no es una gráfica, pero sí una abstracción De que consiste: De un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo

24. Tipos de Vistas Vista Use- Case: Muestra la funcionalidad del sistema como la perciben los actores externos Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema (Estructura estática y la conducta dinámica del sistema) Vista de Componentes: Muestra la organización de los componentes de código Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente Vista de Distribución: Muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos (Nodos )

25. Diagramas Son gráficas que describen el contenido de una vista Estas proveen todas las vistas de un sistema: Diagramas UML: Diagramas de caso de uso De clases De objetos De estados De secuencia De colaboración De actividad De componentes De distribución.

26. Símbolos o Elementos de modelo Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos Ejemplo: Clases Objetos y mensajes Relaciones Adicionalmente se incluyen La asociación La dependencia La generalización Nota: Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología

27. Reglas o Mecanismos generales Proveen Comentarios extras Información o semántica acerca del elemento de modelo Mecanismos de extensión para extender UML a un método adaptar o o proceso específico, organización o usuario

28. Fases o Etapas de Desarrollo Fase/Etapa: Es la identificación y organización de todas las actividades y procesos importantes que intervienen en la búsqueda de una meta u objetivo, estas etapas deben ser definidas en función de sus características e importancia que presenten La fase de desarrollo está estrechamente vinculada a la del diseño La fase de desarrollo es la auténtica etapa de producción del entorno de aprendizaje Por ello es importante planificarla bien y gestionar correctamente el equipo de producción La fase de desarrollo se dirige a través de la gestión didáctica del proyecto

29. Análisis de Requerimientos Extrae los requisitos de un producto de software Se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema Define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software De esta etapa depende en gran medida el logro de los objetivos finales Ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830- 1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).

30. Análisis de Requerimientos Como realiza UML el Análisis de Requerimientos: 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 actores y los casos de uso son: Modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías Descritos en un diagrama use- case Cada use- case es descrito en texto y especifica los requerimientos del cliente Que contiene: Lo que el cliente 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

31. Requerimientos Requerimientos No Funcionales La descripción de los requerimientos no funcionales, tendrá como característica definir todo aquello que limite el funcionamiento del módulo y/o sistema Aquí se podrá considerar temas relacionados con: El rendimiento del módulo y/o sistema cualificado en tiempo y espacio Temas relacionados con los diferentes interfaces desarrolladas Fiabilidad del módulo y/o sistema. Aquí se deberán explicar temas relacionados con la seguridad informática (confidencialidad de la información, integridad y disponibilidad de los datos y recursos y confiablidad en la calidad de la información). Portabilidad. Se definirán las características del producto y la capacidad que este tiene para que pueda ser ejecutado en una o en varias plataformas. Mantenibilidad: El diseño de las interfaces deben garantizar que las propiedades y parámetros enviados a los métodos deben ser estándares.

32. Requerimientos Requerimientos de Interfaz Los requerimientos de interfaz permite describir todos los elementos que provee el sistema para la interacción con el usuario (cajas de texto, botones de búsqueda, títulos, objetos de selección, radiobuttons, checkbox, ayudas en línea, etc.) y la funcionalidad de cada uno de estos Estos requerimientos tienen como finalidad clarificar el número de elementos a ser implementados y la interrelación de cada uno de estos elementos

33. Requerimientos Requerimientos Funcionales La descripción del requerimiento funcional detallara el funcionamiento de un proceso, función, actividad o componente Aquí se especifica cuáles son las entradas, el comportamiento de los datos y las salidas Como un requerimiento funcional se puede calificar al: Registro de un dato, de un detalle técnico, selección de una fecha, etc., la realización de un calculo, la manipulación de una determinada porción de información o de un dato, control a ser implementado sobre un campo o proceso

34. Análisis Lleva el lenguaje natural a un lenguaje técnico que es fácilmente interpretado por desarrollador de un sistema 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 Sólo consideran clases que están en el dominio del problema (conceptos del mundo real) No se consideran clases que definen detalles y soluciones en el sistema de software (clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.)

35. Diseño Indica la forma en la que se debe construir un sistema para dar cumplimiento a los requerimientos de un cliente o usuario De un buen diseño depende el resultado de un sistema 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 Comunicaciones con otros sistemas, etc. El diseño resulta en especificaciones detalladas para la fase de programación

36. Programación Son todas las actividades necesarias para transformar los requerimientos de un usuario plasmado en un diseño y convertido en un sistema de software 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

37. Pruebas Es la parte donde se verifica, valida y se evidencia la calidad del producto o sistemas de software desarrollado 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 final 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

38. Pruebas

39. Tipo de Pruebas PRUEBAS UNITARIAS Pruebas de muy bajo nivel Están compuestas de pruebas de métodos y funciones individuales de las clases, componentes o módulos que usa tu software Son bastante baratas de automatizar, y se pueden ejecutar rápidamente mediante un servidor de integración continua PRUEBAS DE INTEGRACIÓN Verifican que los distintos módulos o servicios utilizados por la aplicación funcionan en conjunto Se puede probar la interacción con la base de datos o asegurarse de que los micro- servicios funcionan bien en conjunto y según lo esperado Son costosas de ejecutar, ya que requieren que varias partes de la aplicación estén en marcha.

40. Tipo de Pruebas PRUEBAS FUNCIONALES Existe confusión de las pruebas de integración con las funcionales Ambas requieren que varios componentes interactúen entre sí La diferencia es que una prueba de integración puede simplemente verificar que se puede hacer consultas en la base de datos, mientras que una prueba funcional esperaría obtener un valor específico desde la base de datos, según dicten los requisitos del producto PRUEBAS INTEGRALES Replican el comportamiento de un usuario con el software en un entorno de aplicación completo Verifican que diversos flujos de usuario funcionen según lo previsto, y pueden ser tan sencillos como cargar una página web o iniciar sesión, o mucho más complejos, como la verificación de notificaciones de correo electrónico, pagos en línea, etc. Las pruebas integrales son útiles, pero costosas de llevar a cabo y pueden resultar difíciles de mantener cuando están automatizadas Recomendación: Tener algunas pruebas integrales clave y depender más de pruebas de menor nivel (unitarias y de integración)

41. Tipo de Pruebas PRUEBAS DE ACEPTACIÓN Pruebas formales ejecutadas para verificar si un sistema satisface los requisitos empresariales Se requiere que toda la aplicación esté en marcha y que se centre en replicar las conductas de los usuarios También puede medir el rendimiento del sistema y rechazar cambios si no se han cumplido determinados objetivos PERFORMANCE TESTING Por su naturaleza, pueden ser bastante costosas de implementar y ejecutar Ayudan a entender si los nuevos cambios van a degradar el sistema

42. Tipo de Pruebas PRUEBAS DE HUMO Son pruebas que sirven para comprobar la funcionalidad básica de la aplicación Están concebidas para ejecutarse rápido Objetivo: Ofrecer la seguridad de que las principales funciones del sistema funcionan según lo previsto PRUEBAS DE SEGURIDAD Validan los servicios de seguridad de una aplicación e identifican posibles fallos y debilidades Los proyectos utilizan un enfoque de caja negra para las pruebas de seguridad, lo que permite a los expertos, sin conocimiento del software, probar la aplicación en busca de agujeros, fallos, exploit y debilidades.

43. Tipo de Pruebas PRUEBAS DE CAJA BLANCA Es un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo Están dirigidas a las funciones internas Se llevan a cabo sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración) Técnicas usadas Cobertura de caminos: Pruebas que hagan que se recorran todos los posibles caminos de ejecución Pruebas sobre las expresiones lógico-aritméticas Pruebas de camino de datos (definición- uso de variables), comprobación de bucles (se verifican los bucles para 0,1 e interacciones, y luego para las interacciones máximas, máximas menos uno y más uno)

44. Tipo de Pruebas PRUEBAS DE CAJA NEGRA Son pruebas funcionales Se parte de los requisitos funcionales, a muy alto nivel, para diseñar pruebas que se aplican sobre el sistema sin necesidad de conocer como está construido por dentro (Caja negra) Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la función se está desempeñando correctamente por el sistema bajo prueba Las herramientas básicas son observar la funcionalidad y contrastar con la especificación

45. Modelos UML Un modelo representa a un sistema software desde una perspectiva específica Los modelos de UML son los siguientes: Diagrama de Estructura Estática Diagrama de Casos de Uso Diagrama de Secuencia Diagrama de Colaboración Diagrama de Estados Diagrama de Actividades

46. Modelos UML El proceso de desarrollo de software se inicia con la construcción de un modelo El modelo debe representar la especificación precisa de las necesidades del usuario trasladadas a los requerimientos Un modelo interpreta de manera simplificada la realidad Estructuralmente destaca la organización del sistema y a nivel de comportamiento destaca la dinámica del sistema Se construyen modelos para comprender mejor el sistema que se esta desarrollando

47. Porque construir un Modelo Visualizar cómo es o como se desea el sistema Especificar la estructura y comportamiento del sistema Proporcionan plantillas que guían la construcción del sistema Documentar las decisiones

48. Principios del Modelo La elección de los diferentes modelos tiene una profunda influencia sobre cómo se interpreta el problema y se determina la solución Los modelo se expresan a diferentes niveles de detalle y se usan en diferentes momentos del ciclo de vida El modelo debe estar ligado a la realidad Se deben desarrollar varios modelos

49. Características del Modelo Abstracto : Enfatizar los elementos importantes y oculta los irrelevantes Comprensible : Fácil de comprender por los observadores Preciso : Representa de forma fiel el sistema que modela Predictivo : Se pueden usar para deducir conclusiones sobre el sistema que se esta modelando Barato : Mucho más barato y sencillo de construir  Evidencia en el desarrollo

50. Utilidad del Modelo Detectar errores/omisiones en el diseño antes de comprometer recursos para la implementación Analizar y experimentar Investigar/comparar soluciones alternativas Minimizar riesgos

51. Utilidad del Modelo Comunicación con los clientes, usuarios, implementadores, encargados de pruebas, documentadores, etc. Guiar la implementación (construcción y codificación)

52. Como utilizar UML Primero para desarrollar un modelo en UML es seleccionar la metodología de desarrollo que defina la naturaleza concreta del proceso a seguir Definir el modelo en base al proceso elegido Para ello se divide en varios tipos de modelo o vistas

53. Como utilizar UML Cada una debe estar centrada en un aspecto o punto de vista del sistema En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas: Vista de diseño Vista de implementación Vista de procesos Vista de despliegue Vista de Casos de Uso

54. Elementos Estructurales Son partes estáticas de un modelo y representan cosas que son conceptuales o materiales Estos elementos son: Las clases Las interfaces Los casos de uso Los componentes Los nodos

55. Elementos Estructurales - Clase Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica Una clase implementa una o más interfaces Gráficamente se presenta como un rectángulo que normalmente incluye su nombre, atributos y operaciones

56. Elementos Estructurales - Clase

57. Diagramas de Clases Sirva para documentar arquitectura de software Tipo de diagrama de estructura que describe lo que debe estar presente en el sistema que se está modelando Si las clases son los componentes básicos de los objetos  los diagramas de clases son los componentes básicos del UML

58. Beneficios Diagramas de Clases Ilustrar modelos simples/complejos de datos para sistemas de información Comprender la visión general de los esquemas de una aplicación Expresar visualmente las necesidades específicas de un sistema y difundir esa información en toda la empresa.

59. Beneficios Diagramas de Clases Crear diagramas detallados que resalten cualquier código específico que será necesario programar e implementar en la estructura descrita Ofrecer una descripción independiente de la implementación empleados en un sobre los tipos sistema que son posteriormente transferidos entre sus componentes

60. Componentes Diagramas de Clases

61. Clases Plantilla para crear objetos e implementar un comportamiento en un sistema En UML: Representación de un objeto o un conjunto de objetos que comparte una estructura y un comportamiento común Detalles Nombre Atributos Métodos

62. Señales Símbolos comunicaciones que representan unidireccionales y asincrónicas entre objetos activos

63. Tipos de Datos Clasificadores que definen valores de datos Los tipos de datos pueden modelar tanto enumeraciones como tipos primitivos

64. Paquetes Figuras diseñadas para clasificadores relacionados diagrama organizar en un Se simbolizan con una figura de un gran rectángulo con pestañas

65. Interfaces Recopilación de firmas de operaciones o de definiciones de atributo que define un conjunto uniforme de comportamientos Las interfaces son similares a una clase Excepción: La clase puede tener una instancia de su tipo, y una interfaz debe poseer, como mínimo, una clase para implementarla

66. Enumeraciones Representaciones de tipos definidos por el usuario de datos Una enumeración incluye grupos de identificadores que representan valores de la enumeración

67. Objetos Instancias de una clase o clases Los objetos se pueden agregar a un diagrama de clases para representar instancias prototípicas o concretas

68. Artefactos Elementos modelo que representan las entidades concretas de un sistema de software, como documentos, bases de datos, archivos ejecutables, componentes de software y más

69. Interacciones Se refiere a múltiples relaciones y enlaces que pueden existir en diagramas de objetos y de clases Interacciones más comunes: Herencia/Generalización: Asociación bidireccional Asociación bidireccional

70. Herencia Una subclase/derivada recibe la funcionalidad de una superclase/ clase principal

71. Asociación bidireccional Relación predeterminada entre dos clases Ambas clases están conscientes una de la otra y de la relación que tienen entre sí Esta asociación se representa mediante una línea recta entre dos clases

72. Asociación unidireccional Relación poco común entre dos clases Una clase está consciente de la otra e interactúa con ella

73. Elementos Estructurales - Interfaz Es una colección de operaciones que especifican un servicio de una clase o componente Representar el comportamiento completo de una clase o sólo una parte de ese comportamiento Define las operaciones pero no la implementación de las mismas Se representa con un círculo

74. Elementos Estructurales – Casos de Uso Descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado de interés para un actor en particular Se usa para estructurar aspectos de comportamiento de un modelo Se representa con una elipse incluyendo el nombre del caso de uso

75. Notación de Casos de Uso

76. Definiciones básicas Actor: Es toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad Incluye a los operadores humanos pero también incluye a todos los sistemas externos Seres humanos: Ve a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o más Actores

77. Definiciones básicas Tipos de Relaciones: Asociación de Comunicación: Relación entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso Inclusión: Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. Generalización: Indica que un caso de uso es una variante de otro. El caso de uso especializado puede variar cualquier aspecto del caso de uso base. Extensión: Ofrece una forma de extensión mas controlada que la relación de generalización

78. Definiciones básicas Cuando usarlos <<extends>>: Cuando un caso de uso es similar a otro pero que hace algo más que éste (variante) <<uses>> o <<include>>: Cuando una parte de comportamiento es similar en dos casos de uso y no se quiere repetir la descripción de dicho comportamiento común Concluyendo: Se usara <<extends>> cuando se presenta una variación del comportamiento normal, e <<include>> cuando se repite un comportamiento en dos casos de uso y se quiere evitar dicha repetición

79. Elementos Estructurales - Componente Parte física y reemplazable de un sistema que conforma un conjunto de interfaces y proporciona la implementación de dicho conjunto Representa un empaquetamiento físico de diferentes elementos lógicos como clases, colaboraciones, interfaces Se representa con un rectángulo con pestañas

80. Elementos Estructurales - Nodo Elemento físico que existe en tiempo de ejecución y representa un recurso computacional Por lo general dispone de algo de memoria y capacidad de procesamiento Un nodo se utiliza para modelar la topología del hardware el que se ejecuta el sistema Gráficamente se representa como un cubo