LATIN AMERICAN CONGRESS ON REQUIREMENTS ENGINEERING & SOFTWARE TESTING LACREST MEDELLN 2012. July 13-14, Medelln, Colombia.

Antipatterns catalog to use when specifying functional requirements with use cases Catlogo de antipatrones al especificar requisitos funcionales usando casos de uso
Juan Bernardo Quintero1, Diana Mara Hernndez2, Pamela Rucinque3
1 2

Arquitecto en ABC-Flex Ltda., Docente en Universidad de Antioquia y Universidad EAFIT. Medelln, Colombia. jbq@abcflex.net. Analista de Requisitos en ABC-Flex Ltda. Medelln, Colombia. dianahdez@abcflex.net. 3 Analista de Desarrollo en PSL. Medelln, Colombia. prucinque@psl.com.co. INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin: X Historia del artculo: Recibido: Correcciones: Aceptado: Palabras clave: Antipatrones, Patrones, Requisitos, Casos de Uso Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications Elicitation methods, Methodologies. General Terms: Requirements Engineering. Keywords: Antipatterns, Patterns, Requirements, Use Cases ABSTRACT Problems during requirements specification diminish the chances of project success or the ability for the development process to run smoothly. This is why studying antipatterns in use cases is important as they raise more problems than they solve. This paper introduces an antipattern catalog with the single purpose of avoiding the bad practices they suggest for the specification of functional requirements using use cases. RESUMEN Los problemas en la especificacin de requisitos son un factor que afecta considerablemente las posibilidades de alcanzar el xito o de que el proceso transcurra con fluidez en el desarrollo de un proyecto de software, este es el motivo por el que es importante el estudio de los antipatrones en los casos de uso, como soluciones negativas que presentan ms problemas que los que solucionan. Este artculo presenta un catlogo de antipatrones para evitar las malas prcticas que estos siguieren en la especificacin de requisitos funcionales usando casos de uso.

1. INTRODUCCIN A pesar del surgimiento de nuevas tcnicas en desarrollo de software y estrategias de gestin de proyectos, los factores por los que falla un proyecto de desarrollo, todava se encuentran muy relacionados con la gestin de requisitos. El prestigioso reporte caos, pone en evidencia esta situacin, que se ha presentado durante las ltimas dcadas, aunque cabe anotar que el porcentaje de proyectos exitosos ha aumentado [1]. Este planteamiento implica que para aumentar las posibilidades de xito en un proyecto de desarrollo de software, es necesario poner especial atencin en el anlisis de los requisitos. Los casos de uso constituyen unas de las tcnicas ms usadas para la especificacin de requisitos, es por esto que resulta de gran importancia conocer las buenas y malas prcticas al respecto, para mejorar los posibles resultados. En este sentido las buenas prcticas estn dadas por los patrones para definir casos de uso efectivos, mientras que las malas prcticas se plantean en los antipatrones para la especificacin de requisitos funcionales usando casos de uso. Para conocer bien los antipatrones en casos de uso, es necesario el buen conocimiento de los patrones en casos de uso, por tanto este artculo presenta un resumen de un reconocido catlogo de patrones para casos de uso efectivos detallado en el libro [2]. Por otro lado, el catlogo de antipatrones que se presenta en este artculo, proviene de un cuidadoso anlisis de los autores, acerca de los proyectos en los que han participado durante los ltimos aos, en los cuales los casos de uso han sido la tcnica de especificacin de casos de uso imperante. La labor docente de algunos de los autores, ha motivado la

revisin de las situaciones que atentan contra el buen desempeo de un proyecto de software, a partir de las fallas en la especificacin de los casos de uso; la recopilacin de la informacin derivada de esta situacin, es la que fundamenta el desarrollo del catlogo de antipatrones para la especificacin de requisitos funcionales usando casos de uso, planteado en este artculo. Para la presentacin del catlogo de antipatrones, este artculo se estructura de la siguiente forma: en el captulo 2 se revisa la disciplina del anlisis de requisitos y su relacin con los casos de uso, el captulo 3 presenta informacin de los patrones y los antipatrones, el captulo 4 resume el catlogo de patrones para casos de uso efectivos, el captulo 5 plantea el catlogo de antipatrones para especificar requisitos funcionales usando casos de uso, y el captulo 6 expone unas conclusiones al respecto.. 2. PAPEL DE LOS CASOS DE USO EN EL ANLISIS DE REQUISITOS El anlisis de requisitos es una disciplina o flujo de trabajo, posterior al modelado de negocio y previa al anlisis y diseo, segn el proceso unificado de desarrollo tambin llamado RUP (por la sigla inglesa de Rational Unified Process) [3]. El principal artefacto a construir en este flujo es el documento de especificacin de requisitos, en el cual los casos de uso de requisitos juegan un papel fundamental, al punto que RUP plantea que es un proceso dirigido por los casos de uso. Otra de las caractersticas de RUP es que se define como un proceso centrado en la arquitectura; el principal artefacto en este frente es el documento de arquitectura; en este tambin aparecen los principales casos de uso primarios como parte de los conductores o drivers de la arquitectura. Esta importancia que se le da a los casos 1

