Transicin de los requisitos para el diseo de por Paul Reed Presidente Jackson-Reed, Inc.

Uno de los mayores desafos que enfrenta proyectos de software es determinar cundo y Cmo iniciar la transicin de especificar a los requisitos de trabajo en un sistema diseo. Surgen preguntas como: Cundo voy hecho con los casos de uso? Tengo detalle todo el uso casos primero y luego saltar en el diseo? Qu requisitos debo afrontar por primera vez en diseo? La mayora de los miembros del equipo parecen darse cuenta de la beneficios de tomar una decisin correcta en as como la desventaja de hacer un uno correctos. Leap demasiado pronto, y la proyecto corre el riesgo de formular un diseo basado en chungo requisitos. Dar el salto demasiado tarde, y tomar ms riesgos al posponer alta decisiones de arquitectura de riesgo hasta ms tarde en el ciclo de vida del proyecto. Adems, en la preparacin de los artefactos para la transicin de los requisitos de diseo, se debe tener cuidado de no perder el contexto en el que fueron originalmente capturados (por ejemplo, quin tomaba las decisiones? Hubo relaciones nicas entre ciertos requisitos?). Este artculo establece las bases para una transicin suave de los requisitos especificacin de diseo, centrndose en aquellos artculos en que se presentan los ms problemas. En primer lugar voy a hablar de lo lejos que un equipo debe ir con los casos de uso antes de comenzar el diseo. En segundo lugar, voy a revisar un marco para identificar requisitos de gran importancia arquitectnica. Y, por ltimo, voy a explicar cmo utilizar realizaciones de casos de uso como el artefacto fundamental para superar la transicin de especificacin de requisitos de diseo. Cuando exposicin de riesgo es "algo bueno" Sabemos, en base a la historia, que el enfoque de cascada tradicional desarrollo de software no mitiga los riesgos ms importantes a principios de la ciclo de vida del proyecto. Esto se deriva del hecho de que las decisiones de alto riesgo, tales como la direccin arquitectnica del proyecto, no se ponen a prueba su validez hasta comienza la codificacin. Esto puede llevar a resultados desastrosos, muchos proyectos cascada http://www.therationaledge.com/content/jun_02/m_requirementsToDesign_pr.jsp Derechos de autor Rational Software 2002 Pgina 2 estn bien recortado o cancelado por completo despus significativa Se han hecho inversiones. El Rational Unified Process (RUP ) Se encuentra en contraste con este enfoque debido a dos caractersticas fundamentales: 1) RUP est basado en el riesgo; 2) RUP es

centrada en la arquitectura. RUP reta al equipo del proyecto, desde el principio, identificar requisitos que se exponen tanto los mayores riesgos potenciales y permitir a poner en marcha planes para mitigar esos riesgos. Los llamados requisitos de gran importancia arquitectnica se descubren normalmente durante la Fase inicial de las RUP y son objeto de anlisis y diseo de la primera iteracin de la fase de elaboracin. La exposicin de este riesgo es algo bueno para el proyecto, ya que exige que el equipo de formulacin de los planes de mitigacin lo ms pronto posible. El reto en avanzar es responder la pregunta ms importante: hasta qu punto la el equipo tiene que ir con los casos de uso antes de dar ese salto inicial en el diseo? Qu pasa con los actores y uso Casos? Los proyectos han luchado por aos para concebir la mejor mtodo para obtener, documentar y rastrear requisitos funcionales. Los enfoques van desde mini especificaciones - una narracin texto de la requisitos en forma de prrafo - a los diagramas que mostrar el flujo de cada requisito de control. Racional de Ivar Jacobson fue pionera en el concepto de uso casos mientras se trabaja en telecomunicaciones complejas proyectos en Ericsson. El enfoque de casos de uso se centra primero en la identificacin de los actores y usuarios de la aplicacin. Los actores suelen adoptar una de cuatro formas: los seres humanos, otros sistemas, dispositivos de hardware, o temporizadores. Ellos tienen un objetivo que debe ser satisfecho por el sistema, y que se basan en el caso de uso a lograr eso. Los casos de uso representan las principales categoras de funcionalidad tal como se percibe por el usuario de la aplicacin; es el caso de uso que proporciona en ltima instancia valor medible para el Actor. Diagramas de caso de uso se complementan con una plantilla de casos de uso para cada de casos de uso. La figura 1 muestra un caso de uso con los actores. Una milla de ancho y cinco Pulgadas de profundidad Antes de que el proyecto puede identificar uso arquitectnicamente significativos casos (ver recuadro), se debe profundizar en los requisitos suficiente para hacer inteligente decisiones sobre donde el mayor riesgo reside. La clave para el nivel de detalle para proporcionar se encuentra en el mantra, "una milla de ancho y cinco centmetros de profundidad ". En la fase inicial de un proyecto, mi escritura estndar cuando se trata de proyectos

