Académique Documents
Professionnel Documents
Culture Documents
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]).
@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.
@startuml
object computador
'o atributo é marcado pelo[]
computador: atributo[]
@enduml
E no plantUML:
@startuml
object computador
computador: processador[]
computador: memoriaRam[]
computador: discoRigido[]
computador: dispositivoDeEntrada[]
computador:dispositivosDeSaida[]
@enduml
@startuml
'object computador
computador : processador[]
computador : memoriaRam[]
computador : discoRigido[]
computador : dispositivoDeEntrada[]
computador : dispositivosDeSaida[]
computador : realizaCalculos()
@enduml
@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
@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 precisar do e-mail,
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
@startuml
sistLogin : + email[]
sistLogin : #senha[]
sistLog : email[]
sistLog : + dataEHora[]
sistLog : armazenarDadosLog()
sistInsDados : ~ email[]
sistInsDados : gravarDados()
relatorios : email[]
relatorios : dataEHora[]
relatorios :
imprimirRelatorios()
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
@startuml
sistLogin : + email[]
sistLogin : #senha[]
sistLog : email[]
sistLog : + dataEHora[]
sistLog : armazenarDadosLog()
sistInsDados : ~ email[]
sistInsDados : gravarDados()
sistLogin <|-- sistLog
sistLogin <|-- sistInsDados
@enduml
function hora(){
$hora = date('H:i:s');
echo $hora;
}
function data(){
$data = date('d/m/Y');
echo $data;
}
class Tempo{
function hora(){
$hora = date(‘H:i:s’);
echo $hora;
}
function data(){
$data = date(‘d/m/Y’);
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.
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!
class Pai{
$valor = '1, 2, 3, 4, 5';
strrev($valor);
}
class Filho extends Pai{
$parteValor = substr($valor, 0, 4);
echo $parteValor;
}
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
'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
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
@startuml
:Usuário: --> (Cadastro de usuário)
:Usuário: --> (Editar cadastro)
@enduml
@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.
UC 01 Acesso ao 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.
UC 01 Acesso ao sistema
5 - Abre a sessão
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
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 15 de 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
@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 16 de 64
(Excluir dados) ..> (Log do
sistema)
@enduml
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)
Multiplicidade
Um para muitos ou um para um. Um processo pode ser chamado n vezes por um ator
ou o inverso.
@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
UC 01
4 - exclui-se do BD
4 - exclui-se do BD
6 - Exclui usuários
Requisição Resposta
1 - Acessa o sistema
5 - sai do sistema
Exercício 2
Crie um sistema de controle de petshop. Seus requisitos são:
UC 01 Acesso à Agenda
2 - Consulta serviços
4 - Emite relatórios
Requisição Resposta
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:
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[]
@startuml
class professor
class sala
class turma
left to right direction
professor "leciona" -- "possui" turma
(professor, turma) --> sala : ocupam
@enduml
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[]
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
@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 26 de 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
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
@startuml
left to right direction
object Aluno
object Série
object Disciplinas
object Professor
object AnoAtivo
object Sala
@enduml
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 de forma completa:
@startuml
object Aluno
object Série
object Disciplinas
object Professor
object AnoAtivo
object Sala
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).
@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
@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 32 de 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 33 de 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 10.activate Programacao
2. title Login e senha 11.alt email ok
3. actor Usuario 12. Programacao -> BD : senha
4. Usuario -> LoginSenha : acessa daquele email
5. LoginSenha -> Programacao : email e 13. deactivate Programacao
senha 14. BD --> Programacao : ok ou
6. activate Programacao falha
7. Programacao -> BD : email 15. deactivate BD
8. activate BD 16. Programacao -> ValidaSessao :
9. BD --> Programacao : ok ou falha caso ok
Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 34 de 64
17. activate ValidaSessao 25. Logout -> LoginSenha
18. ValidaSessao -> PaginaProtegida 26. ValidaSessao --> LoginSenha :
19. ValidaSessao -> ValidaSessao caso expirado
20. PaginaProtegida -> Logout 27.else
21. activate Logout 28. Programacao --> LoginSenha :
22. destroy ValidaSessao email ou senha invalidos
23. deactivate Logout 29. deactivate Programacao
24. deactivate ValidaSessao 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
@startuml
[Interface] --> [Programação]
[Programação] --> [Banco de Dados]
[Banco de Dados] --> [Programação]
[Programação] --> [Interface]
@enduml
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.
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.
Atividades (Activities)
Atividades representam um trabalho realizado em uma etapa do processo de negócio.
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.
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
Uma tarefa executada por uma pessoa (usuário) e uma tarefa executada
automaticamente (serviço)
Conector de Sequência de fluxo (Sequence flow)
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 41 de 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.
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”.
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.
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.
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 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.
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).
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.
• 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”.
É 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.
None
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
Conditional
O evento de fim será sempre do tipo throw, marcando que o processo termina com a
geração de um fato.
None
Message
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.
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).
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.
Timer interrupting
Timer non-interrupting
Condicional (Conditional)
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)
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.
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)
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.
Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:
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
Subprocessos também podem ser úteis para reunir partes de fluxos que podem ser
repetidas em momentos distintos do processo, caracterizando reuso.
Este é o último artigo de uma série de seis postagens sobre a utilização dos elementos
básicos da notação BPMN.
Swimlanes
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.
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.
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.