de uso dentro del proceso, es un factor que motiva un cuidadoso anlisis de las buenas y malas prcticas en este sentido. Un caso de uso se define como una coleccin de escenarios de xito y fracaso relacionados, que describe a los actores que usan un sistema para conseguir un objetivo, mientras que un escenario se define como una secuencia especfica de acciones e interaccin entre el usuario y el sistema bajo discusin [4]. Los elementos que se utilizan en la construccin de modelos de casos de uso, definen las categoras de los antipatrones en el catlogo planteado. Cabe aclarar que RUP tambin propone casos de uso de negocio los cuales se construyen en la disciplina de modelado de negocio, sin embargo el catlogo de patrones planteado en el artculo se centra en los casos de uso de requisitos. 3. LOS PATRONES Y LOS ANTI-PATRONES Un patrn presenta un esquema genrico de solucin probada, a un problema recurrente que surge en contextos especficos. El esquema de la solucin describe un conjunto de componentes, sus responsabilidades, las relaciones entre estos, y la forma en que dichos componentes colaboran entre s [5]. Existen diversos catlogos de patrones que tienen como propsito definir buenas prcticas en los diferentes frentes del desarrollo de software; el ms famoso es el catlogo GoF que define un conjunto de patrones para tratar problemas de diseo [6]. En contraposicin los antipatrones son soluciones negativas que presentan ms problemas que los que resuelven; extienden y complementan los patrones de forma natural. El estudio de los antipatrones permite conocer los errores ms comunes relacionados con la industria del software para intentar evitarlos o recuperarse de ellos [7]. Al ilustrar situaciones negativas, los antipatrones se documentan con cierto sarcasmo, lo que los hace graciosos y fciles de recordar, los nombres pueden aludir con algn grado de humor o cinismo al problema que presentan. Al igual que los patrones, los antipatrones se documentan mediante una plantilla que puede considerar diferentes elementos. Sin embargo, para el caso especfico de los antipatrones para especificar requisitos con caso de uso, se debe tener en cuenta que corresponden a la disciplina de anlisis de requisitos y adicionalmente considerar que un buen antipatrn explica por qu la solucin original parece atractiva, por qu se vuelve negativa y cmo recuperarse de los problemas que sta genera [8]. Con base en estos aspectos, se definen los siguientes tems para la plantilla de documentacin de los antipatrones: Nombre: que ilustre con un toque de humor la situacin problemtica que se presenta. Nombre alterno: sinnimo para el nombre que motive su recordacin. Causas: situacin que motiva la aplicacin de la solucin negativa. Descripcin: explicacin del problema que se presenta. Factores que motivan su uso: situacin que hace que la solucin negativa parezca atractiva. Ejemplo y/o posible solucin: ejemplo para aclarar el problema de la solucin negativa y de su solucin, o en

caso de que la situacin problemtica sea evidente, solo se plantea un posible esquema de solucin. 4. CATLOGO DE PATRONES EN LA ESPECIFICACIN DE CASOS DE USO Para definir un catlogo de antipatrones que presenta malas prcticas alrededor de los casos de uso, es fundamental conocer detalladamente las buenas prcticas y los catlogos de patrones acerca de casos de uso. Las buenas prcticas para escribir casos de uso efectivos, se compendiaron en el libro Writing effective use cases [9]; luego se formalizaron en el catlogo presentado en Patterns for Effective Use Cases [2]. La tabla 1 ilustra las categoras y patrones presentados en este catlogo:
Tabla 1. Catlogo de Patrones para Casos de Uso Efectivos. Categora Team Nombre del Patrn SmallWritingTeam ParticipatingAudience BalancedTeam BreadthBeforeDepth SpiralDevelopment MultipleForms TwoTierReview QuittingTime WritersLicense SharedClearVision VisibleBoundary ClearCastOfCharacters UserValuedTransactions EverUnfoldingStory CompleteSingleGoal VerbPhraseName ScenarioPlusFragments ExhaustiveAlternatives Adornments PreciseAndReadable DetectableConditions LeveledSteps ActorIntentAccomplished ForwardProgress TechnologyNeutral CommonSubBehavior InterruptsAsExtensions PromoteAlternative RedistributeTheWealth MergeDroplets CleanHouse
Fuente: Patterns for Effective Use Cases [2]

Process

Use Case Set

Use Case

Scenarios and Steps

Use Case Relationships Editing Existing Use Cases

Para facilitar la comprensin de los patrones para casos de uso efectivos presentados en el catlogo, a continuacin se hace un breve resumen de cada categora con el conjunto de patrones que le corresponden. 4.1. El Equipo El tamao del equipo, la retroalimentacin que reciben e incluso el background y personalidad de sus miembros son aspectos fundamentales en la conformacin de equipos de elicitacin de casos de uso ideales. Un equipo ideal sera aquel que no exceda el tamao de 3 miembros (SmallWritingTeam), que mantengan constante contacto con los posibles usuarios de los casos de uso en desarrollo (ParticipatingAudience) y sus miembros tengan diferentes

