Diseño de Sistemas
Crear el conjunto mínimo de vistas que responda a la pregunta del usuario. Preferir archivos .drawio editables para diagramas formales; respetar la notación, el formato, la rúbrica del curso y los archivos existentes solicitados. Un archivo XML válido no es prueba de un modelo correcto.
Flujo de trabajo
- Establecer la audiencia, el límite del sistema, la pregunta, el escenario y el nivel de abstracción. Leer los requisitos/esquema/código proporcionados y cualquier rúbrica. Registrar cardinalidades inciertas, permisos, reglas de ciclo de vida e interfaces externas como suposiciones; preguntar solo cuando cambien materialmente la respuesta. No inventar infraestructura o relaciones obligatorias.
- Elegir vistas usando la tabla de enrutamiento a continuación. Leer solo las referencias relevantes más
diagram-validation.md. Distinguir la evidencia del estado actual del diseño propuesto. Mantener un glosario pequeño con identificadores de concepto estables cuando varios diagramas compartan conceptos. - Construir un inventario semántico antes de colocar formas: participantes/elementos, relaciones con dirección y significado de los extremos, restricciones e identificadores de requisitos. Para un DFD, agregar un diccionario de flujos y firmas de límites de descomposición; para un modelo de datos, identificar claves y dependencias.
- Seguir el procedimiento de dibujo específico del diagrama. Establecer la notación explícitamente (p. ej., UML 2, Pata de Gallo, Gane–Sarson; contexto luego nivel 0). Separar las reglas semánticas de las recomendaciones de diseño. Resolver fuentes conflictivas como se describe en
sources.md. - Para Draw.io, leer
drawio-rendering.mdylayout.md. Crear formas y conectores nativos con identificadores estables, usando un serializador XML. Copiar un ejemplo relevante solo después de reemplazar sus hechos de dominio. Para otros formatos, leerfallbacks.md. - Ejecutar
python3 <directorio-del-skill>/scripts/validate_drawio.py <archivo-o-directorio>. Reparar los errores estructurales reportados. Usar las listas de verificación semántica y entre vistas: el script no puede probar la corrección de UML, DFD, ERD o BPMN. - Abrir/importar en diagrams.net o exportar usando un renderizador Draw.io disponible. Inspeccionar cada página en busca de etiquetas, extremos de flechas, recortes, contención y cruces; ajustar e inspeccionar de nuevo. Si ningún renderizador funciona, entregar la fuente editable e informar explícitamente que el renderizado no está verificado. No llamar "prueba de apertura" al análisis XML.
- Entregar archivos fuente, vistas previas útiles y una breve nota de verificación/suposiciones. Indicar exactamente qué comprobaciones se ejecutaron. Preservar el diseño manual existente y las páginas no relacionadas durante las ediciones; actualizar las vistas previas obsoletas.
Enrutamiento de referencia
| Pregunta del usuario | Leer |
|---|---|
| Elección de UML / línea base de notación | uml.md |
| Actores y objetivos de usuario | use-case.md |
| Estructura de dominio o software | class-diagram.md |
| Un escenario entre colaboradores | sequence-diagram.md |
| Flujo de trabajo, ramas, concurrencia | activity-diagram.md |
| Ciclo de vida de una entidad impulsado por eventos | state-machine.md |
| Instancias, enlaces, módulos, ubicación en tiempo de ejecución | structural-views.md |
| Comunicación, temporización, visión general de interacción | advanced-interactions.md |
| Entidades, relaciones, esquema relacional | erd.md, normalization.md |
| Movimiento de datos y descomposición | dfd.md, context-diagram.md |
| Niveles de arquitectura | c4-model.md |
| Colaboración/proceso de negocio | bpmn.md |
| Procedimiento simple o transferencias de responsabilidad | flowchart-swimlane.md |
| Generación / pulido de salida | drawio-rendering.md, layout.md, fallbacks.md |
| Revisión / consistencia entre vistas | diagram-validation.md |
| Procedencia de fuentes / ediciones / limitaciones | sources.md |
Convención de salida
Respetar la ruta del usuario. De lo contrario, usar docs/diagrams/<sistema>-<vista>.drawio, con vistas previas .svg o .png coincidentes cuando sea posible. Usar <sistema>-assumptions.md para suposiciones importantes y <sistema>-validation.md para auditorías entre vistas. Mantener las exportaciones temporales fuera de los entregables finales. Usar archivos separados para vistas mantenidas de forma independiente, o páginas con nombre para un conjunto coordinado. Nunca reemplazar silenciosamente una notación formal solicitada con un diagrama de flujo genérico.
Comprobaciones innegociables
- Los hechos del modelo deben provenir de evidencia o suposiciones etiquetadas.
- Verificar la semántica de los extremos; una flecha apuntando en la dirección incorrecta puede seguir siendo sintácticamente válida.
- Una flecha de DFD transporta datos; el flujo de control UML/BPMN transporta significado de ejecución.
- No inferir la propiedad del ciclo de vida a partir de una clave foránea o una frase vaga "tiene un".
- Revisar los conceptos compartidos relevantes; no exigir contenidos idénticos en vistas de diferente alcance.
- Mantener los dibujos editables; una imagen incrustada en un archivo
.drawiono es un diagrama nativo.
Los ejemplos y verificaciones ejecutables están en examples/ y scripts/. La evidencia de pruebas específicas del paquete está en TEST-REPORT.md.