Jonatan Moncada

Diseño de
Sistemas
Fase de Diseño

 La fase de diseño se considera una de las etapas más importantes del ciclo de vida del desarrollo de software.
Se ubica entre las fases de análisis y de implementación, y su objetivo principal es traducir los requisitos del
sistema en una arquitectura y diseño detallados que puedan ser implementados por los desarrolladores.
 Esta fase permite una mejor comprensión del sistema, reduce el riesgo de errores, facilita la comunicación
entre los stakeholders y ahorra tiempo y dinero.
 Un stakeholder, en el contexto del desarrollo de software, es cualquier individuo o grupo que tiene un interés en
el sistema que se está desarrollando. Esto puede incluir:
 Usuarios: Las personas que utilizarán el sistema de forma regular.
 Clientes: Aquellos que compran o pagan por el sistema.
 Desarrolladores: Los programadores que construyen el sistema.
 Probadores: Las personas que verifican que el sistema funciona correctamente.
 Gestores de proyecto: Las personas que supervisan el desarrollo del proyecto.
 Inversores: Las personas que proporcionan financiación para el proyecto.
 Gobiernos: Entidades que regulan el software o que pueden ser usuarios del mismo.
 Proveedores: Aquellos que proporcionan software o servicios que se utilizan en el desarrollo del sistema.
 Comunidad: Las personas o grupos que se verán afectados por el sistema de alguna manera.
 Los stakeholders son importantes porque sus necesidades e intereses deben tenerse en cuenta durante todo el
proceso de desarrollo de software. Esto significa que los analistas/desarrolladores deben:

 Identificar a todos los stakeholders relevantes.

 Entender las necesidades e intereses de cada stakeholder.
 Comunicarse con los stakeholders de forma regular.
 Involucrar a los stakeholders en el proceso de toma de decisions.
 Beneficios de involucrar a los stakeholders:
 Aumento de la calidad del software: Al tener en cuenta las necesidades de los stakeholders, los desarrolladores pueden
crear un software que sea más útil y utilizable.
 Reducción del riesgo: Al identificar y abordar los posibles problemas desde el principio, se pueden evitar costosos
cambios en etapas posteriores del proyecto.
 Mejor comunicación: La comunicación regular con los stakeholders puede ayudar a evitar malentendidos y a asegurar
que todos estén en la misma página.
 Mayor satisfacción: Al involucrar a los stakeholders en el proceso de toma de decisiones, es más probable que se
sientan satisfechos con el resultado final.
Siguiendo con el tema de la fase de diseño del sistema:
 En esta fase se realizan las siguientes actividades:
 Diseño Detallado: Se desarrollan diagramas de clases, diagramas de secuencia, diagramas de actividad, entre otros,
para representar visualmente la estructura y el comportamiento del sistema.
 Diseño de la interfaz de usuario: Se define cómo los usuarios interactuarán con el sistema, incluyendo la apariencia
de las pantallas, los elementos de navegación y la gestión de errores.
 Diseño de la base de datos: Se define la estructura de la base de datos que almacenará los datos del sistema,
incluyendo las tablas, diagrama entidad relación y las reglas de negocio.
 Revisión y Validación del Diseño: se llevan a cabo revisiones técnicas y reuniones de validación para revisar y
validar el diseño del sistema.
 Se recopilan y documentan los comentarios y sugerencias de mejora, y se realizan ajustes en el diseño según sea necesario.
 Las principales herramientas y técnicas utilizadas en la fase de diseño incluyen:
 Diagramas de flujo de datos: Representan el flujo de datos a través del sistema.
 Diagrama de contexto: Define el alcance del sistema, identifica las entidades y brinda una comprensión del flujo de los datos.
 Diagrama padre: sirve para descomponer el sistema en unidades mas pequeñas e identificar los componentes principales del
sistema.
 Diagrama de flujo de procesos: es una herramienta que ayuda a visualizar procesos complejos en forma de pasos para