especialidades y formas de pensar para as resolver problemas desde el mayor nmero de puntos de vista posible (BalancedTeam). 4.2. El Proceso Un buen proceso de requerimientos prioriza el valor de cada caso de uso sobre los detalles y tecnicismos. Obtener una visin general de la aplicacin resulta ms beneficioso que dedicarle tiempo a los detalles en una etapa temprana del proceso (BreadthBeforeDepth); una vez se conoce la aplicacin a alto nivel, se pueden desarrollar los casos de uso iterativamente (SpiralDevelopment) y detallarlos hasta que se considere necesario sin caer en el perfeccionismo (QuittingTime). Cada equipo debe ser libre de escoger el formato con el que se sientan mejor escribiendo, es ms productivo (MultipleForms); as como se debe entender que cada escritor tiene su estilo (WritersLicense), el formalismo no debe ser un impedimento; sin embargo estilos y formalismos muy dispares pueden causar dificultades en la comprensin. Finalmente, las revisiones deben ser en dos etapas: Detalladas, revisando forma y fondo, por un grupo interno y pequeo y luego la funcionalidad del caso de uso por parte de los dems involucrados (TwoTierReview). 4.3. El conjunto de Casos de Uso Tener un buen conjunto de casos de uso, organizados tal que sus nombres y orden puedan contar una historia (EverUnfoldingStory), garantiza una visin clara del proyecto por parte de todos los involucrados. Para empezar, la visin del proyecto debe apoyar la misin de la organizacin (SharedClearVision), y se debe establecer claramente cules son sus lmites (VisibleBoundary), una aplicacin no lo puede resolver todo, debe ser enfocada en resolver lo que realmente es de alto valor para los usuarios (UserValuedTransactions) y tener claro quines son los actores reales del sistema (ClearCastOfCharacters). 4.4. Los Casos de Uso Un caso de uso es una historia y debe ser escrito como tal, recordando que su audiencia es diversa (PreciseAndReadable). Su nombre debe generar recordacin, y ser en voz activa, un verbo en infinitivo seguido de un sustantivo y de ser necesario un corto complemento (VerbPhraseName); adems, el objetivo del caso de uso tiene que ser nico y claro (CompleteSingleGoal). Sus flujos alternos y excepciones deben ser, en su totalidad, incluidos (ExhaustiveAlternatives); sin embargo, no pueden interferir en la lectura del flujo principal (ScenarioPlusFragments). Tambin se deben crear campos en las plantillas que permitan incluir datos significativos pero que no distraigan al lector de la descripcin del escenario (Adornments). 4.5. Escenarios y Pasos El caso de uso, al ser una historia, debe generar inters en el lector; que con cada paso escrito en forma simple, logre avanzar (ForwardProgress); describiendo claramente quien ejecuta la accin y cul es su intencin (ActorIntentAccomplished). Combinar condiciones que concluyan en la misma accin (DetectableConditions) y mantener el mismo nivel de abstraccin en la descripcin de cada paso, contribuye a la fluidez y simpleza del caso de uso (LeveledSteps). Es imperativo que el caso de uso se

mantenga al margen de la tecnologa que se vaya a usar (TechnologyNeutral). 4.6. Las Relaciones de los Casos de Uso Los casos de uso pueden relacionarse entre s, dichas relaciones deben ser manejadas con cuidado. Cuando cierta funcionalidad es compartida por varios casos de uso, sta se extrae en otro y se incluye (include) desde el caso de uso padre o base (CommonSubBehavior). Si, por otra parte, hay una condicin que se repite en varios pasos y conduce a un flujo alterno (InterruptsAsExtensions) o hay un flujo alterno tan importante que parece relegar al flujo principal (PromoteAlternative), ste debe extraerse tambin en un caso de uso aparte, pero en este escenario el caso de uso nuevo extiende al padre o base (extend). 4.7. Editando Casos de Uso existentes Cuando los casos de uso no son legibles, ni cumplen con las buenas prcticas, pueden resultar en errores de implementacin. Es posible que un caso de uso largo en pasos, generalmente ms de nueve, tenga ms de un objetivo y sea candidato a dividirse (RedistributeTheWealth). Opuesto a esto, casos de uso pequeos que se relacionen con una misma meta, y que por s solos no tengan objetivo de valor para el negocio deben ser agrupados (MergeDroplets). Y por ltimo, aquellos casos de uso que no aaden valor al negocio o ya no sern tenidos en consideracin, deben ser eliminados para evitar distracciones de quien revisa el conjunto de casos de uso (CleanHouse). 5. CATLOGO DE ANTIPATRONES EN LA ESPECIFICACIN DE CASOS DE USO Teniendo en cuenta que ya existe un catlogo de patrones para especificar casos de uso efectivos; este artculo no pretende ilustrar los antipatrones como la no aplicacin de estos patrones; en contraposicin pretende estudiar las situaciones que recurrentemente atentan contra una buena especificacin de casos de uso, dentro de los modelos de requisitos que se construyen en el desarrollo de un proyecto de software. Este es el motivo para que el nombre de los antipatrones planteados, no se derive de la no aplicacin de un patrn. Trabajos previos: para la definicin de un catlogo de antipatrones, es necesario revisar tanto las buenas prcticas como las malas prcticas que han sido estudiadas previamente por otros autores. En este frente nos encontramos con diversos trabajos: En [11] se hace un detallado anlisis de las 10 principales trampas en las que caen los analistas de requisitos que usan casos de uso cuando enfrentan proyectos reales. En [15] se muestran un conjunto de buenas y malas prcticas en la especificacin de requisitos usando casos de uso. En [16] se hace un anlisis de un asunto puntual pero muy recurrente en el anlisis de requisitos: Por qu los casos de uso nos son funciones?. El estudio de los referentes anteriores, y la experiencia derivada de la participacin en proyectos de software por parte de los autores, sirven de fundamentacin para el planteamiento de los antipatrones propuestos en este catlogo, cuyos nombres se ilustran en la tabla 1, clasificados en cuatro categoras, de acuerdo con el frente en particular donde se suelen presentar: 3

