Es sabido que el mayor porcentaje de esfuerzo para el desarrollo de software se encuentra en las etapas más tempranas del ciclo de vida del mismo. Desde la etapa de relevamiento de requerimientos hasta la etapa de inicio del desarrollo, existe un momento crucial que puede garantizar el éxito o fracaso de un proyecto de software.
Durante las etapas de Análisis y Diseño de los sistemas, se proveen entregables que en la actualidad son tomados muy a la ligera. La documentación deja marcada la idea del software, sus necesidades y sus funcionalidades. Entre estas documentaciones se tienen muchas preguntas sin contestar especialmente con los Casos de Uso.
Aunque existen estándares de codificación para la etapa de desarrollo e inclusive patrones de diseño que ayudan enormemente a marcar la forma de comportamiento y estructura en el código, uno de los principales problemas viene dado por las preguntas ¿cómo realizar correctamente la documentación de los Casos de Uso? y si ¿Existe una manera estandarizada para este tipo de documentación?
Para este tema, escribí un ensayo para la maestría que estoy cursando sobre “La importancia de la estandarización de los Casos de Uso por medio de Patrones”. Esta investigación, después de buscar muchísimo y leer bastante, me llevó a encontrar uno de los mejores artículos que pude encontrar sobre este tema. El artículo fue escrito por Martin Langlands , y tomando en cuenta el arduo trabajo de investigación, este ensayo será entonces el punta pie inicial para una serie de artículos que quiero escribir sobre estos patrones. Recomiendo ampliamente la lectura del artículo original que se puede encontrar al final de este artículo. A continuación el texto del ensayo.
En la publicación “How Microsoft builds software” (Michael A. Cusumano y Richard W. Selby, 1997), se menciona que “Desde mediados de los años 1980, Microsoft y otras compañías de software han reorganizado gradualmente la forma de construir productos de software en respuesta a los problemas de calidad y retrasos en las entregas”.
En el mismo artículo, se menciona que como estrategia, Microsoft distribuye los trabajos en equipos pequeños para luego ser sincronizados nuevamente. Esto permite que cada equipo de trabajo se centre en los objetivos de su desarrollo hasta el momento en que deben unir sus resultados con los demás equipos. Cusumano, comenta en su artículo como esta estrategia ayuda a Microsoft a mejorar la calidad del software.
La realización de trabajos en equipos permite dividir el problema en partes, pero a la vez que admite uno de los inconvenientes más comunes dentro del desarrollo del software, ya que se deben definir estándares a la hora de realizar el desarrollo, de otra forma, cada equipo puede tener su propio camino para resolver el problema en el que se centra.
Cuando hablamos sobre la fase de desarrollo, podemos ver que existen estándares a nivel de código e incluso patrones de diseño que permiten centrarse en la lógica del negocio y no dedicar tiempo extra a reinventar la rueda sobre problemas comunes.
Como bien es sabido, la parte más importante de un proyecto de desarrollo de software se encuentra en las fases tempranas de requerimientos, análisis y diseño, por lo que la estandarización no solo debería ser tarea de los arquitectos y desarrolladores, sino más bien de los analistas en estas primeras fases.
Entre los documentos que resultan ser entregables en las fases de Análisis y Diseño, se encuentran los casos de uso, los cuales son de gran ayuda para los desarrolladores e inclusive los testers, y es muy normal que la experiencia de cada analista defina la forma de uso de este tipo de documentación, por lo que le tema de este ensayo es investigar sobre estandarización y patrones de los casos de uso para poder definir un criterio común y base para este tipo de documentación.
Martin Langlands (2008) en su artículo “Inside The Oval : Use-Case Content Patterns”, propone que los patrones de casos de uso estén dados por su contenido.
De esta manera, Langlands propone 10 patrones para la estandarización del contenido de los casos de uso más utilizados dentro de los sistemas informáticos, vinculados según se muestra en el anexo “Fig P-1: The patterns in the Language”.
Uno de los problemas principales a la hora de realizar los casos de uso es definir el nivel de granularidad que se debe tomar en cuenta. Los patrones mencionados al ser orientados al contenido, es decir a los flujos principales, alternativos, de excepción con sus pasos respectivos y las pre y post-condiciones, permiten justamente marcar un estándar que permitirá a los analistas y desarrolladores comunicarse entre sí, como así también definir un lenguaje en común para los distintos equipos de trabajo.
A continuación, se hace una breve descripción de cada uno, según el orden más común del uso de los sistemas, a diferencia del artículo original.
- Basic Creator: Marca las pautas para un caso de uso en el que se desea crear un nuevo objeto, utilizando sus propiedades principales y validando su duplicación. Opcionalmente, como camino alternativo, permite identificar si el mismo objeto existe bajo otros parámetros. Se puede ver representado por el diagrama de actividades del anexo “Fig BC-1: Basic Creator Main Flow”.
- Criteria Search: Permite realizar una búsqueda de objetos existentes permitiendo al usuario realizar acciones sobre el resultado. Opcionalmente, como caminos alternativos, prevé nuevas búsquedas, ordenamiento por columnas, filtros avanzados y por columna. Se puede ver representado por el diagrama de actividades del anexo “Fig CS-2: Activity diagram for criteria search use-case, including alternative flows”.
- Known Object: Este patrón es el punto de partida sobre cualquier acción que se desea realizar sobre un objeto. Pretende aislarse de los demás patrones para permitir que los siguientes casos de uso ya conozcan al objeto sobre el cual se desea trabajar.
- Viewer/Updater: Este patrón pretende ser la base para la visualización y actualización de un objeto conocido por medio del patrón Known Object. Se implementa por medio de dos patrones que extienden a este:
- Simple Viewer/Updater: Este patrón permite la visualización y actualización de un objeto simple. Se puede ver representado en el anexo “Fig SVU-1: simple viewer / updater Main Flow”.
- Multiple Selectable Paths: Al igual que el patrón anterior, permite la visualización y actualización pero de un objeto compuesto. Generalmente se utilizan para objetos que contengan dependencias o estén compuestos por otros objetos, con los cual la modificación resulta más complicada y se debe organizar sus propiedades para facilitar la carga al usuario. Se puede ver representado en el anexo “Fig MSP-1: multiple selectable paths Main Flow”.
- Destructor: Este patrón permite la eliminación de un objeto conocido por medio del patrón Known Object. Se puede ver representado por el diagrama de actividades del anexo “Figure DES-1: destructor Pattern Main Flow”.
- Object Manager: Este patrón reúne los patrones anteriores para ejecutar las actividades de CRUD (create, read, update, delete) sobre los objetos. Se puede ver representado en el anexo “Fig OM-1: Object Manager Use-Case Diagram”.
- Selector: Permite una búsqueda para seleccionar objetos a ser utilizados por otros objetos.
- Property List: Propone una sección en los casos de uso para determinar las propiedades de los objetos utilizados.
Conclusión
El desarrollo basado en equipos propuesto por Microsoft permite centrar la atención en problemas más pequeños pero a su vez deben ir acompañados por patrones y estándares desde sus las etapas iniciales del análisis y diseño para permitir un lenguaje común entre analistas y diseñadores con sus pares en etapas posteriores como ser los arquitectos y desarrolladores.
Anexos
Referencias
Cusumano, M. A., & Selby, R. W. (1997, Junio). How Microsoft builds software. Communications of the ACM
Langlands, M. (2013). Inside The Oval : Use-Case Content Patterns (version 2.0). Link alternativo: descargar
[sc name=»posts_use_cases_patterns» ][/sc]Descubre más desde Neurosimbiosis
Suscríbete y recibe las últimas entradas en tu correo electrónico.