saber exactamente cuál es el siguiente paso en función de determinadas condiciones.
 Diagramas de casos de uso: Describen las diferentes formas en que los usuarios interactúan con el sistema.
 Diagramas de clases: Representan las clases y objetos que componen el sistema.
 Prototipos: Implementaciones parciales del sistema que se utilizan para probar y evaluar el diseño.
 La fase de diseño es crucial para el éxito del proyecto de desarrollo de software por las siguientes razones:
 Permite una mejor comprensión del sistema: El diseño detallado ayuda a los desarrolladores a comprender mejor el
sistema y cómo funciona.
 Reduce el riesgo de errores: Un diseño bien definido ayuda a prevenir errores en la fase de implementación.
 Facilita la comunicación entre los stakeholders: El diseño proporciona un lenguaje común para que los diferentes
stakeholders del proyecto puedan comunicarse de manera efectiva.
 Ahorra tiempo y dinero: Un diseño adecuado puede ayudar a evitar cambios costosos en etapas posteriores del
proyecto.
Diagrama de casos de uso

 El diagrama de casos de uso es uno de los diagramas incluidos en UML 2.5, estando este clasificado dentro
del grupo de diagramas de comportamiento. Es, con total seguridad, el diagrama más conocido y es utilizado
para representar los actores externos que interactúan con el sistema de información y a través de que
funcionalidades (casos de uso o requisitos funcionales) se relacionan.
 Muestra de manera visual las distintas funciones que puede realizar un usuario (más bien un tipo de usuario)
de un Sistema de Información.
 Lo primero es saber cual es su finalidad. El diagrama de casos de uso, dependiendo de la profundidad que le
demos, puede ser utilizado para muchos fines, entre ellos podemos encontrar los siguientes:
 Representar los requisitos funcionales.
 Representar los actores que se comunican con el sistema. Normalmente los actores del sistema son los usuarios y
otros sistemas externos que se relacionan con el sistema. En el caso de los usuarios hay que entender el actor como un
“perfil”, pudiendo existir varios usuarios que actúan como el mismo actor.
 Representar las relaciones entre requisitos funcionales y actores.
 Guiar el desarrollo del sistema. Crear un punto de partida sobre el que empezar a desarrollar el sistema.
 Comunicarse de forma precisa entre cliente y desarrollador. Simplifica la forma en que todos los participes del
desarrollo, incluyendo el cliente, perciben como el sistema funcionará y ofrecerá una visión general común del
mismo.
Elementos de un diagrama de casos de uso
 Un diagrama de casos de uso está compuesto, principalmente, de 3 elementos: Actores, Casos de uso y
Relaciones:

 Actores: es algo o alguien externo al sistema que interactúa de forma directa con el sistema. Cuando decimos
que interactúa nos referimos a que aporta información, recibe información, inicia una acción…
 Se representan con una imagen de un “muñeco de palo” con el nombre del actor debajo.
 Existen dos tipos de actores: Los usuarios y los sistemas

 Nota: No hay que entender a los usuarios como personas singulares, sino como “perfiles o roles” que
identifican a un tipo de usuario, pero no al usuario en sí. Por ejemplo, en una aplicación de gestión de
nóminas, un actor de este tipo podría ser “gestor de nóminas” que se encarga de emitir y firmar nóminas.
Este rol podría ser tomado, por ejemplo, por cualquier individuo del personal de recursos humanos y,
además, por el jefe de la empresa. Por lo tanto un actor no representa a una única persona o a un único
usuario.
 Por otro lado, los actores pueden ser otros sistemas que también interactúan con nuestro propio sistema. Un
ejemplo podría ser, en la aplicación de nóminas, un sistema que almacene las nóminas firmadas a modo de
archivo. En este caso cuando se firma la nómina se recibe la misma por el sistema de archivo, por tanto el
caso de uso se relaciona con el actor.
 Casos de uso
 Un caso de uso se utiliza para representar una de las funcionalidades que realiza el sistema. Es una secuencia
