Diagrama de clases UML: cómo modelar las relaciones sobre cómo llamar a un método o iniciar una actividad o servicio
Estoy creando mi primera aplicación de Android. He evitado asociaciones de etiquetas con el usuario o las interacciones del sistema (por ejemplo, he etiquetado comienza en lugar startsWhenClick , he etiquetado comienza en lugar de startsWhenDetection ). Sin embargo, después de leer esto , estoy considerando cambiar las asociaciones de inicio por << crear >> dependencias. ¡Estoy confundido!
La aplicación funciona de la siguiente manera. Cuando se inicia la aplicación, LauncherActivity llamará a los métodos de BaseActivity para iniciar la actividad marcada en SettingsActivity (también podría ser SettingsActivity). LauncherActivity lanzará ambos servicios también. Este es el diagrama:
Nota: esta pregunta es la continuación de esta pregunta.
No es un diagrama de clase real.
- Inicios y llamadas pertenecen a las notas, o si está seguro de que desea verlas en las conexiones, hacer estereotipos sobre DEPENDENCIAS, no asociaciones.
- Todavía no tienes asociaciones, y son la parte principal del diagrama de clases. Mira aquí cómo trabajar con ellos. Primero debe crear asociaciones. Sólo después de eso se muestran las dependencias. (No es una regla común, pero usted debe hacerlo para una mejor comprensión)
- En cuanto a las acciones que está intentando mostrar aquí, haga el diagrama de máquina de estado para ellos, entonces probablemente diagrama de la secuencia o de la actividad. No utilice el diagrama de vista general de Interacción, se perderá en él.
Pero deja de poner tantas acciones en el diagrama de clases
IMHO, porque las actividades no tienen o casi ninguna dependencia de la estructura, el diagrama de clase apropiado será muy pobre – bloques simples sin asociaciones. Y las dependencias en todo el campo … Por lo tanto, el diagrama de clases no es útil en este nivel. Parece, ya les he dicho, que los diagramas de clases son para las clases que están en una misma intención de Android – uno o más para una intención.
En cuanto al diagrama de comunicación , creo que no es tu caso. Es más común, cerca del usuario, que los diagramas de secuencia o actividad. Es para el caso cuando usted tiene muchos tipos de mensajes y está planeando sus rutas. Para la planificación del camello, por ejemplo. Pero por desgracia – no ha implementado patrones de mensajes. Por lo tanto, sigue siendo sólo para la planificación muy común de los sistemas con mensajería masiva. Sus "mensajes" están iniciando, iniciando componentes y así sucesivamente. No se puede mostrar con ese diagrama.
Puede probar diagrama de objetos o diagrama de estructura compuesta . Si desea mostrar funcionalidad en el diagrama de clases, no puede hacerlo, pero puede pasar a estos.