Tabla 1. Catlogo de Antipatrones en Casos de Uso. Categora 1: en los conjunto de casos de uso PuntoDeEntrada (EntryPoint) ModeladoDesordenado (MessyModeling) Categora 2: en los casos de uso NombreConfuso (ConfusingName) AlcanceMezclado (MixedUpScope) GranularidadFueraDeLugar (MisplacedGranularity) CasoDeUsoImperativo (ImperativeUseCase) Categora 3: en los escenarios y pasos TiposDeFlujoIndeterminados (IndeterminateFlowTypes) EstiloDeEscrituraIndefinido (UndefinedWritingStyle) DesempoderamientoFuncional (FunctionalDisempowerment) Categora 4: en las relaciones RelacionesEnmaraadas (TangledRelationships) RelacionesRedundantes (RedundantRelationships) RelacionesIncorrectas (WrongRelationships)
Fuente: Construccin propia de los autores

b) Modelado Desordenado Nombre: ModeladoDesordenado (MessyModeling) Nombre alterno: FormateoDifuso (DiffuseFormatting) Causas: Descuido y deficiencias en la arquitectura. Descripcin: Se presenta cuando los diagramas quedan desordenados, bien porque tienen muchos casos de uso o porque no se pone el lmite del sistema o mdulo; esto dificulta su comprensin, realizacin e implementacin. Factores que motivan su uso: La necesidad de representar lo que requiere el usuario por ms extenso o confuso que resulte, sin hacer un ejercicio de modularizacin que conduzca a una vista conceptual de la arquitectura con los paquetes relativos al usuario. Ejemplo y/o posible solucin: Para resolver la situacin de la falta de lmite y el desorden, a nivel del equipo de trabajo, se pueden hacer acuerdos en cuanto al modelado para usar el lmite del sistema o paquete y un nmero de casos de uso por diagrama. La figura 2 ilustra un diagrama en el que se presenta este caso en el antipatrn y la forma en que se resuelve.

A continuacin se explican los antipatrones en cada una de las cuatro categoras definidas. 5.1. CATEGORA 1: En los conjuntos de casos de uso Esta categora se centra en los antipatrones que se presentan en un conjunto de casos de uso relacionados, que se suelen diagramar en un mismo modelo. a) Punto de Entrada Nombre: PuntoDeEntrada (EntryPoint) Nombre alterno: CasoDeUsoDirector (DirectorUseCase) Causas: Desconocimiento y modelado del flujo en la interface de usuario. Descripcin: Se presenta cuando el actor principal se relaciona con solo un caso de uso, el cual tiene relaciones de dependencia con los dems casos de uso. El nombre de Caso de Uso Director proviene de la denominacin que le dan a la ilustracin de este problema en [2]. Factores que motivan su uso: La necesidad de modelar el flujo de la interface de usuario y la navegacin, los cuales quedan muy claros usando esta estrategia; sin considerar las verdaderas implicaciones de las relaciones de dependencia entre los casos de uso. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, el caso de uso director pasa a ser parte del ttulo del lmite del sistema o paquete y el actor se relaciona directamente con los dems casos de uso, esto evita el modelado de la navegacin en la interface de usuario o la secuencialidad de los casos de uso, como lo recomienda [10]. La figura 1 ilustra un diagrama en el que se presenta este antipatrn y la forma en que se resuelve.

Figura 2. Caso 1 de ModeladoDesordenado y su solucin

Para resolver la situacin de muchos casos de uso en el mismo diagrama, a nivel de arquitectura, se puede hacer una modularizacin en paquetes y hacer un diagrama de casos de uso para cada paquete, de esta forma se mejora la comprensin de los diagramas [11]. Inclusive se puede usar un Diagrama de Paquetes de Casos de Uso, basado en la estrategia diagramacin propuesta en [12]. La figura 3 ilustra un diagrama en el que se presenta este caso en el antipatrn y la forma en que se resuelve.

