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.

1
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.

2
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

3
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.

4
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

5
 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

6
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

7
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.

8
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.

9
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.

10
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

11
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

12
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

13
 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.

14
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.

15
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 dediga, uno por el paquete de caso de usoporque 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.

16
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

17