equipos es tenerlos realizar las siguientes tareas: 1. Identificar el proyecto interesados y clave caractersticas del producto para el sistema en discusin (Vision artefacto de RUP). 2. Lluvia de ideas una lista de eventos mediante la identificacin de la primera actores (los seres humanos, otros sistemas, hardware dispositivos y temporizadores) y qu acontecimientos estimular el sistema con. 3. Lluvia de ideas que utilizan casos satisfacen los Pgina 3 Figura 1: Diagrama de la Place Order Uso Caso Quieres ms informacin sobre los actores y casos de uso? Pruebe las siguientes fuentes: Web http://www.rational.com/uml/index.jsp http://www.usecases.org/ http://www.therationaledge.com/admin/archives.jsp (Bsqueda de casos de uso) Libros Alistair Cockburn, escribiendo casos de uso efectivo. Addison-Wesley, 2001. Daryl Kulak y Eamonn Guiney, casos de uso: Requisitos en su contexto. Addison-Wesley, 2000. acontecimientos. 4. Para cada caso de uso, completar un caso de uso plantilla que en una mnimo identificar las vas principales. Estas vas pueden ser dividido en categoras: ms comn o feliz trayectoria, variaciones a la camino feliz, y caminos de excepcin. 5. El tiempo lo permite, detalle los pasos de la feliz ruta para cada caso de uso,

o como mnimo la camino feliz para el uso central de proyecto casos. 6. Identificar los requisitos que representan la mayor cantidad de riesgo. Estas tareas se pueden realizar de forma iterativa, montar en bicicleta a travs de ellos como paquetes de casos de uso relacionados con los proyectos ms grandes si es necesario. En este punto en el proyecto, el equipo ha recorrido una milla de ancho a travs de la toda la amplitud del proyecto, pero slo cinco centmetros en sus profundidades. Usted no se puede decir en este punto que se conocen todos los requisitos funcionales. Sin embargo, usted sabe lo suficiente sobre el proyecto para identificar a los requisitos que expondrn la mayor cantidad de riesgo arquitectnico. Requisitos de gran importancia arquitectnica Cuando se trabaja con los equipos de proyecto, que se centran en las reas de cobertura que son arquitectnicamente significativa (es decir, que llevan a un alto riesgo; vase la Tabla 1). Tabla 1: reas de cobertura de gran importancia arquitectnica rea de cobertura Factores de riesgo 1. La nueva tecnologa o marcos no trabajan actualmente en otro proyectos dentro de la organizacin Identifica las reas en las que el organizacin an no es experto en utilizando una nueva tecnologa. Pgina 4 2. Negocio nuevo o revisado procesos que el cliente es a travs de la introduccin de las nuevas tecnologas Expone las expectativas del cliente pueden tener sobre los flujos de trabajo que tienen no se ha probado en un nuevo la tecnologa. Por ejemplo, si una rama banco est cambiando sus datos de la cuenta los procesos de introduccin y recuperacin a un cliente ligero, aplicacin basada en Web, a continuacin, que la aplicacin podra no ser casi tan flexible como antes, en el cliente solucin centrada cuando se trata de flujo de trabajo y la interfaz de usuario posibilidades. 3. Tiempo de procesamiento basado Hay muy pocos robusta, off-theproductos del almacn que facilitan tiempoprocesamiento de eventos basado. Muchos aplicaciones requieren ya sea un solucin personalizada o

