{"id":9301,"date":"2022-02-28T09:15:19","date_gmt":"2022-02-28T09:15:19","guid":{"rendered":"https:\/\/www.cybermedian.com\/es\/?p=9301"},"modified":"2026-04-20T09:11:50","modified_gmt":"2026-04-20T09:11:50","slug":"una-guia-rapida-para-el-modelado-de-casos-de-uso","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/es\/a-quick-guide-to-use-case-modeling\/","title":{"rendered":"Una gu\u00eda r\u00e1pida para el modelado de casos de uso"},"content":{"rendered":"

El modelado de casos de uso<\/a>\u00a0es una herramienta \u00fatil para capturar requisitos.\u00a0Proporciona una representaci\u00f3n gr\u00e1fica de los requisitos de un sistema de software.<\/p>\n

Con la publicaci\u00f3n del libro de\u00a0Ivar Jacobson<\/a>\u00a0(1991)\u00a0Ingenier\u00eda de software orientada a objetos, un enfoque basado en casos de<\/a>\u00a0uso, el modelado de casos de uso se convirti\u00f3 efectivamente en una t\u00e9cnica de an\u00e1lisis pr\u00e1ctica.\u00a0Hoy en d\u00eda, Jacobson contin\u00faa promoviendo este enfoque para el an\u00e1lisis de sistemas y lo ha actualizado a Use Case 2.0, que es oficialmente uno de los\u00a014 tipos de diagramas UML<\/a>\u00a0.<\/p>\n

Debido a que el modelo de caso de uso es simple en concepto y apariencia, es relativamente f\u00e1cil discutir su correcci\u00f3n con personal no t\u00e9cnico (como los clientes).<\/p>\n

Un caso de uso no es un procedimiento, proceso o funci\u00f3n.<\/p>\n

Los Elementos del Diagrama de Casos de Uso<\/span><\/h2>\n

Los\u00a0elementos de un diagrama de casos de uso<\/a>\u00a0son los actores (entidades externas) y el caso de uso mismo.\u00a0En t\u00e9rminos generales, un caso de uso es una unidad funcional (requisito) o servicio en un sistema.<\/p>\n

Actor<\/span><\/h3>\n

Un\u00a0actor<\/a>\u00a0es cualquier entidad externa al sistema de dise\u00f1o, ya sea una persona u otra entidad no humana.\u00a0Un usuario de un sistema es un ejemplo t\u00edpico de un actor.\u00a0Otros tipos de actores incluyen sistemas de software que se est\u00e1n integrando con el sistema actual (por ejemplo, un sistema de base de datos), hardware externo como un sensor, etc.\"tipos<\/p>\n

Hay dos notaciones en la\u00a0especificaci\u00f3n UML<\/a>\u00a0:<\/p>\n

\"\"<\/p>\n

Usar stickman para actores es m\u00e1s expresivo, pero puede generar confusi\u00f3n si el actor no es realmente una persona, sino una m\u00e1quina o un dispositivo externo.\u00a0El s\u00edmbolo del rect\u00e1ngulo es la\u00a0notaci\u00f3n UML<\/a>\u00a0est\u00e1ndar para una\u00a0clase<\/a>\u00a0.<\/p>\n

Un actor es un papel en lugar de una persona real\u00a0<\/strong><\/p>\n

Un actor representa el rol de la entidad que interact\u00faa con el sistema actual, no una instancia.\u00a0La notaci\u00f3n de actor indica que la entidad es una clase en lugar de una instancia de lectura (es decir, un usuario real John o Mary).\u00a0La raz\u00f3n por la que un actor es un tipo de clase es que no es el actor mismo, sino el papel que interpreta.<\/p>\n

Por ejemplo, un actor puede representar a los clientes de un banco, en lugar de especificar un actor independiente para cada cliente.\u00a0Asimismo, puede haber otro actor en representaci\u00f3n del gerente del banco.\u00a0Curiosamente, en el mundo real, el gerente de un banco tambi\u00e9n puede ser cliente del mismo banco.\u00a0En otras palabras, la misma persona desempe\u00f1a el papel de cliente y gerente.<\/p>\n

Actores primarios vs secundarios<\/strong><\/a><\/p>\n

El actor principal<\/strong>\u00a0de un caso de uso es la parte interesada que requiere que el sistema proporcione sus servicios.\u00a0Tiene una meta asociada con el sistema, una meta que puede ser satisfecha por la operaci\u00f3n del sistema.\u00a0El actor principal suele ser, aunque no siempre, el actor que desencadena el caso de uso.<\/p>\n

El actor secundario<\/strong>\u00a0es utilizado por el sistema, pero no interact\u00faa con el sistema por s\u00ed solo.\u00a0En otras palabras, los actores secundarios no inician ning\u00fan caso de uso.<\/p>\n

Los casos de uso generalmente son iniciados por los actores principales.\u00a0El sistema utiliza un actor secundario como una base de datos a trav\u00e9s de un conjunto de casos de uso.\u00a0La asociaci\u00f3n entre casos de uso y participantes representa una comunicaci\u00f3n bidireccional.<\/p>\n

Por lo tanto, para cada caso de uso iniciado por un actor principal, se debe responder al caso de uso conectado.\u00a0De manera similar, para cada asociaci\u00f3n entre un actor secundario y un caso de uso, la comunicaci\u00f3n comienza con el caso de uso y el actor secundario debe responder al inicio.<\/p>\n

Caso de uso<\/span><\/h3>\n

Los casos de uso<\/strong>\u00a0representan las funciones (generalmente requisitos) que se espera que implemente el sistema.\u00a0Los detalles del caso de uso, excepto su nombre \u00fanico, no se expresan intuitivamente en el diagrama;\u00a0Estos detalles se dan en la descripci\u00f3n del caso de uso.<\/p>\n

Los casos de uso generalmente son iniciados por actores clave.\u00a0El sistema utiliza la base de datos y otros participantes auxiliares a trav\u00e9s de un conjunto de casos de uso.<\/p>\n

La asociaci\u00f3n entre casos de uso y actores representa una comunicaci\u00f3n bidireccional.\u00a0Por lo tanto, para cada caso de uso iniciado por el actor principal, se debe dar respuesta a este \u00faltimo.\u00a0De manera similar, para cada asociaci\u00f3n entre el actor secundario y el caso de uso, la comunicaci\u00f3n comienza con el caso de uso y el actor secundario debe responder al inicio.<\/p>\n

L\u00edmite del sistema<\/span><\/h3>\n

El l\u00edmite del sistema define el sistema de inter\u00e9s en relaci\u00f3n con el mundo que lo rodea.<\/p>\n

Ejemplo de diagrama de caso de uso: sistema de reservas de aerol\u00edneas<\/span><\/h3>\n

Los casos de uso definen las interacciones entre los actores externos y el sistema para lograr objetivos particulares.\u00a0Un diagrama de caso de uso contiene cuatro componentes principales<\/p>\n

En el diagrama de casos de uso de un sistema de reserva de boletos, el sistema est\u00e1 representado por cajas que contienen muchos casos de uso diferentes.\u00a0El actor principal es el cliente y el actor secundario es el administrador.\u00a0El cliente inicia los casos de uso, como reservar, navegar y cancelar vuelos, mientras que el administrador inicia los casos de uso, como actualizar los registros de vuelo, pero se considera un actor secundario en el caso de uso de cancelaci\u00f3n de vuelo, ya que solo ayuda a completar los casos de uso iniciados por el cliente.<\/p>\n

<\/p>\n

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASOS DE USO DE UML<\/a><\/p>\n

Estructuraci\u00f3n de casos de uso<\/span><\/h3>\n

De acuerdo con el campo de aplicaci\u00f3n y la elecci\u00f3n del dise\u00f1ador, un caso de uso se puede dividir en m\u00faltiples casos de uso, que est\u00e1n conectados a trav\u00e9s de relaciones < <incluir>> o <<extender>>.<\/p>\n

El v\u00ednculo de asociaci\u00f3n<\/strong>\u00a0representa una comunicaci\u00f3n bidireccional entre un actor y un caso de uso y, por lo tanto, es una relaci\u00f3n binaria.\u00a0Dado que es una comunicaci\u00f3n bidireccional, para cada caso de uso iniciado por un actor principal, ese actor debe obtener una respuesta del caso de uso.<\/p>\n

\"El<\/p>\n

De manera similar, para cada comunicaci\u00f3n entre un caso de uso y un actor secundario (iniciada por el caso de uso), el actor secundario debe enviar una respuesta al caso de uso.<\/p>\n

Generalizaci\u00f3n<\/span><\/h4>\n

La generalizaci\u00f3n representa la relaci\u00f3n entre<\/p>\n