DISTRIBUIDOS

20/12/2014

Casos a incluir y casos a extender

Inicio

Capacitación por tema

Capacitación por perfil

Calendario

Contáctanos

Casos a incluír y casos a extender 
Un tema que genera mucha polémica entre la gente que modela casos de uso es la elección entre la
relación de  y . Lo peor es que muchas de esas discusiones generan muy pocovalor en el resultado final en el modelo y en cambio quitan tiempo valioso del proyecto. Esto se debe a
que  dichas  relaciones,  muchas  veces  no  son  del  todo  comprendidas  por  la  persona  que  la  modela,  y
mucho menos son comprendidas por las personas que leen el modelo. Así que al final no se le saca el
provecho que en todo caso debería de tener dicha elección.Es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos gráficos de UML,
si eso va a facilitar el modelado y la comunicación en el proyecto. Pero, después de todo este tiempo y de
los  diferentes  temas  que  hemos  venido  tratando,  es  importante  avanzar  y  adentrarnos  en  algunos
pormenores del lenguaje unificado.
Nuestros  cursos  de  Certificación  PMP®  y
CAPM®  incluyen  40  y  24  horas
respectivamente  de  capacitación  presencialmás  un  programa  integral  en  línea  para
complementar  tu  preparación  desde  la
comodidad  de  tu  casa,  y  garantizar  tu
certificación.
17 módulos en video (80 videos)
60 contact hours / PDUs
Simulador de examen
Autoevaluaciones por cada video
Acceso al foro No. 1 de PM en español
Libro digital de Pablo Lledó
60 plantillas de PM
PMBOK® Guide con descuentoEntre otros beneficios...

Antes que todo, ¿qué es el “include” y el “extend”? 
Gráficamente  lo  que  mostramos  es  una  relación  de  dependencia  entre  el  par  de  casos  de  uso,  con  el
nombre correspondiente al tipo de relación de la que se trate: ya sea  o .
Estas,  son  relaciones  que  usamos  para  ligar  gráficamente  dos  casos  de  uso,  cuyos  flujos  de  eventosestán unidos, normalmente en una sola sesión del usuario. En otras palabras, un caso de uso que está
ligado, por medio de una de estas dos relaciones, a otro caso de uso; también podría leerse o ejecutarse
como un sólo caso de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos
en dos, lo cual explicaremos más adelante.
Imagina  el  conjunto  de  pasos  que  ocurren  al  realizar  una  compra  en una  tienda  departamental.
Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la autorización de la
tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a
comprar. Es decir, los flujos de eventos de ambos procesos forman una sola cosa; juntos podrían formar
un  solo  caso  de  uso,  en  lugar  de  dos  casos  de uso  unidos  por  alguna  de  estas  relaciones  que  aquí
estamos tratando.

Información general
Novedades
Conoce la Póliza Abiztar Plus
Nuestros clientes
Recomendaciones de capacitación 
Calendario de cursos
Cursos de Ingeniería de software
Bootcamp de UML
Modelado con SysML
Modelado de Negocios /BPMN 
Patrones de Diseño
Casos de Uso
TOGAF
Desarrollo automatizado de software con MDAGrails 
Java 6
Fundamentos de Pruebas

Figura 1. Relacionando casos de uso
Include.  En  términos  muy  simples,  cuando  relacionamos  dos  casos  de  uso  con  un  “include”,  estamos
diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluído). Es decir, el
segundo  es  parte  esencial  del  primero.  Sin  el  segundo,  el  primero  no  podría  funcionar bien;  pues  no
podría  cumplir  su  objetivo.  Para  una  venta  en  caja,  la  venta  no  puede  considerarse  completa  si  no  se
realiza el proceso para cobrarla en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso
de uso “Rentar Video”, o lo que es lo mismo “Rentar Video” incluye () “Cobrar Renta”.

Cursos de Dirección de proyectos...