Está en la página 1de 27

Análisis y Desarrollo de software

Resultado de Aprendizaje
220501093-02. Modelar las funciones del software de acuerdo con el informe de requisitos.

• Diagramas y documentación de actividades del proyecto. GA2-220501093- AA1-EV04


• Elaboración de los diagramas del Modelo de dominio del proyecto. GA2-220501093- AA2-
EV01.
Agenda
• Bienvenida
• Socialización de la evidencia
• Preguntas
ACTIVIDAD DE RESULTADO DE APRENDIZAJE EVIDENCIA FECHA DE ENTREGA
APRENDIZAJE (RAP)

GA2-220501093- 220501093-02. Modelar las Diagramas y documentación 12/JUNIO/2023


AA1. Elaborar diagrama y funciones del software de de actividades del A
documentación de casos acuerdo con el informe de proyecto. GA2-220501093- 19/JUNIO/2023
de uso / historias de requisitos. AA1-EV04.
usuario de acuerdo con el
refinamiento de requisitos. Elaboración de los diagramas
del Modelo de dominio del
GA2-220501093- proyecto. GA2-220501093-
AA2. Representar el AA2-EV01.
contexto del negocio a
través del diagrama de
dominio y actividades
Evidencia GA2-220501093-AA1-EV04: diagramas y documentación de actividades del proyecto

Con base en los requisitos del sistema ya especificados, se empiezan a construir los artefactos del modelo
necesarios para representar la solución de software, por medio de los siguientes documentos: diagramas de clase,
documentos de casos de uso o historias de usuario en plantillas, modelo de base de datos, modelo del dominio,
diagramas de actividades y también un documento informe con los resultados obtenidos. Aspectos a tener en
cuenta:

• Estudiar detenidamente los conceptos y características definidas en el componente formativo.


• Revisar el video sugerido como material complementario del componente formativo.
• Manejar el lenguaje de modelado UML.
• Manejar metodologías tipo ágil.
• Identificar la metodología de desarrollo a seguir.

Lineamientos generales para la entrega de la evidencia:


• Producto para entregar: diagramas, documento de casos de uso e historias de usuario.
• Formato: PDF.
Evidencia GA2-220501093-AA2-EV01: elaboración de los diagramas del modelo de dominio del proyecto

Esta evidencia se centra en la elaboración del diagrama de clases del proyecto, identificando cómo las categorías que
intervienen se relacionan, teniendo en cuenta su cardinalidad, dependencias y herencias, llevando esto a la organización de
objetos por medio de segmentación de componentes en paquetes claramente identificables. Aspectos a tener en cuenta:

• Se deben seguir las características e instrucciones para la elaboración de un diagrama de dominio del proyecto.
• El modelo conceptual resultante debe guardar las proporciones necesarias, de modo que se vea ordenado y sea fácil su
lectura.
• Para complementar el modelo del dominio, se puede representar por medio de otra vista que corresponde al diagrama de
paquetes del proyecto.
• Tener en cuenta los requisitos del software.
• Identificar el tipo de diagrama apropiado para modelar el dominio.
• Diagramar con UML los artefactos del sistema, diagrama de clases y de paquetes.
• Manejar herramientas de software para apoyar la elaboración de los diagramas.
• Elaborar documento plantilla de casos de uso con base en estándares de documentación.

Lineamientos generales para la entrega de la evidencia:


• Producto para entregar: documento del dominio del proyecto.
• Formato: PDF
Diagrama de actividades
Estos son diagramas de comportamiento que se utilizan para representar una sucesión de
actividades, explican el flujo de operaciones desde el punto en que inician hasta el punto final
definiendo una variedad de caminos de decisiones en el desarrollo de eventos que abarca una
actividad

• Demostrar la lógica de un algoritmo.


• Describir los pasos realizados en un caso de uso UML.
• Ilustrar un proceso de negocios o flujo de trabajo entre los
usuarios y el sistema.
• Simplificar y mejorar cualquier proceso clarificando casos
de uso complicados.
• Modelar elementos de arquitectura de software, tales como
método, función y operación.
Componentes básicos de un diagrama de actividades
Flujos paralelos
los flujos paralelos se utilizan para representar actividades que ocurren simultáneamente o en
paralelo dentro del proceso. Esto se utiliza cuando hay tareas independientes que se pueden realizar
al mismo tiempo, lo que puede mejorar la eficiencia y reducir el tiempo de ejecución del proceso.
Los flujos paralelos se representan mediante líneas paralelas que salen de una actividad y se reúnen
nuevamente en otra actividad.

