modelagem de sistemas -...
TRANSCRIPT
MODELAGEM DE SISTEMAS Da Orientação a Objetos à UML
UHLMANN, Erwin A. Título do trabalho. Instituto Siegen. Guarulhos, 2015
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 1 64
Agradecimentos
Agradeço à minha esposa Kátia por entender minha ausência, meu filho Henrique que me motiva trabalhar (!!!), meus pais Mirtes e Günter por terem criado meu caminho, aos meus alunos que viabilizaram este trabalho e a todos os autores de livros e bibliotecas que consultei para que pudesse devidamente embasar este.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 2 64
Sumário Modelagem de Sistemas 1
Agradecimentos 2Sumário 3Modelagem de Sistemas 5Orientação a Objetos 5Objeto 5Programação Orientada a Objeto 10Introdução à UML 12Diagramas 13Diagrama de Casos de Uso 13Scripts 13Atores 14Casos de Uso 14Associação 15Generalização ou Especialização 16Include 16Extend 17Multiplicidade 17Estereótipos 18Exercício 1 18Documentação de Casos de Uso 19Fluxo das Informações 19Exercício 2 19Diagrama de Casos de Uso 20Documentação de Casos de Uso 21Fluxo das Informações 22Diagrama de Classes 23Relacionamentos ou Associações 23Diagrama de Objetos 29Diagrama de Sequência 31Diagrama de Sequência 31Diagrama de Colaboração 32Sistema de Login 34Diagrama de Atividades 35
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 3 64
Diagrama de Componentes 36Modelagem de Processos de Negócios - BPM 38Um guia para iniciar estudos em BPMN (I): Atividades e sequência | Blog da iProcess38Um guia para iniciar estudos em BPMN (II): Gateways | Blog da iProcess 42Gateway exclusivo (Databased Exclusive Gateway) 43Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim | Blog da iProcess
47Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários | Blog da iProcess
52Um guia para iniciar estudos em BPMN (V): Subprocessos | Blog da iProcess 58Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos | Blog da iProcess
60
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 4 64
Modelagem de Sistemas Orientação a Objetos A Orientação a Objetos (OO) é um paradigma de programação concebido para o
reaproveitamento de códigos em um mesmo software ou em outros externos.
A OO se vale de conceitos do mundo real para facilitar a programação, melhorar a
qualidade do software, aumentar a produtividade e facilitar a manutenção, ou seja, a
manutenabilidade e a documentação.
Um objeto é uma entidade que possui uma identificação própria. Este é um conceito
importante, pois cada objeto deve ser único e identificável. Os objetos podem
compartilhar aspectos semelhantes, comportamentos idênticos e até os mesmos
atributos. Quando objetos apresentam os mesmos atributos e comportamentos, eles são
agrupados em classes. As classes então possuem objetos, chamados de instâncias e
elas é que são as chamadas para ativarem os objetos. Vamos ver os exemplos:
Objeto Um Objeto é como no mundo real algo tátil(exceto por isto!), que possui determinadas
características (Atributos ou Propriedades) e tem alguma utilidade (Método, Operação
ou Comportamento) e pertencem a algo ou alguém (Visibilidade[Público, Protegido,
Privado ou Pacote]).
Para construir no plantUML:
@startuml object computador @enduml
Atributos ou Propriedades
Os atributos de um Objeto possuem dois tipos de dados: Nome e tipo de dados.
O Nome, de forma geral, remete ao que o Atributo contém, como no Objeto Casa, o
Atributo Cômodo remete à um cômodo da casa e o Tipo de dado, também de forma
geral, é relacionado o que deve conter, como o numero (integer) de cômodos ou o
nome (character) deles.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 5 64
No plantUML:
@startuml object computador 'o atributo é marcado pelo[] computador: atributo[] @enduml
Podem haver vários atributos, como:
E no plantUML:
@startuml object computador computador: processador[] computador: memoriaRam[] computador: discoRigido[] computador: dispositivoDeEntrada[] computador:dispositivosDeSaida[] @enduml
Métodos, Operações ou Comportamentos
As Operações são as determinações de ação de um Objeto. Elas obedecem os
parâmetros determinados em programação e estes parâmetros atendem os valores. Um
parâmetro típico é o “H” de hora da função date. O valor é recebido pelo sistema.
Outro exemplo de parâmetro é “$_POST[]” que recebe os dados escritos num
formulário. O valor é o que é digitado pelo usuário. Uma Operação então é o
descritor das atividades de um objeto.
@startuml 'object computador computador : processador[] computador : memoriaRam[] computador : discoRigido[] computador : dispositivoDeEntrada[] computador : dispositivosDeSaida[] computador : realizaCalculos() @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 6 64
Visibilidade
Podem ser quatro estados: Público, Protegido, Privado ou Pacote.
@startuml comput : (-) privado[] comput : (+) público[] comput : (#) protegida() comput : (˜) pacote() @enduml
Público
Qualquer objeto pode utilizar um Atributo público. É representado pelo símbolo “+”.
Uma Operação ou Atributo público de exemplo são os dispositivos de entrada e saída
de um computador, pois qualquer computador da rede
pode utilizá-los.
@startuml computador : processador[] computador : memoriaRam[] computador : discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : realizaCalculos() @enduml
Privado
São os Atributos ou Métodos que podem ser utilizados somente pelo Objeto pai. É
representado pelo símbolo “-“, como a memória RAM, o HD ou o processador.
@startuml computador : - processador[] computador : - memoriaRam[] computador : - discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : realizaCalculos() @enduml
Protegida
É representada pelo símbolo “#” e pode ser visualizada pela classe pai e as subclasses.
As classes relacionada não visualizam. Um exemplo é o método ou operação do objeto
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 7 64
computador. Seus dados podem ser visualizados por todos os componentes, mas
somente por eles, por outro objeto não.
@startuml computador : - processador[] computador : - memoriaRam[] computador : - discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : # realizaCalculos() @enduml
Pacote
Representado pelo “˜”, o o pacote pode ser visualizado pelos que pertencerem a ele,
ou seja, os objetos que pertençam ao pacote podem visualizar. O monitor e o teclado
não foram retratados aqui, mas fazem parte do pacote em que o computador está
inserido.
@startuml teclado : ~exibeDados() @enduml
Herança
A Herança é um dos mais importantes conceitos da Orientação a Objetos. Ela garante
que os Atributos e Operações do Objeto pai ou Superobjeto sejam aproveitados em
código pelos objetos filhos ou subobjetos. Um o exemplo de herança é um sistema de
login e senha. A busca do login que pode ser o e-mail e a senha. O e-mail pode ser
público e a senha protegida, logo privada. No entanto outros objetos protegidos
podem prec i sar do e -mai l ,
herdando sua validação, não
apenas o dado.
@startuml sistLogin : + email[] sistLogin : #senha[] sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog() sistInsDados : ~ email[] sistInsDados : gravarDados() sistLogin <|-- sistLog sistLogin <|-- sistInsDados @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 8 64
Herança Múltipla
Assim como a Herança simples, a múltipla recebe ou herda dados de mais de um
objeto. Como é possível notar, o Atributo dataEHora do Objeto sistLog é público e o
A t r i bu t o ema i l do Ob j e t o
sistInsDados é privado a todos
que pertençam ao pacote, logo
um novo Objeto herdará estes
atributos.
@startuml sistLogin : + email[] sistLogin : #senha[]
sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog()
sistInsDados : ~ email[] sistInsDados : gravarDados()
relatorios : email[] relatorios : dataEHora[] relatorios : imprimirRelatorios()
sistLogin <|-- sistLog sistLogin <|-- sistInsDados sistLog <|-- relatorios sistInsDados <|-- relatorios @enduml
Polimorfismo
Polimorfismo é um método de reutilizar um objeto em outro objeto especializando-o, ou
seja, se em um objeto que realiza determinada Operação é necessário em outro objeto
porém com alguma especialização, isto constitui o polimorfismo. Ex.: Imagine um
código que exiba números em ordem decrescente. Em outro ponto do software
(pacote), você precisa exibir os três primeiros ou os três últimos colocados. Para quê
reprogramar? Herde o métodos e decida como utilizá-los.
Outro caso: Em um banco cliente é um objeto. Todos os clientes obedecem a uma regra
básica: Quanto e quando depositou, quanto e quando retirou. Só isto já é difícil de
controlar! Imagine quando você altera o status de um destes clientes, mas não de
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 9 64
todos(-), para cliente especial, com crédito, ou seja, cheque especial. Quanto a mais
pode retirar e quanto e quando vai pagar?
@startuml sistLogin : + email[] sistLogin : #senha[] sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog() sistInsDados : ~ email[] sistInsDados : gravarDados() sistLogin <|-- sistLog sistLogin <|-- sistInsDados @enduml
Programação Orientada a Objeto Na programação, o Objeto é representado nesta linguagem pela function e seu nome é
hora. Ignore a linguagem. O resultado é a exibição da hora atual, este é seu atributo.
function hora(){ $hora = date('H:i:s'); echo $hora; }
Se imaginarmos o seguinte novo objeto:
function data(){ $data = date('d/m/Y'); echo $data; }
Os objetos hora e data possuem o mesmo comportamento: Exibir uma informação,
especificamente informações sobre data e hora, então eles podem pertencer à mesma
classe, a classe tempo.
class Tempo{ function hora(){ $hora = date(‘H:i:s’); echo $hora; } function data(){ $data = date(‘d/m/Y’);
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 10 64
echo $data; } }
A classe Tempo possui duas instâncias, hora e data, e para chamar seu resultado, ou
dispará-lo, por assim dizer, é preciso instanciá-lo. Mais uma vez ignore a linguagem.
$instancia = new Tempo; $instancia -> hora();
Todas vez que seu programa precisar exibir a hora atual, basta instanciar o objeto
hora(). Isto reduz o número de linhas de programação e pode-se aproveitar este
código em outros softwares. Outra vantagem da Orientação a Objetos é o
Polimorfismo, ou seja, o programa se comporta conforme o ambiente. Como ignoramos
a linguagem, esta impressão de hora é estática, isto é, ocorre apenas uma vez, mas e
se chamarmos este objeto em um looping? A hora irá mudar a cada novo segundo!
O programa é o mesmo, mas o comportamento muda conforme o meio! Polimorfismo!
$instancia = new Tempo; $instancia -> hora(); for($i=$instancia+60;$i<$instancia;$i++){ $instancia; }
Herança é o comportamento da OO para os atributos de um objeto poderem ser
incorporados por um novo objeto, aproveitando um código já escrito, sendo assim, a
classe pai, envia os dados para a classe filho.
class Pai{ $valor = '1, 2, 3, 4, 5'; strrev($valor); } class Filho extends Pai{ $parteValor = substr($valor, 0, 4); echo $parteValor; }
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 11 64
Introdução à UML O projeto do software é um esquema visual que permite a criação do projeto antes de
sua execução ou programação. A Unified Modeling Language (UML), para Guedes
(2011) é uma linguagem visual utilizada para modelar softwares baseados no
paradigma da orientação a objetos. O autor explica ainda que a programação
orientada a objetos é um método de atribuir identidade a scripts que realizem funções
específicas e pertençam a uma parte maior de um software.
A UML é constituída de 14 diagramas com especificidades e representações para
diversas situações, como explica Guedes (2011).
Para criarmos os diagramas, vamos utilizar o NetBeans 8.0 (https://netbeans.org/),
com o plugin PLantUML (http://plugins.netbeans.org/plugin/49069/plantuml) e o
Graphviz(http://www.graphviz.org/) como gerador de imagens.
ArgoUML (http://argouml.tigris.org/)
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 12 64
Diagramas
Diagrama de Casos de Uso O diagrama de Casos de Uso, comumente chamado de UC, por questões óbvias, é
normalmente o primeiro a ser desenvolvido. Isto por que ele permite a primeira visão
do sistema numa rápida conversa com o cliente e sua demonstração do uso, da
dinâmica do software, além disto ele serve como guia para o desenvolvimento deste e
é recorrentemente consultado e alterado para se adequar.
O Diagrama de Casos de Uso tem por objetivo apresentar a visão externa das
funcionalidades do sistema, isto é, a visão do usuário sobre o uso do sistema, sem se
preocupar com a implantação destas funções.
Para criar um Diagrama de Casos de Uso é preciso compô-lo de:
Scripts @startuml title Exemplos de Sintaxe de Casos de Uso
'direcionamento 'left to right direction 'top to bottom direction
(Caso de Uso) usecase (Caso de Uso Dois) as CUD :Ator 1: actor Ator2 actor :Outro Ator: as OA
'relação entre atores e casos de uso
:Ator 1: -- (Caso de Uso) 'Uma declarado como ator, chame somente o nome Ator2 -> CUD OA --> (Terceiro \nCaso de Uso) :Ator 4: ---> (Caso de Uso) : Uma mensagem simples
'extensão 'O Caso de Uso Dois leva ao Outro Ator OA <|-- CUD Ator2 --|> OA
'notas de projeto note right of :Ator 4: : Nota de projeto note "Nota em meio de caminho" as N2 CUD .. N2 N2 .. (Terceiro \nCaso de Uso)
'direções e ligações
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 13 64
:AtorCentral: (CasoDeUso1) (CasoDeUso2) (CasoDeUso3) (CasoDeUso4) :AtorCentral: -left- (CasoDeUso1) : associação :AtorCentral: -up-> (CasoDeUso2) : link ou encaminhamento :AtorCentral: .right.> (CasoDeUso3) : <<include>> inclusão :AtorCentral: <.down. (CasoDeUso4) : extensão <<extend>> @enduml
Atores Representa qualquer elemento externo que interaja com o sistema, podendo ser um
usuário, um hardware ou outro software.
@startuml :Ator: @enduml
Casos de Uso Os Casos de Uso servem para expressar o comportamento primário ou secundário de
um sistema. Quando primário ele é associado às funções para o qual o software foi
concebido e o secundário para funções de manutenção, por exemplo.
Num sistema de cadastro de usuário, o cadastro é a função primária e a edição destes
dados é a função secundária.
@startuml (Caso de Uso) @enduml
Os atores acessam as funcionalidades de um sistema, desta forma eles representam
fracamente um descritivo destas funções, como segue:
@startuml :Usuário: --> (Cadastro de usuário) :Usuário: --> (Editar cadastro) @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 14 64
No plantUML, você pode definir o ator entre dois pontos ou especificá-lo como actor,
veja:
@startuml 'actor Ator 'ou :Ator: @enduml
O Caso de Uso possui, de forma geral, uma documentação que descreve de forma
sucinta a sequencia de ações do sistema.
Observe que no ator principal, o texto “além de todo conteúdo” foi tachado, pois não
pertence ao Caso de Uso UC 01 que descreve ações de acesso ao sistema.
A continuidade é o descritivo do fluxo de ações do sistema.
Associação é a relação criada entre atores e atores ou casos de uso e casos de uso dentro de um
diagrama. Exemplos:
@startuml :Cliente: -- (Cadastro de clientes) :Cliente: -- (Edita cadastro) :Suporte: -- (Edita cadastro) :Cliente: -- Suporte (Edita cadastro) -- (Cadastro de clientes) : Verifica existência \n do cadastro
Nome do Caso de Uso Descrição
UC 01 Acesso ao sistema
Ator principal: Diretor Cadastra usuários, edita e exclui, além de todo conteúdo
Ator secundário: Gerente Cadastra usuários
Ator terciário: Funcionário Acessa o sistema
Ator quaternário: Usuário Não pode acessar
Nome do Caso de Uso Descrição
UC 01 Acesso ao sistema
1 - Ator solicita acesso por login e senha
2 - Sistema busca no Banco de Dados o login
3 - Caso o usuário seja encontrado, solicita a senha
4 - Caso a senha esteja correta, permite acesso, senão solicita o cadastro
5 - Abre a sessão
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 15 64
@enduml
Generalização ou Especialização O diagrama de Especialização ou Generalização
determina um plano abstrato e o decompõe em níveis mais
baixos, veja:
@startuml (Usuário Diretor) -up-> (Usuário) (Usuário Gerente) -up-> (Usuário) (Usuário Funcionário) -up-> (Usuário) @enduml
Também se especifica as permissões, como segue:
@startuml :Diretor: -- (Cadastra, edita e exclui usuário) :Gerente: -- (Cadastra usuários) :Funcionário: -- (Acessa o sistema) @enduml
Include É utilizado quando uma função é recorrente em um sistema, assim um Caso de uso ou
ator pode chamar este processo e incluí-lo no sistema. De forma geral, o Include é
utilizado quando você deve consultar outro processo para concluir o primeiro, este
outro processo é o Include.
@startuml :Ator 1: --> (Acesso ao Sistema) (Acesso ao Sistema) ..> (Log do sistema) :Ator 2: --> (Excluir dados)
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 16 64
(Excluir dados) ..> (Log do sistema) @enduml
O Include é representado pelo
tracejado.
Extend É indicado quando uma excessão
é executada ou uma condição
específica, como um cadastro que
é feita apenas na primeira vez. No extend, em
oposição ao Include, a seta é invertida. De
maneira ampla, o Extend é utilizado quando o
processo primário não pode concluir o serviço,
então chama-se outro extenso a ele, como uma
condição.
@startuml :Usuário: --> (Acesso ao Sistema) (Acesso ao Sistema) ..> (Log do sistema)
note "Caso não tenha cadastro \n (Opicional)" as nota1
(Acesso ao Sistema) <.. nota1 nota1 .. (Cadastro de usuário) :Funcionário: --> (Excluir dados) (Excluir dados) ..> (Log do sistema)
note "Confirmação de motivo \n(Opcional)" as nota2
:Funcionário: <.. nota2 nota2 .. :Usuário: @enduml
Multiplicidade Um para muitos ou um para um. Um processo pode ser chamado n vezes por um ator
ou o inverso.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 17 64
Estereótipos Para representar processos, utiliza-se os sinais << e >>, assim, o processo de validação
de acesso ao sistema, pode ser representado apenas como:
@startuml (<<Acesso>> \n Acesso ao sistema) @enduml
Exercício 1 Crie a UML de um sistema de login simples com validação de login e recriação e
validação de sessão (caso correto) e três páginas protegidas e uma de cadastro.
@startuml title Sistema de login simples left to right direction (Acesso ao Sistema) as AS (Valida Login) as VL (Cadastro) (Página Protegida 1) as PP1 (Página Protegida 2) as PP2 (Página Protegida 3) as PP3 (Valida Sessão) as VS (Menu de Acesso) as MA :master: -- AS :funcionário: -- AS AS --|> VL VL ..> (Cadastro) : <<extend>> VL --|> PP1 PP1 <.. VS : <<include>> PP1 <.. MA : <<include>> PP2 <.. VS : <<include>> PP2 <.. MA : <<include>> PP3 <.. VS : <<include>> PP3 <.. MA : <<include>> (Cadastro) <.. VS @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 18 64
Documentação de Casos de Uso
Fluxo das Informações
Exercício 2 Crie um sistema de controle de petshop. Seus requisitos são:
• Agenda de serviços, animais e clientes;
• Tipo de serviço: Consulta veterinária ou petshop (banho)?;
• Dados par ao serviço (Doença, tosa, castração…);
• Exames a serem marcados pelo veterinário;
Casos de Uso de Login Descritivo
UC 01
Ator Cliente 1 - Acessa o sistema
2 - Acessa cadastro de usuário
3 - edita dados próprios se cadastrado
4 - exclui-se do BD
Ator Master 1 - Acessa o sistema
2 - Acessa cadastro de usuário
3 - edita dados próprios se cadastrado
4 - exclui-se do BD
5 - Inclui novos usuários
6 - Exclui usuários
7 - Edita dados de usuários
7.1 - Edita o tipo de usuário como adm/usuário
Casos de uso de Login
Requisição Resposta
1 - Acessa o sistema
2 - Sistema procura do BD o email e a senha
3 - usuário entra no sistema
4 - acessa página de edição de dados
5 - sai do sistema
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 19 64
• A secretária é o ator agenciador entre clientes, veterinários e agenda do petshop.
Diagrama de Casos de Uso
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 20 64
@startuml title <b>Casos de Uso de uma veterinária</b> :Animal: :Cliente: :Secretária: :Veterinário: :Tratador: :Animal: -- :Cliente: :Cliente: -- :Secretária: :Secretária: -- (Serviço) : acessa | \nconsulta (Serviço) <-- (Serviço veterinário) (Serviço) <-- (Serviço petshop) :Secretária: -- (Agenda) : acessa | \nconsulta :Secretária: -- (Cadastro veterinário) :Secretária: -- (Cadastro tratador) :Secretária: -- (Cadastro clientes) :Secretária: -- (Cadastro animais) (Cadastro clientes) <.. (Cadastro animais) : <<include>> (Serviço) <.. (Agenda) : <<include>> (Insumos veterinários) <.. (Serviço) : <<include>> :Veterinário: -- (Insumos veterinários) : informa :Veterinário: -- (Cadastro veterinário) (Cadastro veterinário) ..> (Autocadastro) : <<extend>> (Autocadastro) <.. (Tipo função) : <<include>> :Veterinário: -- (Serviço) :Veterinário: -- (Agenda) :Veterinário: -- (Serviço veterinário) note bottom of (Serviço veterinário) : Cadastra novos serviços (Insumos petshop) <.. (Serviço) : <<include>> :Tratador: -- (Insumos petshop) : informa :Tratador: -- (Cadastro tratador) (Cadastro tratador) ..> (Autocadastro) : <<extend>> :Tratador: -- (Serviço) :Tratador: -- (Agenda) :Tratador: -- (Serviço petshop) note bottom of (Serviço petshop) : Cadastra novos serviços @enduml
Documentação de Casos de Uso Casos de Uso Agenda Veterinária Descritivo
UC 01 Acesso à Agenda
Ator Secretária 1 - Consulta horários, agenda novos e desmarca;
2 - Consulta serviços
3 - Cadastra, edita e exclui clientes e animais, veterinários e tratadores.
4 - Emite relatórios
Ator Veterinário 1 - Cadastra-se como veterinário (validado pelo CPF)
2 - Cadastra novos serviços de veterinária
3 - Consulta e marca novos compromissos na agenda
Casos de Uso Agenda Veterinária
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 21 64
Fluxo das Informações
Ator Tratador 1 - Cadastra-se como novo Tratador (validado pelo CPF)
2 - Cadastra novos serviços de petshop
3 - Consulta e marca novos compromissos na agenda
Ator Cliente 1 - Consulta verbalmente o Ator Secretária
Ator Animal 1 - Dependente do Ator Cliente
DescritivoCasos de Uso Agenda Veterinária
Casos de uso da Veterinária
Requisição Resposta
1 - O Cliente entra em contato com o Ator Secretária solicitando uma consulta
2 - O Ator Secretária questiona o tipo de serviço
3 - O Ator Cliente descreve o tipo de serviço: Veterinário ou petshop
4 - O Ator Secretária, consulta na Agenda o Serviço e verifica as datas e horários disponíveis por profissional Veterinário ou Tratador;
5 - O Ator Cliente concorda com a data
6 - O Ator Secretária solicita os dados do Ator Cliente, caso não exista no sistema, deve ser cadastrado e o Ator Animal cadastrado como dependente do Ator Cliente; O Ator Secretária associa o profissional ao cliente na data e horário solicitado.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 22 64
Diagrama de Classes O Diagrama de Classes é um dos mais importantes da UML, servindo de base para
outros. Este diagrama serve para projetar, documentar ou mesmo compreender como
um software foi projetado e como as métodos dos objetos interagem, servindo de base
para os diagramas de Sequência, Estados e Comunicação.
Uma Classe é um elemento que contém diversos objetos que tenham as mesmas
características ou aspectos. Ex.: A Classe Login reúne os Objetos ValidaLogin,
ValidaSessao e LogDeErros. Todos eles servem ao login. Neste diagrama podem ser
definidos Atributos como a Visibilidade, Tipo de Dados, Multiplicidade e Propriedade.
Um Diagrama de Classe exibe o nome da Classe a qual pertence, seus atributos
(nomeArquivo[], numLink[] e conteudoLink[]), o tipo
de dado que compõe o atributo (varchar, int, date,
etc) e na parte inferior os métodos, ou seja, as ações
que a classe executa, neste caso, imprimir o nome do
link (imprimeNomeLink()). Além destes elementos,
também é possível descrever a visibilidade do atributo
ou o método (privado(-), público(+), protegido(#) ou pacote(˜)).
Relacionamentos ou Associações Classes e objetos podem se relacionar de diversas formas para permitir o
funcionamento do software. O tipo de relação determina como é esta relação, vejamos:
Relação Unária ou Reflexiva
A relação uniria ou reflexiva
descreve a relação entre objetos
de uma mesma classe. Como um
c o n t a d o r d e e l e m e n t o s é
chamado para construir uma laço
de repetição em outro objeto.
Ela pode expressar de forma
simplificada, também a hierarquia
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 23 64
dos relacionamentos e o numero de chamados. Estes chamados podem ser 0..*, ou
seja, não há chamado de um elemento, porém muitos de outro, 1..* como um chefe tem
vários funcionários, um elemento chama muitos de outro, 1..1 um elemento se relaciona
com outro diretamente como uma chamada telefônica e determinado, como 5 gerentes
se relacionam com 8 funcionários.
Binária
É a associação mais simples. O contratante de um plano de
saúde possui dependentes, estes não comandam nem
enviam dados ao contratante, porém ele determina o tipo
de contrato de todos.
Navegabilidade
@startuml class contratante contratante : -salárioDebito[] contratante : +planoSaúde[] contratante : #agregaDependentes()
class dependente dependente : +planoSaúde[]
contratante "possui" --> "0..*" dependente @enduml
Associação Ternária ou N-ária
@startuml class professor class sala class turma left to right direction professor "leciona" -- "possui" turma (professor, turma) --> sala : ocupam @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 24 64
Agregação
Um elemento puxa para si outro elemento,
como um CEP agrega uma cidade ou um
Bairro, mas um Bairro não pode Agregar
Cidade, certo?
Composição
Uma classe é composta por outras classes,
como um cliente que tem um endereço.
@startuml class Cliente Cliente : - endereço[] class CEP CEP : + CEP[] CEP : + logradouro[] class Estado Estado : + Estado[] class Cidade Cidade : + Cidade[] class Bairro Bairro : + Bairro[] CEP "*" *-- "1" Estado CEP "*" *-- "1" Cidade CEP "*" *-- "1" Bairro Cliente "*" o-- "1" CEP @enduml
Generalização e especialização
A Generalização (inverso da Especialização) é o aproveitamento de diversas
características de uma classe que se aproveita em outras, como o cadastro de
funcionários e de clientes. Ambos são pessoas que possuem endereços e dados
pessoais, sendo diferenciados por dados de relacionamento com a empresa.
@startuml class Clientes Clientes : + numCliente[] class Funcionarios Funcionarios : # Cargo
class Pessoas Pessoas : + Nome[] Pessoas : # Endereço[] Pessoas : # Telefone[] Pessoas : # Foto[]
Pessoas <|-- "Generalização" Clientes Pessoas <|-- "Generalização" Funcionarios
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 25 64
@enduml
Associação
A Associação é uma relação entre classes que permite a
definição de n atributos para n atributos sob uma
determinada condição, comovam nota fiscal de uma loja. A
nota fiscal pode conter n produtos e n tipo de produtos
podem estar em n notas fiscais, porém, suas quantidades
podem varias, sendo então uma condição específica para
cada registro.
@startuml 'left to right direction class "Nota Fiscal" as NF class "Produtos" as Prod
NF : + númNotaFiscal[] NF : + dataEmissão[] NF : # produtos[] NF : # quantProd[]
Prod : + descrtProd[] Prod : + qteEstoque[] Prod : +preçoProd
class Clientes Clientes : + numCliente[]
Clientes --o NF NF o-- Prod @enduml
Diagrama de Classes para uma Veterinária
@startuml title Classes Veterinária
class CEP CEP : + CEP[] CEP : + logradouro[] CEP : + CRUD() CEP : + Lista_Estados() CEP : + Lista_Cidades() CEP : + Lista_Bairros()
class Estado Estado : + Estado[] Estado : + CRUD() class Cidade Cidade : + Cidade[] Cidade : + CRUD() class Bairro
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 26 64
Bairro : + Bairro[] Bairro : + CRUD()
class Pessoa Pessoa : - nome[] : string Pessoa : - CEP[] : string Pessoa : - telefone[] : string Pessoa : - email[] : string Pessoa : + animal[] : int Pessoa : + Função : int Pessoa : + registaCliData() : int Pessoa : + CRUD() Pessoa : + Lista_Funções() Pessoa : + Lista_Animais() Pessoa : + Lista_CEP()
class Animal Animal : - nome[] : string Animal : - idade[] : number Animal : - sexo[] : char Animal : + Espécie[] : int Animal : + FiloAnimal: int Animal : + CRUD()
class Espécie Espécie : + nome[] : string Espécie : + CRUD()
class FiloAnimal FiloAnimal : + nome[] : string FiloAnimal : + CRUD()
class Tratamento Tratamento : - nome[] : string Tratamento : + Animal : int Tratamento : - dataInicio[] : date Tratamento : - dataFinal[] : date Tratamento : + CRUD() Tratamento : + Lista_Animais()
class Consulta Consulta : - historico[] : string Consulta : - Função[] : int Consulta : - Animal[] : int Consulta : - data[] : date Consulta : - Tratamento[] : int Consulta : - Exame[] : int Consulta : + Lista_Animais() Consulta : + Lista_Exames()
class Função Função : - nome[] : string (Veterinário, \nSecretária, Cliente, \nTratador...) Função : - descritivo[] : string Função : + CRUD()
class Exame Exame : + nome[] : string Exame : + custo[] : string Exame : + CRUD() Exame : + Lista_Insumos()
class Insumos Insumos : + nome[] : string Insumos : + fabricante[] : string Insumos : + qte[] : numero
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 27 64
Insumos : + validade[] : date Insumos : + posição_estoque[] : string
class PessAnim PessAnim : - Pessoa[] : int PessAnim : - Animal[] : int PessAnim : + Lista_Pessoas() PessAnim : + Lista_Animais()
class Veterinário Veterinário : - Nome[] : string Pessoa "*" *-left- "*" PessAnim : possui PessAnim "*" -- "*" Animal : pertence Animal *-- Espécie : pertence Animal "1" -right- "*" Tratamento : realiza Animal *-left- FiloAnimal Tratamento "1" -- "*" Consulta : tem Veterinário "*" *-- "*" Pessoa Pessoa "1" *-- "1" Função Consulta "1" -right- "*" Exame Exame "*" -right- "*" Insumos CEP "*" *-- "1" Estado CEP "*" *-- "1" Cidade CEP "*" *-- "1" Bairro Pessoa "*" o-- "1" CEP @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 28 64
Diagrama de Objetos O Diagrama de Objetos é um complemento ao de Classes. Enquanto o primeiro exibe
os atributos (valores) e métodos (ações) que aquele objeto trata, ignorando os outros
valores (atributos) que compõem o software, o Diagrama de Objetos exibe a
totalidade de atributos (valores) que pertencem ao objeto. Este diagrama permite o
programador fazer a ponte com o Modelo de Entidade Relacionamento (MER) que
pertence ao desenvolvimento do Banco de Dados por sua semelhança.
@startuml left to right direction object Aluno object Série object Disciplinas object Professor object AnoAtivo object Sala @enduml
Para se demonstrar os dados hipotéticos ou dados tipo do objeto.
Aluno : id = "1101" Aluno : Nome = "Cunegundes Jacinto Leite Aquino Rego" Aluno : Número = "10" Aluno : ano = "2016" Aluno : histórico = "A aluna é problemática...\nEm Março ele fez a aula de Objetos!"
E para se demonstrar os relacionamentos.
Série --|> Sala Sala o-- Aluno Série --* Aluno : Composição Série --* Disciplinas Disciplinas --|> Professor AnoAtivo --|> Série
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 29 64
AnoAtivo --|> Aluno
E de forma completa:
@startuml object Aluno object Série object Disciplinas object Professor object AnoAtivo object Sala
Série --|> Sala Sala o-- Aluno Série --* Aluno : Composição Série --* Disciplinas Disciplinas --|> Professor AnoAtivo --|> Série AnoAtivo --|> Aluno
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 30 64
Aluno : id = "1101" Aluno : Nome = "Cunegundes Jacinto Leite Aquino Rego" Aluno : Número = "10" Aluno : ano = "2016" Aluno : histórico = "A aluna é problemática...\nEm Março ele fez a aula de Objetos!"
Série : id = "3" Série : nome = "Terceiro Ano" Série : sala_id = "38" Série : ano = "2016"
Sala : id = "38" Sala : nome = "38" Sala : capacidade = "50"
AnoAtivo : id = "19" AnoAtivo : AnoAtivo = "2016" AnoAtivo : histórico = "Ano do Impeachment!\nCoordenação: Profa. Silvia"
Disciplinas : id = "18" Disciplinas : nome = "História" Disciplinas : ementa = "Contar história!!!"
Professor : id = "12" Professor : nome = "Erwin Alexander Uhlmann"
@enduml
Diagrama de Sequência O Diagrama de Sequência é uma forma esquemática de representar a ordem com que
partes do sistema trocam mensagens entre si e acontecem, e tem por objetivo
demonstrar o comportamento dos objetos em um determinado contexto, ou seja, uma
parte específica como um Caso de Uso.
Os diagrama de Casos de Uso e de Classe podem servir de suporte para sua
construção, assim como após sua elaboração deve ser verificado nestes diagramas a
coerência do projeto.
De forma genérica a interação entre os objetos pode ser representada pelo Diagrama
de Sequência e pelo de Colaboração, sendo:
Diagrama de Sequência Enfatiza o tempo em que ocorrem as ações;
Mostra os objetos e interações durante sua linha de vida (tempo de atividade).
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 31 64
Diagrama de Colaboração Enfatiza o relacionamento entre os objetos.
@startuml ObjetoA -> ObjetoB : Requisição activate ObjetoA activate ObjetoB ObjetoB -> ObjetoB : Auto delegação ObjetoB --> ObjetoA : Resposta deactivate ObjetoB ObjetoA ->> ObjetoB : Mensagem Assíncrona destroy ObjetoB ObjetoA ->> ObjetoA : Objeto ativo com resposta\n para objeto inativo em linha de vida deactivate ObjetoA @enduml
Exercício 1 : Grupos e Comunicações
@startuml title Exercício 1 - Comunicação entre os participantes 'Existem várias formas de requisição e resposta group Mudando a ordem dos participantes Cliente -> Servidor: Requisição de Arquivo Servidor --> Cliente: Resposta em HTML end 'Forma dois group Mudando as requisições Cliente -> Servidor: Requisição de Arquivo Cliente <-- Servidor: Resposta em HTML end 'Forma assíncrona group Forma assíncrona Cliente ->> Servidor: Requisição Assíncrona de Arquivo Servidor ->> Cliente: Resposta Assíncrona em HTML end @enduml
Exercício 2 : Identificações e
Ativações
@startuml actor Usuário as U #blue participant Interface as I #88AAFF participant "Regras de Negócio" Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 32 64
as RDN #FFAA88 participant "Banco de Dados" as BD #88FFAA U -> I: Acesso ao sistema activate I I -> RDN: Verificação de conexão com o BD activate RDN RDN -> BD: Requisição de dados activate BD BD --> RDN: Banco de dados Ativo deactivate BD RDN --> I: Resposta em HTML deactivate RDN I --> U: Págin ade login deactivate I @enduml
Exercício 3 : Completo
@startuml title Exemplo 1 actor Usuário as U #blue participant Interface as I #88AAFF participant "Regras de Negócio" as RDN #FFAA88 participant "Banco de Dados" as BD #88FFAA autonumber "<b> [00] " group Requisições U -> I: Acesso ao sistema activate I note left: Este é o usuário I -> RDN: Verificação de conexão com o BD activate RDN note left: Este é o computador RDN -> BD: Requisição de dados note left: Esta é a programação alt Resposta OK do BD
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 33 64
activate BD BD --> RDN: Banco de dados Ativo deactivate BD note over BD: Este é o Banco de Dados RDN --> I: Resposta em HTML I --> U: Págin ade login end == Caso não tenha conexão == group Condição não satisfeita else RDN --> RDN: Sem conexão com BD RDN --> I: Resposta em HTML: Sem conexão, retorne depois! deactivate RDN I --> U: Popup: OOps... Volte mais tarde! deactivate I end @enduml
Sistema de Login 1. @startuml 2. title Login e senha 3. actor Usuario 4. Usuario -> LoginSenha : acessa 5. LoginSenha -> Programacao : email e
senha 6. activate Programacao 7. Programacao -> BD : email 8. activate BD 9. BD --> Programacao : ok ou falha
10.activate Programacao 11.alt email ok 12. Programacao -> BD : senha
daquele email 13. deactivate Programacao 14. BD --> Programacao : ok ou
falha 15. deactivate BD 16. Programacao -> ValidaSessao :
caso ok
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 34 64
17. activate ValidaSessao 18. ValidaSessao -> PaginaProtegida 19. ValidaSessao -> ValidaSessao 20. PaginaProtegida -> Logout 21. activate Logout 22. destroy ValidaSessao 23. deactivate Logout 24. deactivate ValidaSessao
25. Logout -> LoginSenha 26. ValidaSessao --> LoginSenha :
caso expirado 27.else 28. Programacao --> LoginSenha :
email ou senha invalidos 29. deactivate Programacao 30.@enduml
Diagrama de Atividades
@startuml (*) --> "Inserir email e senha" if "email e senha preenchidos?" then -->[sim] "Verificar em BD" if "email existe?" then -->[sim] "verificar senha" if "senha certa?" then --> === AP1 === -->[sim] "criar sessão" --> === AP2 === === AP1 === --> "encaminhar para página protegida" --> === AP2 === === AP1 === --> "revalidar sessão" --> === AP2 === --> (*) else --> [não]"Inserir email e senha" end if else --> [não] "Inserir email e senha" end if else --> [não] "Inserir email e senha" end if @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 35 64
Diagrama de Componentes
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 36 64
O Diagrama de Pacotes é o diagrama que demonstra a organização de um sistema,
desde sua arquitetura como sua interface, sua programação e seu Banco de Dados, e
outras partes, como também os componentes de um sistema, os servidores,
componentes de uma rede e outros sistemas e sub-sistemas.
Este tipo de diagrama é também muito útil para desenvolver projetos com a visão top-
down, ou seja, a partir da visão geral do projeto para decompor em partes menores.
@startuml [Interface] --> [Programação] [Programação] --> [Banco de Dados] [Banco de Dados] --> [Programação] [Programação] --> [Interface] @enduml
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 37 64
Modelagem de Processos de Negócios - BPM Texto na íntegra de: http://blog.iprocess.com.br/2012/11/um-guia-para-iniciar-estudos-
em-bpmn-i-atividades-e-sequencia/
Um guia para iniciar estudos em BPMN (I): Atividades e sequência | Blog da iProcess
BPMN (Business Process Model and Notation) é uma notação gráfica que tem por
objetivo prover uma gramática de símbolos para mapear, de maneira padrão, todos os
processos de negócio de uma organização.
Desde sua disponibilização formal em 2004, BPMN tem sido amplamente utilizada em
organizações do mundo inteiro. Atualmente há uma grande oferta de ferramentas de
mapeamento de processos(gratuitas e licenciadas) que oferecem suporte à notação.
Devido à sua grande aceitação, BPMN está ajudando a disseminar conceitos
relacionados a processos de negócio e é considerada hoje uma característica chave de
qualquer iniciativa BPM.
Dedicaremos os artigos semanais de novembro e dezembro para contribuir com o
estudo progressivo dos elementos dede BPMN que compõem o nível 1 desta notação,
utilizados para mapear processos em nível descritivo.
Representando Processos com BPMN
Em BPMN, um processo de negócio é representado através do encadeamento de
eventos e atividades, ligados através de conectores que demonstram a sequência em
que os mesmos são realizados. Além de eventos e atividades, outros elementos de
controle de fluxo podem ser utilizados na modelagem para permitir a criação ou
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 38 64
unificação de fluxos paralelos que ocorram no decorrer de um mesmo processo de
negócio.
Processo de Compra de Refrigerante
Exemplo de um processo mapeado utilizando BPMN
O grande potencial de BPMN para representação de processos está no fato de que ela
propõe um conjunto simplificado de elementos (atividades, eventos, gateways,
conectores e swimlanes), mas que podem ser derivados para atender situações
específicas de negócio, de forma que a documentação de um processo em nível de
negócio possa adquirir profundidade técnica à medida que é preparado para a
implementação.
Nota: A especificação BPMN está documentada em inglês e não existe uma
tradução oficial para o português. A tradução neste e nos próximos
artigos é livre por parte dos autores, e pode ser diferente entre
bibliografias ou ferramentas que adotem esta notação.
Para mais informações sobre a documentação oficial e completa
consulte http://www.omg.org/bpmn.
Atividades (Activities)
Atividades representam um trabalho realizado em uma etapa do processo de negócio.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 39 64
As atividades podem ser de dois tipos:
Tarefa (task)
Sub-processo (subprocess)
Tarefa (Task)
A tarefa é a atividade de trabalho atômica. Ela representa uma ação no processo que
pode ser executada por uma pessoa ou um sistema.
Visualmente é representada como um retângulo com bordas arredondadas, contendo
sua descrição dentro da área da caixa.
Exemplos de atividades que podem ser representadas através de tarefas são:
Avaliar documentos
Calcular impostos
Elaborar parecer técnico
Elaborar proposta comercial
Cadastrar operação
BPMN sugere alguns símbolos que podem ser adicionados à tarefa para representar
visualmente sua utilização:
Assim é possível distinguir visualmente que uma atividade é realizada por um usuário
através do sistema se for simbolizada por uma Tarefa de usuário, enquanto uma tarefa
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 40 64
que pode ser executada automaticamente pelo sistema pode ser sinalizada como
Tarefa automática.
Uma tarefa executada por uma pessoa (usuário) e uma tarefa executada
automaticamente (serviço)
Conector de Sequência de fluxo (Sequence flow)
O principal objetivo no mapeamento de um processo com BPMN é representar a
sequência em que as atividades acontecem desde o seu início até a sua conclusão. Em
BPMN Method & Style (2ed), Bruce Silver esclarece que o propósito de BPMN é
representar a lógica do processo. A lógica do processo é visualmente demonstrada
através do fluxo criado pelos conectores de sequência.
No exemplo acima, o conector de sequência torna explícito que há uma sequência a
ser realizada entre as atividades. A atividade “Digitalizar documento” só poderá ser
realizada após a atividade “Receber documento” ser concluída. Da mesma forma, a
atividade de “Arquivar documento” só poderá ser iniciada após o término da tarefa
“Digitalizar documento”.
O conector de fluxo de sequência é representado através de uma linha sólida com uma
seta preenchida apontando para o destino (o próximo elemento do fluxo). Em um
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 41 64
processo de negócio, todos os elementos de fluxo precisam estar conectados uns aos
outros através de um conector de sequência conforme a ordem em que devem ser
realizados.
É importante entender que, na interpretação de um processo BPMN, o conector de
sequência implica que existe uma dependência entre as atividades conectadas, do tipo
fim-início. Ou seja, a conexão significa que após a conclusão da atividade, a próxima
atividade poderá ser iniciada.
Um guia para iniciar estudos em BPMN (II): Gateways | Blog da iProcess
No artigo anterior, iniciamos o estudo da notação BPMN apresentando os elementos
task e sequence flow, utilizados para representar a sequência lógica de atividades a
serem executadas para a realização do processo. Neste artigo estudaremos um novo
elemento de fluxo.
Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo,
criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando
fluxos para continuação em uma mesma sequência de atividades.
Gateways são elementos chave na modelagem de processos de negócio, pois permitem
descrever não apenas o “dia feliz” do processo, em que as atividades acontecem
sempre da mesma maneira ou na mesma sequência, mas prever possíveis exceções
conhecidas do negócio, ou beneficiar a duração do processo através da paralelização
de atividades.
O gateway é conectado ao fluxo através de setas de fluxo de sequência e é
representado visualmente por um losango. O símbolo interno do losango identifica a
interpretação lógica representada.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 42 64
Gateway exclusivo (Databased Exclusive Gateway)
Representa uma condição de fluxo exclusiva, em que apenas um dos caminhos criados
a partir do gateway será seguido, de acordo com uma informação a ser testada.
Este gateway pode ser representado visualmente como o losango vazio ou com um
marcador de “x”.
Quando o processo em execução atingir este gateway, o processo deverá verificar a
condição indicada, e apenas uma das saídas do gateway dará seguimento.
Semanticamente, este gateway funciona como um “ou”, já que ou um ou outro caminho
será seguido – nunca mais de um.
Os conectores de sequência de saída deste gateway podem apresentar descrições que
ajudem a identificar qual a condição para que o fluxo siga por aquele caminho.
Além de realizar separação de fluxos, o gateway também pode unificar fluxos distintos
em uma única sequência de atividades. Neste caso, o gateway exclusivo implica no
entendimento que, dos caminhos que convergem a ele, o primeiro que chegar dará
continuidade no fluxo do processo.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 43 64
No exemplo acima, o gateway “Resultado da avaliação” testará o resultado da
atividade anterior. Se na execução da atividade “Avaliar artigo” o usuário aceitar o
conteúdo, o fluxo seguirá pela saída superior “Conteúdo aceito”, e as atividades
“Realizar revisão final do artigo” e “Publicar artigo” serão realizadas. Se o usuário
rejeitar o conteúdo, o fluxo seguirá pela saída “Conteúdo rejeitado”, e apenas a
atividade “Cancelar artigo” será realizada. Por fim, se o usuário optar por requerer
ajustes, o fluxo seguirá a sequência “Requer ajustes”, iniciando a atividade “Ajustar
artigo”. Ao terminá-la, note que o fluxo seguirá novamente para a atividade de
“Avaliar artigo”. Ainda no exemplo acima, note a utilização do gateway exclusivo
para convergir dois dos fluxos criados. Isto garante que a atividade “Comunicar partes
interessadas” só aconteça depois que a tarefa “Publicar artigo” ou a tarefa “Cancelar
artigo” for executada, de acordo com o fluxo iniciado pelo gateway anterior.
Gateway paralelo (Parallel Gateway)
A paralelização de trabalho em um diagrama BPMN é possível com a utilização do
gateway paralelo. Este gateway representa a divisão de um fluxo em dois ou mais que
serão executados paralelamente. Todos os caminhos que saem deste gateway são
executados.
Este gateway é representado visualmente como o losango com um marcador de “+”
dentro dele.
Semanticamente, este gateway funciona como um “e”, já que um e outro caminho
serão executados.
Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá
que todos os fluxos paralelos sejam concluídos, chegando até ele antes de dar
continuidade ao fluxo de saída.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 44 64
No exemplo acima, o primeiro gateway paralelo produz dois fluxos que serão
executados paralelamente. Enquanto a tarefa “Escrever artigo” é realizada, as
atividades “Selecionar imagens” e “Tratar imagens” também podem ser executadas.
Ainda no exemplo acima, o segundo gateway faz a convergência dos fluxos,
garantindo que a tarefa “Realizar diagramação” só seja executada depois que
“Escrever artigo” e “Tratar imagens” tenham sido finalizadas.
Gateway inclusivo (Databased Inclusive Gateway)
Representa uma condição de fluxo inclusiva, em que pode haver uma combinação dos
caminhos criados a partir do gateway, de acordo com uma informação a ser verificada.
Este gateway é representado visualmente como o losango com um marcador de círculo
dentro dele.
Quando o processo em execução atingir este gateway, o processo deverá avaliar a
condição relacionada, e uma ou mais das saídas do gateway poderão dar seguimento.
Semanticamente, este gateway funciona como um “e/ou”, já que o caminho a ser
seguido pode ser um e/ou outro, de acordo com as informações e a lógica do negócio.
Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá
que todos os fluxos que estiverem em execução sejam concluídos, chegando até ele
antes de dar continuidade à sequência de atividades.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 45 64
No exemplo acima, o gateway “Documentos necessários” testará o resultado da
atividade anterior. Se na execução da atividade “Identificar documentação necessária”
o usuário identificar a necessidade de um, dois, ou três dos documentos requeridos,
cada um dos fluxos será executado. Por exemplo, se para um processo em execução
for identificada a necessidade da Negativa civil e Negativa criminal, mas não a de
débitos, o processo seguirá pelas saídas “Negativa civil” e “Negativa criminal”, mas
não pela “Certidão negativa de débitos”. Assim, as atividades “Anexar negativa civil”
e “Anexar negativa criminal” deverão ser executadas. Em outro processo, pode ser
possível que uma combinação diferente de documentos seja requerida. Ainda no
exemplo acima, note a utilização do gateway inclusivo para convergir os fluxos
criados. Isto garante que a atividade “Analisar validade dos documentos” só aconteça
depois que todos os fluxos que forem iniciados pelo gateway anterior sejam
executados, para então a atividade ser iniciada. No exemplo citado, a tarefa de
analisar validade dos documentos só será iniciada depois que as tarefas “Anexar
negativa civil” e “Anexar negativa criminal”, mas sem que ocorra a atividade “Anexar
negativa de débitos”.
Algumas coisas importantes que devem ser observadas ao utilizar gateways:
• Diferente dos diamantes dos tradicionais fluxogramas, os gateways em BPMN
não são apenas pontos de divisão binária do fluxo. É possível (e muito mais
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 46 64
vantajoso!) utilizá-los para realizar testes mais complexos do que o tradicional “sim/
não”. Isto vale para todos os tipos de gateway nesta notação.
• Nos gateways exclusivo e inclusivo, onde o fluxo é direcionado com base em uma
condição, a informação a ser validada (para identificar que fluxo o gateway deve
seguir) já deve ter sido obtida anteriormente no processo.
• Embora a notação não coloque isto como uma regra obrigatória, é sempre uma
boa prática descrever, nos conectores de sequência que saem destes gateways com
decisão, que valor resultante da condição deve ser verdadeiro para que o fluxo siga
por aquele caminho. (Veja nos exemplos aplicados como os conectores de
sequência que saem dos gateways exclusivo e inclusivo possuem descrições
associadas às suas linhas.) Isto deixará o diagrama mais claro para a leitura dos
que venham a consultá-lo futuramente!
BPMN 2.0 possui outros tipos de gateways, como os baseados em eventos, por
exemplo. estes gateways, entretanto, são utilizados em casos mais especializados (a
partir do nível 2 – analítico, de acordo com a classificação de Bruce Silver).
Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim | Blog da iProcess
Este é o terceiro artigo de uma série dedicada ao estudo da notação BPMN básica, ou
nível descritivo. No artigo anterior, descrevemos um importante elemento na
representação de processos nesta notação, os gateways.
Este artigo é dedicado ao esclarecimento de outro importante componente de fluxo em
BPMN: os eventos.
Eventos (Events) são elementos utilizados para representar a ocorrência de fatos em um
processo.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 47 64
Eventos podem representar a espera de que um fato aconteça para iniciar/prosseguir a
execução o processo ou então sinalizar que o processo produzirá a ocorrência de um
fato durante ou ao término de sua execução.
Os eventos são sinalizados no processo através de um círculo, e dependendo do ponto
do processo onde ocorrem podem ser sinalizados de forma diferente:
• Eventos de início (Start events) marcam o ponto onde o processo inicia e são
representados por um círculo de linha simples.
• Eventos intermediários (Intermediate events) marcam ocorrência de eventos no
decorrer do processo e são representados por um círculo de linha dupla.
• Eventos de fim (End events) marcam o ponto onde o processo termina e são
representados por um círculo de linha grossa.
Eventos que aguardam fatos e possuem uma causa são chamados “catch”.
Eventos que produzem fatos e possuem um resultado são chamados “throw”.
A causa ou resultado do evento é chamado “trigger” (gatilho) e sinalizado através de
um símbolo dentro do elemento. Os tipos de gatilho variam de acordo com cada tipo
de evento.
Evento de início (Start Event)
O evento de início marca o ponto onde deve-se iniciar a leitura ou a execução de um
processo.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 48 64
O evento de início será sempre do tipo catch, pois deve aguardar a ocorrência de um
evento para realizar o disparo (início da execução) do processo.
É recomendável que todo o processo tenha um evento de início para facilitar a leitura
do diagrama, possibilitando a quem lê identificar por onde começa o fluxo de
atividades.
Os tipos de evento de início mais comuns são:
None
O processo é iniciado sem a definição de um
fato específico que gere o seu início.
Não possui símbolo.
Timer
O processo é iniciado pela ocorrência de um
fato temporal, como a chegada de uma data
específica (ex. 01 de janeiro) ou relativa (ex.
primeira terça-feira do mês).
É simbolizado por um relógio.
Message
O processo é iniciado com a chegada de
uma comunicação de qualquer tipo (um
documento, uma mensagem, um telefonema,
etc).
É simbolizado por um envelope branco
(catch).
Conditional
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 49 64
O processo é iniciado quando uma determinada condição torna-se verdadeira. É
simbolizado por um desenho de página com linhas representando as condições.
Evento de fim (End event)
O evento de fim marca o término onde deve-se iniciar a execução de um processo.
O evento de fim será sempre do tipo throw, marcando que o processo termina com a
geração de um fato.
É recomendável que todo o processo tenha ao menos um evento de fim. É possível
entretanto simbolizar términos diferentes para o processo usando mais de um evento de
fim.
Os tipos de evento de fim mais comuns são:
None
O processo termina sem gerar nenhum fato
específico.
Não possui símbolo.
Message
O processo é finalizado com o envio de uma
comunicação de qualquer tipo (um documento,
uma mensagem, um telefonema, etc). É usado
para iniciar um outro processo ou fornecer um
resultado a uma comunicação começada no
início ou decorrer do processo.
É simbolizado por um envelope preto (throw).
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 50 64
Terminate
O processo é terminado finalizando
por completo, mesmo que existam
atividades em fluxos paralelos em
execução. Caso existam atividades
em execução quando um dos fluxos
existentes atinja o evento de fim
terminate, as tarefas pendentes são
canceladas e o processo é dado
como completamente finalizado.
É simbolizado por um círculo preto preenchido.
No exemplo acima, o evento de fim “Processo arquivado” é do tipo terminate. Se a
tarefa “Arquivar processo” for concluída antes das atividades do fluxo paralelo, o
processo chegará ao evento terminate e as tarefas que ainda estavam em execução
serão interrompidas. Mas se a tarefa “Anexar documentos pendentes” terminar antes
de “Arquivar processo”, o processo finalizará com todas as atividades executadas,
pois diferente do evento terminate o evento do tipo none não interrompe a execução
de atividades no fluxo paralelo.
Embora o uso de eventos de início e fim não sejam obrigatórios, são considerados uma
boa prática, fundamental para a obtenção de um processo bem mapeado, claro e
legível a todos os participantes do processo.
Há porém uma regra na especificação que deve ser observada: se for utilizado um
evento de início no processo, deve obrigatoriamente haver ao menos um evento de
fim. Da mesma forma, se for adicionado ao mapeamento do processo um evento de
fim, então o processo deve obrigatoriamente possuir ao menos um evento de início.
Existem outros gatilhos para eventos de início e de fim do processo. Estes apresentados,
porém, são os mais comumente utilizados e que compõem o nível de componentes do
nível descritivo da notação BPMN.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 51 64
Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários | Blog da iProcess
No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de
gatilhos para eventos de início e fim de processo.
O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo
no qual é previsto que um fato irá ocorrer.
Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato
para que o processo continue) quando do tipo throw (geram a ocorrência do fato e
dão continuidade ao processo).
Em geral os eventos intermediários são conectados ao processo através de conectores
de fluxo de sequência, dando o contexto de que ocorrem durante o processo.
Entretanto, um evento intermediário também pode ser definido para ocorrer durante
uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da
atividade, como mostrado em alguns exemplos abaixo.
Os tipos de evento intermediário mais comuns são:
Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma
data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um
intervalo de tempo (em sete dias) ou uma situação de espera de tempo.
O evento de timer é simbolizado por um relógio.
Quando utilizado no fluxo do processo, o evento intermediário de timer representa que
o processo deverá parar naquele ponto do processo e aguardar que a condição de
tempo se torne verdadeira.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 52 64
Neste exemplo, quando a
tarefa “Preparar viagem” for
fi n a l i z a d a , o p r o c e s s o
r e a l i z a r á u m a p a u s a
aguardando a data de início
da viagem. Só então o processo continuará, iniciando a tarefa “Realizar viagem”.
Quando utilizado na borda de uma atividade, o evento intermediário de timer
representa que que, enquanto a atividade estiver em execução, o evento poderá
acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste
caso, o evento intermediário poderá ser de dois tipos:
Timer interrupting
Se o evento ocorrer enquanto a atividade
estava sendo executada, ela será interrompida,
e o fluxo seguirá pelo conector que se origina
no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a at ividade
“Confirmar recebimento de mercadorias” for
concluída antes da data de entrega prevista, o
processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de
entrega prevista for atingida e o recebimento das mercadorias não tiver sido
confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer
é disparado, dando início à atividade “Cancelar o pedido”. A atividade de “Confirmar
recebimento de mercadorias” não poderá mais ser realizada pois foi interrompida.
Timer non-interrupting
Se o evento ocorrer enquanto a atividade
estava sendo executada, um fluxo paralelo
será iniciado a partir do conector que se
origina no evento, mas a tarefa permanece
aguardando a sua execução.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 53 64
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa “Avaliar pedido” ainda não
tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa
“Receber aviso de atraso na avaliação”. A atividade de avaliar pedido, entretanto,
poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se
a tarefa “Avaliar pedido” for finalizada antes da ocorrência dos dois dias úteis, então
a atividade “Receber aviso de atraso na avaliação” não acontecerá.
Condicional (Conditional)
Utilizado para representar um
fato relacionado a uma
c o n d i ç ã o d e n e g ó c i o ,
pausando o processo até que
ela se torne verdadeira.
No exemplo ao lado, ações são compradas e então o processo aguarda até que a
condição “Valor de venda atingido” se torne verdadeira, dando continuidade ao
processo e iniciando a tarefa “Vender ações”.
O evento do tipo conditional também pode ser conectado à borda de atividades como
demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting.
Neste caso, o evento será acionado quando a condição de negócio associada se torne
verdadeira.
Mensagem (Message)
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 54 64
Eventos intermediários de tipo message são utilizados para demonstrar um ponto do
processo onde ocorre uma comunicação com um outro processo ou agente externo.
O evento de “throw message” tem como símbolo um envelope preto e sinaliza o envio
da comunicação, enquanto o evento do tipo “catch message” tem como símbolo um
envelope branco e sinaliza o recebimento da mesma.
No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para
“Alugar sala de treinamento”. Após alugar a sala, o processo aguarda uma
“Comunicação do número de Participantes”. Quando esta comunicação for recebida, a
próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os
participantes do treinamento cujas inscrições foram confirmadas.
Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma
tarefa para receber as fichas de inscrição e então uma atividade para “Verificar
inscrições pagas”. Quando as inscrições pagas forem verificadas, o processo poderá
comunicar o número de participantes que estão inscritos, enviando uma mensagem (que
será recebida no processo demonstrado anteriormente, no evento com o mesmo nome).
Após, o processo segue, iniciando a tarefa de “Providenciar impressão dos
certificados”.
A identificação de que a mensagem enviada por um processo é a mesma recebida em
outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.
É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois
processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de
um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 55 64
essa ligação entre processos através da troca de mensagens (envio e recebimento): o
conector de fluxo de mensagem (message flow).
O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de
envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma
seta vazada apontando para o destino da mensagem.
É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para
fora do processo, nunca entre eventos de mensagem de um mesmo processo.
O evento do tipo mensagem também pode ser utilizado à borda de atividades como
demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting.
Neste caso, o evento será sempre “catch”, aguardando a chegada de uma mensagem,
e será acionado se a mensagem for recebida enquanto a atividade estiver sendo
executada.
Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um
mesmo do processo.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 56 64
Este elemento é utilizado frequentemente em processos cujo número de atividades é
muito grande e há pontos do processo que estão visualmente distantes ou bloqueados.
Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar
este evento, criando uma “ponte virtual” entre pontas do fluxo do processo.
O evento de “throw” link tem como símbolo uma seta preta e sinaliza a ponta de
origem da ligação, enquando o evento do tipo “catch” tem como símbolo uma seta
branca e sinaliza o destino da mesma.
O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe
que há dois eventos de ligação com o mesmo nome: “Continuar negociação”. O
primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca,
indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que
após a realização da atividade “Verificar condições de férias” o processo dá
sequência ao fluxo iniciando a tarefa “Avaliar solicitação de férias”.
Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 57 64
BPMN: Diferenças entre eventos de Link, Message e Signal
BPMN: Modelando corretamente o fluxo de sequência de atividades
Um guia para iniciar estudos em BPMN (V): Subprocessos | Blog da iProcess
Retornando ao tema Atividades (Activities), em nossa série de artigos dedicados ao
BPMN Nível 1, há um segundo tipo deste elemento além das tarefas (tasks): são os
subprocessos.
Tarefas que em conjunto possuam um propósito específico dentro de um processo de
negócio podem ser abstraídas em uma outra unidade de processo e representadas no
processo maior por um único objeto do tipo atividade, denominado Subprocesso.
Subprocessos são representados visualmente como retângulos com bordas
arredondadas (como as tarefas), porém apresentam um símbolo [+] na base inferior
implicando no entendimento que esta atividade contém um conjunto de tarefas.
Subprocessos são conectados ao fluxo do processo da mesma forma que as outras
atividades, através de conectores de fluxo de sequência.
No exemplo acima, a atividade “Aprovação de exceções de negócio” é um
subprocesso, que abstrai um conjunto de atividades cujo propósito é avaliar uma
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 58 64
exceção de negócio (por exemplo, crédito para um cliente antigo mesmo que tenha
situação financeira negativa) para então dar continuidade à concessão do crédito se
esta exceção for autorizada. Abaixo tem-se um exemplo de detalhamento das
atividades deste subprocesso.
Em geral, o fluxo que compõe o subprocesso é mapeado em um diagrama separado.
Algumas ferramentas permitem criar vínculo entre o diagrama do processo principal e o
subprocesso, possibilitando a navegação de um para outro com um ou dois cliques de
mouse.
Se o processo que está sendo modelado possui muitas atividades e conexões, tornando-
o difícil para a interpretação dos leitores, a utilização de subprocessos pode ser um
excelente artificio para organizar o fluxo sem interferir diretamente na execução do
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 59 64
mesmo, possibilitando criar uma visão mais abstrata e objetiva das atividades que
ocorrem no processo.
Subprocessos também podem ser úteis para reunir partes de fluxos que podem ser
repetidas em momentos distintos do processo, caracterizando reuso.
Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos | Blog da iProcess
Este é o último artigo de uma série de seis postagens sobre a utilização dos elementos
básicos da notação BPMN.
Neste artigo, tratamos alguns elementos utilizados a nível de organização do diagrama
do processo: swimlanes para atribuir visualmente responsabilidades sobre as
atividades, e artefatos para agregar informações adicionais que possam contribuir com
a compreensão da lógica do processo de negócio.
Swimlanes
Swimlanes são os elementos de BPMN utilizados para organizar os processos de um
diagrama, definindo o escopo de cada processo e possibilitando identificar os papéis
responsáveis pela execução de cada atividade do processo.
Estes elementos são definidos em uma estrutura semelhante a uma piscina (pool) e suas
raias (lanes).
Uma pool pode conter apenas um processo de negócio. Processos de negócio distintos
devem estar contidos, cada um, em uma pool específica.
Uma pool pode conter tantas lanes quantas forem necessárias para caracterizar os
participantes envolvidos na realização das atividades do processo.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 60 64
A prática comum é desenhar as pools e suas lanes horizontalmente, mas a notação
permite a representação vertical.
No exemplo acima, a pool contém todo o processo para conceder crédito. O nome do
processo está na borda da pool, que é o retângulo inteiro contendo todo o “Processo
de Concessão de Crédito”. Este processo contém atividades que envolvem dois papéis:
o Gerente da Conta e o Gerente do Produto. Cada é representado no processo através
de uma lane da pool. O diagrama de processos utilizando pools e lanes facilita a
identificação visual da troca de mãos da responsabilidade de agir em cada etapa do
processo.
As pools são nomeadas com a identificação do Processo (quando o processo modelado
está em nível de detalhe operacional) ou com a identificação do Participante (por
exemplo, uma entidade externa que se envolve de alguma forma com o processo de
negócio modelado em outra pool).
No exemplo acima temos o exemplo de dois processos que se comunicam através de
message flow. Observe que cada processo está contido em uma pool. Uma pool pode
conter apenas um processo de negócio. Processos de negócio distintos devem estar
contidos, cada um, em uma pool específica. A interação entre processos se dá por
comunicação, utilizando-se o conector de message flow.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 61 64
Em alguns casos, pools podem não detalhar o seu conteúdo, mas figurar em um
diagrama apenas como um apontamento visual de que aquele processo existe no
contexto de negócio no qual um processo comunica-se com outros processos ou
entidades. Nestes casos, chamamos as pools não detalhadas de collapsed ou black box
(caixa preta).
No exemplo acima, o mesmo processo agora é apresentado em um diagrama que
demonstra a comunicação do Processo de Concessão de Crédito com os participantes
externos Cliente e SERASA. Estes participantes também possuem seus processos, porém
o detalhamento das atividades realizadas em cada um é transparente para o Processo
de Concessão de Crédito. Por este motivo, estes participantes são representados no
processo como pools black box. Observe que a comunicação entre os processos (ou do
processo modelado com os outros processos/participantes) é sempre representada
através do conector de message flow.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 62 64
Artefatos (Artifacts)
Além dos elementos de fluxo (atividades, gateways e eventos), dos elementos
conectores (fluxo de sequência e fluxo de mensagem) e dos elementos organizacionais
(swimlanes), BPMN oferece elementos adicionais para sinalização visual do processo
mas que não influenciam no fluxo do processo. São elementos de anotações, que
podem ser utilizados para adicionar informações complementares ao processo.
O objeto de dados (data object) é um elemento que representa um conjunto de
informações no contexto do processo, de uma atividade ou de uma troca de mãos
(através do fluxo de sequência). É representado por uma página com a ponta dobrada.
No exemplo, “Lista de alunos” é um objeto de dados que transita da tarefa “Verificar
inscrições pagas” para “Providenciar impressão dos certificados”.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 63 64
O artefato de anotação de texto (annotation) é um elemento que pode ser utilizado
para agregar comentários ao processo ou a um elemento. É representado por uma
área de texto marcada com a borda lateral, e pode ou não estar conectado a
elementos do diagrama.
No exemplo, há uma anotação na tarefa “Preparar cadeiras e mesas” que
complementa o entendimento da tarefa.
O artefato de grupo (group) é um elemento de anotação visual que pode ser utilizado
para sinalizar grupos de atividades dando-lhes algum destaque. O grupo é uma simples
anotação e não influencia no fluxo do processo, podendo inclusive ser desenhado
cruzando lanes e pools. É representado por um retângulo com bordas arredondadas e
linha tracejada.
No exemplo, há um grupo denominado “Controle das Inscrições” destacando um
grupo de elementos relacionados a este controle. Procure abstrair a existência do
grupo e note que o fluxo do processo não se altera se este elemento for ou não
utilizado.
O conector de associação (association) é um conector específico para conectar os
elementos de artefatos ao diagrama, e é representado por uma linha pontilhada,
podendo ou não apresentar setas em “v” (ele é distinto do message flow, que tem a
linha tracejada e ponta de triângulo).
No exemplo, os artefatos de objeto de dados e anotação estão ligados ao fluxo do
processo através de conectores de associação.
Com este artigo, finalizamos nosso guia para iniciar estudos em BPMN.
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 de 64 64