combinacin de pre-comprado componentes y cdigo personalizado. 4. Procesamiento por lotes No creo que el mito de que los lotes tareas orientadas han desaparecido con la tecnologa de generacin ms reciente opciones. Esto es simplemente errnea; el procesamiento por lotes puede ser una delicada parte de la arquitectura. Compartiendo lgica de negocio entre lote y Internet puede ser una proposicin difcil. 5. Interacciones mltiples paneles que requieren gestin estatal en todo el proceso (gestin de flujo de trabajo) Esto se dirige principalmente a la Web soluciones basadas, ya los aptridas naturaleza de la Web. La manera en la que proveedores de software de gestin de estado cuando se trata de varias pginas interacciones rangos en complejidad y afecta a la disponibilidad. 6. Seguridad, registro y archivo demandas Teniendo en cuenta el deseo de la mayora de los clientes de inicio de sesin nico (SSO) y la integracin de la capacidad de seguridad y archivado con soluciones pre-comprados, esto zona solo puede consumir tremenda cantidades de esfuerzo para integrarse en la solucin global. 7. Gestin Persistencia Si la solucin se basa en tcnicas orientadas a objetos, y luego debe tenerse cuidado a la impedancia desajuste hacer el mapa objetos a los almacenes relacionales. Pgina 5 8. La calidad del servicio El rendimiento es siempre una consideracin. Aunque la actual volumen de pruebas puede no ser factible en las primeras etapas de la elaboracin, herramientas de simulacin se pueden aplicar a proporcionar aproximacin significativa de los rendimiento potencial. Tenga en cuenta que los casos de uso deben ser evaluados por su capacidad para ejercer una o ms de las reas de cobertura indicados en la Tabla 1. Con demasiada frecuencia,

primer paso en falso de un proyecto es la identificacin de los requisitos que son fciles de poner en prctica, pero tienen un impacto relativamente pequeo en la disminucin de la arquitectura riesgo. Las vas de casos de uso, frente a todo el caso de uso, deben ser el foco de la bsqueda de los requisitos de gran importancia arquitectnica. Estos deben estar procedentes de todo el conjunto de casos de uso. En la primera iteracin de la Fase de elaboracin, trato de evitar un nmero excesivo de CRUD (Create, Read, Update, Delete) caminos. Aunque esto puede ser bueno para los ajustes las reas de cobertura, hacer demasiados de ellos puede ser una forma de evitar otras reas ms importantes. La iteracin ms importante que tendr que Emprender Sin lugar a dudas, la primera iteracin en la fase de elaboracin es el ms importante iteracin del proyecto ser siempre realizar (vase la Figura 1 y RUP recuadro). Las entradas para la entrega de esta versin, la arquitectura Prototype, son los requisitos de gran importancia arquitectnica seleccionada en el final de la fase de inicio. Pgina 6 Figura 2: Fases e iteraciones del RUP Es tambin durante la primera iteracin de elaboracin que el equipo explora vas de casos de uso arquitectnicamente significativos en profundidad. Todos los negocios reglas y dependencias estn completamente plasmen. Esto no slo aade conocimiento ms funcional para el proyecto, pero tambin ms pruebas del solidez de la arquitectura. Una vez que la fase de elaboracin se ha completado, no debe haber absolutamente ninguna decisiones de arquitectura ms difciles de hacer. El resto de vas de casos de uso deben ser recogidos y detallados en iteraciones posteriores durante Elaboracin, Construccin, e incluso Transicin. El Rational Unified Process (RUP) Como muestra la Figura 2 representa, RUP consta de cuatro fases y nueve disciplinas o flujos de trabajo. Una iteracin es un proyecto vertical que corta a travs de los nueve flujos de trabajo, basndose en las actividades que se ofrecen en cada flujo de trabajo. Cada iteracin generalmente incorpora elementos de todas las nueve disciplinas. El conjunto resultante de tareas comprende lo que se conoce como la iteracin plan. Una fase dada puede tener mltiples iteraciones, y el nmero es por lo general un factor de la tcnica complejidad y el tamao del proyecto. Iteracin Muestra planes para cada una de las cuatro fases se proporcionan con el producto RUP. El final de cada fase se caracteriza por la terminacin de un hito. Los hitos de las cuatro fases de las RUP son: Ciclo de vida objetivo, del ciclo de vida Arquitectura, capacidad operativa inicial, y