Figura 3. Caso 2 de ModeladoDesordenado y su solucin Figura 1. PuntoDeEntrada y su solucin

5.2. CATEGORA 2: En los casos de uso Esta categora se centra en los antipatrones que se presentan en cada caso de uso individualmente. a) Nombre Confuso Nombre: NombreConfuso (ConfusingName) Nombre alterno: NombreErrado (Misnomer) Causas: Descuido y deficiencias en gestin del equipo de trabajo. Descripcin: Se presenta cuando los nombres de los casos de uso se ponen desde la perspectiva del sistema y no del usuario, o cuando no se utiliza voz activa para su denominacin, sea que no se usa un verbo en infinitivo seguido de un sustantivo y de ser necesario un corto predicado, indicando de esta forma una accin. Factores que motivan su uso: La necesidad de que los casos de uso queden bien documentados y representen bien lo que se implementa, en lugar de representar lo que requiere el usuario. Ejemplo y/o posible solucin: Ejemplo de esta situacin podra ser un caso de uso llamado Matrcula Estudiante en una institucin educativa que permite a los estudiantes realizar la matrcula en lnea por Internet; primero su nombre se orienta ms al sistema que al actor, segundo no est en voz activa y por ende no indica una accin en s; en este caso lo correcto sera por ejemplo un caso de uso llamado Realizar Matrcula. b) Alcance Mezclado Nombre: AlcanceMezclado (MixedUpScope) Nombre alterno: NegocioOSistemaDeInformacion (BusinessOrComputerSystem) Causas: Desorganizacin y falta de niveles de abstraccin en el modelado. Descripcin: Se presenta cuando los modeladores tratan de mostrar tanto a los actores de la empresa como a los usuarios del sistema informtico en el mismo modelo de casos de uso. El modelo y la especificacin textual se vuelven confusos, ya que el conjunto de interacciones del cliente de negocio es diferente al de los actores del sistema informtico [11]. Factores que motivan su uso: La necesidad de que los casos de uso documenten completamente la empresa, sin diferenciar lo que quieren los diferentes tipos de actores. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben definir niveles de modelado para diferenciar casos de uso de requisitos y casos de uso del negocio, estos segundos se pueden articular con la arquitectura empresarial o artefactos similares. La figura 4 ilustra un diagrama en el que se presenta este antipatrn y la forma en que se resuelve.

c) Granularidad Fuera de Lugar Nombre: GranularidadFueraDeLugar (MisplacedGranularity) Nombre alterno: ObjetivoDeNegocioOAccinIncidental (BusinessGoalOrIncidentalAction) Causas: Descuido y falta de niveles de abstraccin en el modelado. Descripcin: Se presenta cuando los casos de uso constituyen procesos muy generales con granularidad muy gruesa, en este caso corresponden ms a objetivos en el modelado de negocio, que a requisitos en el anlisis. Tambin se presenta cuando los casos de uso constituyen operaciones muy puntuales con granularidad muy fina, en este caso corresponden ms a acciones incidentales en el diseo del sistema, que a requisitos en el anlisis. El trmino acciones incidentales proviene de la denominacin que le dan a la ilustracin de este problema en [11]. Factores que motivan su uso: La necesidad de que los casos de uso documenten completamente la empresa o cmo se implementarn funcionalidades muy puntuales, sin diferenciar lo que quieren los actores del sistema de informacin. Ejemplo y/o posible solucin: Los casos de uso en el anlisis de requisitos corresponden a Procesos Elementales de Negocio (Elementary Business Process) [4], por tanto se debe definir y revisar la granularidad de los casos de uso por parte del equipo de trabajo, para evitar trabajo innecesario o implementaciones muy complejas. Un ejemplo de esta situacin en una institucin educativa podra ser, Mejorar la Calidad de la Educacin como objetivo de negocio, Seleccionar Curso como accin incidental en el sistema y Matricular Estudiante como proceso elemental de negocio, por tanto solo el ltimo caso corresponde a un caso de uso de requisitos. d) Caso de Uso Imperativo Nombre: CasoDeUsoImperativo (ImperativeUseCase) Nombre alterno: CasosDeUsoEnDiseo (UseCaseInDesign) Causas: Desconocimiento y modelado desde la perspectiva del desarrollo. Descripcin: Se presenta cuando los casos de uso se centran ms en el Cmo que en el Qu. Los casos de uso hacen parte fundamental del anlisis de requisitos, por tanto son por naturaleza declarativos (se enfoca mayoritariamente en el Qu o el espacio del problema), mientras que el diseo es imperativo (se enfoca mayoritariamente en el Cmo o el espacio de la solucin), por tanto los modelos de casos de uso no deben invadir el diseo. Factores que motivan su uso: La necesidad de que los casos de uso documenten y representen bien cmo se implementarn, en lugar de representar lo que requiere el usuario. Ejemplo y/o posible solucin: Incluyen los llamados casos de uso CRUD, denominados as por representar las operaciones de Create, Read, Update y Delete; en ocasiones llamadas operaciones CRUDEL [13], adicionando Exist para verificar la existencia de una instancia de una entidad y List para recuperar todos los datos de una entidad. Es notorio que estas operaciones entran ms en el diseo que en el anlisis, por tanto ms que hacer un caso de uso por cada operacin, se debera hacer un caso de uso que agrupe este conjunto de 5