Tendremos un Nodo llamado Fork o bifurcación nos sirve para iniciar la concurrencia y también
tenemos un Nodo llamado Join que es para regresar a un solo flujo.
Ejemplo del proceso de compra
Nodo de subactividad
El nodo de subactividad en un diagrama de actividades se utiliza para desglosar una actividad
principal en tareas más detalladas y específicas. Proporciona una manera de representar acciones
más pequeñas y manejables dentro de una actividad principal. En resumen, el nodo de subactividad
permite subdividir una actividad en subtareas para mostrar el flujo de trabajo más detallado y
organizado.

La notación de este nodo es la siguiente


Ejemplo del proceso de compra
Señales
En un diagrama de actividades, las señales son eventos o condiciones que pueden ocurrir durante el proceso
y que pueden desencadenar una transición de una actividad a otra. Representan momentos significativos que
afectan el flujo del proceso.
Excepciones
En un diagrama de actividades, las excepciones representan situaciones inesperadas o condiciones de error
que pueden ocurrir durante el proceso de un ecommerce y que requieren un manejo especial. Las
excepciones se utilizan para capturar y manejar desviaciones del flujo normal del proceso.

Las excepciones en un diagrama de actividades se representan mediante un símbolo en forma de tridente,


que se coloca cerca de la actividad que puede generar la excepción. La flecha del tridente apunta hacia una
actividad de manejo de excepciones, donde se describe cómo se debe gestionar la situación excepcional.
Actividades interrumpibles
Las regiones de actividad interrumpibles en un diagrama de actividades son áreas del diagrama donde se
pueden interrumpir o detener temporalmente las actividades en curso para realizar otras tareas o responder a
eventos externos. Estas regiones permiten manejar situaciones en las que se requiere una atención inmediata
a una señal o evento sin tener que completar la actividad actual.

En esencia, una región de actividad interrumpible es un mecanismo que permite que una actividad en curso
sea suspendida temporalmente para manejar una interrupción, y luego se reanuda desde el punto de
interrupción una vez que se ha completado la tarea relacionada con la interrupción.

La representación gráfica de una región de actividad interrumpible en un diagrama de actividades es una


región rectangular con una línea discontinua o punteada, que rodea a las actividades que pueden ser
interrumpidas. Dentro de la región, se coloca un símbolo de interruptor o señal que indica la interrupción o
evento que puede ocurrir.
Particiones
Las particiones, son elementos visuales utilizados en un diagrama de actividades para agrupar y organizar
actividades relacionadas o roles en el proceso. Las particiones se representan mediante líneas horizontales o
verticales que dividen el diagrama en secciones distintas.

Las particiones ayudan a visualizar y comprender mejor la responsabilidad y la relación entre diferentes
roles, departamentos, sistemas u otras entidades involucradas en el proceso. Cada partición puede representar
un actor, un departamento, un sistema o cualquier otra entidad relevante para el proceso.
Diagramas de clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando
sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de
análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el
sistema, y los componentes que se encargarán del funcionamiento y la relación entre uno y otro.

Beneficios de los diagramas de clases

• Ilustrar modelos de datos para sistemas de información, sin importar qué tan
simples o complejos sean.
• Comprender mejor la visión general de los esquemas de una aplicación.
• 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 sobre los tipos
empleados en un sistema que son posteriormente transferidos entre sus
componentes.
Elementos que componen un diagrama de clase

Nombre de la clase: Es el nombre que identifica a la clase y se coloca en la parte superior del rectángulo que
representa la clase.

Atributos: Representan las propiedades o características de la clase. Se colocan en el centro del rectángulo y
se describen mediante una combinación de nombre y tipo de datos. Por ejemplo: "nombre: String".