Lanzamiento del producto. A diferencia de los modelos de procesos basados en la cascada, el RUP de iterativo modelo reconoce que las actividades de el amplio espectro de flujos de trabajo (es decir, requisitos, diseo) en realidad tienen lugar al mismo tiempo en todo el ciclo de vida del proyecto. Obtenga ms informacin sobre el RUP de estas fuentes: Web: http://www.rational.com/products/rup/index.jsp http://www.therationaledge.com/admin/archives.jsp (Bsqueda de RUP) Libros: Philippe Kruchten, The Rational Unified Process: Una Introduccin, 2 edicin. Addison-Wesley, 2000. Use-Case Realizaciones: Los Puente entre Requisitos y Diseo Una parte clave de suavizar la transicin de los requisitos el diseo es tener un artefacto que vincula directamente los dos flujos de trabajo juntos. La equipo del proyecto utiliza el usocaso de realizacin como su artefacto de transicin. Este Actividad de diseo se lleva a cabo inicialmente en la primera iteracin de la fase de elaboracin. Una realizacin de casos de uso es una Diseo Vista de un caso de uso. Inicialmente, slo el caso de uso identifica "lo que" el usuario quiere. El caso de uso realizacin es la transicin elemento que especifica "cmo" el caso de uso ser implementado. Sin embargo, la de casos de uso realizacin es en realidad un artefacto compuesto, contiene otro diseo modelos para representar el realizacin real. El ms modelos comnmente utilizados contenida dentro de la realizacin es el UML secuencia y / o colaboracin

diagramas. El proyecto puede representar grficamente la realizacin de casos de uso con Rational Rose (Vase la Figura 3). Una relacin de dependencia estereotipada es Page 7 creada entre el caso de uso del Caso de Uso View y un caso de uso creada en la vista lgica estereotipada como una realizacin. Haga Click para agrandar Figura 3: Realizacin de casos de uso en Rational Rose El empate de nuevo al caso de uso real no es slo para las miradas. Recuerde que una caso de uso en el caso de uso Ver contiene vas. Estas vas son articulada como una secuencia de pasos con una mirada de reglas de negocio que hacer cumplir la estructura de la va, con lo expuesto en trminos del usuario. Es estos pasos que ahora modelo en Diseo como una coleccin de objetos mensajera de uno con el otro para satisfacer el objetivo de que el actor (s). Este mensajera se modela con una de dos diagramas de interaccin: Secuencia o Colaboracin. (Nota: Me parece que en la prctica los proyectos prefieren ya sea la Diagrama de secuencia o el esquema de colaboracin y no suelen mezclar los dos.) La vista de rbol en la Figura 4 se muestra la explosin de los diagramas de secuencia dentro de cada caso de uso realizacin. Un diagrama de interaccin se crea para cada va clave a travs de los casos de uso. Inicialmente, durante la primera Elaboracin de iteracin, esto significa que slo las vas que se seleccionan por su capacidad para eliminar las zonas de los proyectos de alto riesgo. Pgina 8 Haga Click para agrandar Figura 4: Diagramas de secuencia dentro de las Realizaciones de casos de uso (como se ve en el rbol Ver) Realizaciones de casos de uso: Cuando uno no es suficiente En los ltimos proyectos que he estado involucrado con, exista la necesidad de tener ms de un caso de uso por la realizacin de casos de uso en el caso de uso Ver. Esto suele indicar que el caso de uso requiere de una tecnologa multisolucin. Por ejemplo, para el caso de uso de orden del lugar, es posible que tenga un requisito adicional no funcionales que las rdenes se pueden colocar en lnea a travs de la Web o a travs de una interfaz inalmbrica para PDAs y similares. En este caso, sera apropiado tener un caso de uso para la realizacin Aplicacin Web y uno para la aplicacin inalmbrica (vase la figura 5). Pgina 9 Haga Click para agrandar Figura 5: Dos variantes del caso de uso Misma La razn de tener dos realizaciones es que, tcnicamente, el

