ICONIX

El proceso de ICONIX maneja casos de uso, como el RUP, pero le falta mucho para llegar al nivel del RUP. También es relativamente pequeño y firme, como XP, pero no desecha el análisis y diseño que hace XP. Este proceso también hace uso aerodinámico del UML mientras guarda un enfoque afilado en el seguimiento de requisitos. Y, el proceso se queda igual a la visión original de Jacobson del ”manejo de casos de uso”, esto produce un resultado concreto, específico y casos de uso facilmente entendible, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real.

La Figura 1 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales básicos.

Cuadro para manejar Casos de Uso en el modelamiento de Objetos

Nos gustaría señalar tres rasgos significantes de este enfoque.

Primero, es reiterativo e incremental. Las iteraciones múltiples ocurren entre el desarrollo del modelo del dominio e identificar y analizar los casos de uso. Otras iteraciones existen tambien, como los procesos del equipo a través del ciclo de vida. El modelo estático se refina incrementalmente durante las iteraciones sucesivas a través del modelo dinámico (compuesto del casos de uso, análisis de robustez y el diagrama de secuencia). Note sin embargo, que el acercamiento no requiere hitos formales y la teneduría de muchos libros; más bien, los esfuerzos de refinamiento producen los hitos naturales como el equipo del proyecto que gana conocimiento y experiencia.

Segundo, el enfoque ofrece un alto grado de seguimiento. Por el camino, a cada paso usted consultara de alguna manera los requisitos anteriores. Nunca hay un punto en que el proceso le permita desviarse lejos de las necesidades del usuario. Seguimiento se refiere tambien al hecho que usted puede seguir los objetos paso a paso como el analisis dentro del diseño.

Tercero, el enfoque ofrece uso aerodinámico del UML. Los pasos que nosotros describiremos en los siguientes temas representan un minimo del acercamiento, ellos comprenden el juego mínimo de pasos que nosotros hemos encontrado para ser necesarios y suficiente en el desarrollo de un proyecto Orientado a Objetos exitoso. Enfocando en un subconjunto del grande y pesado UML, un equipo del proyecto también puede dirigirse fuera de "la parálisis del análisis ".

Las Capacidades de Iconix

La solución de Iconix incluye un ancho rango de ofrecimientos de servicios de negocios. Las soluciones de negocios de extremo a extremo se concentran en los servicios en tres áreas primarias, con la estrategia y planeacion recubriendo cada área. La especialización equilibrada en las tres áreas (la experiencia del usuario, funcionalidad comercial, e infraestructura) contribuye al éxito de las soluciones que se entrega a los clientes.

El Dominio del Problema

El modelo del dominio es una parte esencial del proceso de ICONIX.

Construye la porción estática inicial de un modelo que es esencial al manejar su plan de la aplicación, antes de los casos del uso.

El enfoque de este tema es el modelo del dominio. El término "dominio del problema" se refiere al área que abarca cosas del mundo real y conceptos relacionados al problema que el sistema está diseñándose para resolver. El modelo del dominio es la tarea de descubrir " los objetos " (las clases) estos representan cosas y conceptos.

Dentro del proceso de ICONIX, el modelo de dominio activado involucra, fuera de los requisitos de los datos, construir un modelo estático del dominio del problema pertinente al sistema propuesto.

Figura 1. El Cuadro para manejar Casos de Uso en el modelamiento de Objetos

La Figura 1 ilustra donde el modelo del dominio reside dentro del cuadro para el proceso de ICONIX.

Los Elementos importantes del modelo del Dominio

La primera cosa que usted debe hacer cuando este construyendo un modelo estático de su sistema es el hallazgo de clases apropiadas que con precisión representan las abstracciones reales de los problemas que se presentan en el modelo del dominio. Si usted ejecuta bien esta actividad, usted no sólo tendrá una construccion sólida para construir el sistema, sino también las excelentes perspectivas para reutilizacion de sistemas que se diseñarán y se construirán con el tiempo.