de acciones que hace el sistema y que producen un resultado que puede percibir un usuario.
 Ejemplos de casos de uso: Crear pedido, Listar productos, Enviar correo. Cualquier acción que realice la
aplicación.
 Se representan con una elipse que incluye en su interior el nombre del caso de uso.
 Relaciones:
 Las relaciones conectan los casos de uso con los actores o los casos de uso entre sí.
 Cuando conectan un actor con un caso de uso representa que ese actor interactúa de alguna manera con ese caso de
uso y se representa con una linea continua con la identificación <<communicates>>.
 Cuando conectan casos de uso entre sí se pueden diferenciar dos tipos de relaciones: <<include>> y
<<extends>>. En español a veces se usa la nomenclatura <<usa>> y <<extiende>>:

 <<include>>: Se utiliza para representar que un caso de uso utiliza siempre a otro caso de uso. Es decir, un
caso de uso se ejecutará obligatoriamente (lo incluye, lo usa). Se representa con una flecha discontinua que
va desde el caso de uso de origen al caso de uso que se incluye.
 Ejemplo: Un uso típico de este tipo de relaciones se produce cuando dos casos de uso comparten una
funcionalidad. Esa funcionalidad es extraída de los dos y se crea un caso de uso nuevo que se relaciona con
los anteriores con un include.
 <<extend>>: Este tipo de relaciones se utilizan cuando un caso de uso tiene un comportamiento opcional,
reflejado en otro caso de uso. Es decir, un caso de uso puede ejecutar, normalmente dependiendo de alguna
condición o flujo del programa, otro caso de uso. Se representa con una flecha discontinua que va desde el
caso de uso opcional al original.
 Ejemplo: Hacer pedido puede dar lugar (o no) a otros dos casos de uso: Enviar notificación SMS y Enviar
notificación email. Se supone que, cuando un usuario hace un pedido, el sistema le permite elegir si quiere
que se envíe una notificación de ese pedido por SMS o por email.
 Resumen de las relaciones Extend e Include:
 Extend:Extend (Extender):
 La relación de "extend" se utiliza para representar un caso de uso que opcionalmente añade funcionalidad a otro caso
de uso base.
 El caso de uso base puede ejecutarse sin la extensión, pero la extensión proporciona funcionalidades adicionales.
 Se representa mediante una flecha punteada que se origina desde el caso de uso que extiende hacia el caso de uso
base.
 Se utiliza cuando hay una funcionalidad opcional que puede ser activada en ciertas circunstancias, sin afectar la
funcionalidad principal del caso de uso base.
 Include (Incluir):
 La relación de "include" se utiliza para representar un caso de uso que depende de otro caso de uso para su ejecución.
 Esencialmente, el caso de uso incluido no puede ser realizado sin la presencia y ejecución del caso de uso base.
 Se representa mediante una flecha sólida que se origina desde el caso de uso que incluye hacia el caso de uso base.
 Se utiliza cuando un caso de uso depende de la funcionalidad de otro caso de uso para lograr su objetivo.
Descripción de requisitos funcionales y no funcionales

 Es común en este tipo de diagramas describir cada caso de uso junto con la secuencia de pasos necesaria
para completarlo y las posibles excepciones hasta definir todas las situaciones posibles. Esta descripción
servirá de guía para el desarrollo, la profundidad de las situaciones que se traten dependerá de cada fase del
proyecto o de cada situación en particular.
 Existen dos tipos de requisitos:
 Requisitos funcionales
 Requisitos no funcionales
Los requisitos suelen ser plasmados junto a la siguiente información:
 Identificador y nombre descriptivo: Se utiliza una identificación única para diferenciarlo de los demás y un nombre descriptivo que suele coincidir