Métodos: Representan las operaciones o acciones que pueden ser realizadas por la clase. Se colocan en la
parte inferior del rectángulo y se describen mediante el nombre del método, parámetros (si los hay) y el tipo
de retorno. Por ejemplo: "+obtenerNombre(): String".
Controles de acceso
Tipos de asociación
Asociación simple: Es la forma básica de asociación entre dos clases. Indica que una clase tiene una referencia a otra
clase. Por ejemplo, en un sistema de gestión de una biblioteca, podemos tener una asociación simple entre las clases
"Biblioteca" y "Libro", donde la clase "Biblioteca" tiene una colección de libros.

Asociación bidireccional: Es una asociación en la que las clases están conectadas entre sí en ambas direcciones. Esto
significa que ambas clases pueden acceder y referenciarse mutuamente. Por ejemplo, en un sistema de redes sociales,
puede haber una asociación bidireccional entre las clases "Usuario" y "Amigo", donde un usuario puede tener amigos y
esos amigos pueden tener una referencia al usuario.

Asociación unidireccional: Es una asociación en la que la relación está definida en una sola dirección. Una clase puede
hacer referencia a la otra clase, pero no viceversa. Por ejemplo, en un sistema de compras en línea, puede haber una
asociación unidireccional entre las clases "Carrito de compras" y "Producto", donde el carrito de compras hace referencia
a los productos que contiene, pero los productos no hacen referencia al carrito de compras.

Asociación con nombre de rol: En esta asociación, se le da un nombre específico al papel que una clase desempeña en
relación con la otra clase. Esto ayuda a proporcionar una mejor comprensión de la relación entre las clases. Por ejemplo,
en un sistema de reservas de vuelos, puede haber una asociación con nombre de rol entre las clases "Pasajero" y "Vuelo",
donde el pasajero reserva un vuelo.
Multiplicidad
la multiplicidad se utiliza para especificar la cantidad de instancias de una clase que pueden estar
asociadas con una instancia de otra clase en una relación de asociación. Indica la cardinalidad de
la relación entre las clases.

La multiplicidad se representa mediante números o símbolos que indican los límites superior e
inferior de la asociación. Los símbolos más comunes utilizados para representar la multiplicidad
son los siguientes:
Herencia
En un diagrama de clases, la herencia es una relación que permite que una clase herede atributos y métodos de otra
clase. La herencia es uno de los conceptos fundamentales de la programación orientada a objetos y se utiliza para
modelar jerarquías de clases y compartir características comunes entre ellas.

En el diagrama de clases, la herencia se representa mediante una línea con una flecha que apunta desde la clase
hija (subclase) hacia la clase padre (superclase). Esto indica que la clase hija hereda todos los atributos y métodos
de la clase padre. La clase hija puede agregar nuevos atributos y métodos propios o puede redefinir (sobreescribir)
los atributos y métodos heredados según sus necesidades.
Agregación
la agregación es una relación entre clases que representa una asociación de "todo-parte". Indica que una clase
contiene otras clases como sus partes o componentes, pero las partes pueden existir independientemente de la
clase que las contiene.

La agregación se representa mediante una línea sólida con un rombo vacío en el extremo de la clase que contiene
las partes. El rombo vacío apunta hacia las clases que son parte de la agregación. Esto indica que la clase que
contiene la agregación es responsable de la creación, destrucción y gestión de las partes, pero las partes pueden
existir de forma independiente.

La agregación se utiliza cuando una clase tiene una relación de "todo-parte" con otras clases, pero las partes no
son exclusivas de la clase que las contiene y pueden estar asociadas con otras clases también.
Composición
La composición es una relación entre clases que representa una asociación de "todo-parte" más estricta que la
agregación. Indica que una clase está compuesta por otras clases y que las partes no pueden existir de forma
independiente sin la clase contenedora.

La composición se representa mediante una línea sólida con un rombo lleno en el extremo de la clase que contiene
las partes. El rombo lleno apunta hacia las clases que son parte de la composición. Esto indica que la clase
contenedora es responsable de la creación, destrucción y gestión de las partes, y que las partes no pueden existir
sin la clase contenedora.

La composición se utiliza cuando una clase tiene una relación de "todo-parte" con otras clases, pero las partes son
exclusivas de la clase contenedora y no pueden ser compartidas con otras clases.

También podría gustarte