Figura 4. AlcanceMezclado y su solucin

operaciones, generalmente denominado Gestionar [Nombre de la Entidad Implicada]. Dicha regla podra tener una excepcin, cuando la labor de creacin de una instancia de la entidad implicada es muy compleja, justificando la definicin de casos de uso para algunas de sus operaciones CRUDEL; sin embargo, en este caso es posible que un verdadero proceso elemental de negocio haya sido omitido y se est enmascarando dichas operaciones. Ejemplo de operaciones CRUDEL que ocultan un proceso elemental de negocio, podra ser Gestionar Estudiante en una institucin educativa, el cual podra enmascarar el proceso de Matricular Estudiante. 5.3. CATEGORA 3: En los escenarios y pasos Esta categora se centra en los antipatrones que se presentan en la especificacin de los casos de uso, cuando se describen sus escenarios y sus pasos. a) Tipo de Flujos Indeterminados Nombre: TiposDeFlujoIndeterminados (IndeterminateFlowTypes) Nombre alterno: FlujoAlternativoOExcepcional (AlternativeOrExceptionalFlow) Causas: Desconocimiento y deficiencias en gestin del proyecto o del equipo de trabajo. Descripcin: Cuando se especifican los casos de uso, se hace especial nfasis en la documentacin del flujo de eventos principales, los cuales definen la coleccin de escenarios que suceden regularmente (o como es llamado en ocasiones: Happy Path); mientras que en algunos casos los dems flujos no son trabajados con el rigor debido. En otros casos los flujos alternativos y excepcionales no se separan, por el desconocimiento de la principal diferencia entre estos dos tipos de flujos: Un flujo alternativo: Alcanza el objetivo planteado para el caso de uso por un camino diferente al Happy Path. Un flujo excepcional: NO alcanzan el objetivo planteado para el caso de uso. En ocasiones los flujos excepcionales necesitan definir eventos de compensacin, o sea devolver el sistema al estado en el que estaba antes de la ejecucin del caso de uso, mientras que los flujos alternativos no sugieren esta labor. Al no hacer un anlisis separado de estas situaciones, se dificulta la realizacin de pruebas apropiadas para cada situacin, se pueden disminuir los llamados casos de prueba y aumenta la posibilidad de errores. Factores que motivan su uso: La premura en la entrega de los proyectos hace que el tiempo para la capacitacin del personal, la definicin de acuerdos y las pruebas sean labores que pueden retrasar la agenda de los proyectos. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben definir acuerdos tendientes a diferenciar estos tipos de flujos en la especificacin de los casos de uso, y de esta forma poder darle el tratamiento apropiado a cada tipo de flujos. b) Estilo de Escritura Indefinido Nombre: EstiloDeEscrituraIndefinido (UndefinedWritingStyle) Nombre alterno: DesacuerdoEnTipoDeEscritura (DisagreementOnWritingType) Causas: Descuido y deficiencias en gestin del equipo de trabajo.

Descripcin: Existen varias caractersticas que pueden afectar la redaccin de los flujos de trabajo, entre ellos se destacan: Escenarios muy largos o con redaccin confusa: esto dificulta considerablemente la comprensibilidad del caso de uso. Diferencias en la granularidad de los escenarios: se plantan actividades con granularidad muy gruesa y muy fina en el mismo escenario. Mezcla de estilos de escritura: en el estilo esencial se evita tratar la interface de usuario y en el estilo concreto se refieren elementos de la interface de usuario. Parcialidad tecnolgica: en la descripcin del caso de uso se incluyen elementos propios de la plataforma en la que ser implementado el sistema. Factores que motivan su uso: La necesidad de que los casos de uso queden bien documentados, en algunos casos hacen que el especificador incurra en detalles innecesarios que entran ms en el espacio de la solucin que del problema. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, en los escenarios muy largos se puede considerar dividirlo en varios casos de uso, pues es posible que se est enmascarando un proceso elemental de negocio. Para resolver los otros casos es necesario definir acuerdos en el equipo de trabajo para usar trminos del domino y definir una granularidad apropiada y un estilo determinado. c) Desempoderamiento Funcional Nombre: DesempoderamientoFuncional (FunctionalDisempowerment) Nombre alterno: EmpoderamientoPerdido (LostEntitlements) Causas: Desorganizacin y falta de acuerdos para el modelado. Descripcin: Se presenta cuando un caso de uso que involucra dos o ms actores, inicia su flujo preguntando quien es el actor para definir que flujos o escenarios puede utilizar. En estas situaciones ninguno de los actores est verdaderamente empoderado del caso de uso. Factores que motivan su uso: La necesidad de que los casos de uso documenten todos los actores implicados, a la par que se factoriza el comportamiento en comn que estos realizan, aunque ello conlleve a artificiosas especificaciones de los casos de uso. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se debe dividir el caso de uso en dos para garantizar el empoderamiento de cada actor. Un ejemplo de esta situacin en una institucin educativa podra ser el caso de uso de Gestionar Oferta de Cursos relacionado con los actores Directivo y Docente, su flujo inicia preguntando si se trata de un Directivo para permitirle modificar o hacer cualquier otra accin sobre la oferta de curso, o si se trata de un Docente para permitirle solo revisar la oferta de cursos para hacer reservas de cupos o acciones por el estilo. En esta situacin se debe dividir en dos casos de uso, inclusive buscando un nombre ms apropiado para los procesos elementales de negocio implicados, un caso de uso llamado Revisar Oferta de Cursos relacionado con ambos actores, y otro caso de uso llamado Programar Oferta de Cursos que permite cualquier accin sobre la oferta de cursos al Directivo. La figura 5 ilustra un diagrama en el que se presenta este antipatrn y la forma en que se resuelve. 6

