SERVICIO NACIONAL DE APRENDIZAJE SENA REGIONAL TUNJA, BOYACA ANALISIS Y DESARROLLO DE SOFTWARE FICHA 2547391 APRENDICES: ANDREA BRIÑEZ DEISY BOLAÑOZ DIEGO CAICEDO DAVID RODRIGUEZ RODRIGUEZ FABER STIVEN LONDOÑO DIAGRAMAS Y DOCUMENTACION DE ACTIVIDADES DEL PROYECTO GA2-220501093-AA1-EV04 CONTENIDO 1. 2. 3. 4. 5. INTRODUCCION DIAGRAMA DE ACTIVIDADES DIAGRAMA DE CLASE HISTORIA DE USUARIO EN PLANTILLA CONCLUSION INTRODUCCIÓN Los diagramas de actividades trazan flujos de procesos de una forma que es sencilla de entender. El Lenguaje Unificado de Modelado incluye varios subconjuntos de diagramas, incluidos los diagramas de estructuras, los diagramas de interacción y los diagramas de comportamiento. Los diagramas de actividades, junto con los diagramas de casos de uso y los diagramas de máquina de estados, son considerados diagramas de comportamiento porque describen lo que debe suceder en el sistema que se está modelando. Las partes interesadas tienen muchos asuntos que manejar, por lo que es importante una comunicación clara y concisa. Los diagramas de actividades ayudan a que las personas en las áreas de negocios y desarrollo de una organización se integren para comprender el mismo proceso y comportamiento. Usarás un conjunto de símbolos especializados incluidos aquellos para pasos de inicio, finalización, fusión y recepción en el flujo para crear un diagrama de actividades, lo cual cubriremos con más detalle dentro de esta guía de diagramas de actividades. DIAGRAMA DE ACTIVIDADES “TOUR FAMILY” Los diagramas de actividades UML pertenecen al grupo de diagramas de comportamiento en UML. Mientras que un diagrama de estructura registra el estado de un sistema, es decir, los objetos existentes y sus jerarquías, así como las conexiones entre ellos en un momento determinado, los diagramas de comportamiento describen el flujo cronológico de la circulación de datos. Además del diagrama de actividades, el diagrama de caso de uso y el diagrama de máquina de estados también pertenecen a este grupo. Los diagramas de actividades son similares en su uso y notación a los diagramas de flujo (especialmente a los diagramas de programas), pero se adaptan a la POO. DIAGRAMA DE CLASE El propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema. Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden utilizar los diagramas de clase: • Conceptual: El diagrama de clase representa los conceptos en el dominio del problema que se está estudiando. Este modelo debe crearse con la mayor independencia posible de la implementación final del sistema. • Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que un tipo representa una interfaz que puede tener muchas implementaciones diferentes. • Implementación: Esta vista representa las clases tal cual aparecen en el entorno de implementación. HISTORIA DE USUARIO EN PLANTILLA Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software. Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final o cliente. El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un valor particular al cliente. Ten en cuenta que los "clientes" no tienen por qué ser usuarios finales externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu organización que dependen de tu equipo. Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados por el equipo. Nombre: <TOURS FAMILY> Autor: <ADMINISTRADOR> Fecha: <23 Noviembre del 2022> Descripción: <Se desarrollan un conjunto de opción en la plataforma para confirmar o cancelar la separación de un tour de viaje> Actores: <Administrador_ cliente> Precondiciones: <Registrar datos, Decisión de compra> Flujo Normal: <Pago virtual> Flujo Alternativo: <pago en efectivo> Pos condiciones: <Forma de pago, Confirmación de correo > CONCLUSION De acuerdo con los datos pospuestos se desarrollaron los Diagramas de actividades, de clase e historias de usuario en plantilla, teniendo en cuenta metodología y requerimientos, así mismo enriqueciendo conocimientos de implementación mediante variables dentro del UML, adquiriendo así nuevas habilidades para el desarrollo de trabajo en el día a día de las buenas prácticas en el software.
