Casos de uso en programacion orientada a objetos
Quién escribe los casos de uso
La programación es tanto un arte como una ciencia. Las preferencias personales desempeñan un papel importante a la hora de determinar su estilo de programación, por lo que no le sorprenderá encontrarse en un debate con un compañero. Uno de los debates actuales es la elección entre dos paradigmas de programación diferentes: la programación funcional y la programación orientada a objetos. ¿Cuál es mejor? ¿Cuál debería utilizar?
Los partidarios de uno u otro bando dirán que su paradigma favorito ofrece algunas ventajas claras que se aplican casi universalmente. Se podría argumentar que depende. En este artículo analizaremos ambas opciones e intentaremos destilar el mito de la realidad. El objetivo es comprender mejor estos métodos de programación y estar preparado para utilizarlos cuando tenga sentido.
La programación funcional (PF) es uno de los tipos de programación más antiguos, quizá incluso el más antiguo. Define un proceso de construcción de software que se basa exclusivamente en funciones. En FP, los desarrolladores componen funciones para crear nuevas funciones y escriben aplicaciones para evitar aspectos como el estado compartido o los datos mutables. Para conseguirlo, los desarrolladores suelen utilizar FP de forma declarativa en lugar de imperativa.
Elementos de un caso práctico
El comportamiento estático no es suficiente para modelar un sistema, sino que el comportamiento dinámico es más importante que el estático. En UML, hay cinco diagramas disponibles para modelar la naturaleza dinámica y el diagrama de caso de uso es uno de ellos. Ahora como tenemos que discutir que el diagrama de casos de uso es de naturaleza dinámica, debe haber algunos factores internos o externos para hacer la interacción.
Estos agentes internos y externos se conocen como actores. Los diagramas de casos de uso constan de actores, casos de uso y sus relaciones. El diagrama se utiliza para modelar el sistema/subsistema de una aplicación. Un único diagrama de casos de uso captura una funcionalidad concreta de un sistema.
El propósito del diagrama de casos de uso es capturar el aspecto dinámico de un sistema. Sin embargo, esta definición es demasiado genérica para describir el propósito, ya que otros cuatro diagramas (actividad, secuencia, colaboración y Statechart) también tienen el mismo propósito. Examinaremos algún propósito específico, que lo distinguirá de los otros cuatro diagramas.
Podemos decir que los casos de uso no son más que las funcionalidades del sistema escritas de forma organizada. La segunda cosa que es relevante para los casos de uso son los actores. Los actores pueden definirse como algo que interactúa con el sistema.
Tipo de caso de uso
Un caso de uso es una lista de acciones o pasos de eventos que suelen definir las interacciones entre un rol (conocido en el Lenguaje Unificado de Modelado (UML) como actor) y un sistema para alcanzar un objetivo. El actor puede ser un ser humano u otro sistema externo. En la ingeniería de sistemas, los casos de uso se utilizan a un nivel más alto que en la ingeniería de software y suelen representar misiones u objetivos de las partes interesadas. Los requisitos detallados pueden plasmarse en el Lenguaje de Modelado de Sistemas (SysML) o en declaraciones contractuales.
En 1992 fue coautor del libro Object-Oriented Software Engineering - A Use Case Driven Approach,[4] que sentó las bases del método de ingeniería de sistemas OOSE y ayudó a popularizar los casos de uso para capturar requisitos funcionales, especialmente en el desarrollo de software. En 1994 publicó un libro sobre casos de uso y técnicas orientadas a objetos aplicadas a modelos de negocio y reingeniería de procesos empresariales[5].
Al mismo tiempo, Grady Booch y James Rumbaugh trabajaron en la unificación de sus métodos de análisis y diseño orientados a objetos, el método Booch y la Técnica de Modelado de Objetos (OMT) respectivamente. En 1995 se les unió Ivar Jacobson y juntos crearon el Lenguaje Unificado de Modelado (UML), que incluye el modelado de casos de uso. UML fue estandarizado por el Object Management Group (OMG) en 1997[6]. Jacobson, Booch y Rumbaugh también trabajaron en un perfeccionamiento del proceso de desarrollo de software Objectory. El Proceso Unificado resultante se publicó en 1999 y promovía un enfoque basado en casos de uso[7].
Casos prácticos en ingeniería de software
Obtenga acceso completo a Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, Second Edition y 60K+ títulos más, con una prueba gratuita de 10 días de O'Reilly.
No hay nada orientado a objetos en los casos de uso; no se está haciendo análisis orientado a objetos si se escriben casos de uso. Esto no es un defecto, sino una aclaración. De hecho, los casos de uso son una herramienta de análisis de requisitos ampliamente aplicable que puede aplicarse a proyectos no orientados a objetos, lo que aumenta su utilidad como método de requisitos. Sin embargo, como se analizará, los casos de uso son una aportación fundamental a las actividades clásicas de OOA/D.