Factores que motivan su uso: Dejar en claro dentro de los diagramas todos los casos de uso que se relacionan con los actores, sin revisar las implicaciones de las relaciones de dependencia que existen entre estos. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben eliminar la relacin redundante. La figura 7 ilustra un diagrama en el que se presenta este antipatrn y la forma en que se resuelve.
Figura 5. DesempoderamientoFuncional y su solucin

5.4. CATEGORA 4: En las relaciones Esta categora se centra en los antipatrones que se presentan en la especificacin de relaciones entre los casos de uso, o entre estos y los actores. a) Relaciones Enmaraadas Nombre: RelacionesEnmaraadas (TangledRelationships) Nombre alterno: RelacionesDeTelaraa (SpiderwebRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripcin: Muchos actores que se relacionan al tiempo con muchos casos de uso en el mismo diagrama, generan una complicada red de relaciones que dificulta la comprensin del modelo. Factores que motivan su uso: La necesidad de que el modelo documente completamente las tareas que realizan todos los actores, sin considerar lo complicado que puede ser la comprensin del diagrama. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se debe buscar un supertipo en los actores para construir una jerarqua que simplifique las relaciones, inclusive se pueden soportar ligeras diferencias en las relaciones entre actores y casos de uso como se ilustra en la figura 6 con el actor C que es el nico que est relacionado con el caso de uso Z.

Figura 7. RelacionesRedundantes y su solucin

e) Relaciones Incorrectas Nombre: RelacionesIncorrectas (WrongRelationships) Nombre alterno: RelacionesErradas (MisusedRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripcin: Se presenta cuando la direccin o la semntica de las relaciones de inclusin o extensin son mal utilizadas, al igual que la generalizacin entre casos de uso. Factores que motivan su uso: La necesidad de dejar clara la relacin entre todos los casos de uso implicados, sin considerar la semntica de las relaciones. Ejemplo y/o posible solucin: Para resolver esta situacin, se debe revisar la semntica y la direccin de las relaciones de dependencia y generalizacin, esto evita modelar la navegacin de la interface de usuario o la secuencialidad de los casos de uso, como lo recomienda [10]. Para ejemplificar el buen uso de las relaciones entre casos de uso, la figura 8 ilustra una situacin en una institucin educativa que presenta las diferentes situaciones.

Figura 6. RelacionesEnmaraadas y su solucin

d) Relaciones Redundantes Nombre: RelacionesRedundantes (RedundantRelationships) Nombre alterno: RelacionesSobrantes (WastedRelationships) Causas: Desconocimiento y falta de acuerdos para el modelado. Descripcin: Se presenta cuando un caso de uso tiene relaciones de dependencia con otro, y al actor involucrado se le pone asociacin con ambos casos de uso. En estas situaciones solo es necesario que los actores estn relacionados con el caso de uso base.

Figura 8. Ejemplo de buen uso de relaciones entre casos de uso

En cuanto a la direccin de relaciones de dependencia de <<include>> y <<extend>>, es importante considerar que para la lectura del modelo, ambos verbos se asumen como si estuvieran conjugados en presente (incluye y extiende), por tanto la lectura y direccin queda de la siguiente forma:

En el caso de la inclusin (include): o El caso de uso base incluye el caso de uso incluido. o La direccin va desde el base hacia el incluido. 7

En el caso de la extensin (extend): o El caso de uso extensor extiende el caso de uso base. o La direccin va desde el extensor hacia el base.

En cuanto a la semntica de las relaciones entre casos de uso, la diferenciacin de las relaciones entre casos de uso est determinada por la comparacin de sus objetivos, a continuacin se describen las principales condiciones que estas deben cumplir:

En el caso de la inclusin (include): o Objetivo incluido es obligatorio o Objetivo base = Objetivo incluido + o Objetivo base Objetivo incluido es grande En el caso de la extensin (extend): o Objetivo extensor es opcional o Objetivo extensor = Objetivo base + o Objetivo base Objetivo extensor es pequeo En el caso de la herencia o generalizacin: o Objetivo heredado solo cambia la modalidad o Objetivo base = Objetivo heredado