con el objetivo que los actores esperan alcanzar al realizar el caso de uso.
 Versión
 Autores
 Objetivos asociados
 Requisitos asociados
 Descripción: Este campo debe completarse de forma distinta en función de si el caso de uso es abstracto o concreto.
 Precondición: se expresan en lenguaje natural las condiciones necesarias para que se pueda realizar el caso de uso.
 Secuencia normal: secuencia normal de interacciones del caso de uso. En cada paso, un actor o el sistema realiza una o más acciones, o se realiza
otro caso de uso.
 Postcondición: se expresan en lenguaje natural las condiciones que se deben cumplir después de la terminación normal del caso de uso.
 Excepciones: especifica el comportamiento del sistema en el caso de que se produzca alguna situación excepcional durante la realización de un paso
determinado, lo que modifica el flujo «normal» del caso de uso.
 Importancia
 Urgencia
 Comentarios
 Modelado de un requisito Funcional
 Modelado de un requisito no funcional
Cómo dibujar un diagrama de casos de uso

 Para dibujar un diagrama de casos de uso se recomienda que se compruebe que se ha realizado previamente todas
estas tareas, respondiendo a las siguientes preguntas:
 Recopilar fuentes de información: ¿cómo se supone que debo saber eso?
 Identificar actores potenciales: ¿qué usuarios utilizan los bienes y servicios del sistema empresarial?.
 Identificar posibles casos de uso: ¿a qué bienes y servicios pueden recurrir los actores?
 Conectar los casos de uso: ¿quién puede hacer uso de los bienes y servicios del sistema empresarial?
 Describir actores: ¿a quién o qué representan los actores?
 Buscar más casos de uso: ¿Qué más debe hacer el sistema?
 Documentar casos de uso: ¿qué sucede exactamente en cada caso de uso?
 Relacionar modelos entre casos de uso empresarial: ¿qué actividades se realizan repetidamente?
 Verificar la vista, ¿todo es correcto?

Nota: este orden no es obligatorio, ya que en la práctica, los pasos individuales a menudo se superponen unos con otros.
 Nota2: Para poder seguir los pasos de una forma óptima, es importante comprender el negocio/sistema para
conseguir seguir cada paso individual. En algunos casos también es necesario consultar a los expertos o
consultores del negocio. No tiene sentido aferrarse a la visión personal del analista, si este no tiene mucho
conocimiento del área de negocio de la aplicación.
Diagrama de flujo de datos

 Diagrama de contexto (nivel 0):

 Es una representación gráfica de alto nivel de un sistema. Muestra el sistema como una sola entidad, sin entrar en
detalles sobre sus procesos internos.
 Componentes:
 Entidad: El sistema en sí, representado por un rectángulo con el nombre del sistema dentro.
 Flujos de datos: Líneas que representan el intercambio de información entre la entidad y los agentes externos.
 Agentes externos: Entidades externas que interactúan con el sistema, como usuarios, otros sistemas, bases de datos,
etc.
 Funciones:
 Definir el alcance del sistema: Delimita qué se incluye y qué se excluye del sistema.
 Identificar las partes interesadas: Muestra las entidades que interactúan con el sistema.
 Visualizar la interacción del sistema con el entorno: Describe cómo el sistema recibe y envía información.
 Ejemplo:

 Un diagrama de contexto para un sistema de gestión de pedidos podría mostrar la entidad "Sistema de gestión de
pedidos" interactuando con agentes externos como "Clientes", "Proveedores" y "Empresas de transporte".
 Diagrama Padre (Nivel 1):
 Un diagrama de nivel 1 es el siguiente nivel de descomposición en el análisis de un sistema. Desarrolla el diagrama de
contexto y muestra los principales procesos internos del sistema.

 Componentes:
 Procesos: Funciones principales que el sistema realiza, representados por rectángulos con nombres descriptivos.
 Almacenes de datos: Lugares donde se almacena la información, como archivos, bases de datos, etc., representados
por rectángulos con dos líneas paralelas.
 Flujos de datos: Líneas que representan el flujo de información entre los procesos, almacenes de datos y agentes
