Casos de Uso, éxito y crítica
Publicado por Javier Garzás el miercoles 30 de julio de 2006 a las 19:35
Ultima modificación el el miercoles 30 de julio de 2006
Corria el año 1986 cuando el Dr. Ivar Jacobson trabajaba en Ericsson (Suecia) modelando switches de telefonía. Llevaba ya más de 20 trabajando en la compañia y bastante tiempo sufriendo las limitaciones que ofrece el lenguaje natural a la hora de realizar especificaciones de requisitos y con el objetivo de superarlas creo el concepto de caso de uso ("a special sequence of transactions, performed by a user and a system in a dialogue"). A raiz de esto Jacobson fundó su propia consultora, Objectory, para difundir su Object Oriented Software Engineering (OOSE) y su aproximación desde casos de uso. Objectory llegó a tener más de 20 clientes, Ericcson entre ellos.
El concepto de caso de uso se ha convertido hoy, casi en exclusividad, en la técnica principal a la hora de realizar un analisis de requisitos y posibilitar un correcto paso de los mismos al equipo de desarrollo. Más tarde junto a Booch y Rumbaugh, Jacobson incorporaría su técnica al conocido UML, alcanzando entonces su mayor popularidad (e incluso en muchas ocasiones se asocia de manera erronea el caso de uso exclusivamente con su representación gráfica en UML, olvidando que el caso de uso es en realidad una descripción textual de los pasos que llevan a completar una necesidad de un actor por parte del sistema).
No obstante a pesar de su actual difusión y de la innumerable cantidad de métodos que utilizan esta técnica no todo han sido halagos en la vida del caso de uso. Y las críticas de mayor repercusión vinieron de un Dr. francés que es, al menos en mi opinión, el más influyente, mayor conocedor, estudioso y experto en los fundamentos de la Orientación a Objetos: Bertrand Meyer. Tan genial como muchas veces polémico (se cuenta como en cierta ocasión al preguntarle sobre UML contestó: It would be unfair to say that the piles of UML documentation are empty of any substance, when in fact they contain one genuine idea. … this admirable self-feeding machine, devoted from A to Z to the creation of a new market, free of any of the difficulties associated with the unpleasant business of software development: UML books! UML courses! Courses on the books! Books on the courses! Books on the books! Introductory courses to prepare for the advanced courses! Courses for those who teach the courses! Revisions! UML journals! Conferences! Workshops! Tutorials! Standards! Committees! T-shirts!). Y respecto a los casos de uso famosas son las citas que podemos extraer de su genial obra Object Oriented Software Construction (pg. 739): "Except with a very experienced design team (having built successful systems of several thousand classes each in a pure O-O language), do not rely on use cases as a tool for object oriented analysis and design."
De maneral general, la crítica viene de que describen una aproximación funcional, qué hace el sistema y no cómo se comportan los elementos del sistema. Y desde aquí los posibles riesgos de su uso:
- Enfatizan el orden: (se introduce el password, este se envía a la BBDD y se valida, etc.). Esto es incompatible con la OO: evitar la secuencialidad por que es sensible a los cambios. Propiedades de la forma “Si a entonces b” deben ser rechazadas, en lugar de esto se debe preguntar “cuales son las operaciones disponibles en esta abstracción del modulo A y cuales son sus restricciones. La temprana secuencialidad es un error, esta en todo caso, debe solucionarse con precondiciones.
- Son peligrosos, animan a un desarrollo funcional
- Confiar en un escenario significa que hay un enfoque en cómo los usuarios ven las operaciones del sistema. Es un riesgo serio usar, bajo el título de desarrollo objeto-orientado, a las formas más tradicionales del diseño funcional. Cierto, puede confiar en varios escenarios en lugar de simplemente un programa principal. Pero éste todavía es un acercamiento que considera lo que el sistema hace como punto de partida, mientras que la tecnología del objeto considera lo a que lo hace. El choque es irreconciliable.
- Caso de uso desemboca en Top – Down
No obstante, y a pesar de ello, en la actualidad los casos de uso son una técnica reconocida, extendida, y de "uso obligado" en un proceso de requisitos software.
© Copyright Javier Garzás, all rights reserved. All material on this site is copyrighted. For articles attributed to named authors, they are the copyright of the corresponding authors. Any unattributed articles are copyright Javier Garzás. Please link freely to this site, but if you want to copy any of the materials you should contact the authors first.