{"id":4332,"date":"2026-04-06T06:36:28","date_gmt":"2026-04-06T06:36:28","guid":{"rendered":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/"},"modified":"2026-04-06T06:36:28","modified_gmt":"2026-04-06T06:36:28","slug":"use-case-diagram-case-study-prevent-overhaul","status":"publish","type":"post","link":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/","title":{"rendered":"Estudo de Caso: Como um Diagrama de Caso de Uso Simples Evitou uma Grande Reformula\u00e7\u00e3o de Recursos"},"content":{"rendered":"

No desenvolvimento de software, os bugs mais caros n\u00e3o s\u00e3o encontrados no c\u00f3digo. Eles s\u00e3o encontrados nos requisitos. Quando uma equipe de desenvolvimento constr\u00f3i um recurso com base em uma descri\u00e7\u00e3o vaga, o resultado frequentemente \u00e9 retrabalho. Esse retrabalho consome tempo, or\u00e7amento e moral. Um artefato de requisitos bem estruturado pode atuar como escudo contra esses custos. Neste estudo de caso, analisamos como uma t\u00e9cnica de modelagem visual identificou uma falha cr\u00edtica no escopo do projeto antes de uma \u00fanica linha de c\u00f3digo ser escrita.<\/p>\n

O projeto envolveu uma plataforma de log\u00edstica projetada para conectar operadores de armaz\u00e9ns com motoristas de entrega. O pedido inicial era simples: construir um m\u00f3dulo para gerenciar a entrega de pacotes. A equipe assumiu que o fluxo de trabalho era linear. No entanto, a introdu\u00e7\u00e3o de um diagrama de caso de uso revelou casos de borda complexos que o breve verbal original havia completamente ignorado. Essa interven\u00e7\u00e3o visual simples salvou a organiza\u00e7\u00e3o de uma grande reformula\u00e7\u00e3o arquitet\u00f4nica posteriormente no ciclo de vida.<\/p>\n

\n
\"Cartoon<\/figure>\n<\/div>\n

\ud83c\udfd7\ufe0f O Contexto do Projeto<\/h2>\n

O cliente era uma empresa de cadeia de suprimentos de porte m\u00e9dio que estava expandindo sua infraestrutura digital. Eles estavam passando de um rastreamento manual para um sistema totalmente automatizado. O objetivo principal era reduzir o tempo entre a chegada de um pacote em um hub e sua atribui\u00e7\u00e3o a um motorista. O grupo de interessados inclu\u00eda gerentes de opera\u00e7\u00f5es, supervisores de armaz\u00e9m e desenvolvedores s\u00eanior.<\/p>\n

As reuni\u00f5es iniciais focaram no \u201ccaminho feliz\u201d. Este \u00e9 o cen\u00e1rio ideal em que tudo ocorre conforme o planejado. Os interessados descreveram um processo em que um motorista chega, escaneia um c\u00f3digo de barras e o sistema confirma a entrega. Todos concordaram com a cabe\u00e7a. O projeto foi aprovado. A equipe de desenvolvimento come\u00e7ou a configurar o esquema do banco de dados e os pontos finais da API.<\/p>\n

No entanto, as opera\u00e7\u00f5es raramente s\u00e3o lineares. A log\u00edstica do mundo real envolve interrup\u00e7\u00f5es, erros e exce\u00e7\u00f5es. Sem um modelo visual formal para testar os requisitos sob press\u00e3o, a equipe prosseguiu com a suposi\u00e7\u00e3o de que o sistema lidaria apenas com intera\u00e7\u00f5es padr\u00e3o. Foi nessa suposi\u00e7\u00e3o que o risco come\u00e7ou.<\/p>\n

\ud83d\udcd0 Compreendendo o Diagrama de Caso de Uso<\/h2>\n

Um diagrama de caso de uso \u00e9 uma vis\u00e3o comportamental de um sistema. Ele ilustra as intera\u00e7\u00f5es entre atores externos e o pr\u00f3prio sistema. Ele n\u00e3o mostra a l\u00f3gica interna nem a estrutura do c\u00f3digo. Em vez disso, foca no \u201cquem\u201d e no \u201co que\u201d.<\/p>\n

Os componentes principais incluem:<\/p>\n

    \n
  • Atores:<\/strong>Usu\u00e1rios ou sistemas externos que interagem com o aplicativo. Neste caso, Motoristas, Funcion\u00e1rios de Armaz\u00e9m e Administradores.<\/li>\n
  • Casos de Uso:<\/strong>Objetivos ou a\u00e7\u00f5es espec\u00edficas que o ator pode realizar, como \u201cEscaneiar Pacote\u201d ou \u201cRelatar Danos\u201d.<\/li>\n
  • Fronteira do Sistema:<\/strong>A caixa que define o escopo do software. Tudo dentro \u00e9 parte do sistema; tudo fora \u00e9 o ambiente.<\/li>\n
  • Relacionamentos:<\/strong>Linhas que conectam atores a casos de uso. Elas definem o fluxo de intera\u00e7\u00e3o.<\/li>\n<\/ul>\n

    Criar este diagrama obriga a equipe a articular os limites do sistema. Transforma suposi\u00e7\u00f5es impl\u00edcitas em expl\u00edcitas. Se um interessado menciona um processo que n\u00e3o se encaixa no diagrama, isso sinaliza uma lacuna nos requisitos.<\/p>\n

    \ud83e\udd14 O Escopo Inicial e as Suposi\u00e7\u00f5es<\/h2>\n

    Antes do diagrama ser elaborado, o escopo era definido por um documento que listava recursos de alto n\u00edvel. A equipe acreditava que o escopo estava contido no m\u00f3dulo \u201cEntrega\u201d. As suposi\u00e7\u00f5es eram:<\/p>\n

      \n
    • O motorista sempre tem uma conex\u00e3o de internet funcional.<\/li>\n
    • O c\u00f3digo de barras \u00e9 sempre leg\u00edvel pelo scanner.<\/li>\n
    • O pacote est\u00e1 sempre no local correto.<\/li>\n
    • N\u00e3o h\u00e1 disputas sobre o estado do pacote.<\/li>\n<\/ul>\n

      Essas suposi\u00e7\u00f5es s\u00e3o comuns nas fases iniciais de planejamento. Elas permitem que a equipe comece o trabalho rapidamente. No entanto, s\u00e3o fr\u00e1geis. Quando a realidade do ambiente de armaz\u00e9m foi introduzida, essas suposi\u00e7\u00f5es falharam.<\/p>\n

      Os interessados n\u00e3o mencionaram explicitamente as exce\u00e7\u00f5es. Eles assumiram que o sistema as lidaria automaticamente. A aus\u00eancia de um modelo visual significava que ningu\u00e9m questionou a completude do fluxo at\u00e9 que fosse tarde demais.<\/p>\n

      \ud83c\udfa8 Criando o Modelo Visual<\/h2>\n

      O l\u00edder do projeto solicitou uma revis\u00e3o formal dos requisitos usando um modelo visual. Este passo n\u00e3o fazia parte da linha do tempo inicial, mas foi introduzido para validar a arquitetura. A equipe reuniu os supervisores de armaz\u00e9m para desenhar o diagrama em um quadro branco.<\/p>\n

      Esta sess\u00e3o mudou a din\u00e2mica do projeto. Em vez de discutir recursos abstratos, todos olharam para um mapa concreto do fluxo de trabalho. O diagrama foi constru\u00eddo de forma iterativa:<\/p>\n

        \n
      • Passo 1: Definir os Atores.<\/strong> Colocamos o Motorista, o Supervisor do Armaz\u00e9m e o Pr\u00f3prio Sistema como os atores principais.<\/li>\n
      • Passo 2: Mapear o Caminho Feliz.<\/strong> Desenhamos o fluxo padr\u00e3o: Motorista faz login \u2192 Escaneia o c\u00f3digo de barras \u2192 Sistema atualiza o status.<\/li>\n
      • Passo 3: Identificar Exce\u00e7\u00f5es.<\/strong> Perguntamos: \u201cO que acontece se isso der errado?\u201d<\/li>\n
      • Passo 4: Adicionar Relacionamentos.<\/strong> Conectamos as exce\u00e7\u00f5es aos casos de uso principais.<\/li>\n<\/ul>\n

        \u00c0 medida que o diagrama crescia, a complexidade tornava-se vis\u00edvel. O quadro branco j\u00e1 n\u00e3o era mais uma linha simples. Ramificava-se em m\u00faltiplos caminhos. Essa evid\u00eancia visual era ineg\u00e1vel.<\/p>\n

        \ud83d\udd0d A Descoberta Cr\u00edtica<\/h2>\n

        Durante a sess\u00e3o de modelagem, uma intera\u00e7\u00e3o espec\u00edfica foi sinalizada e havia sido ignorada. O caso de uso \u201cEscaneamento de Pacote\u201d estava conectado ao caso de uso \u201cRelatar Danos\u201d por meio de uma rela\u00e7\u00e3o \u201cExtend\u201d. Isso significava que, se um motorista escaneasse um pacote, teria a op\u00e7\u00e3o de relatar danos.<\/p>\n

        O diagrama revelou uma depend\u00eancia que n\u00e3o estava no escopo inicial. Para suportar \u201cRelatar Danos\u201d, o sistema precisava capturar fotos, coordenadas de GPS e uma marca\u00e7\u00e3o de tempo. Tamb\u00e9m precisava notificar imediatamente o supervisor do armaz\u00e9m.<\/p>\n

        Inicialmente, a equipe achou que se tratava de uma pequena adi\u00e7\u00e3o. O diagrama mostrou que essa funcionalidade exigia uma estrutura de dados completamente diferente. O esquema original do banco de dados era projetado para atualiza\u00e7\u00f5es simples de status. N\u00e3o suportava anexos de m\u00eddia nem notifica\u00e7\u00f5es em tempo real.<\/p>\n

        Al\u00e9m disso, o diagrama destacou um conflito entre o ator \u201cMotorista\u201d e o ator \u201cSupervisor do Armaz\u00e9m\u201d. O motorista precisava fazer o upload de dados offline, mas o supervisor precisava visualiz\u00e1-los online. Isso implicava a necessidade de armazenamento local e l\u00f3gica de sincroniza\u00e7\u00e3o, que n\u00e3o faziam parte do plano original.<\/p>\n

        Sem o diagrama, essa descoberta teria provavelmente ocorrido na fase de testes. Nesse ponto, alterar o esquema do banco de dados seria custoso. Com o diagrama, a equipe identificou o problema na fase de design.<\/p>\n

        \ud83d\udee0\ufe0f A Arquitetura Revisada<\/h2>\n

        Assim que a lacuna foi identificada, a arquitetura foi ajustada. A equipe decidiu dividir o m\u00f3dulo em duas componentes distintas:<\/p>\n

          \n
        • M\u00f3dulo Central de Entrega:<\/strong> Gerencia o escaneamento padr\u00e3o e as atualiza\u00e7\u00f5es de status.<\/li>\n
        • M\u00f3dulo de Gest\u00e3o de Exce\u00e7\u00f5es:<\/strong> Gerencia relat\u00f3rios de danos, sincroniza\u00e7\u00e3o offline e notifica\u00e7\u00f5es.<\/li>\n<\/ul>\n

          Essa separa\u00e7\u00e3o de responsabilidades simplificou o m\u00f3dulo principal. Ele poderia permanecer leve e r\u00e1pido. O m\u00f3dulo de exce\u00e7\u00f5es poderia ser mais complexo sem prejudicar o fluxo principal.<\/p>\n

          O diagrama tamb\u00e9m esclareceu as permiss\u00f5es. O caso de uso \u201cRelatar Danos\u201d foi estendido para incluir uma etapa de \u201cAprova\u00e7\u00e3o do Gerente\u201d. Isso adicionou uma camada de seguran\u00e7a que anteriormente estava ausente. O modelo visual deixou claro que nem todos os relat\u00f3rios de danos eram iguais. Alguns exigiam interven\u00e7\u00e3o imediata, enquanto outros poderiam ser registrados para revis\u00e3o posterior.<\/p>\n

          \ud83d\udcb0 Quantificando as Economias<\/h2>\n

          O impacto deste exerc\u00edcio de modelagem visual foi mensur\u00e1vel. Ao identificar os requisitos cedo, o projeto evitou uma reformula\u00e7\u00e3o significativa ap\u00f3s o in\u00edcio do desenvolvimento. A tabela abaixo resume as diferen\u00e7as entre o cen\u00e1rio \u201cSem Diagrama\u201d e o cen\u00e1rio \u201cCom Diagrama\u201d.<\/p>\n\n\n\n\n\n\n\n\n\n
          M\u00e9trica<\/th>\nSem Modelo Visual<\/th>\nCom Modelo Visual<\/th>\n<\/tr>\n<\/thead>\n
          Descoberta da Falha Cr\u00edtica<\/td>\nP\u00f3s-Desenvolvimento (Fase de Testes)<\/td>\nPr\u00e9-Desenvolvimento (Fase de Projeto)<\/td>\n<\/tr>\n
          Refatora\u00e7\u00e3o do Banco de Dados Necess\u00e1ria<\/td>\nSim (Alto Custo)<\/td>\nN\u00e3o (Planejado desde o In\u00edcio)<\/td>\n<\/tr>\n
          Impacto no Cronograma do Projeto<\/td>\nAtrasado em 4 Semanas<\/td>\nNa Cronologia<\/td>\n<\/tr>\n
          Confian\u00e7a dos Stakeholders<\/td>\nBaixa (Incerteza)<\/td>\nAlta (Confirma\u00e7\u00e3o Visual)<\/td>\n<\/tr>\n
          Esfor\u00e7o de Desenvolvimento<\/td>\n120% da Estimativa<\/td>\n100% da Estimativa<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          O custo de alterar um requisito na fase de projeto \u00e9 significativamente menor do que na fase de codifica\u00e7\u00e3o. O diagrama permitiu que a equipe calculasse o esfor\u00e7o com precis\u00e3o. Eles sabiam exatamente o que estavam construindo antes de come\u00e7arem.<\/p>\n

          \u2705 Melhores Pr\u00e1ticas para Modelagem<\/h2>\n

          Para replicar esse sucesso, as equipes devem seguir diretrizes espec\u00edficas ao criar diagramas de casos de uso. Essas pr\u00e1ticas garantem que o modelo seja \u00fatil e n\u00e3o apenas uma formalidade.<\/p>\n

            \n
          • Foque nos Objetivos do Usu\u00e1rio:<\/strong> Cada caso de uso deve representar um objetivo que o ator deseja alcan\u00e7ar. Evite etapas t\u00e9cnicas como ‘Clique no Bot\u00e3o Enviar’. Foque no resultado.<\/li>\n
          • Envolve Stakeholders:<\/strong> N\u00e3o desenhe o diagrama em isolamento. Inclua os supervisores do armaz\u00e9m e os motoristas na sess\u00e3o. Seu input \u00e9 essencial para a precis\u00e3o.<\/li>\n
          • Mantenha Simples:<\/strong> Um diagrama com cinquenta casos de uso \u00e9 dif\u00edcil de ler. Comece com os fluxos principais. Adicione detalhes apenas quando necess\u00e1rio.<\/li>\n
          • Valide as Rela\u00e7\u00f5es:<\/strong> Verifique as linhas que conectam os atores. Certifique-se de que a dire\u00e7\u00e3o do fluxo fa\u00e7a sentido. Pergunte se o ator inicia a a\u00e7\u00e3o ou a recebe.<\/li>\n
          • Itere:<\/strong> A primeira vers\u00e3o n\u00e3o ser\u00e1 perfeita. Trate o diagrama como um documento vivo. Atualize-o \u00e0 medida que novos requisitos surgirem.<\/li>\n<\/ul>\n

            Usar essas pr\u00e1ticas evita que o diagrama fique desatualizado ou irrelevante. Garante que o modelo permane\u00e7a uma ferramenta valiosa ao longo de todo o ciclo de vida do projeto.<\/p>\n

            \u274c Armadilhas Comuns a Evitar<\/h2>\n

            Mesmo com boas inten\u00e7\u00f5es, as equipes podem cometer erros ao modelar requisitos. Essas armadilhas podem levar \u00e0 confus\u00e3o, e n\u00e3o \u00e0 clareza.<\/p>\n

              \n
            • Engenharia Excessiva:<\/strong> Tentando modelar cada clique de bot\u00e3o. Isso cria ru\u00eddo e obscurece a l\u00f3gica principal. Mantenha-se em intera\u00e7\u00f5es de alto n\u00edvel.<\/li>\n
            • Ignorando Requisitos N\u00e3o Funcionais:<\/strong>Os diagramas de caso de uso focam na funcionalidade. Eles n\u00e3o mostram restri\u00e7\u00f5es de desempenho ou seguran\u00e7a. Essas devem ser documentadas separadamente.<\/li>\n
            • Assumindo Linearidade:<\/strong>Sistemas reais n\u00e3o s\u00e3o lineares. Eles t\u00eam loops, ramifica\u00e7\u00f5es e estados de erro. Certifique-se de que o diagrama reflita essa complexidade.<\/li>\n
            • Pulando Valida\u00e7\u00e3o:<\/strong>Desenhando o diagrama e depois nunca mostrando aos usu\u00e1rios. Se os usu\u00e1rios n\u00e3o concordarem com o diagrama, ele ser\u00e1 in\u00fatil.<\/li>\n
            • Confundindo Atores com Pap\u00e9is:<\/strong>Um ator \u00e9 um tipo de usu\u00e1rio, n\u00e3o uma pessoa espec\u00edfica. N\u00e3o nomeie um ator como \u201cJo\u00e3o\u201d. Nomeie como \u201cGerente de Armaz\u00e9m\u201d.<\/li>\n<\/ul>\n

              Evitar esses erros garante que o diagrama cumpra sua finalidade. Ele se torna uma ferramenta de comunica\u00e7\u00e3o, e n\u00e3o uma restri\u00e7\u00e3o t\u00e9cnica.<\/p>\n

              \ud83d\ude80 Principais Conclus\u00f5es Finais<\/h2>\n

              O estudo de caso demonstra que o modelamento visual n\u00e3o \u00e9 apenas uma etapa burocr\u00e1tica. \u00c9 um ativo estrat\u00e9gico. O diagrama de caso de uso atuou como um filtro para os requisitos. Ele detectou erros que documentos baseados em texto haviam ignorado.<\/p>\n

              Para gerentes de projeto e desenvolvedores, a li\u00e7\u00e3o \u00e9 clara. N\u00e3o dependam apenas de descri\u00e7\u00f5es textuais. Use visualiza\u00e7\u00f5es para pontuar a lacuna entre necessidades de neg\u00f3cios e implementa\u00e7\u00e3o t\u00e9cnica. Quando os requisitos s\u00e3o claros, o c\u00f3digo \u00e9 mais f\u00e1cil de escrever. Quando o c\u00f3digo \u00e9 mais f\u00e1cil de escrever, o produto tem maior qualidade.<\/p>\n

              O investimento em criar um diagrama simples se pagou muitas vezes. Evitou uma grande reformula\u00e7\u00e3o de funcionalidade. Manteve o projeto no prazo. Garantiu que o produto final atendesse \u00e0s necessidades reais dos usu\u00e1rios.<\/p>\n

              No futuro, esta organiza\u00e7\u00e3o planeja tornar o modelamento de casos de uso uma etapa obrigat\u00f3ria para todos os pedidos importantes de funcionalidade. O custo da sess\u00e3o de modelamento \u00e9 uma fra\u00e7\u00e3o do custo de retrabalho. O retorno sobre o investimento \u00e9 claro.<\/p>\n

              Priorizando clareza em vez de velocidade nas fases iniciais, as equipes podem alcan\u00e7ar velocidade e qualidade nas fases posteriores. O caminho para um projeto bem-sucedido \u00e9 pavimentado por requisitos claros. Diagramas de casos de uso s\u00e3o um mapa confi\u00e1vel para essa jornada.<\/p>\n

              Resumo das Principais Conclus\u00f5es<\/h3>\n
                \n
              • Visualiza\u00e7\u00f5es Esclarecem Ambiguidades:<\/strong>O texto pode ser interpretado de muitas formas. Um diagrama mostra exatamente como o sistema se comporta.<\/li>\n
              • Detec\u00e7\u00e3o Antecipada Economiza Dinheiro:<\/strong>Descobrir uma falha no design \u00e9 mais barato do que descobri-la em produ\u00e7\u00e3o.<\/li>\n
              • Engajamento de Stakeholders:<\/strong>Construir o modelo juntos garante que todos concordem com o escopo.<\/li>\n
              • Design Modular:<\/strong>Visualizar exce\u00e7\u00f5es ajuda na cria\u00e7\u00e3o de uma arquitetura modular e sustent\u00e1vel.<\/li>\n<\/ul>\n

                A diferen\u00e7a entre um projeto que tem sucesso e outro que enfrenta dificuldades muitas vezes depende de qu\u00e3o bem os requisitos foram compreendidos. Um diagrama simples pode fazer toda a diferen\u00e7a.<\/p>\n","protected":false},"excerpt":{"rendered":"

                No desenvolvimento de software, os bugs mais caros n\u00e3o s\u00e3o encontrados no c\u00f3digo. Eles s\u00e3o encontrados nos requisitos. Quando uma equipe de desenvolvimento constr\u00f3i um recurso com base em uma descri\u00e7\u00e3o vaga, o resultado frequentemente \u00e9 retrabalho. Esse retrabalho consome tempo, or\u00e7amento e moral. Um artefato de requisitos bem estruturado pode atuar como escudo contra esses custos. Neste estudo de caso, analisamos como uma t\u00e9cnica de modelagem visual identificou uma falha cr\u00edtica no escopo do projeto antes de uma \u00fanica linha de c\u00f3digo ser escrita. O projeto envolveu uma plataforma de log\u00edstica projetada para conectar operadores de armaz\u00e9ns com motoristas de entrega. O pedido inicial era simples: construir um m\u00f3dulo para gerenciar a entrega de pacotes. A equipe assumiu que o fluxo de trabalho era linear. No entanto, a introdu\u00e7\u00e3o de um diagrama de caso de uso revelou casos de borda complexos que o breve verbal original havia completamente ignorado. Essa interven\u00e7\u00e3o visual simples salvou a organiza\u00e7\u00e3o de uma grande reformula\u00e7\u00e3o arquitet\u00f4nica posteriormente no ciclo de vida. \ud83c\udfd7\ufe0f O Contexto do Projeto O cliente era uma empresa de cadeia de suprimentos de porte m\u00e9dio que estava expandindo sua infraestrutura digital. Eles estavam passando de um rastreamento manual para um sistema totalmente automatizado. O objetivo principal era reduzir o tempo entre a chegada de um pacote em um hub e sua atribui\u00e7\u00e3o a um motorista. O grupo de interessados inclu\u00eda gerentes de opera\u00e7\u00f5es, supervisores de armaz\u00e9m e desenvolvedores s\u00eanior. As reuni\u00f5es iniciais focaram no \u201ccaminho feliz\u201d. Este \u00e9 o cen\u00e1rio ideal em que tudo ocorre conforme o planejado. Os interessados descreveram um processo em que um motorista chega, escaneia um c\u00f3digo de barras e o sistema confirma a entrega. Todos concordaram com a cabe\u00e7a. O projeto foi aprovado. A equipe de desenvolvimento come\u00e7ou a configurar o esquema do banco de dados e os pontos finais da API. No entanto, as opera\u00e7\u00f5es raramente s\u00e3o lineares. A log\u00edstica do mundo real envolve interrup\u00e7\u00f5es, erros e exce\u00e7\u00f5es. Sem um modelo visual formal para testar os requisitos sob press\u00e3o, a equipe prosseguiu com a suposi\u00e7\u00e3o de que o sistema lidaria apenas com intera\u00e7\u00f5es padr\u00e3o. Foi nessa suposi\u00e7\u00e3o que o risco come\u00e7ou. \ud83d\udcd0 Compreendendo o Diagrama de Caso de Uso Um diagrama de caso de uso \u00e9 uma vis\u00e3o comportamental de um sistema. Ele ilustra as intera\u00e7\u00f5es entre atores externos e o pr\u00f3prio sistema. Ele n\u00e3o mostra a l\u00f3gica interna nem a estrutura do c\u00f3digo. Em vez disso, foca no \u201cquem\u201d e no \u201co que\u201d. Os componentes principais incluem: Atores:Usu\u00e1rios ou sistemas externos que interagem com o aplicativo. Neste caso, Motoristas, Funcion\u00e1rios de Armaz\u00e9m e Administradores. Casos de Uso:Objetivos ou a\u00e7\u00f5es espec\u00edficas que o ator pode realizar, como \u201cEscaneiar Pacote\u201d ou \u201cRelatar Danos\u201d. Fronteira do Sistema:A caixa que define o escopo do software. Tudo dentro \u00e9 parte do sistema; tudo fora \u00e9 o ambiente. Relacionamentos:Linhas que conectam atores a casos de uso. Elas definem o fluxo de intera\u00e7\u00e3o. Criar este diagrama obriga a equipe a articular os limites do sistema. Transforma suposi\u00e7\u00f5es impl\u00edcitas em expl\u00edcitas. Se um interessado menciona um processo que n\u00e3o se encaixa no diagrama, isso sinaliza uma lacuna nos requisitos. \ud83e\udd14 O Escopo Inicial e as Suposi\u00e7\u00f5es Antes do diagrama ser elaborado, o escopo era definido por um documento que listava recursos de alto n\u00edvel. A equipe acreditava que o escopo estava contido no m\u00f3dulo \u201cEntrega\u201d. As suposi\u00e7\u00f5es eram: O motorista sempre tem uma conex\u00e3o de internet funcional. O c\u00f3digo de barras \u00e9 sempre leg\u00edvel pelo scanner. O pacote est\u00e1 sempre no local correto. N\u00e3o h\u00e1 disputas sobre o estado do pacote. Essas suposi\u00e7\u00f5es s\u00e3o comuns nas fases iniciais de planejamento. Elas permitem que a equipe comece o trabalho rapidamente. No entanto, s\u00e3o fr\u00e1geis. Quando a realidade do ambiente de armaz\u00e9m foi introduzida, essas suposi\u00e7\u00f5es falharam. Os interessados n\u00e3o mencionaram explicitamente as exce\u00e7\u00f5es. Eles assumiram que o sistema as lidaria automaticamente. A aus\u00eancia de um modelo visual significava que ningu\u00e9m questionou a completude do fluxo at\u00e9 que fosse tarde demais. \ud83c\udfa8 Criando o Modelo Visual O l\u00edder do projeto solicitou uma revis\u00e3o formal dos requisitos usando um modelo visual. Este passo n\u00e3o fazia parte da linha do tempo inicial, mas foi introduzido para validar a arquitetura. A equipe reuniu os supervisores de armaz\u00e9m para desenhar o diagrama em um quadro branco. Esta sess\u00e3o mudou a din\u00e2mica do projeto. Em vez de discutir recursos abstratos, todos olharam para um mapa concreto do fluxo de trabalho. O diagrama foi constru\u00eddo de forma iterativa: Passo 1: Definir os Atores. Colocamos o Motorista, o Supervisor do Armaz\u00e9m e o Pr\u00f3prio Sistema como os atores principais. Passo 2: Mapear o Caminho Feliz. Desenhamos o fluxo padr\u00e3o: Motorista faz login \u2192 Escaneia o c\u00f3digo de barras \u2192 Sistema atualiza o status. Passo 3: Identificar Exce\u00e7\u00f5es. Perguntamos: \u201cO que acontece se isso der errado?\u201d Passo 4: Adicionar Relacionamentos. Conectamos as exce\u00e7\u00f5es aos casos de uso principais. \u00c0 medida que o diagrama crescia, a complexidade tornava-se vis\u00edvel. O quadro branco j\u00e1 n\u00e3o era mais uma linha simples. Ramificava-se em m\u00faltiplos caminhos. Essa evid\u00eancia visual era ineg\u00e1vel. \ud83d\udd0d A Descoberta Cr\u00edtica Durante a sess\u00e3o de modelagem, uma intera\u00e7\u00e3o espec\u00edfica foi sinalizada e havia sido ignorada. O caso de uso \u201cEscaneamento de Pacote\u201d estava conectado ao caso de uso \u201cRelatar Danos\u201d por meio de uma rela\u00e7\u00e3o \u201cExtend\u201d. Isso significava que, se um motorista escaneasse um pacote, teria a op\u00e7\u00e3o de relatar danos. O diagrama revelou uma depend\u00eancia que n\u00e3o estava no escopo inicial. Para suportar \u201cRelatar Danos\u201d, o sistema precisava capturar fotos, coordenadas de GPS e uma marca\u00e7\u00e3o de tempo. Tamb\u00e9m precisava notificar imediatamente o supervisor do armaz\u00e9m. Inicialmente, a equipe achou que se tratava de uma pequena adi\u00e7\u00e3o. O diagrama mostrou que essa funcionalidade exigia uma estrutura de dados completamente diferente. O esquema original do banco de dados era projetado para atualiza\u00e7\u00f5es simples de status. N\u00e3o suportava anexos de m\u00eddia nem notifica\u00e7\u00f5es em tempo real. Al\u00e9m disso, o diagrama destacou um conflito entre o ator \u201cMotorista\u201d e o ator \u201cSupervisor do Armaz\u00e9m\u201d. O motorista precisava fazer o upload de dados offline,<\/p>\n","protected":false},"author":1,"featured_media":4333,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[77,87],"class_list":["post-4332","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uml","tag-academic","tag-use-case-diagram"],"yoast_head":"\nEstudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade<\/title>\n<meta name=\"description\" content=\"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/\" \/>\n<meta property=\"og:locale\" content=\"pt_PT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Estudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade\" \/>\n<meta property=\"og:description\" content=\"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/\" \/>\n<meta property=\"og:site_name\" content=\"Diagrams AI Portuguese\" \/>\n<meta property=\"article:published_time\" content=\"2026-04-06T06:36:28+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1664\" \/>\n\t<meta property=\"og:image:height\" content=\"928\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"vpadmin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Escrito por\" \/>\n\t<meta name=\"twitter:data1\" content=\"vpadmin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo estimado de leitura\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/\"},\"author\":{\"name\":\"vpadmin\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"headline\":\"Estudo de Caso: Como um Diagrama de Caso de Uso Simples Evitou uma Grande Reformula\u00e7\u00e3o de Recursos\",\"datePublished\":\"2026-04-06T06:36:28+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/\"},\"wordCount\":2242,\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/wp-content\\\/uploads\\\/sites\\\/8\\\/2026\\\/04\\\/use-case-diagram-case-study-infographic-16x9-1.jpg\",\"keywords\":[\"academic\",\"use case diagram\"],\"articleSection\":[\"UML\"],\"inLanguage\":\"pt-PT\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/\",\"name\":\"Estudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/wp-content\\\/uploads\\\/sites\\\/8\\\/2026\\\/04\\\/use-case-diagram-case-study-infographic-16x9-1.jpg\",\"datePublished\":\"2026-04-06T06:36:28+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"description\":\"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#breadcrumb\"},\"inLanguage\":\"pt-PT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-PT\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/wp-content\\\/uploads\\\/sites\\\/8\\\/2026\\\/04\\\/use-case-diagram-case-study-infographic-16x9-1.jpg\",\"contentUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/wp-content\\\/uploads\\\/sites\\\/8\\\/2026\\\/04\\\/use-case-diagram-case-study-infographic-16x9-1.jpg\",\"width\":1664,\"height\":928},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/use-case-diagram-case-study-prevent-overhaul\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Estudo de Caso: Como um Diagrama de Caso de Uso Simples Evitou uma Grande Reformula\u00e7\u00e3o de Recursos\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/#website\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/\",\"name\":\"Diagrams AI Portuguese\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-PT\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\",\"name\":\"vpadmin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-PT\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"caption\":\"vpadmin\"},\"sameAs\":[\"https:\\\/\\\/www.diagrams-ai.com\"],\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/pt\\\/author\\\/vpadmin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Estudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade","description":"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/","og_locale":"pt_PT","og_type":"article","og_title":"Estudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade","og_description":"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.","og_url":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/","og_site_name":"Diagrams AI Portuguese","article_published_time":"2026-04-06T06:36:28+00:00","og_image":[{"width":1664,"height":928,"url":"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg","type":"image\/jpeg"}],"author":"vpadmin","twitter_card":"summary_large_image","twitter_misc":{"Escrito por":"vpadmin","Tempo estimado de leitura":"11 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#article","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/"},"author":{"name":"vpadmin","@id":"https:\/\/www.diagrams-ai.com\/pt\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"headline":"Estudo de Caso: Como um Diagrama de Caso de Uso Simples Evitou uma Grande Reformula\u00e7\u00e3o de Recursos","datePublished":"2026-04-06T06:36:28+00:00","mainEntityOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/"},"wordCount":2242,"image":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg","keywords":["academic","use case diagram"],"articleSection":["UML"],"inLanguage":"pt-PT"},{"@type":"WebPage","@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/","url":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/","name":"Estudo de Caso de Diagrama de Caso de Uso: Evitando Reestrutura\u00e7\u00e3o de Funcionalidade","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#primaryimage"},"image":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg","datePublished":"2026-04-06T06:36:28+00:00","author":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"description":"Descubra como um diagrama de caso de uso visual salvou o or\u00e7amento de um projeto. Aprenda t\u00e9cnicas de an\u00e1lise de requisitos para evitar retrabalho caro em software e mudan\u00e7as arquitet\u00f4nicas.","breadcrumb":{"@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#breadcrumb"},"inLanguage":"pt-PT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/"]}]},{"@type":"ImageObject","inLanguage":"pt-PT","@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#primaryimage","url":"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg","contentUrl":"https:\/\/www.diagrams-ai.com\/pt\/wp-content\/uploads\/sites\/8\/2026\/04\/use-case-diagram-case-study-infographic-16x9-1.jpg","width":1664,"height":928},{"@type":"BreadcrumbList","@id":"https:\/\/www.diagrams-ai.com\/pt\/use-case-diagram-case-study-prevent-overhaul\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.diagrams-ai.com\/pt\/"},{"@type":"ListItem","position":2,"name":"Estudo de Caso: Como um Diagrama de Caso de Uso Simples Evitou uma Grande Reformula\u00e7\u00e3o de Recursos"}]},{"@type":"WebSite","@id":"https:\/\/www.diagrams-ai.com\/pt\/#website","url":"https:\/\/www.diagrams-ai.com\/pt\/","name":"Diagrams AI Portuguese","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.diagrams-ai.com\/pt\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-PT"},{"@type":"Person","@id":"https:\/\/www.diagrams-ai.com\/pt\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12","name":"vpadmin","image":{"@type":"ImageObject","inLanguage":"pt-PT","@id":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","caption":"vpadmin"},"sameAs":["https:\/\/www.diagrams-ai.com"],"url":"https:\/\/www.diagrams-ai.com\/pt\/author\/vpadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/posts\/4332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/comments?post=4332"}],"version-history":[{"count":0,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/posts\/4332\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/media\/4333"}],"wp:attachment":[{"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/media?parent=4332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/categories?post=4332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/pt\/wp-json\/wp\/v2\/tags?post=4332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}