uml-modeling
Skill1 starsChanged 6 months agoMITView on GitHub
Boas práticas de modelação UML (base RMAC/UMinho): diagramas de casos de uso, sequência/comunicação, classes, atividades, estados, pacotes/componentes/deployment. Trigger phrases: casos de uso, diagrama de casos de uso, use case diagram, diagrama UML, UML diagram, diagrama de classes, class diagram, diagrama de sequência, sequence diagram, diagrama de estados, diagrama de atividades, modelo UML, atores do sistema, include extend
In this repository41 other files it gives its agents.
- AGENTS.mdAGENTS.md
- academic-evaluationSkill
- academic-writingSkill
- agent-orchestrationSkill
- agents-md-writerSkill
- algorithmic-artSkill
- brand-guidelinesSkill
- codebase-architectureSkill
- code-reviewSkill
- commit-workflowSkill
- context-checkpointSkill
- doc-coauthoringSkill
- docxSkill
- etl-runnerSkill
- eval-runnerSkill
- feature-devSkill
- frontend-designSkill
- hpc-deucalionSkill
- internal-commsSkill
- langchainSkill
- langfuseSkill
- langgraphSkill
- llm-observability-stackSkill
- mcp-builderSkill
- neo4j-verifySkill
- pdfSkill
- pptxSkill
- project-conventionsSkill
- python-best-practicesSkill
- react-namingSkill
- security-hooksSkill
- service-verifySkill
- skill-creatorSkill
- skill-inspectorSkill
- slack-gif-creatorSkill
- sprint-contractSkill
- theme-factorySkill
- webapp-testingSkill
- web-artifacts-builderSkill
- web-debugSkill
- xlsxSkill
The file
Files
Modelação UML — Boas Práticas
Regras destiladas dos materiais de Modelação com UML (R. J. Machado, Universidade do Minho — RMAC_ModelacaoComUMLp1–p5, RMAC_MetodosOrientadosAosObjectos), escritas como instruções acionáveis. Terminologia UML 2.x. Exemplos renderizáveis em PlantUML em examples/plantuml-exemplos.md.
Quando usar
- Levantar e especificar requisitos com casos de uso (atores, fronteira do sistema, cenários).
- Produzir ou rever qualquer diagrama UML: casos de uso, sequência/comunicação, classes, atividades, estados, pacotes, componentes, deployment.
- Decidir relações entre casos de uso (include/extend/generalização) ou entre classes (associação vs. agregação vs. composição).
- Refinar casos de uso em sub-casos sem cair em decomposição funcional.
Processo de modelação (ordem obrigatória)
- Separar requisitos do utilizador dos requisitos do sistema — nunca os misturar no mesmo diagrama/nível. Requisitos do utilizador: terminologia do problema, ponto de vista operacional (P1).
- Filtrar a informação do cliente: eliminar decisões de conceção demasiado restritivas ("quero uma base de dados") e rejeitar requisitos vagos ("fácil de usar") — pedindo concreto (P1).
- Diagrama de contexto ANTES dos casos de uso: é mais fácil listar primeiro os atores/papéis e depois obter os casos de uso de cada um. Iterativo — atores podem nascer/morrer durante a descoberta dos casos de uso; o importante são os casos de uso (P1).
- Capturar por cenários concretos, não por idealizações abstratas — cenários são instâncias de um caso de uso. Podar variantes sem valor funcional (P1).
- Refinar risk-driven: só os casos de uso mais complexos/relevantes se refinam; usar vistas ortogonais (especialização + desagregação) para controlar a explosão de sub-casos (P1).
- Descrição de cada caso de uso em linguagem natural na primeira fase (passos numerados, pré/pós-condições) — o cliente tem de conseguir validar. Formalizar depois com diagramas de interação, que documentam cenários imputados a requisitos (P1, P2).
Regras transversais
- Nomes vêm do domínio do problema, nunca da tecnologia (MET).
- Ator = papel, nunca pessoa ("o António") nem cargo profissional literal ("o supervisor de produção"); um utilizador pode desempenhar vários papéis (P1).
- Nível de abstração correto: nem demasiado alto nem demasiado baixo; a classificação depende da perspetiva relevante para o problema (MET).
- Num diagrama de contexto, tudo menos a camada mais externa é caixa preta; fluxos de mensagens no contexto são prematuros antes dos casos de uso (P1).
- Modelos devem ser: compreensíveis, completos, expressivos, corretos (P1).
- UML é notação, não método — o processo é nosso (MET).
Guias de decisão rápidos
| Dúvida | Regra | Detalhe |
| Elemento dentro ou fora do sistema? | Fora se: interface com dispositivos existentes, já existe, fornece/recebe info do sistema, ou é pessoa que monitoriza/é afetada. Caso contrário, dentro (P1) | references/casos-de-uso.md |
«include» vs «extend»? | include: comportamento obrigatório fatorizado do base; extend: comportamento opcional/variante que acrescenta ao base (P1) | references/casos-de-uso.md |
| Ator herda associações? | Generalização entre atores quando um papel é especialização de outro (Salesperson → Supervisor) (P1) | references/casos-de-uso.md |
| Sequência vs comunicação? | Comportamento complexo → sequência (mais legível); relações estáticas simples → comunicação (P2) | references/interacao.md |
| Agregação ou composição? | Parte pode existir fora do todo → agregação (diamante oco); parte só existe no todo → composição (diamante cheio) (P3) | references/classes.md |
| Que evento num estado? | call op(a:T) · change when(exp) · signal sname(a:T) · time after(time) (P4) | references/atividades-estados.md |
| «access» vs «import» entre pacotes? | access: ver públicos sem mudar namespace; import: adiciona públicos ao namespace (P5) | references/outros-diagramas.md |
Erros comuns a evitar
- Amálgama de requisitos: necessidades do utilizador misturadas com conceção no mesmo artefacto (P1).
- Atores com nomes de pessoas ou de cargos (P1).
- Explosão de cenários: manter só os indispensáveis, ignorar pequenas variações (P1).
- Fluxos de mensagens no diagrama de contexto antes dos casos de uso existirem (P1).
- Refinar tudo em vez de risk-driven (P1).
- Diagramas de comunicação para comportamentos complexos (ficam ilegíveis) (P2).
- Restrições deixadas implícitas quando a notação não as cobre — usar constricções/OCL (P3).
- Guards de branch não mutuamente exclusivos ou incompletos (P4).
Referências detalhadas
| Ficheiro | Conteúdo |
references/casos-de-uso.md | Fronteira, atores, cenários, relações, refinamento, descrições — regras completas |
references/interacao.md | Sequência e comunicação: níveis, notação, critério de escolha |
references/classes.md | Classes: notação, associações, herança, todo-parte, interfaces, OCL |
references/atividades-estados.md | Atividades e estados: notação, sintaxe de eventos/ações, decomposição |
references/outros-diagramas.md | Pacotes, componentes, deployment |
examples/plantuml-exemplos.md | PlantUML renderizável por tipo de diagrama |
Renderização
Para gerar PNG a partir de .puml:
java -jar plantuml.jar -charset UTF-8 -o <pasta_saida> ficheiro.pumlDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.