soluciones son bastante diferentes. En el caso de la solucin Web, suponiendo que estn utilizando Java, habr clases Servlet ms cualquier nmero de apoyo clases que no se utilizarn para nada para la solucin inalmbrica. Sin embargo, en el mismo tiempo que puede aprovechar la mensajera que es comn entre la dos soluciones tcnicas diferentes. Seamos realistas: Cuando todo est dicho y hecho, los mensajes que se produce entre las clases de entidad (es decir, Orden, Cliente) para conseguir realmente el orden en el sistema y para hacer cumplir la reglas comerciales que rigen ese proceso son idnticos para los dos enfoques. En este caso, los diagramas de interaccin en la Plaza realizacin de pedidos Web y los diagramas de interaccin en la Plaza realizacin de pedidos Wireless hara ambos apuntan a un diagrama de interaccin comn que se ocupa de la comn mensajera de clase de entidad. Es la realizacin de casos de uso que proporciona el contexto en la transicin de los requisitos de diseo. Haba un asistente seminario vez preguntar si no era peligroso tener realizaciones vinculadas directamente a la forma en la requisitos fueron estructurados. Mi respuesta fue que no poda haber nada ms natural. As como el pensamiento orientado a objetos nos trajo la concepto de entidades del mundo real que representan tanto a la estructura y el comportamiento, as que las realizaciones de casos de uso representan la transicin natural, del mundo real para la vista de diseo del caso de uso. Birds of a Feather En los enfoques de ciclo de vida del pasado, haba un aura de misterio que rodea la transicin de las actividades de recopilacin de requisitos para las actividades de diseo. Requisitos se describen generalmente en los prrafos dentro de un texto formato, y los documentos de diseo visual fueron completamente imposible de rastrear a esos requisitos. Este proceso de grabacin de los requisitos estticos y luego traducirlos en artefactos de diseo promueve la prdida de contexto y menudo oscurecida intenciones originales del usuario para el sistema. Por el contrario, un proceso iterativo como RUP permite seleccionar los requisitos desde el principio que exponga los altos riesgos cualquier proyecto de desarrollo de software conlleva. El caso de uso realizacin proporciona una palabra real Diseo Vista de los requisitos superficiales capturados durante el Inicio. Orientacin de los casos de uso vas que exponen el proyecto a un mayor riesgo durante la primera iteracin Elaboracin mejora en gran medida las posibilidades del equipo para el xito iteraciones futuras. No se conforme con los artefactos que no se transfieran bien a travs de las fases del proyecto. Cada artefacto debe ser trazable, hacia adelante y hacia atrs a travs de la vida del proyecto. La transicin de los requisitos de diseo no debe ser un misterioso o un acontecimiento milagroso. Debe ser un proceso natural que es fcil de explicar y fcil de entender por todos los miembros del equipo del proyecto. Pgina 10 Referencias Philippe Kruchten, The Rational Unified Process: An Introduction, segundo Edition. Addison-Wesley, 2000. Paul R. Reed, Jr., "Anlisis Orientado a Objetos y Diseo usando UML." Material del Seminario, 1993-2002.

Paul R. Reed, Jr., Desarrollo de Aplicaciones con Java y UML. AddisonWesley, 2002. Notas 1 Ivar Jacobson, Ingeniera de Software Orientada a Objetos, Addison-Wesley, 1992. Para obtener ms informacin sobre los productos o servicios mencionados en este artculo, por favor haga click aqu y siga las instrucciones proporcionada