Es probable que los mejores recursos de clases sean la declaración del problema de alto nivel, los niveles bajos de requisitos y conocimientos del experto sobre el espacio del problema. Para empezar, ponga las todas las declaraciones pertinentes de estas áreas (e incluso otros) como pueda encontrar, y entonces señalas o resaltas, todos los sustantivos de la frase. Refine las listas gradualmente, los sustantivos de la frases se volverán objetos y atributos, mientras los verbos se volverán funcionamientos y asociaciones. Los posesivo (" su," nuestro " y " suyo ") tiende a indicar que los sustantivos deben ser los atributos, en lugar de los objetos.

Luego, seleccione de su lista de clases de candidato y elimine los artículos innecesarios. Busque las clases que son redundantes, no pertinentes, incorrectas o vagas. Las clases no esenciales también pueden representar los conceptos fuera del alcance del modelo, o representa las acciones aunque ellos se expresan como los nombres.

También se debe tomar algunas decisiones de la inicial sobre la generalización (el " tipo de " o " es un " relacion entre las clases) mientras construye su diagrama de clases. Si se necesita, y es mas cómodos para esta fase, generalice a más de un nivel de subclase. Recuerde buscar tipo de declaraciones que son verdad en el mundo real. El modelamiento del dominio también es el área apropiada para las decisiones sobre las agregaciones ("parte de" o " tiene " relaciones entre clases).

Finalmente, tal como muchos diagramas de relación de entidad (ERD), su modelo del dominio, pone al día para mostrar las asociaciones (las relaciones estáticas entre los pares de clases) debe ser una verdadera declaración sobre el espacio del problema, independiente del tiempo (es decir, estática). Este modelo sirve como la construccion de su modelo de la clase estático.

Los 10 Errores mas comunes del Modelado del Dominio

10. No asigne las multiplicidades inmediatamente a las asociaciones. Asegúrese que cada asociación tiene una multiplicidad explícita. Algunas asociaciones en un diagrama de clase representan relaciones uno a uno, mientras otros representan relaciones uno a muchos. Éstos son las dos llamadas multiplicidades. Sin embargo, usted puede evitar el trato total con la multiplicidad, durante el modelo del dominio, a tiempo y puede ser una causa mayor de parálisis del análisis que nosotros señalaremos con este símbolo.

9. No haga un exhaustivo análisis del nombre y del verbo. Kurt Derr está Aplicando OMT (SIGS Books, 1995) es una fuente buena de información sobre " la inspección gramatical ". Si se sigue el consejo de Derr a la letra, se alcanzará un nivel extremo de detalle, por tanto un nivel bajo de abstracción. Use esta técnica para conseguir su descubrimiento del objeto, pero cuidado no llevarlo lejos.

8. No asigne los funcionamientos a las clases sin explorar los casos de uso y los diagramas de secuencia. Haga un aseguimiento minimo al definir los funcionamientos durante el modelo del dominio. De hecho, no asigne ningún funcionamiento a las clases durante el modelo del dominio, porque no hay bastante información disponible como para tomar las buenas deciciones sobre los funcionamientos del plan en esta fase. Espere hasta que empiece el modelo de la interacción, antes de que usted asigne los funcionamientos de las clases.

7. No perfeccione su código para la reutilizacion antes de asegurarse que se ha satisfecho los requisitos del usuario. Sobre todo sus objetos y clases, para hacer más alta la probabilidad que usted podrá reusar esos objetos y clases para otros proyectos. Una clase completa es una que es teóricamente reusable en cualquier número de contextos. Sin embargo para lograr esta reutilizacion e integridad, usted debe considerar atributos y funcionamientos, y solo se dijo por qué usted no debe estar asignando los funcionamientos a las clases durante el modelo del dominio. Así no se preocupa demasiado por hacer las clases reusable cuando usted está haciendo los diagramas de la clase de alto nivel.

6. No dude en usar agregación o composición para cada una de las partes de las asociaciones. Las descripciones originales de Grady Booch de "Tener por Referencia” se relaciona con la agregación dentro de UML. Semejantemente, " tiene por el valor " se volvió una " forma fuerte " de agregación llamada " composición " dentro de una " parte de la clase " que pertenecea " una clase más grande”. Intentando diferenciar entre estos dos durante el esfuerzo del modelado del dominio es una manera definida de hacer alguna captura seria. Se prefiere enfocar en la agregación simple durante el modelado del dominio. La agregación contra la composición es un problema del diseño detallado.

5. No presuma una estrategia de aplicación específica sin modelar el espacio del problema. Como la parte del refinamiento continuado de su modelo del dominio, debe quitar algo que aclare los estados de una acción en lugar de una dependencia o algo que se relacione específicamente a la aplicación. No introduzca los objetos en sus diagramas de la clase de alto nivel que representan los compromisos a las tecnologías específicas, si es una base de datos correlativo o un tipo particular de servidor.

4. No use nombres dificiles de entender para sus clases, como el PortMang, en lugar de intuitivamente obvio, PortfolioManager. Al hacer el modelado del dominio primero, ayuda a todos en el equipo del proyecto a estar de acuerdo como debe llamarse la clase. El nombre más obvio de la clase, el más fácil sera la tarea que realizara. Ahorre las siglas y otros tipos de abreviaciones para la aplicación.

3. No salte directamente a las construcciones de aplicaciónes como las relaciones amigas y clases con parametros. UML ofrece muchas oportunidades de agregar lo que nosotros llamamos "Materia de Booch" para clasificar los diagramas. Esto incluye estructuras que vienen más o menos directamente de C++, tal como clases abstractas y parametrizadas y relaciones amigas. Éstos son más pertinentes al espacio de la solución que al espacio del problema, sin embargo, el enfoque modelado del dominio debe ser definitivamente el espacio del problema.

2. No crear un trazo correlativa uno-para-uno entre el dominio de clases y las tablas de la base de datos. Si usted rediseña un sistema legado que usa un banco de datos correlativo, es probable que las tablas dentro de ese banco de datos sean una fuente excelente de clases del dominio. Las tablas correlativas pueden tener muchos atributos que no podrían pertenecer juntos en el contexto de un modelo del objeto. Usted debe usar la agregación para factorizar grupos de atributos en " clases de ayuda" que contienen los atributos y funcionamientos que son pertinente a las clases más significantes.

1. No realice un " diseño prematuro " que involucre la construcion de las soluciones nuevas de modelos que tienen pequeña o ninguna conexión a los problemas del usuario. Los modelos a menudo son visibles durante el análisis de robustez. Los modelos del plan pueden ser muy útiles en el contexto de diagramas de secuencia y los diagramas de clase en el nivel de diseño. Sin embargo, en el modelado del dominio no es tiempo para empezar a pensar a lo que se refiere a los modelos.

Figure 2. UN Diagrama de Clase Defectuoso

Este diagrama de clase viola el tercero, quinto, sexto, octavo y novena regla de nuestra lista de errores

• La clase cBinaryTree es una clase parametrizada (también conocido como una clase plantilla dentro de UML). Esto viola la regla número tres. No hay ninguna razón para definir una estructura de aplicación como un árbol binario en esta fase del modelo.

• El nombre de la clase cSessionBeanShpngCrt indica que el modelador ha decidido representar el concepto de carrito usando una sesión de la Empresa Java Bean(EJB). Esto viola la regla número cinco.

• Esta clase también tiene una relación de la composición con la clase Order. Esto viola la regla número seis. El modelador ha comprometido la idea que una orden desaparece cuando el objeto del carrito a que pertenece se destruye. Esto puede o no tener sentido a la larga, pero es ciertamente demasiado pronto para estar pensando a lo largo de esas líneas.

• La clase del cLoginMgr se opera nombrando el verifyPassword. Esto viola la regla número ocho. Es demasiado temprano para tomar decisiones sobre que los funcionamientos hacen en que las clases, y además, las oportunidades sin embargo son buenas por que el funcionamiento pertenece a la clase Login Info. Los nombres de las dos clases que nosotros discutimos deben ser Shopping Cart y Login Manager. Ambos nombres violan la regla número cuatro.

Figura 3. Un Diagrama de Clase Corregido

Aquí se corrigen las violaciones de la regla encontradas en Figura 2.

Casos de uso

" manejando casos de Uso " primero la escritura del manual del usuario, despues escribir el código . Esta práctica refuerza la noción fundamental que un sistema debe conformar a las necesidades de los usuarios, en lugar de sus usuarios que conforman al sistema.

Dentro del proceso de ICONIX, uno de los primeros pasos involucra la construcciondel modelo de casos de uso. Este modelo se usa para capturar los requisitos del usuario de un nuevo sistema (si está desarrollándose desde el principio o basado en un sistema existente) detallando todos los guiones que los usuarios realizarán. Los casos del uso manejan al modelo dinámico y, por la extensión, el esfuerzo del desarrollo entero.

Figure 1. El Cuadro para manejar Casos de Uso en el modelamiento de Objetos

El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente.

Figure 1 muestras dónde usan el caso modelado que reside dentro del cuadro del proceso de ICONIX.

Los Elementos Importantes

La tarea de construir casos de uso para su nuevo sistema esta basado en identificar inmediatamente tantos casos como se puede, y estableciendo una vuelta continua de escribir y refinar el texto que los describe entonces. Por el camino, usted descubrirá los nuevos casos del uso, y también se factorizara los casos de uso que sean combenientes.

Usted debe tener presente en un principio de no atropellar durante su esfuerzo al identificar los casos del uso: Estos deben tener las correlaciones fuertes con material encontrado en el manual del usuario del sistema. La conexión entre cada caso del uso y una sección distinta de su guía del usuario debe ser obvia. Refuerza la noción fundamental que usted está diseñando un sistema que conformará los puntos de vista de los usuarios. También proporciona un resumen conveniente de los medios del manejo de los caso de uso ": Escriba el manual del usuario, luego escriba el código. Si esta rediseñando un sistema legado, usted simplemente puede regresar a trabajar el manual del usuario.

Una vez tenga algún documento para un caso del uso, es tiempo de refinarlo asegurándose las frases esten claras y discreto, el formato básico de su texto es sustantivo-verbo- sustantivo, y los actores y los objetos del dominio potenciales son fáciles de identificar. También debe poner al día a su modelo del dominio como vaya descubriendo los nuevos objetos y extiender la comprensión de los objetos que creo previamente. Y, es importante determinar todo los posibles cursos alternados de acción donde se requiera para cada caso de uso posible, una actividad que debe asumir la mayoría del tiempo.

Se puede usar varios mecanismos para factorizar fuera del uso común, tal como el manejo de errores, fijados en los casos de uso. Esto es normalmente eficaz, porque eliminandose el uso de los pequeños niveles aliviarán el esfuerzo del análisis y no requiere de mucho tiempo al dibujar los diagramas de secuencia. Si usted usa la generalización de UML y las relaciones include y extends, o relaciones OML invokes y precedes, su meta debe ser fijar casos de uso pequeños, precisos, reusables.

Usted debe sentir el procedimiento ideal a las próximas fases del desarrollo que av ha procesar cuando usted haya logrado las metas siguientes:

• Haber construido casos del uso que juntos respondan de toda la funcionalidad deseada del sistema.

• Haber producido las descripciones escritas claras y concisas del curso básico de la acción, junto con los cursos alternativos apropiados de la acción, para cada caso de uso.

• Haber factorizado fuera de los guiones en común a más de un caso de uso, mientras estructura lo que le sea mas comodo.

La Cima 10 Caso del Uso los Errores Modelados

10. No escribir los requisitos funcionales en lugar del texto de guión de uso. Generalmente se declaran los requisitos de acuerdo a lo que el sistema hará, mientras los guiones del uso describen las acciones que los usuarios toman y las contestaciones que el sistema genera. En el futuro, nuestro texto del caso de uso se usará como un run-time para la especificación conductual del guión que describiremos, y este texto se establecera en el margen izquierdo de un diagrama de secuencia. Queremos poder ver fácilmente cómo el sistema (mostrado con los objetos y mensajes) implementa la conducta deseada, como esta descrito en el texto del caso de uso. Así que, necesitamos distinguir claramente entre las descripciones del uso (la conducta) y requisitos del sistema.

9. No describa atributos y métodos en lugar del caso de uso. Su texto del caso de uso no debe incluir demasiados presentación detalla, pero también debe estar relativamente libre de los detalles sobre los campos en sus pantallas. No deben nombrarse los métodos o describirlos en el texto del caso de uso porque ellos representan cómo el sistema hará las cosas.

8. No escriba el caso de uso demasiado conciso. Cuando escriba el texto para los casos de uso, extensivo es preferible. Usted necesita dirigir todos los detalles de las acciones del usuario y contestaciones del sistema, luego se pasara al análisis de robustez y diseño de la interacción, en el podra poner algunos de esos detalles en sus casos de uso. También recuerde que su caso de uso elaborado servirá como la creacion para su manual del usuario. Es bueno errar en el lado de demasiado detalle cuando viene la documentación del usuario.

7. No se le separe completamente de la interfaz del usuario. Uno de las nociones fundamentales de el manejo del caso de uso es que el equipo de desarrollo conforma el plan del sistema desde el punto de vista de los usuarios. Usted no puede hacer esto sin estar específicadas acerca de qué acciones los usuarios realizará en sus pantallas.. Usted necesita discutir esos rasgos de la interfaz del usuario que le permite al usuario decir al sistema que haga algo.

6. No evite los sustantivos explícitos para sus objetos del límite. Los sustantivoso del límite son los objetos con el cual los actores actuarán recíprocamente. Éstos frecuentemente incluyen ventanas, pantallas, diálogos y menús. Siguiendo nuestro tema de incluir el amplio detalle y siendo explícito sobre la navegación del usuario, Es necesario nombrar explícitamen un objeto Limite en el texto del caso de uso. También es importante hacer esto porque usted explorará la conducta de estos objetos durante el análisis de robustez y puede reducir sólo ambigüedad y confusión para nombrarlos temprano.

5. No escriba en la voz pasiva , mientras este usando una perspectiva diferente al del usuario. un caso de uso es más eficaz cuando es escrito en la perspectiva del usuario como un conjunto de frases de verbos en tiempo presente en la voz activa. La tendencia de los ingenieros es usar la voz pasiva cuando este bien establecido, pero los casos de uso deben declarar las acciones que el usuario realiza, y las contestaciones del sistema a esas acciones. Este tipo de texto sólo es eficaz cuando se expresa en la voz activa.

4. No describa sólo interacciones del usuario; ignore las respuestas del sistema. La descripcion de un caso de uso debe estar orientado a la respuesta del evento, como " El sistema hace esto cuando el usuario aquello ". El caso de uso debe capturar un trato bueno de lo que pasa en la respuesta de lo que el actor está haciendo, si el sistema crea los nuevos objetos, valida al usuario ingresado, genera los mensajes del error o cualquier cosa. Recuerde que su texto del caso de uso describe ambos lados del diálogo entre el usuario y el sistema.

3. No omita el texto para los caminos alternativos de acción. Los caminos básicos de acción son generalmente más fáciles de identificar y escribir para el texto. Esto no significa, sin embargo, que usted debe aplazar tratando con los caminos alternativos hasta llegar al modelo detallado. De hecho, según la experiencia cuando los caminos alternativos importantes de acción no son descubiertos hasta codificar y poner a punto, el programador responsable tiende a escribir o arreglar el código para tratarlos de la manera mas conveniente para él. Esto no es saludable para un proyecto.

2. No enfoque de otra manera algo que está dentro de un caso de uso, tal cómo se ha llegado allí o lo que pasa después. Varios autores como Alistair Cockburn y Larry Constantine, defienden el uso extenso, complicando el uso de las plantillas de caso de uso. Los espacios para las precondiciones y postcondiciones están generalmente presentes en estas plantillas. No se debe insistir en usar mucho tiempo las plantillas complejas de casos de uso sólo porque estos aparecen en un libro o artículo.

1. No se debe desperdiciar mas de un mes en decidir si se va ha usar include o extends. Si usted usa UML incluye su estructura, u OML los mecanismos invoke and precede , o algo que le sea mas comodo; simplemente escoja una manera de hacer las cosas y sigua con ella. Tener dos estructuras que son similares es peor que tener una. Simplemente es mas fácil confundirse cuando usted intenta usar ambos.

Figure 2. Muestra el texto del caso de uso que contiene cinco violaciones de las 10 reglas.

1. camino básico: el cliente entra la información requerida. el sistema valida la información y crea un nuevo objeto de cuenta. Camino alternativo: si cualquier dato es inválido, el sistema despliega un mensaje de error apropiado.

2. el usuario somete la demanda. El sistema despliega otra página que contiene los resultados de la búsqueda

3. Nombre: registrar Objetivo: registrar a un usuario en el sistema. Precondición: el usuario no esta registrado en el sistema. Camino basico: El Cliente teclea su contraseña en su correo electrónico. Postcondicion: El Usuario es anotado en el sistema

4. El Cliente hace los cambios al Shopping Cart y presiona el botón de Actualización. Entonces el Cliente aprieta el botón de Check Out. Cuando el Cliente ha terminado especifica la facturación y envia la información, el sistema crea una Orden.

5. El Cliente teclea su dirección del correo electrónico y contraseña, y presiona el botón de Registrarse. El sistema empieza una Sesión y despliegua la Página Principal.

• El caso de uso 1 es demasiado conciso. No hay ninguna referencia a qué tipo de información el cliente ingresa, ni la página que aparece. El texto no explica como está validando los datos que el cliente ingreso. Y el caso de uso no describe cómo el cliente tiene que responder a una condición de error.

• El caso de uso 2 no tiene los nombres explícitos para los objetos del límite pertinentes.

• El caso de uso 3 revela que tan inútil puede ser obsesionarse al usar una plantilla complicada de caso de uso. El nombre del caso de uso expresa la objetivo claramente; el contenido del camino básico aclarara la precondición y hara redundante la postcondition.

• El caso de uso 4 faltan los caminos alternativos, aunque debe estar bastante claro del contexto que un poco de aprobación necesita ocurrir, y que hay varios posibles errores que condicionan (por ejemplo, el sistema no puede encontrar la dirección del correo electrónico, o la contraseña que el cliente ha ingresado no es igual al que se ha registrado).

• El caso de uso 5 no especifica cómo el sistema responde cuando el cliente presiona el botón de actualización.

Figura 3. muestra el texto del caso de uso con los errores corregidos.

1. curso básico: el cliente ingresa la información requerida en la página Cree su Cuenta. El sistema valida la dirección del correo electrónico que está en un formato aceptable, y asegura que el cliente no tenga una cuenta, y se crea un nuevo objeto de Cuenta. curso alternativo: si el cliente digita una dirección del correo electrónico equivocada, el sistema despliega un masaje de error a ese efecto y le pide al cliente que teclee una nueva dirección. curso alternativo: si el cliente ya ha creado una cuenta, el sistema despliega el masaje a ese efecto.

2. el usuario aprieta el botón Aceptar. El sistema realiza la búsqueda y se despliegua los resultados en la Página de Resultados de Búsqueda.

3. camino básico: el cliente teclea su dirección del correo electrónico y contraseña...

4. curso básico: el cliente teclea su correo electrónico y contraseña, y las presiona el botón Registrarse. El sistema valida la información registrada, y empieza la sesión y se despliega la Página principal curso alternativo: si el sistema no puede encontrar la dirección del correo electrónico, despliega un masaje a este efecto y da sugerencias el cliente para entrar en una dirección diferente. curso alternativo: si la contraseña que el cliente ha ingresado no es igual a la contraseña guardada, el sistema despliega un masaje a ese efecto y le pregunta al cliente que ingrese una contraseña diferente.

5. El Cliente hace los cambios al Shopping Cart y presiona el botón de Actualización. El sistema pone al día los contenidos del Shopping Cart apropiadamente. Entonces el Cliente presiona el Check Out. Cuando el Cliente ha terminado especifica la facturación y envia la información, entonces el sistema crea una Orden.

EL ANALISIS DE ROBUSTES

Esta técnica es simple y útil se une el análisis al diseño asegurando que su texto de caso de uso es correcto. Se dirige caminos necesarios de acción y le permite continuar descubriendo los objetos.

Este tema enfoca el análisis de robustez que involucra analisis del texto de descripcion de los casos del uso e identificando un conjunto de primeras suposiciónes de los objetos que participarán en cada caso de uso, clasificando estos objetos en tres tipos:

• El objeto Límite que los actores usan para comunicarse con el sistema.

• El objeto Entidad que normalmente son los objetos del modelo del dominio.

• El objeto Control (qué nosotros normalmente llamamos controladores porque ellos no son a menudo los objetos reales), qué sirve como la " union " entre el objeto Limite y el objeto entidad.

Figura 1. Los Iconos Visuales de los Tres Estereotipos para estos tipos de objetos.

Los Actores usan el objeto Límite para comunicarse con el sistema. Normalmente se derivan los objetos de Entidad de los modelos del dominio, y objetos de Control sirven como la enlace entre los objetos Limite y Entidad.

Figura 2. El Propósito de Análisis de Robustez

Esta técnica es simple pero muy útil porque sirve como un eslabón crucial entre el Análisis Modelo.

Figure 3. El Cuadro para manejar Casos de Uso en el modelamiento de Objetos

El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente.

Figura 4. Los Roles Esenciales del Análisis de Robustez

Usted refinará su texto del caso de uso y su mopdelo sera solido como resultado del análisis de robustez.

Dentro del proceso de ICONIX, esta técnica simple pero muy útil sirve como un eslabón crucial entre el Modelo y el analisis, como se muestra en la Figura 2. la Figura 3 muestra dónde el análisis de robustez reside dentro del " cuadro " para el proceso de ICONIX.

Los Elementos Importantes

El análisis de robustez juega varios papeles esenciales dentro del proceso de ICONIX. se refinará su texto de caso de uso y su modelo estático diseñado como resultado del análisis de robustez, como muestra la Figura 4.

El análisis de robustez proporciona un “control de sanidad” ayudándole a asegurar que su texto de caso de uso es correcto y que usted no ha especificado una conducta imposible para el sistema o el conjunto de objetos que se tiene no es razonable. Este refinamiento del texto de caso de uso cambia la naturaleza del texto de la perspectiva manual un de usuario a una descripción del uso en el contexto del modelamiento de objetos.

También proporciona una integridad y control de exactitud ayudándole a determinar si el caso uso toma la dirección de todos los caminos alternativos necesarios. El tiempo que se emplea en los dibujo de diagramas de robustez hasta aqui, y también hacia la produccion del texto que adhiere a algunas pautas bien definidas, el tiempo que se ahorra es significativo para dibujar los diagramas secuencia.

El análisis de robustez habilita el descubrimiento continuo de objetos; un paso crucial porque ciertamente se obvio de algunos objetos durante el modelamiento del dominio. Usted también puede determinar diferencias de denominación de objetos y conflictos antes de que ellos causen serios problemas. Y, el análisis de robustez le ayuda a asegurar que usted ha identificado la mayoría de las clases del dominio antes de empezar los diagramas de secuencia.

Finalmente, el análisis de robustez llena el papel del Modelo preliminar, cerrando el hueco entre el análisis y el modelo detallado.

Echemos una mirada más íntima a los tres estereotipos que aplicamos a los objetos durante el análisis de robustez.

Los Objetos Limite son los objetos con que los actores (por ejemplo, los usuarios) estarán actuando recíprocamente en el nuevo sistema. Éstos frecuentemente incluyen ventanas, pantallas, diálogos y menús.

Los Objetos Entidad trazan a menudo las tablas de la base de datos y archivos que contienen la información que necesita sobrevivir a " la ejecución de caso de uso”. Algunos de sus objetos entidad son " objetos transeúntes ", como los resultados de búsqueda.

Los objetos Control (controles) incluyen la lógica de la aplicación y sirve como el tejido que une entre los usuarios y los datos guardados. Esto es donde usted frecuentemente captura reglas de negocio cambiantes y políticas, y localiza los cambios a estos objetos sin romper su interfaz de usuario o su esquema de la base de datos. De vez en cuando (quizás 20 por ciento del tiempo), los controladores son " los objetos " reales en un modelo, pero los controladores normalmente sirven como el guias para asegurar que no se olvide de cualquier funcionalidad y la conducta del sistema requirido por sus casos de uso.

Usted realiza el análisis de robustez para un caso de uso utilizando el texto del caso de uso, una frase a la vez, y dibujando a los actores, el límite apropiado, el objeto entidad y el controlador, y las conexiones entre los varios elementos del diagrama. Usted debe poder encajar el camino básico y todos los caminos alternados en un diagrama. Cuatro reglas básicas se aplican:

• Los Actores sólo pueden interactuar con los objetos limite.

• Los objetos límite sólo pueden interactuar con controladores y actores.

• Los objetos entidad sólo pueden interactuar con controladores.

• Los controladores pueden interactuar con objetos limite y objetos entidad, y con otros controladores, pero no con actores

Figure 5. las Reglas de Análisis de Robustez

Los Objetos Límite y objetos Entidad son los sustantivos, y los controladores son los verbos. Los sustantivos no pueden interactuar con otros sustantivos, pero los verbos pueden interactuar con sustantivos o verbos.

Cualquiera que repase un diagrama de robustez debe poder leer un camino de acción en el texto del caso de uso, debe seguir a lo largo de las asociaciones en el diagrama, y debe ver un luz clara entre el texto y el cuadro. Se tendrá que volver a escribir el texto del caso de uso, para quitar la ambigüedad y poner explícitamente la referencia a los objetos límite y a los objetos entidad. La mayoría de las personas no escribe el texto de caso de uso perfecto en el primer proyecto.

Además de usar los resultados de análisis de robustez para señirse al texto de caso de uso, se debe refinar también continuamente al modelo estático. Los nuevos objetos que se descubre en el dibujo que los diagramas deben llevarse al diagrama de clase, y éste también es el tiempo correcto para agregar algunos atributos clave a sus clases más significantes.

Los 10 Errores mas comunes del Análisis de Robustez

10. No viole las reglas del diagrama de robustez. Estas reglas están principalmente para ingresar su texto en el formato del sustantivo-verbo-sustantivo y ayudar a que asegura no se empiese a asignar la conducta a los objetos antes de que usted tenga bastante información para tomar las decisiones. Las reglas sobre los objetos límite están para asegurar que se especifique los límites del sistema explícitamente del lugar en que estan los actores involucrados en los casos del uso.

9. Usar el análisis de robustez para ayudarle a usar un formato consistente para su texto de caso de uso. Los objetos límite-controlador-entidad tiende a aparecer mucho en los diagramas de robustez. Este modelo pone en correlación estrechamente con el modelo del sujeto-verbo-objeto de frases inglesas básicas. Se debe usar el análisis de robustez para hacer el texto del caso de uso consistente entre ellos a la magnitud más grande, se dara cuenta que mejora grandemente su legibilidad y mantenimiento.

8. Incluir los caminos alternativos en los diagramas de robustez. Se necesita realizar el análisis de robustez en todo su texto del caso de uso, no sólo los caminos básicos. Mucha de la conducta interesante de un sistema ocurre en el contexto de caminos alternativos, por lo que es importante analizar esta conducta como parte de sus esfuerzos del modelado. El análisis de robustez también puede ayudarle a descubrir los nuevos caminos alternativos, sobre todo cuando usted dibuja los controladores con las etiquetas Verificar y Validar.

7. Usar el análisis de robustez para asegurar la consistencia entre los nombres de la clase en los diagramas de clase y en el texto del caso de uso. Especificando el texto del caso de uso en el contexto del modelo del objeto es la fórmula mágica que usted necesita para construir los diagramas de la secuencia útiles. Nombrar su objeto límite y el objeto entidad de su caso de uso, se tomara un paso saludable hacia los diagramas de la secuencia y una salida buena, dibujar estos objetos de la forma mas comun del diagrama de la secuencia para cada caso del uso.

6. No asignar el comportamiento de las clases en los diagramas de robustez. Como se menciono antes, los controladores sirven como guias para la funcionalidad y conducta del sistema. No se debe empezar asignando los métodos a las clases en un diagrama de robustez, porque no es probable que usted tenga bastante información. Tome las decisiones sobre asignación de comportamiento que usa los diagramas de secuencia.

5. No incluir uno o demasiados controladores. Debe haber entre dos y cinco controladores en un diagrama de robustez. Si usted sólo tiene un controlador en el caso del uso, es probable que usted tenga muchos casos de uso muy pequeños, cada uno de los cuales realmente no realizan muchas funciones. Por otro lado, si se tiene más de 10 controladores en un diagrama, usted debe considerar dividir el caso de uso en partes mas manejables.

4. No tomar demasiado tiempo en intentar perfeccionar los diagramas de robustez. El diagrama de robustez sirve como un aparato propulsor que consigue manejar el proceso del caso de uso hacia un modelo Orientado a Objetos fundamentado. El análisis de robustez nos ayuda a descubrir los objetos, asigna los atributos, y verifica el texto de caso de uso para la integridad y exactitud. Pero una vez que se logra la misión global, no necesitamos mantener el producto del trabajo. Es un medio para el fin, no un fin en sí mismo.

3. No intente hacer el modelo detallado en los diagramas de robustez. El concepto de diagramas a manera de lanzamiento es útil en relación con el modelo preliminar; no es un concepto útil cuando viene al modelo detallado. Los diagramas de secuencia son el lugar apropiado para el modelo detallado. El análisis de robustez debe ser un paso rápido por todos los guiones que usted va a construir para proporcionar el valor máximo a su proyecto. Si su modelo preliminar cae en un modelo detallado, usted perderá los beneficios de este control de sanidad rápido.

2. Realice un seguimiento visual entre el texto de caso de uso y el diagrama robustez. Se recomienda que se tenga una revisión del par para todo su texto del caso de uso y el diagrama robustez. No se debe considerar el caso de uso hecho, hasta que pase la prueba del seguimiento visual simple. Cuando se haya alcanzado el punto dónde cada uno de los caso de uso haya pasado la prueba, el próximo paso del dibujo del diagrama de secuencia será más fácil para realizar que si se estuviera empezando exclusivamente de su texto del caso de uso.

1. Actualice su modelo estático. Se debe actualizar el modelo del dominio antes de que se considere hecho el análisis de robustez y pueda preparar para seguir al interacción del modelo usando los diagramas de secuencia. Después de todo, no se puede asignar el comportamiento a las clases que no aparecen en su modelo estático.

Figura 6. El Diagrama de Robustez Incorrecto con 4 violaciones a las reglas

Este diagrama viola las reglas tres, seis, ocho y diez.

El objeto límite Home Page debe comunicarse con el objeto límite Login Páge y el objeto entidad Account Table, violan la regla 10.

El objeto Account Table tiene un método asignado a él. Esto viola regla seis.

No hay ningún camino alternantivo ( por ejemplo, lo que pasa si las contraseñas no emparejan) asociado con el objeto control Validate Login Info, una violación de regla ocho.

El objeto Intercept Request es una estructura que pertenece al plan detallado. Esto viola regla tres.

Figure 7 muestras el diagrama de robustez con los errores corregidos.

Este diagrama no hace el plan detallado: No hay conducta asignada a los objetos e incluye los caminos alternativos.

DIAGRAMA DE SECUENCIA

La interacción diseñada le permite detalladar la conducta de sus objetos y encuentre las clases apropiadas para los atributos y funcionamientos.

Este tema perfila los errores más comúnes, y entonces explica cómo corregirlos. Este enfoque estará orientado en realizar el interacción del diseño usando UML y diagramas de secuencias.

Cuando usted termina con planeamiento de dominio y análisis de robustez, usted habrá encontrado la mayoría de los objetos en el problema y asignara algunos atributos a ellos. Se habrá definido las relaciones estáticas entre los objetos en su diagrama de la clase de alto nivel y unas relaciones dinámicas en sus diagramas de robustez.

Figure 1. El Cuadro para manejar Casos de Uso en el modelamiento de Objetos

El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente.

Ahora es tiempo para diseñar como su software realmente trabajará (en otros términos, para definir la solución a su problema). El diseño de Interacción es la fase dónde usted construye a los hilos que unen sus objetos . Aquí, usted empezará a ver cómo su nuevo sistema realizará una conducta útil. Figure 1 muestras dónde los diagramas de secuencia residen dentro del proceso de ICONIX.

Los Elementos Importantes de los Diagramas de la Secuencia

Usted quiere lograr tres metas primarias durante el diseño de interacción.

Primero, asigne el comportamiento entre los objetos límite, entidad y de control. Durante el análisis de robustez, usted puede identificar un conjunto de objetos que pueden lograr la conducta deseada de sus casos del uso. Se puede también romper esa conducta en las unidades discretas y puede crear que las guias controlen los objetos para cada una de esas unidades. Entonces se puede decidir qué objetos son responsables para cierta parte del comportamiento. Si no se tiene una clara idea de los ojetos limite, entidad y control, es demasiado pronto para estar contemplando cómo usted asignará el comportamiento. En ese caso, usted necesitará regresara al análisis de robustez y realizarlo bien.

Segundo, muestre las interacciones detalladas que ocurren entre los objetos asociados con cada uno de los casos del uso. Los objetos actúan recíprocamente enviando los mensajes a nosotros. Estos mensajes sirven como lo que Ivar Jacobson llama los estímulos (es decir, un mensaje estimula a un objeto para realizar algunas acciones deseadas. Para cada unidad de comportamiento dentro de un caso de uso, se debe identificar los mensajes y métodos necesarios.

Tercero, termine la distribución de funcionamientos entre las clases. Se debe apuntar para tener un 75 a 80 por ciento aproximadamente de sus atributos definidos dentro del modelo estático, cuando se halla terminado el análisis de robustez. Sin embargo, no empiece definiendo los funcionamientos durante el modelo del dominio y análisis de robustez. De hecho, se recomienda que no se asigne ningún método en este punto, porque no hay bastante información disponible.

Una vez que se ha consiguido el modelo de interacción, se debe tener bastante información. Entonces se puede poner el comportamiento detallado de sus objetos (en los diagramas de secuencia, en el contexto de su caso de uso) y se puede finalizar encontrando los lugares apropiadas para los atributos y funcionamientos. Mientras se hace este modelo dinámico,se estará actualizando y se extenderá su modelo estático, y esto solidificará su creciente conocimiento de cómo su nuevo sistema debe trabajar.

El diagrama de secuencia del UML evolucionó de una combinación del diagrama de interacción de objetos de Jacobson y del diagrama de control de eventos del OMT. Dentro del enfoque de ICONIX, los diagramas de secuencia representan el producto de trabajo de un mayor modelo. Se dibuja un diagrama de secuencia que abarque el camino básico y todos los caminos alternativos dentro de cada uno de casos de uso. Los resultados forman el centro de su modelo dinámico (que es la conducta del tiempo de ejecucion del sistema, incluyendo cómo se logrará esa conducta) que se define en gran detalle.

Hay cuatro tipos de elementos en un diagrama de secuencia: el texto para el camino de acción de los casos de uso, objetos, mensajes y métodos (funcionamientos).

• El texto para el camino de acción de los casos de uso aparecen abajo en el lado izquierdo. Es una buena idea separar el texto con el espacio en blanco para que sea fácil ver qué frase(s) corresponde con cada uno de los elementos a la derecha.

• Los Objetos que usted trae directamente de sus diagramas de robustez, se representa con dos componentes: el nombre del objeto y la clase a que ese objeto pertenece. Éstos aparecen en una caja arriba de la página, de la forma object::class. Una línea punteada corre de esa caja hacia abajo en toda la longitud de la página. Usted puede mostrar los iconos de diagrama de robustez sobre las cajas del objeto.

• Los mensajes son las flechas entre los objetos. Una flecha del mensaje puede ir directamente entre dos líneas punteadas, entre una línea y un rectángulo del método, o entre dos rectángulos del método.

• Los métodos (funcionamientos) se muestran como rectángulos que quedan encima de las líneas punteadas que pertenecen a los objetos a que ellos se asignan. Usted puede usar las longitudes de estos rectángulos para reflejar el enfoque de mando dentro de la secuencia. Un método en particular parte del extremo del rectangulo.

Figure 2. Cuatro Pasos para Dibujar los Diagramas de Secuencia

La Figura 2 muestra los cuatro pasos para realizar cuando se realiza el dibujo del diagrama de secuencia a la manera de ICONIX. Los pasos se realizan como sigue:

Paso 1. Copiar el texto del caso de uso obtenido para especificarlo. Pegúelo en el margen izquierdo de la página. Esto se hace para permitir a ese texto servir como un recordatorio continuo de lo que usted necesita lograr. El resultado es que cuando usted está haciendo el diseño, el comportamiento del sistema requerido siempre está mirándolo fijamente a la cara. Pero si no se tiene todos los caminos de acción alternativos pertinentes escritos para cada uno de los casos de uso, no se debe proceder hasta que ellos estén en su lugar. Por otra parte, los diagramas no cubrirán todos los casos especiales, y usted no encontrara el comportamiento total del caso de uso. Esto significa que no se descubrirá todos los métodos necesarios para sus objetos.

Paso 2. Agregue los objetos entidad del diagrama de robustez. Cada uno de estos objetos es un tipo caso que aparece en el Diagrama de clase que representa el modelo estático. (Si se olvido de actualizar el diagramas de clase estático en respuesta a los nuevos objetos que descubrió durante el análisis de robustez, hágalo ahora). Estos objetos deben tener la mayoría de sus atributos en sitio. Muchos de ellos estarán sirviendo de datos a otros objetos. Se puede esperar descubrir los atributos perdidos para trabajar el diagrama de secuencia. Sea meticuloso sobre agregarlos al modelo estático; es probable que esto sea su último paso antes del código.

Paso 3. Agregue los objetos límite del diagrama de robustez. En este punto se preguntara por qué no mencionamos la adicion de los objetos límite al modelo del dominio. La razón es que estos objetos son parte de la solución. Respondiendo de los objetos límite de los diagramas de secuencia, usted empieza ha integrar el modelo detallado.

Si se sigue el enfoque de ICONIX, los primeros tres pasos involucrados dibujan los diagramas de secuencia, su naturaleza es completamente mecanica.

Paso 4. Ponga los métodos en las clases. Esto involucra convertir los objetos control del diagrama de robustes en un conjuntos de métodos y mensajes que incluyen el comportamiento deseado (De vez en cuando, usted puede dejar un control como un objeto control real). Use su diagrama de robustez como una lista de control, asegurese que se tiene todo el comportamiento que el sistema requiere para los diagramas de secuencia. Entonces simplemente controle las respuestas de cada objeto control que se dibuja en los diagramas de secuencia.

Hay dos estrategias básicas por convertir los controladores que aparecen en los diagramas de robustez: control en la pantalla y controplador de caso de uso. Si usted usara sólo una estrategia durante sus esfuerzos en la diagramacion de secuencia, seria el patron a seguir. La idea es que se debe establecer a los miembros del equipo, responsable para los diagramas, las normas del diseño que pueden usarse para todos los casos de uso.

Por otro lado, las diagramaciones son las interacciones entre varios objetos, puede decidir uno o mas modelos del diseño, mejor establecidos, que encajaran. O quizás se podría desarrollar los nuevos modelos para establecer un enfoque regularizado para diseñar resultados a los problemas que aparecen en los multiples casos de uso. Esto es donde el desarrollo orientado a objetos tiene lugar.

A estas alturas, ya se ha verificado los diagramas de robustez con el texto del caso de uso. Verificando sus diagramas de secuencia con sus diagramas de robustez, se agrega una medida de convicción que se está diseñando en la contestación a lo que el usuario necesita (en otros términos, reuniendo requisitos).

Los 10 errores Sucesión los Errores de Diagramming

El lado del capirotazo de estas tomas de los principios la forma de varios errores comúnes que nosotros hemos visto a los estudiantes que hace cuando ellos están dibujando los diagramas de la sucesión la primera vez en sus proyectos para. Nuestra " cima que 10 " lista de errores sigue.

10. No haciendo un diagrama de la sucesión para cada caso del uso. Jacobson mantuvo una descripción sincera de la necesidad interacción que planea en La Ventaja del Objeto: El Proceso comercial Reengineering Con la Tecnología del Objeto (Addison-Wesley, 1995): " sólo es después de que usted ha dibujado que la interacción hace el diagrama de [llamó " los diagramas " de la sucesión en el UML] para todos los cursos de eventos en todos los casos del uso que usted puede estar seguro que usted ha encontrado todos los papeles que el sistema exige a cada objeto jugar y, así, las responsabilidades de cada objeto ".

9. no poniendo el texto de caso de uso en el diagrama de la sucesión. Escribiendo el texto requisito-nivelado original para el caso del uso en el margen del diagrama de la sucesión proporciona el traceability de requisitos visual atrás del plan a sus requisitos usuario-certificados. El equipo del proyecto habrá puesto mucho esfuerzo en escribir el texto de caso de uso, y la comunidad del usuario debe de haber firmado fuera de en los resultados. El diagrama debe emparejar el flujo narrativo del caso del uso asociado.

8. no identificando todos los objetos necesarios primero en un diagrama de robustez. Si usted está teniendo problema que consigue un diagrama de la sucesión empezado, usted probablemente escribió incorrectamente el caso del uso, o usted no completó el análisis de robustez. Diagramas de robustez apropiados teniendo que son asociado con el uso rigurosamente definido embalan las hechuras significativamente más fácil el trabajo. : (

7. no proporcionando un rastro visual entre el texto de caso de uso y las flechas del mensaje. Cada frase, incluyendo los fragmentos apropiados, dentro del texto de caso de uso debe tener algún espacio blanco alrededor de él. Cada uno también debe alinearse visualmente con el mensaje o juego de mensajes que corresponden con la conducta especificada. Esto habilitará a las personas que leen el diagrama para ver fácilmente cómo el sistema logrará lo que el caso del uso describe.

6. no mostrando la fontanería; en cambio, persista su diagrama de la sucesión en un nivel alto de abstracción. No es necesario mostrar la fontanería en la robustez que hace el diagrama de, desde que ellos reflejan una vista del plan preliminar. Sin embargo, los diagramas de la sucesión son la última parada antes de codificar, y necesidad como a tal de mostrar el detalle por completo al plan real.

5. convirtiendo su diagrama de la sucesión en un diagrama de flujo en lugar de usarlo para asignar la conducta entre los objetos. Recuerde que el diagrama de la sucesión es el vehículo primario por tomar las decisiones de asignación de conducta. Usted realmente está usándolos asignar los funcionamientos a sus clases como usted va. La asignación de conducta (decidiendo qué funcionamientos pertenecen a que las clases) es crítico en el acercamiento de ICONIX. Las decisiones hicieron durante esta fase de un dictado del proyecto si el plan global es bueno o malo. Esto es donde los diseñadores experimentados ganan su paga.

4. no enfocando en los métodos interesantes (la conducta del software real), se distraído por los getters y setter. Explorando la conducta dinámica del sistema, usted aprende se necesitan qué atributos y funcionamientos en las clases de su modelo estático. Para empezar, agrega atributos y métodos a sus clases en cuanto usted decida donde ellos entran el contexto de sus diagramas de la sucesión. Pero no gasta la muchos adición de tiempo consigue y ponga los métodos a su modelo. Usted debe aprovecharse la del principio de encapsulation: Sólo permita el acceso a los atributos vía los getters y setter. : (

3. no pensando cuidadosamente sobre los orígenes de las flechas del mensaje (en otros términos, qué objeto está en el mando en cualquier momento dado). los Mensajes entre los objetos in

, una clase) debe tener una sola personalidad. Esto significa que una clase debe enfocarse en un juego fuertemente relacionado de conductas. Esto parangona las reglas bien-establecidas que los objetos estatales deben ser muy cohesivos y flojamente acoplados. Otros principios en que usted debe enfocar incluyen el reusability (el más general sus objetos y clases, el más probablemente ellos son ser reusables para otros proyectos y pertinencia. Cuando usted asigna los métodos a los objetos en sus diagramas de la sucesión, siempre pregunte si allí parece ser un ataque bueno entre el método y objetar, y también si la tarea que el método realiza es evidentemente pertinente al objeto.

1. no poniendo al día a su modelo estático como usted pasan por construir los diagramas de la clase locales para cada paquete de casos del uso. Es bueno guardar un juego limpio de clases del dominio en un puro dominio el diagrama ejemplar. Sin embargo, también es una idea buena para dibujar diagramas de la clase estáticos localizados que muestran objetos espaciales y problema a ambos solución los objetos espaciales. Una pauta buena para esto es un tal diagrama por el paquete de casos del uso. Como usted propone el andamiaje y otros tipos de infraestructura, como las clases del auxiliador, póngalos en el diagrama de la clase estático, también. Esto es donde usted cambia su enfoque del espacio del problema al espacio de la solución. Usará el mejor la clase localizada hace el diagrama de—diga, uno por el paquete de caso de uso—porque por este tiempo su modelo estático es probablemente demasiado expansivo ser capturado dentro de un diagrama leíble. También haciendo esto le permite henderse trabaje por los equipos.

Un diagrama de la sucesión que contiene violaciones de cuatro de la cima 10 reglas (perfiló en los puntos de la bala siguientes) se muestra en Figura 3. Los errores se corrigen en Figura 4.

Figure 3. la Sucesión Hace el diagrama de con las Violaciones

Este diagrama de la sucesión viola cuatro de la cima 10 reglas. ¿Usted puede descubrirlos?

El texto de caso de uso no se extiende fuera, para que los mensajes están rayados a con cada frase del texto. Esto viola regla 7.

Hay que ninguna Búsqueda Resulta objeto que se habría identificado durante el análisis de robustez desde que no se supone obviamente que nosotros desplegamos los volúmenes enteros del catálogo. Esto viola regla 8. (la Nota que el texto de caso de uso también es incorrecto en esto considere.)

La Página de la Búsqueda envía el mensaje del despliegue, aunque las muestras del diagrama que el Catálogo está en el mando. Esto viola regla 3.

El objeto del Catálogo está invocando el despliegue Error Mensaje método en la Página de la Búsqueda. Esto viola regla 2. El acercamiento correcto sería para la Página de la Búsqueda invocar el método en sí mismo.

Figure 4. Corrigió el Diagrama de la Sucesión

Las violaciones para gobernar siete, ocho, se han corregido tres y dos.

Quédese puesto a punto para un additonal tres artículos que proporcionan una mirada del prepublication al ejemplo anotado de nuestro libro venidero Aplicado Use Caso Manejado Objeto que Planea (Addison-Wesley, 2001,; ahora tentativamente fijado durante junio). Nosotros esperamos los cinco artículos anteriores en nuestra guía didáctica planeando le ha proporcionado un proceso eficaz para los sistemas del e-comercio arteros ilustrando cómo construir a un modelo del dominio con las clases flojamente acopladas, escriba los casos del uso concisos, haga el análisis de robustez eficaz y cree los diagramas de la sucesión exitosos.

La nota: :(simboliza la parálisis del análisis.

La Experiencia del Usuario

La Infraestruc-tura del Negocio

La Funcionali-dad Comercial

La Estrategia y el Análisis Comercial

Definiendo la Marca

La Arquitectura de información

El Plan de la interfaz

La Infraestructura e Integración del Sistema

La Aplicación de la Empresa

El Rendimineto del Modelo

Los Objetivos del Negocio

La Planificación de Tecnología

El desarrollo hacia el público

El Desarrollo de la Aplicación

La Integración de la Aplicación Comercial

El Modelo de la base datos

El Almacenamiento de los datos

Estrategia Comercial