Los 10 errores en los diagramas de secuencia

Listamos varios errores comúnes que nosotros hemos visto a los estudiantes cuando  dibujan los diagramas de secuencia:
 
10. No hacer un diagrama de secuencia para cada caso de 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.