← ClaudeAtlas

uml-robustness-diagramlisted

genera, revisa, refactoriza y valida diagramas de robustez ICONIX (analisis de robustez, boundary-control-entity/BCE) en plantuml, a partir de la especificacion de un caso de uso, el modelo de dominio y el diagrama de casos de uso. usar para: diagrama de robustez, robustness diagram, analisis de robustez, objetos tipo borde, tipo controlador y tipo entidad de un caso de uso (boundary/control/entity, frontera, pantalla, controlador), chequeo de sensatez y completitud del texto del caso de uso, diseno preliminar conceptual, el paso o puente entre la especificacion y el diagrama de secuencia (sin generar la secuencia en si), desambiguacion del texto de casos de uso, y descubrimiento de objetos o clases faltantes en el modelo de dominio. no reemplaza la especificacion textual ni el diagrama de secuencia: es el puente entre ambos. cada entregable pasa por un ciclo interno de auditoria antes de entregarse, con reglas verificables por script y trazabilidad bidireccional.
jonatan8254/iconix-uml-skills · ★ 0 · Web & Frontend · score 67
Install: claude install-skill jonatan8254/iconix-uml-skills
# UML Robustness Diagram Trabajar en español por defecto, salvo que el usuario pida otro idioma. Fundamento y fuentes: `references/sources-and-methods.md`. ## Naturaleza y propósito El diagrama de robustez es **el "cuadro de objetos" de un caso de uso**: se dibuja recorriendo el texto del caso de uso frase por frase y colocando los objetos que participan. Es la pieza que cierra el hueco entre el análisis y el diseño — si los casos de uso son el "qué" y el diseño es el "cómo", el análisis de robustez es **diseño preliminar conceptual**. Dos consecuencias que gobiernan todo lo demás: - **No es diseño detallado.** No se asignan operaciones a clases, no se dibuja herencia, no se aplican patrones. Eso pertenece a los diagramas de secuencia y al modelo de clases. Un diagrama de robustez que intenta ser un diseño detallado ha fallado en su propósito. - **No es un fin en sí mismo.** Es un artefacto de transición cuyo valor real es *doble*: obliga a **desambiguar el texto** del caso de uso y **descubre objetos** que faltan en el modelo de dominio. Si al dibujarlo no corriges nada del texto ni encuentras ninguna clase nueva, probablemente no lo estás usando bien. Nota de honestidad sobre las fuentes: los libros no coinciden en cuántos "roles" tiene la técnica — una fuente habla de dos misiones (desambiguar y descubrir objetos) y otra enumera cuatro (chequeo de sensatez, chequeo de completitud, descubrimiento de objetos y diseño preliminar). No fuerces una lista canónica; ambas de