Inclusión y extensión de casos de uso - Brevísimo contexto histórico
Uno de los faros que nos ayudan a navegar mejor en la vida es la historia -el estudio de la historia. Así que -con la misma intención que Lucas expresó al inicio de su Evangelio sinóptico- ofrezco esta brevísima contribución para un mejorado entendimiento de inclusión y extensión de casos de uso en el contexto de la formulación [1] correcta de software.
"Muy distinguido amigo Teófilo:
Usted sabe que muchos se han puesto a escribir informes acerca de las cosas que han pasado entre nosotros. Las escribieron tal como nos las contaron quienes estuvieron con Jesús desde el principio. A ellos, Jesús los mandó a anunciar su mensaje.
Yo también he estudiado con mucho cuidado todo lo sucedido, y creo conveniente ponerlo por escrito, tal y como sucedió. Así, usted podrá saber si le han contado la verdad."
Lucas 1:1-4. La Biblia en Lenguaje Sencillo [2]
El entorno germinal
En 1987 Suecia, Ivar Jacobson publica "Object-oriented development in an industrial environment" [3] donde nos presenta el concepto de caso de uso en el contexto de su método de diseño llamado Objectory:
"El sistema es descrito en Objectory como una caja negra describiendo un número de aspectos del sistema. Estos diferentes aspectos, cada uno correspondiente a una secuencia funcionalmente relacionada, son llamados casos de uso".
El Sr. Jacobson nos presenta la visión que ha resultado de su experiencia con sistemas de tiempo real a gran escala [4,5] usando una técnica llamada diseño por bloques que después fue diseminada por toda la industria de telecomunicaciones según nos dice. Es notable que esta experiencia ocurriera bajo el contexto de centros académicos -el Departamento de Ciencias de la Computación del Instituto Real de Tecnología en Estocolmo y el Instituto Sueco de Ciencias de la Computación- y empresas productivas -Objective Systems SF AB y Ericsson Telecom; sentando tácitamente el precedente que: buena técnica = teoría + práctica. Además, el entorno germinal de los casos de uso fueron sistemas de transmisión e intercambio de mensajes y señalización para mantener el diálogo entre dos o más puntos geográficamente dispersos, esto claramente influyó en la idea de visualizar al software como caja negra -el sistema- cuyo comportamiento se describe por medio de episodios o diálogos particulares entre dicha caja negra y un agente separado -el usuario- por medio del envió de estímulos o señales:
"El fundamento de Objectory es que será diseñado para sus usuarios, queremos armar el sistema para ellos. Para salvaguardar que los usuarios de hecho obtengan el sistema que quieren y necesitan, queremos estructurar el comportamiento total del sistema en aspectos, donde cada aspecto corresponda a lo que llamamos un caso de uso... Un caso de uso es una secuencia especial de transacciones, realizadas por un usuario y un sistema en diálogo. Una transacción es realizada ya sea por el usuario o el sistema y es una respuesta iniciada por un estímulo. Cuando la generación de estímulos haya terminado, todas las transacciones finalizarán. El caso de uso es terminado y un nuevo caso de uso puede ser iniciado".
La riqueza de las publicaciones en esa época [6,7] consistía en mejorar las propiedades internas del software por lo que el enfoque de Ivar Jacobson para diseñar alrededor de la perspectiva del comportamiento externo del software y en particular desde la perspectiva del uso del mismo, resultó ser una innovación importante que ha sido adoptada por muchos desde entonces en el campo de la usabilidad.
Entre casos de uso - extensión
Inicialmente sólo existió una relación entre casos de uso: construido-sobre o basado-en ("built-on") que después cambió de nombre [8] a: extiende ("extends"). Nótese su explicación original:
"...esta relación significa que un caso de uso puede estar basado en otro caso de uso más básico. El término basado-en es usado para indicar que un caso de uso es una especialización de un caso de uso más general. De esta manera solamente la diferencia tendrá que ser especificada en el caso de uso especializado. Esta relación es una forma extendida de la relación de herencia".
El concepto de herencia que Kristen Nygaard y Ole Johan Dahl diseñaron en el lenguaje de programación Simula [9] así como el concepto generalización/especialización de taxonomía y redes semánticas (relación IS-A) tuvieron influencia en el trabajo de Ivar Jacobson pues los adoptó para la relación de extensión entre casos de uso; e.g., caso de uso base: Pagar la cuenta = caso de uso con los elementos básicos para pagar de forma genérica la cuenta -digamos en un restaurante- y cuya descripción contiene el punto de extensión ‘forma de pago'. Ahora considérese un caso de uso extendido: Pagar la cuenta con tarjeta; cuya descripción únicamente incluye la diferencia con su caso de uso base, es decir, la descripción del punto de extensión ‘forma de pago'. Otros casos de uso extendidos podrían ser Pagar la cuenta con efectivo, etc.; esquemáticamente:
Los puntos de extensión pueden corresponder a la enumeración de pasos en el caso de uso base, así los casos de uso extendidos pueden extender cualquiera de dichos pasos.
Los puntos de extensión resultaron -según nos cuenta [10,11] Mr. Jacobson- de gran utilidad para organizar un número creciente de casos de uso y de los documentos correspondientes; pues como los casos de uso son principalmente una técnica semi-formal para organizar narrativas textuales (a diferencia de una noción popular que considera que los casos de uso son los diagramas, que equivale a decir que un mapa de la Ciudad de México es la Ciudad de México) y el número de documentos puede aumentar innecesariamente si no se tiene cuidado en evitar la duplicidad y mantener la estabilidad de las dependencias.
Entre casos de uso - inclusión
La relación de inclusión representa simplemente la descomposición funcional de un caso de uso en uno o más casos de uso, e.g., caso de uso Transferencia entre cuentas bancarias, esquemáticamente:
Mis conclusiones a la fecha
La técnica es magnífica, al entender su potencial se antoja utilizarlo en cada oportunidad para doblegar a la despiadada complejidad inherente que acecha cada proyecto, las explicaciones que ofrece Ivar Jacobson son impecables y a toda cabalidad esta herramienta se ganó formar parte del oficio de formular software correcto. Pero como toda herramienta, su efecto depende de la mano que la usa. Si uno aplica casos de uso, es indispensable aplicar correctamente la técnica, como por ejemplo la relación de inclusión o extensión para cuando se encuentre una situación en donde sea evidente para todos el valor entregado por su aplicación, de otro modo, si solo se usa o se pretende exigir rigor por la técnica misma aunque sólo esté incrementando el trabajo sin relación al valor entregado, entonces por la aplicación inadecuada de una buena técnica estamos perdiendo en vez de ganando algo, y eso no tiene sentido.
La prioridad es para la usabilidad, el diseño de software centrado en cómo este será empleado o usado. Los elementos verdaderamente valiosos de la práctica de la arquitectura de software giran todos alrededor del comportamiento externo observable desde el punto de vista de las tareas que el software habilita para cada tipo de usuario del mismo [12]. No es diseño centrado en el usuario, es diseño centrado en la usabilidad. El usuario promedio no sabe qué es lo que quiere, mucho menos sabe de usabilidad, es por eso que el diseño de software debe estar en manos de alguien con vocación para este oficio.
Referencias
1. Formular software es una idea que intenta recuperar significado para el desarrollo de software: https://formularsoftware.blogspot.com/2005/07/formulando-software.html
2. https://www.biblegateway.com/passage/?search=luke%201:1-4;&version=57
3. Object-oriented development in an industrial environment. Ivar Jacobson. 1987
4. FDL: A Language for Designing Large Real Time Systems. Ivar Jacobson. 1986
5. Language Support for Changeable Large Real Time Systems. Ivar Jacobson. 1986
6. Object-Oriented Development. Grady Booch. 1986
7. An Overview of JSD. J. Cameron. 1986
8. Object-Oriented Software Engineering A Use Case Driven Approach. Ivar Jacobson. 1 Jun 1992. ISBN 9780201544350
9. SIMULA: an ALGOL-based simulation language. Ole-Johan Dahl, Kristen Nygaard. Sep. 1966
10. The Object Advantage: Business Process Reengineering With Object Technology. Ivar Jacobson, Agneta Jacobson, y Maria Ericsson. 30 Sep. 1994. ISBN 9780201422894
11. Software Reuse: Architecture Process and Organization for Business Success. Ivar Jacobson, Martin Griss y Patrik Jonsson. 22 May 1997. ISBN 9780201924763
12. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Lucy A.D. Lockwood, Larry L. Constantine. ISBN 9780201924787
Comments
Anonymous
July 08, 2011
me guzta muxo la pagina‼ LëKäAnonymous
February 15, 2012
=) gracias