# Regras Básicas de BPMN ## **Algumas regras básicas de BPMN:** **Fluxos de Sequência (Sequence Flow)** * São utilizados para mostrar a ordem em que as atividades serão executadas num processo. * Não podem atravessar os limites de um Subprocesso. * Não podem atravessar os limites de uma Piscina (Pool). **Fluxos de Mensagem (Message Flow)** * São utilizados para mostrar a comunicação entre Participantes. * Não podem ligar objetos que estejam dentro da mesma Piscina. **Eventos de Limite (Boundary Events)** ✪ Devem ter no máximo um Fluxo de Sequência de saída. * Não devem ter qualquer Fluxo de Sequência de entrada. **Subprocesso** ✪ Um Evento de Início num Subprocesso deve ser do tipo "Nenhum" (None). *** ## **Boas Práticas de Convenções de Nomenclatura BPMN** Embora não existam convenções oficiais de nomenclatura em BPMN, estas são algumas boas práticas reconhecidas ao longo dos anos: ✪ **Utilizar sempre palavras-chave com significado para o negócio** * Não usar abreviações incomuns * Não incluir o tipo de elemento no nome * Evitar artigos e pronomes *** **Atividades** ✪ Todas as atividades devem ser nomeadas\ ✪ Nomear atividades com uma frase **Verbo-Substantivo** * Usar o tempo presente de um verbo ativo com significado para o negócio * Usar um substantivo qualificado com significado para o negócio * Não nomear várias atividades com o mesmo nome (exceto Atividades de Chamada – *Call Activities*) *** **Decisores (Gateways)** ✪ Os decisores não executam trabalho nem tomam decisões; são apenas uma visualização da divergência ou convergência do fluxo * Não nomear decisores de convergência * Associar uma anotação de texto quando a lógica de convergência não for óbvia\ ✪ Nomear decisores exclusivos de divergência com uma **frase interrogativa** *** **Fluxos de Sequência** ✪ Nomear fluxos de sequência que saem de decisores de tipo Exclusivo, Inclusivo e Complexo com as **condições associadas expressas como resultados**\ ✪ Nomear fluxos de sequência condicionais com as **condições associadas expressas como resultados** * Não nomear fluxos de sequência por defeito *** **Eventos** ✪ Todos os eventos devem ser nomeados\ ✪ Nomear eventos de Mensagem, Sinal, Escalada e Erro com um **particípio passado** de um verbo ativo\ ✪ Nomear eventos de Ligação com um **substantivo**\ ✪ Nomear eventos emparelhados (Mensagem, Ligação, Sinal, Escalada e Erro) com o **mesmo nome**\ ✪ Nomear eventos de Temporizador com o seu **cronograma**\ ✪ Nomear eventos condicionais com a sua **condição de disparo**\ ✪ Nomear eventos de fim com o **nome do estado final** *** **Objetos de Dados** ✪ Todos os objetos de dados devem ser nomeados * Nomear objetos de dados com um **substantivo qualificado** que represente um objeto ou informação relevante para o negócio\ ✪ Nomear múltiplas instâncias do mesmo objeto de dados (referências) com o **mesmo nome seguido do estado aplicável entre parênteses retos** `[Estado]` *** **Participantes** ✪ Nomear participantes com um **substantivo qualificado ou uma frase nominal** *** **Funções (Roles)** ✪ Nomear funções com um **substantivo qualificado ou uma frase nominal** *** **Piscinas (Pools)** ✪ Nomear piscinas com o **nome do participante** * Não nomear piscinas com o nome do processo * Em BPMN, uma piscina representa um participante *** **Faixas (Lanes)** ✪ Nomear faixas com o **nome da categoria** * As faixas são frequentemente usadas para categorizar elementos por função (Role) *** ## **Boas Práticas de Modelação BPMN** **Âmbito do Processo** ✪ Define claramente o âmbito do processo, identificando o **Quem, O Quê, Quando, Onde e Porquê** (o processo representa o **Como**)\ ✪ Identifica o que cada instância do processo irá representar * As instâncias são discretas e identificáveis: podem ser referidas individualmente e contadas\ ✪ Identifica as formas alternativas de iniciar o processo, utilizando **Eventos de Início**\ ✪ Identifica os estados finais alternativos das instâncias do processo, utilizando **Eventos de Fim** *** **Disposição dos Diagramas** ✪ Procura criar diagramas BPMN que caibam numa única página\ ✪ Organiza os diagramas de forma limpa para facilitar a leitura, minimizando cruzamentos de fluxos\ ✪ Usa uma disposição consistente com **fluxos de sequência horizontais** e **associações de dados e fluxos de mensagem verticais** * Os diagramas BPMN não representam uma ordem temporal estrita (é possível haver ciclos), mas a maioria dos leitores espera uma disposição da esquerda para a direita\ ✪ Evita disposições em ziguezague dos elementos\ ✪ Deve ser claro qual é o caminho principal (“Happy Path”) do processo\ ✪ Sempre que possível, **externaliza as regras de negócio** do processo para criar modelos mais concisos e ágeis, utilizando **Tarefas de Regra de Negócio**\ ✪ Cria visualizações alternativas do mesmo processo para diferentes propósitos de comunicação e públicos. Por exemplo:\ ❖ Um diagrama **resumido**, com todos os subprocessos e atividades de chamada colapsados, sem mostrar objetos de dados\ ❖ Um diagrama **detalhado**, com todos os subprocessos e atividades de chamada expandidos, mostrando todos os objetos de dados e anotações *** **Partição e Estrutura do Processo** ✪ Cria **camadas hierárquicas** de detalhe para o processo\ ✪ Usa **Subprocessos** para dividir o processo em “fases”\ ✪ Usa **Atividades de Chamada (Call Activities)** para reutilizar outros processos *** **Eventos de Início e Fim** ✪ Utiliza sempre eventos de início e fim\ ✪ Distingue diferentes formas de iniciar o processo com eventos de início separados\ ✪ Distingue diferentes estados finais com eventos de fim separados\ ✪ Os fluxos que terminam no mesmo estado final devem convergir para o mesmo evento de fim *** **Decisores (Gateways)** ✪ Utiliza sempre decisores para representar divisões ou junções de fluxos * Não utilizar decisores em modo misto (divergente e convergente ao mesmo tempo)\ ✪ Coloca sempre uma atividade que determine a condição de divergência **antes** de um decisor divergente dos tipos Exclusivo, Inclusivo ou Complexo * Esta prática permite que a atividade de decisão possa ser interrompida, se necessário\ ✪ Abstrai cadeias de decisores divergentes em **Tarefas de Regra de Negócio** * Esta prática simplifica diagramas sobrecarregados *** **Colaborações** * Não modeles o processo interno em foco dentro de uma piscina (Pool) * Sem uma piscina para rotular, evita-se a má prática de nomear a piscina com o nome do processo #### 📌 **Resumo visual da prática recomendada:** | Situação | Usar Piscina? | Onde indicar o nome do processo? | | -------------------------------------------- | ------------- | -------------------------------------- | | Modelação de processo interno | ❌ Não | Título do diagrama ou anotação | | Modelação de colaboração entre participantes | ✅ Sim | Nome da piscina = nome do participante | *** Quando estás a modelar um processo com **vários participantes**, e decides representá-los dentro de **Lanes (Faixas)** agrupadas numa **Pool (Piscina)**, aqui está a forma recomendada de nomear cada elemento: *** #### 🏊‍♂️ **Pool (Piscina)** * **Nome da Pool**: deve representar o **participante principal** — por exemplo, uma organização, departamento ou sistema que executa o processo. * **Não** deve ser o nome do processo. * Exemplos: * `CGI Portugal` * `Sistema de Gestão de Pedidos` * `Departamento de Recursos Humanos` *** #### 🛤️ **Lanes (Faixas)** * **Nome das Lanes**: deve representar **categorias funcionais ou papéis (roles)** dentro do participante. * Cada Lane mostra **quem executa o quê** dentro do processo. * Exemplos: * `Gestor de Projeto` * `Consultor` * `Sistema de Faturação` * `Cliente` *** #### 📌 Exemplo prático: Imagina que estás a modelar um processo de **gestão de pedidos** dentro da CGI: * **Pool**: `CGI Portugal` * **Lanes**: * `Comercial` * `Delivery` * `Financeiro` * `Cliente` *** #### 🧠 Dica adicional: > Se o processo envolver **vários participantes externos**, considera usar **várias Pools**, cada uma com as suas próprias Lanes, para representar a colaboração entre entidades. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ulht-jcb.gitbook.io/fundamentals-of-information-systems/documentation/ligacoes-rapidas/images-and-media.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.