externos.
 Funciones:

 Descomponer el sistema en sus principales componentes: Describe qué procesos se llevan a cabo dentro del sistema.
 Mostrar el flujo de información entre los componentes: Permite comprender cómo se procesa la información en el
sistema.
 Servir como base para diagramas de niveles más detallados: Facilita el análisis y diseño de los componentes del
sistema.
 Ejemplo:

 Un diagrama de nivel 1 para un sistema de gestión de pedidos podría mostrar los procesos "Recibir pedido", "Procesar
pedido" y "Enviar pedido", así como los almacenes de datos "Pedidos", "Clientes" y "Productos".
 Simbología:
 Relación entre ambos diagramas
 El diagrama de contexto es la base para el diagrama de nivel 1. El diagrama de contexto proporciona una vista general del
sistema, mientras que el diagrama de nivel 1 ofrece una vista más detallada de los procesos internos del sistema.
 Características:
 Diagrama de contexto:
 Vista general de alto nivel del sistema.
 Muestra la interacción del sistema con el entorno.
 Define el alcance del sistema.
 Diagrama de nivel 1:
 Descompone el sistema en sus principales componentes.
 Muestra el flujo de información entre los componentes.
 Sirve como base para diagramas de niveles más detallados.
 Beneficios de usar ambos diagramas:

 Mejor comprensión del sistema: Permiten visualizar el sistema como un todo y sus componentes internos.
 Comunicación efectiva: Facilitan la comunicación entre los diferentes stakeholders del proyecto.
 Análisis y diseño más eficientes: Ayudan a identificar problemas y oportunidades de mejora en el sistema.
Diagrama Entidad-Relación (Diagrama ER)

 Herramienta de modelado de datos que se utiliza para representar las entidades, sus atributos y las relaciones
entre ellas en una base de datos relacional. Es una representación gráfica que facilita la comprensión y el
diseño de la estructura de la base de datos.
 Es fundamental para el diseño de bases de datos relacionales. Permite visualizar y comprender la estructura
de la base de datos, facilitando su diseño y análisis.
 Componentes:

 Entidades: Objetos o conceptos del mundo real que se representan en la base de datos, como "Cliente", "Producto" o
"Pedido". Se representan como rectángulos.
 Atributos: Propiedades o características de las entidades, como "Nombre", "Apellido" o "Precio". Se representan
como óvalos dentro de la entidad.
 Relaciones: Conexiones entre las entidades que representan una asociación o dependencia entre ellas. Se representan
como líneas que conectan las entidades.
 Cardinalidad: Indica la cantidad de entidades que pueden participar en una relación. Se puede representar con
diferentes notaciones, como "1:N" (uno a muchos) o "N:N" (muchos a muchos).
 Tipos de relaciones:
 Uno a uno (1:1): Una entidad solo se relaciona con una única entidad de otra.
 Uno a muchos (1:N): Una entidad se relaciona con varias entidades de otra.
 Muchos a muchos (N:N): Varias entidades se relacionan con varias entidades de otra.
 Simbología:
 Ejemplo:

 Un diagrama ER para un sistema de gestión de pedidos podría mostrar las entidades "Cliente", "Producto" y "Pedido".
La entidad "Cliente" se relaciona con la entidad "Pedido" mediante una relación de uno a muchos, ya que un cliente
puede realizar varios pedidos. La entidad "Producto" se relaciona con la entidad "Pedido" mediante una relación de
muchos a muchos, ya que un pedido puede incluir varios productos.
 Beneficios de usar diagramas ER:

 Mejor comprensión de la estructura de la base de datos: Permite visualizar las entidades, sus atributos y las relaciones
entre ellas.
 Diseño más eficiente: Facilita la identificación de redundancia y errores en el diseño de la base de datos.
 Comunicación efectiva: Facilita la comunicación entre los diferentes stakeholders del proyecto.