Los trabajos futuros alrededor de este catlogo de antipatrones al especificar requisitos funcionales usando casos de uso, se pueden plantear en varios frentes: Complementar los antipatrones del catlogo para presentar otras malas prcticas experimentadas o propias de un dominio especfico. Encontrar y formalizar relaciones de causalidad entre los antipatrones en el anlisis de requisitos con otras malas prcticas o antipatrones en diferentes disciplinas del proceso como el modelado de negocio, el anlisis y diseo, o las pruebas. Integrar el catlogo de antipatrones en herramientas y nuevos enfoques de construccin de sistemas de informacin como el desarrollo de software dirigido por modelos [14], buscando por ejemplo que los antipatrones sean detectados automticamente en un modelo de casos de uso, y se le den recomendaciones al modelador para que corrija la situacin y mejore su modelos para disminuir la posibilidades de incurrir en errores. 7. REFERENCIAS
[1] The Standish Group International. CHAOS Manifesto 2011. [2] Steve, A. et al. 2003. Patterns for Effective Use Cases (The Agile Software Development Series). Addison-Wesley, Pearson Education, Boston, MA. [3] Booch, G.; Rumbaugh, J. & Jacobson I. 2000. El Proceso Unificado de Desarrollo de Software. 1ed. Addison Wesley, Madrid. [4] Larman, C. 2003. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. 2ed. Prentice Hall, Madrid. [5] Buschmann, F. et al. 1996. Pattern-Oriented Software Architecture: A System of Patterns. Wiley & Sons, England. [6] Gamma, E. et al. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Pearson Education. [7] Brown, W. et al. 1998. Antipatterns: Refactoring Software, Architectures and Project in Crisis. Wiley & Sons. [8] Welicki, L. 2006. Patrones y Antipatrones: una Introduccin. MSDN. Online [Abr. 2012]. [9] Cockburn, A. 2000. Writing effective use cases. 1ed. Addison-Wesley Professional. [10] Booch, G.; Rumbaugh, J. & Jacobson, I. 1999. El Lenguaje Unificado de Modelado. Addison Wesley, Madrid. [11] Lilly, S. 1999. Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases. In proceedings of TOOLS USA '99, IEEE Computer Society. [12] Ambler, S. 2010. Use Case Package Diagrams. Ambysof. Online [Abr. 2012]. [13] Kruger, S. et al. 2007. Engineering WS-I compliant web services for IBM Lotus Domino V8. IBM. Online [Abr. 2012]. [14] Vlter, M. & Stahl, T. 2006. Model-Driven Software Development (Technology, Engineering, Management). Wiley Software Patterns Series. [15] Pow-Sang, J. A. 2003. La Especificacin de Requisitos con Casos de Uso: Buenas y Malas Prcticas. Online [Abr. 2012]. [16] Kurt Bittner. 2001. Why Use Cases Are Not "Functions". Online [Abr. 2012]. [17] Giandin, R. & Pons, C. 2000. Relaciones entre Casos de Uso en el Unified Modeling Language. Online [Abr. 2012].

Cabe aclarar que en las relaciones de herencia, el caso de uso hijo puede adicionar nuevas operaciones, como tambin redefinir o enriquecer con nuevos escenarios, operaciones ya existentes en el caso de uso padre [17]. 6. CONCLUSIONES Y TRABAJOS FUTUROS Un buen anlisis de requisitos y particularmente un buen modelo de casos de uso, resulta fundamental para el xito de un proyecto de software, pues un modelo de requisitos con errores, acarrea desarrollos con errores. La facilidad para construir y comprender un diagrama de casos de uso, ha dado pie para que en algunos casos no se ponga especial atencin en la especificacin de requisitos usando casos de uso. En otros casos, los conocimientos del equipo de trabajo en reas como el desarrollo, los lenguajes de programacin y la tecnologa; en lugar de favorecer un buen modelo de casos de uso, juega en contra de ste al terminar incluyendo detalles propios del diseo o la implementacin. Las malas prcticas que se explicitan en estos antipatrones, han sido encontradas frecuentemente en diversos proyectos de desarrollo de software en los que participaron los autores, tanto en labores de consultora como de desarrollo. En dichos proyectos se inici la construccin del material que sirvi de base para la definicin de este catlogo de antipatrones al especificar requisitos funcionales usando casos de uso. Varias de las empresas para las que se realizaron estos proyectos, han realizado retroalimentacin con respecto a lo til que les resulta el material en el hallazgo de malas prcticas en requisitos, este es uno de los factores que nos hace pensar que el articulo le puede ser de utilidad a los lectores que trabajen en proyectos de desarrollo de software que especifiquen requisitos usando casos de uso. A pesar de contar con un compendio de material acerca de malas prcticas en especificacin de requisitos con casos de uso, formalizar estas experiencias para escribir este catlogo de antipatrones, resulta de gran utilidad para mejorar la compresibilidad del material. Las reflexiones para categorizar, buscar las causas y describir los antipatrones, mejoran las posibilidades de plantear ejemplos y esquemas de solucin que sean entendibles y fciles de aplicar.