Modelagem-04

Prévia do material em texto

103
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGÓCIO
7.1 Introdução
Processos de negócio são atividades previamente estabelecidas que têm como objetivo determinar 
a forma como o trabalho é realizado numa organização.
Constituem um conjunto de ações, relacionadas entre si de forma lógica e coerente, a fim de 
promover uma saída favorável à organização, tanto em termos internos como externos.
Uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia de 
uma empresa por meio dos produtos e serviços que gera e disponibiliza.
Dada a similaridade das suas composições, função de negócio e processo de negócio são conceitos 
que frequentemente suscitam dúvidas entre as pessoas interessadas em formar um melhor entendimento 
a respeito dos elementos de uma arquitetura de negócios.
Ambos são “coisas que a empresa faz”, entretanto, os processos são transfuncionais (ou horizontais), 
já que perpassam diversas barreiras funcionais dentro da organização (por exemplo: adquirir bem, 
alienar bem, contratar funcionário), enquanto que as funções, que em conjunto descrevem a missão da 
empresa, são verticais (por exemplo: contabilidade, vendas, logística).
Um outro aspecto relevante, e que pode representar uma mais valia na implementação dos processos de 
negócio numa organização, tem a ver com a implementação de um sistema de informação bem estruturado.
A existência de uma boa rede de informação, entre todos os intervenientes nos processos de negócio 
da organização, é condição sine qua non, uma vez que permite a comunicação em tempo real, tornando 
possível uma adequada tomada de decisão, resultante do ajuste contínuo de procedimentos que irá 
repercutir em toda a dinâmica organizacional e, consequentemente, na excelência dos seus resultados.
Desse modo, quando se fala em processos de negócio, a abrangência é enorme, pois o seu âmbito de 
atuação é transversal e atua em todas as áreas da organização, com elevado impacto na qualidade dos 
serviços e/ou produtos, na redução de custos e no desenvolvimento do próprio negócio.
Por outro lado, a existência de uma interface entre os processos de negócio e uma rede de sistemas 
de informação constituem fatores-chave fundamentais, quer para a generalidade dos negócios dos 
tempos de hoje, quer para a produção de indicadores e instrumentos de controle efetivo para uma 
constante monitorização das atividades da organização.
104
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Assim, como a Figura 57 sugere, pode-se definir processos de negócio como um conjunto de atividades 
desenvolvidas a partir de um objetivo predefinido que irá concretizar-se num resultado específico, em 
termos de produto ou serviço que se pretenda realizar.
Pessoas Equipamento Informação
Objetivo ResultadoProcessos de negócio
Que tarefas específicas?
Qual a prioridade?
Quais os procedimentos?
Figura 57 – Processos de negócio
7.2 Modelagem de negócio
Para compreender uma organização, é necessário entender seus processos de negócio. Profissionais 
da Tecnologia da Informação se empenham em construir soluções que têm por finalidade auxiliar a 
empresa na conquista de maior espaço no mercado globalizado.
Nesse contexto, os processos são avaliados e, sempre que possível, informatizados, de forma a 
promover vantagens competitivas a partir do alinhamento estratégico entre o sistema e o negócio da 
empresa.
Para a OMG (Object Management Group, 2005), um processo de negócio corresponde a um conjunto 
coeso de atividades que criam um resultado, o qual garante a criação de valor a um cliente externo 
ou interno à empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de 
negócio e que se desenvolve a partir de um determinado evento de negócio.
Segundo Laudon e Laudon (2001), um processo de negócio refere-se à maneira pela qual o trabalho 
é organizado, coordenado e focado, para produzir um produto ou serviço de valor.
De um lado, processos de negócios são fluxos de trabalhos concretos de materiais, 
informações e conhecimentos. De outro, referem-se também à maneira singular de as 
organizações coordenarem trabalho, informação e conhecimento, e de como a gerência prefere 
coordenar o trabalho.
Já a modelagem de negócio é uma técnica de modelagem de alto nível, que surgiu das dificuldades 
identificadas pelos analistas de sistemas.
105
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
É uma abstração voltada à realidade dos administradores, assim, estudiosos e pesquisadores da 
área de TI criaram uma técnica de modelagem de alto nível denominada de modelagem de negócio, 
que hoje é parte integrante no processo de desenvolvimento de software e que serviu para facilitar 
a comunicação com as pessoas que fazem parte do negócio mas não possuem conhecimentos de 
Engenharia de software.
 Observação
Os autores Michael Hammer e James Champy afirmam:
Um processo de negócio é uma coleção de atividades que usam um ou mais tipos 
de entrada e criam uma saída que seja de valor para o cliente. Um processo de negócio 
tem um objetivo e é afetado por eventos que ocorrem no mundo externo ou em outros 
processos.
 Lembrete
A técnica de modelagem de negócio é profundamente relacionada à 
arquitetura de negócios.
 Observação
Já o autor Thomas Davenport aponta que o processo de modelagem de 
negócios:
[...] é um conjunto estruturado de atividades, desenhado para produzir 
um resultado especificado para um cliente ou um mercado em particular. Isso 
implica forte ênfase sobre como o trabalho é feito dentro da organização, 
em contraste com o foco no produto. Um processo é então uma ordenação 
específica de atividades de trabalho, por meio do tempo e do espaço, com 
começo e fim e entradas e saídas claramente dentificadas: uma estrutura 
para ação.
7.2.1 Conceitos de negócio
Funções de negócio são estruturas conceituais idealizadas que servem para descrever a missão de 
uma organização. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantêm 
estáveis ao longo do tempo, mesmo diante de reorganizações da empresa.
Como são perenes, as funções representam um ponto de referência (conceitos comuns) ao se 
descrever diferentes negócios, que de outra forma exibiriam variações significativas.
106
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A Figura 58 exemplifica o relacionamento dentro de uma organização entre as funções de negócio e 
os processos de negócio a partir das atividades organizacionais e atividades de processos.
act Business Process Model
Função de negócio
Atividade de negócio
Atividade componente 
do processo
Processo de negócio
Subprocesso 
componente de processo
Figura 58 – Função de negócio, processo de negócio e seus relacionamentos
Como exemplo da aplicação dessa definição, temos o fato de que a função contabilidade de uma 
empresa define o contador, a função gerencial define o gerente e assim por diante.
Funções de negócio são também alocadas a unidades ou áreas organizacionais específicas (que 
exercerão os diferentes papéis) e são envolvidas e acionadas no decorrer do “comportamento” do 
negócio.
A Figura 58 mostra que uma função corresponde a uma série de atividades relacionadas, envolvendo 
uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da 
missão da empresa.
As atividades de negócio que compõem uma função de negócio são relacionadas entre si por 
“afinidade”, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque 
são sequenciais ou paralelas na realização do trabalho associado a um resultado final comum.
 Observação
A arquitetura de negócio busca uma visão conceitual e única de uma 
atividade ou funcionalidade, deforma que se possa identificar quando e 
como ela se repete nos diversos processos de negócio, a fim de determinar 
107
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
a generalização dos conceitos de tarefas comuns, identificando atividades 
compartilhadas e administrando seu reuso por meio da distribuição dos 
componentes que as suportam.
Da mesma forma, os sistemas de informação que suportam tais funções estarão focados em 
aspectos específicos do funcionamento do negócio, independentemente da forma como a empresa está 
organizada.
As atividades são direcionadas a dados e são “iniciadas” por transações ou solicitações de dados. Elas 
são a porção ativa das funções e tendem a ser repetitivas e formalizadas.
 Observação
É importante notar:
• Uma maneira de se diferenciar o conceito de funções e atividades 
é que, geralmente, as funções são gerenciadas e atividades são 
realizadas.
• Funções são gerenciais e atividades são operacionais.
Já um processo de negócio é definido como a sequência completa de um comportamento de 
negócio, provocado por algum evento, que produz um resultado significativo para o negócio e que, de 
preferência, tenha foco no cliente.
No percurso do processo, desde o evento inicial até a produção de um determinado resultado, 
várias funções do negócio podem estar envolvidas. Assim, diz-se que os processos são elementos 
transfuncionais, já que perpassam diversas funções dentro da organização.
Se uma função é composta de atividades que representam um papel ou razão de existir da 
organização, os processos de negócio “executam” essas atividades de forma que, individualmente ou 
combinadas, realizem o trabalho de uma determinada função.
Um estudo de aplicação de modelagem de processo de negócio para apoiar a 
especificação de requisitos de um sistema
Antes de entrarmos em duas notações de modelagem de processos seria interessante 
analisarmos os resultados obtidos com a aplicação da modelagem apresentada no artigo 
Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação 
de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges 
e Wolber Neves, apresentado no VI Simpósio Internacional de Melhoria de Processos de 
Software, em São Paulo, em 2004.
108
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
No item resultados obtidos, os autores afirmam:
A aplicação da modelagem de processos de negócio trouxe resultados bastante positivos. 
A execução dessa etapa antes da realização do levantamento dos requisitos do sistema foi 
um fator de redução de riscos, tanto para o cliente quanto para o fornecedor.
O cliente pôde ter uma visão melhor do seu negócio, identificando as áreas que realmente 
seriam beneficiadas pela construção do sistema, evitando assim o desperdício de recursos.
Foi interessante observar que, durante as oficinas, o cliente pôde perceber que 
determinados processos não estavam sendo executados da melhor forma. Diante desta 
percepção, alguns processos foram remodelados, evitando que o sistema fosse construído 
sobre uma base operacional deficiente.
Para o fornecedor, a execução da modelagem de processos de negócio resultou em 
maior facilidade na gestão dos requisitos do sistema. Muitas das constantes mudanças 
que ocorrem durante o desenvolvimento de um sistema decorrem da inexistência de um 
consenso entre os representantes do cliente sobre a melhor forma de se executar um 
processo.
A modelagem de processos de negócio fez com que esse consenso fosse alcançado antes 
do início do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente.
A identificação dos casos de uso do sistema (UML) também foi bastante facilitada. Como 
passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam 
ser mais proativos nessa atividade, contribuindo com sugestões e ponderações baseadas em 
conhecimento mais sólido.
Esta proatividade mostrou-se especialmente útil nas primeiras oficinas, já que naquele 
momento os representantes do cliente ainda não estavam totalmente seguros com a 
metodologia de levantamento dos requisitos.
Outro benefício trazido pela modelagem de processos de negócio diz respeito à 
rastreabilidade dos requisitos. Uma característica de qualidade importante para uma 
especificação de requisitos é a facilidade em se determinar os resultados do desenvolvimento 
que serão afetados por cada requisito (rastreabilidade para frente), bem como a origem de 
cada um (rastreabilidade para trás).
Como os requisitos foram derivados diretamente do modelo de processos de negócio, a 
rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo de 
negócio que o gerou.
Um ponto importante no desenvolvimento de um sistema, especialmente quando seu 
porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal de se 
109
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte são 
entregues em menor tempo do que um único módulo que contemple todas as funções.
Isto é importante tanto do ponto de vista técnico quanto do de negócio, já que muitas 
vezes o cliente não dispõe de recursos para construir todo o sistema de uma só vez, e a 
priorização de requisitos dentro de um módulo único não é uma tarefa simples.
Esse foi também um ponto em que a modelagem de processos de negócio foi benéfica. 
Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria composto por 
três produtos. Após a modelagem, percebeu-se que o número de produtos era realmente 
três, mas a composição dos mesmos foi bastante modificada. Dois dos produtos foram 
agrupados em um único, e um produto de controle de fluxo de trabalho (workflow) foi 
identificado.
Apenas um produto permaneceu conforme tinha sido concebido no início. A divisão 
inicial dos produtos espelhava a divisão funcional da empresa, o que não se mostrou uma 
boa idéia do ponto de vista de sistemas. A modelagem de processos de negócio fez com 
que cliente e fornecedor percebessem que duas das áreas eram muito integradas, o que 
justificaria um único produto para atendê-las.
Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as 
áreas funcionais, o que justificaria um produto genérico para este fim, e não a inserção de 
funcionalidades correlatas em um dos produtos específicos para determinada área.
Após a divisão dos produtos, um deles foi escolhido para ser especificado e construído. 
Seria necessário, portanto, realizar uma estimativa do tamanho do produto em pontos 
de função, para orçar-se a fase de elaboração. O melhor conhecimento da organização, 
conseguido por meio da modelagem de processos de negócio, também foi fundamental 
para que essa estimativa fosse bem próxima da contagem oficial de pontos de função, 
realizada alguns meses depois (após o fim da elaboração).
Percebeu-se inclusive que a aproximação do número real foi maior do que em projetos 
em que a modelagem de processos de negócio não foi usada.
Como último resultado importante, podemos citar o artefato resultante da modelagem de 
processos de negócio. Esse documento é importante para o cliente, já que é a documentação 
dos processos da organização. Mas também do ponto de vista do fornecedor o documento 
foi de grande utilidade, pois serviu para dar uma visão geral às pessoas que entravam no 
projeto depois de seu início. Foi uma forma simples e barata de integrar novas pessoas à 
equipe.
Adaptado de: <www.simpros.com.br>. Acesso em: 13 jul. 2012.
110
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
7.2.2 Extensão de negócio da UML
Segundo Paul e Serrano (2003), o estudo sobre processo de negócio não deve ser isolado, sendo 
importanteseu relacionamento com a área de TI, pois ela é considerada sua grande modificadora.
O processo de negócio geralmente confia no suporte fornecido pelos Sistemas de Informação (SI) 
para a realização de suas atividades.
Similarmente, esses sistemas dependem da infraestrutura de comunicação, normalmente oferecido 
por rede de computadores (RC).
A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informação e redes 
de computadores, no qual mudanças ocorridas em alguns dos domínios devem afetar os demais.
Processo1 Processo2
SI1
TI
RC1 RCn
SI2 SIn
Processon
...
Figura 59 – Relacionamento de processos, Sistemas de Informação (SI) e 
Redes de Computadores (RC)
De acordo com Dalal et al (2004), muitas técnicas para modelagem dos processos empresariais, incluindo 
DFDs (Diagramas de Fluxo de Dados), Idef0 (Definições Integradas para Modelagem por Funções, em nível 
0) e diagramas de casos de uso de negócio, têm suas raízes nos processos de desenvolvimento de software.
De acordo com as orientações da UML 2.0 Superstructure Specification, disponibilizada a partir de 
outubro de 2004 pela OMG, os casos de uso são meios de especificar os requisitos de um sistema de 
informação.
Todavia, quando casos de uso documentam processos de negócio de uma organização, o Sistema 
sob Discussão (SsD), do inglês System under Discussion (SuD), é a própria organização.
Os stakeholders ou atores de negócio são os acionistas da companhia, clientes, vendedores e as 
agências governamentais regulamentadoras. Os atores primários incluem os clientes da companhia e 
talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele não faz reEngenharia, ou 
seu projeto novamente (COCKBURN, 2005).
Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma 
descrição de um conjunto de sequências de ações, incluindo variantes realizadas pelo sistema para 
produzir um resultado observável do valor de um ator.
111
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Além disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema 
que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado. 
Também fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os 
usuários finais do sistema e com os especialistas do domínio e servem para ajudar a validar a arquitetura e 
para verificar o sistema à medida que ele evolui durante seu desenvolvimento (BOOCH et al, 2000).
Quando utilizados para representar processos de uma organização, os casos de uso são identificados 
como casos de uso de negócio.
Em outras palavras, um caso de uso de negócio representa o que a organização faz (BOGGS e BOGGS, 
2002). O escopo de um caso de uso pode abranger uma escala de assuntos:
• Uma empresa ou uma linha de negócio: este nível de modelo é utilizado para descrever como os 
sistemas se integram.
• Um sistema individual: este é o nível mais utilizado na abordagem por casos de uso.
• Um simples subsistema simples ou componente: este nível descreve os mecanismos de 
implementação de um elemento do modelo.
• Para descrever um processo de trabalho de um negócio.
• Para focar discussão sobre futuros requisitos de software.
• Para ser os requisitos funcionais de um sistema.
• Para documentar o projeto do sistema.
• Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribuído.
O modelo de casos de uso de negócio é um modelo das funções pretendidas do negócio. É usado 
como base para identificar papéis e produtos liberados na organização.
Os casos de uso de negócios são identificados e possivelmente resumidos no início da fase de 
iniciação, para ajudar a definir o escopo do projeto (RUP, 2001).
Quadro 8 – Propriedades de um caso de uso de negócio
Nome da propriedade Descrição
Nome O nome do caso de uso de negócio.
Breve descrição Uma breve descrição do papel e da finalidade do caso de uso de negócios.
Metas Uma especificação das metas ou objetivos mensuráveis do caso de uso de negócios.
Metas de desempenho Uma especificação das métricas relevantes ao caso de uso de negócios e uma definição das metas de utilização dessas métricas.
112
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Fluxo de trabalho
Uma descrição textual do fluxo de trabalho representado pelo caso de uso de 
negócios. O fluxo deve descrever o que o negócio faz para oferecer vantagens 
a um ator de negócio, e não como esse negócio resolve os problemas. A 
descrição deve ser compreensível para qualquer pessoa dentro do negócio.
Categoria Se o caso de uso de negócios pertence à categoria central, suporte ou gerenciamento.
Risco Uma especificação dos riscos de executar e/ou implementar o caso de uso de negócios. 
Possibilidades Uma descrição do potencial de melhoria estimado do caso de uso de negócios. 
Proprietário do processo Uma definição de quem é o proprietário do processo de negócios: a pessoa que gerencia e planeja as mudanças. 
Requisitos especiais As características do caso de uso de negócio não cobertas pelo fluxo de trabalho conforme descrito.
Pontos de extensão
Uma lista dos locais dentro do fluxo de eventos do caso de uso de negócios 
em que um comportamento adicional pode ser inserido por meio do 
relacionamento de extensão.
Relacionamentos Os relacionamentos (como associações de comunicação, relacionamentos de inclusão e de extensão) dos quais o caso de uso participa.
Diagramas de atividades Esses diagramas mostram a estrutura do fluxo de trabalho.
Diagramas de casos de uso Esses diagramas mostram os relacionamentos que envolvem o caso de uso.
Ilustrações do fluxo de trabalho Resultados ou esboços manuscritos provenientes das sessões de encenação.
Adaptado de: RUP, 2001.
De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negócio podem ser 
demonstrados conforme o quadro 9.
Quadro 9 – Componentes do diagrama de caso de uso de negócio
Nome Notação Descrição
Ator de negócio
Um ator de negócio representa um papel 
desempenhado em relação ao negócio por 
alguém ou algo no ambiente do negócio.
Caso de uso de negócio
Um caso de uso de negócios define uma 
instância de negócio, no qual cada instância 
é uma sequência de ações realizada por um 
negócio que produz um resultado de valor 
observável para um determinado ator de 
negócio.
Modelo de caso de uso de negócio
O modelo de casos de uso de negócios é um 
modelo das funções pretendidas do negócio. 
É usado como base para identificar papéis e 
produtos liberados na organização.
113
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Generalização de ator
Um relacionamento de generalização de uma 
classe de ator de negócio (descendente) com outra 
classe de ator de negócios (ascendente) indica que 
o descendente herda o papel que o ascendente 
pode assumir em um caso de uso de negócios.
Associação de comunicação
Uma associação de comunicação entre um caso 
de uso e um ator indica que uma instância 
do caso de uso e uma instância do ator irão 
interagir.
Relacionamento de extensão “extensão”
Um relacionamento de extensão é aquele que 
se estabelece entre um caso de uso de extensão 
e um caso de uso base, especificando como o 
comportamento definido para o caso de uso de 
extensão pode ser inserido no comportamento 
definido para o caso de uso de base. Ele é 
inserido implicitamente, ou seja, a extensão não 
é exibida no caso de uso base.
Relacionamento de inclusão “inclusão”
Um relacionamento de inclusão é aquele que 
se estabelece entre um caso de uso base e um 
caso de uso de inclusão, especificando como 
o comportamento definido para o caso de uso 
de inclusão é inserido de forma explícita no 
comportamento definido para o caso de uso 
base.
Generalização de casos de uso
Uma generalização decasos de uso é um 
relacionamento de um caso de uso filho com 
um caso de uso pai, especificando como um 
filho pode adotar todo o comportamento e as 
características descritas para o pai.
Diagrama de casos de uso
Um diagrama de casos de uso mostra os atores 
de negócios, os casos de uso de negócios, os 
pacotes de casos de uso e seus relacionamentos.
De acordo com o RUP (2001), a projeção realizada pela Engenharia de negócio é fundamental para 
a realização do sistema.
As atividades do negócio e os relacionamentos identificados entre elas, bem como a atuação dos 
envolvidos, determinarão os objetivos a serem alcançados pelo software a ser desenvolvido.
A Figura 60 apresenta uma conexão entre essas duas áreas.
Proposta para informatização
Proposta 
de software
Engenharia 
de software
Engenharia de 
processo de negócio
Modelo de negócio
Figura 60 – O relacionamento entre Engenharia de processo de negócio e Engenharia de software
114
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
7.2.3 Visões de modelos de negócio
O modelo de negócios é a forma pela qual uma empresa cria valor para todos os seus principais 
públicos de interesse.
Sua utilização ajuda a ver de forma estruturada e unificada os diversos elementos que compõem 
todas as formas de negócios da organização.
O modelo de negócio de uma empresa é composto por 5 principais elementos:
• Modelo de proposta de valor: é a forma pela qual a empresa define qual é o seu diferencial 
no mercado, a forma pela qual é única e se destaca de todas as demais empresas que participam 
desse mesmo mercado.
• Modelo de interface com o consumidor: é o que escreve onde, quando e como uma empresa 
interage com os seus consumidores. Essa interação pode se dar por meio de lojas, embalagens de 
produtos, comerciais, SAC, website etc.
• Modelo de operação: é como que uma empresa faz para levar o seu produto até o seu consumidor. 
Esse modelo deve prever todos as etapas necessária para viabilizar sua produção, passando por 
logística, até chegar às mãos de quem compra o seu produto ou serviço.
• Modelo estratégico: é a descrição de como uma empresa irá atingir os seus objetivos estratégicos. 
Nesse modelo é onde visualiza-se a missão de uma empresa, sua visão, seus valores e todas as 
competências necessárias para que a empresa funcione de forma adequada.
• Modelo econômico: é onde se demonstra a viabilidade financeira de uma empresa. Esse 
modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a 
sustentabilidade.
7.3 OCL e sua utilização na modelagem de processo de negócio
A OCL (Object Constraint Language) é uma notação que permite se dar mais precisão nas especificações 
ou modelos que usam a UML.
 Lembrete
A OCL é baseada na lógica e matemática discreta. Assim como a UML, 
é uma linguagem de modelagem e não uma linguagem de programação. É 
uma linguagem de modelos tipada. Inicialmente, a OCL era uma extensão 
para a UML, agora é parte da UML padrão.
115
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Por que a OCL?
• Um diagrama UML, tal como o diagrama de classes, é tipicamente não refinado o suficiente para 
permitir-se ter todos os aspectos relevantes de uma especificação.
• Há a necessidade de se descrever restrições adicionais sobre os objetos de um modelo.
• A linguagem natural é inerentemente ambígua.
• Linguagens formais tradicionais são dificíeis para usuários de negócio ou modeladores de sistemas.
• A OCL é uma linguagem formal que permanece simples para ler e escrever. 
Quando se deve usar a OCL?
• A linguagem OCL é usada para expressar condições constantes de restrições de especificações 
para sistemas que estão sendo modelados.
• Para especificar invariantes nas classes e tipos no modelo de classes.
• Para especificar tipos invariantes para estereótipos.
• Para descrever pré e pós-condições nas operações e métodos.
• Para especificar restrições nas operações.
A OCL é suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10.
Quadro 10 – Diagramas com suporte OCL
Tipo de diagrama Versão da UML Como o suporte é provido
Use case (caso de uso) UML 2.0
Restrições para o comportamento associado 
com os casos de uso como expressões OCL. 
Por exemplo, uma interação escolhida como 
um comportamento.
Classes (classe, namespace e 
comunicação) UML 1.5 e 2.0
Restrições na criação de objetos são 
suportadas.
Interação (sequência e comunicação) UML 2.0
Restrições de invariância de estado para 
linhas de vida e restrições dos operandos de 
fragmentos combinados como expressões OCL.
Máquina de estado UML 2.0 Condições de guarda de transições como expressões OCL.
Como os modelos de negócio são suportados pelos diagramas de casos de uso a OCL, esses apoiarão 
as restrições das pré e pós-condições para execução de um caso de uso de negócio.
116
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
7.4 Integração com o desenvolvimento de software
Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma série de 
fases, cada uma focando diferentes partes do negócio ou sistema. Existem duas abordagens para a 
modelagem de negócio em um ambiente iterativo:
• Primeiro, terminar toda a modelagem de negócio e, na sequência, iniciar as atividades iterativas 
(análise, design, codificação, teste e implantação).
• Alternativamente, pode-se incluir a modelagem de negócio nas iterações (BOGGS e BOGGS, 2002).
Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo 
“cascata”, a modelagem de negócio surge nas fases iniciais.
As razões pelas quais isso ocorre é que a modelagem de negócio determina o contexto para o 
projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negócio nos processos de 
desenvolvimento de software.
Modelagem de negócio
Análise
Implantação Design
Teste Implementação
Figura 61 – Processo iterativo após o surgimento da modelagem de negócio
Modelagem 
de negócio
Análise
Implantação Design
Teste Implementação
Figura 62 – Modelagem de negócio como fase integrante do processo iterativo
7.4.1 Processo de desenvolvimento de software
Existem inúmeros caminhos para reproduzir modelos de negócio dentro dos processos de 
desenvolvimento de software, incluindo o uso de outras notações tais como Idef0 (modelagem 
funcional), ou mesmo descrições textuais do processo.
117
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
No entanto, a UML é um padrão bem definido, suportado por muitas técnicas. É a linguagem de 
modelagem dominante, usada em sistemas de informação orientados a objeto.
A UML é na atualidade o padrão que possui a melhor definição, suportada por muitas ferramentas e, 
dessa forma, tornou-se a linguagem de modelagem dominante na aplicação da tecnologia da orientação 
a objetos.
Além disso, pode ser utilizada para a modelagem de negócio e também para a modelagem de 
outros sistemas, ou seja, para aqueles que não serão utilizados para o desenvolvimento de softwares 
(OMG, 2005).
Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negócio são: business 
use-case e business object model. Diagramas num modelo de negócio ajudarão a compreender o que a 
organização fornece de valor, dentro de um relacionamento.
Enquanto a maioria dos diagramas da UML foca no sistema que será construído, o modelo de casos 
de uso de negócio se concentra no negócio em torno desse sistema (BOGGS e BOGGS, 2002).
O modelo de caso de uso de negócio consiste na interação entre atores e casos de uso, para 
demonstrar a sequência de eventos necessários na realização de um trabalho.
Juntos, atores e casos de uso descrevem o que está envolvido nas atividades do negócio e também 
como ele ocorre (WIDRIG e LEFFINGWELL, 2003).
7.4.2 Arquiteturade negócio e arquitetura de software
Um dos principais esforços da investigação relacionada com a Engenharia de software tem sido 
a definição e representação de modelos que descrevam os processos de software, garantindo que 
esses correspondam fidedignamente às necessidades efetivas (em forma e conteúdo) dos processos 
de negócio.
Deparamo-nos então com duas realidades complementares: a modelagem dos processos de negócio 
e a modelagem do software, que também podem ser chamadas de arquitetura de negócio e arquitetura 
de software, na qual esta última tem cada vez mais a necessidade de estar em sintonia com toda a 
abrangência do negócio (RODRIGUES, 2004).
As modelagens de negócio e de sistema (software) são frequentemente desenvolvidas como parte 
de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definição, pois são 
ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema 
(PENKER e ERIKSSON, 2000).
Rodrigues (2004), ao avaliar o contexto da modelagem de negócio para a modelagem de sistema, 
especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domínios seja 
estabelecida de forma suave e sem sobressaltos.
118
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A Figura 63 mostra a integração proposta por Rodrigues (2004).
Modelagem do processo Modelagem de sistema
O que existe para fazer a ponte efetiva 
entre modelagem de negócio e sistema?
Figura 63 – Integração entre modelagem de negócio e sistema
No RUP (2001), a integração entre negócio e sistema tem início nas primeiras atividades da iteração 
do ciclo de desenvolvimento do sistema, definida como iniciação.
Nesse momento, a maior parte dos esforços, para as disciplinas Modelagem de Negócios e Requisitos, 
é utilizada com o propósito de obter as informações necessárias para a condução do projeto e elaboração 
do software.
A Figura 64 demonstra, no detalhe, o esforço necessário na fase inicial da iteração, a partir do 
desenho de visão geral do RUP.
Fases
Iniciação ElaboraçãoDisciplinas
Modelagem de negócios
Concentração 
de esforços nas 
fases iniciais.
Requisitos
Construção Transição
Figura 64 – O esforço da modelagem de negócios e requisitos
A Figura 64 mostra que as disciplinas de Modelagem de Negócios e Requisitos do Sistema são 
perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP.
Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia é o gerenciamento 
de processos de negócio ou business process management.
119
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
 Saiba mais
Vale a pena conferir o documento Business Process Management Enabled 
by SOA, da IBM de 2009, em que o gerenciamento de processos de negócio 
é mais frequentemente associado com o ciclo de vida de um de processos 
de negócios. O ciclo de vida de processo de negócio abrange identificar 
e melhorar os processos que proporcionam capacidade de negócios para 
implantar e gerenciar os seus processos quando estiver operacional.
O que é frequentemente esquecido é a gestão do desempenho do processo depois que é operacional. 
De certa forma, essa é provavelmente a fase mais importante do ciclo de vida de processos. Depois que 
um processo de negócio é implantado, ele deve ser gerenciado, e, para gerenciar o processo de negócio, 
deve-se ter visibilidade do desempenho de processos.
Quando um processo não atingir mais o seu desempenho de seus objetivos, é hora de voltar ao 
ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria 
adicionais.
Subjacente, BPM é também governança. Governança é um componente essencial de BPM porque 
fornece a estrutura que garante que a estratégia de negócios e metas sejam implementadas no nível 
operacional.
A estrutura de governança também permite negócio e alinhamento de TI, fornecendo mecanismos 
que aumentem a colaboração e cooperação entre os dois mundos, os processos de negócio e a tecnologia 
da informação.
8 A MODELAGEM DE pROCESSOS DE NEGÓCIO
8.1 Visão Erikson e penker
Antes que a OMG se preocupasse com a modelagem de negócios com a linguagem UML, os autores 
Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negócio, o 
qual apresenta:
• Uma visão de mais alto nível, visando identificar a situação do negócio que será abordada.
• Nessa visão, deve-se definir o contexto e o escopo, sendo que:
— o contexto é o que está relacionado, qual a situação, descrição do problema; e
— o escopo é até onde vai, contorno ou limite.
120
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
• Essa visão pode incluir FCSs (Fatores Críticos de Sucesso).
• As metas e objetivos (do original Goal) podem ser decompostos em diferentes níveis, como, 
estratégico/tático/operacional, sendo que:
— o objetivo é qualificável; e
— a meta é quantificável.
Nesse modelo, os processos de negócio:
• possuem uma meta;
• possuem entradas e saídas específicas;
• usam recursos;
• possuem um número de atividades, realizadas em alguma ordem, que podem ser vistas como 
subprocessos;
• afetam mais de uma unidade da organização;
• criam valor para algum consumidor (interno ou externo).
A figura 65 apresenta os elementos ou símbolos propostos para o modelo de Erikson e Penker.
<<processo>>
<<processo>> <<processo>> <<processo>>
Processo A
Subprocesso A1 Subprocesso A1 Subprocesso A1
Atividade A2a
Atividades podem ser entendidas 
como processos atômicos
Atividade A2b Atividade A2c
Figura 65 – Notação de Erikson e Penker para modelagem de negócio
121
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
As atividades ou processos atômicos são:
• Diretas: diretamente envolvidas na criação do produto ou serviço, que é o valor criado pelo 
processo.
• Indiretas: dá suporte às atividades diretas, como manutenção, administração etc.
• Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como 
inspeção, controle, revisão e validação.
A figura 66 ilustra os passos de um processo de negócio nesta notação.
<<processo>>
Processo contendo 3 subprocessos: dois atômicos e um composto
<<processo>>
Furação
Fazer furo
Calibrar Ligar furadeira
FurarLer 
instrução
Figura 66 – Passos de um processo
A figura 67 mostra um exemplo de um processo de negócio com recepção e emissão.
<<processo>>
Demanda 
do cliente 
por ação
Ordem 
de 
compra
Ordem 
de 
venda
Administração 
de compra de 
ação
Administração 
de venda de 
ação
Compra de 
ação no 
mercado
Venda de 
ação no 
mercado
<<processo>>
<<processo>>
Figura 67 – Processo de recepção e emissão
122
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Como novo exemplo, a figura 68 apresenta um modelo de processo de furação de chapas em uma 
indústria qualquer.
<<processo>>
<<achieve>>
<<information>>
instruções 
de fucação <<physical>>
chapa 
perfurada
<<physical>>
chapa de aço
furação
<<goal>>
chapas furadas 
por dia: Meta 
Quantitativa
Valor = 100
Figura 68 – Exemplo de um processo de furação de chapa
A notação de Erikson e Penker ainda hoje é utilizada, e algumas ferramentas Case, tal como a 
ferramenta EA, mantêm essa notação.
8.2 A modelagem de processos de negócio com a BpM
A notação BPMN surgiu como um padrão alternativo à UML, também sendo gráfica, porém seus 
símbolos são um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada 
especificamente para modelar processos de negócio. Essa notação não oferece qualquer suporte para 
modelar dados, atores, estados de ciclo de vida, ou sistemas.
Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativaoriunda 
da OMG que lançou a especificação 1.0 ao público em maio de 2004.
Tanto a UML como a BPMN são notações mantidas pela OMG.
Os objetivos do esforço do grupo que desenvolveu o BPMN são:
• Fornecer uma notação que seja fácil.
• Ser compreensível por todos os usuários de negócios.
• Envolver os analistas de negócio, os desenvolvedores, os técnicos responsáveis pela aplicação dos 
sistemas que irão executar os processos e as pessoas de negócios.
123
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado 
para a criação de modelos gráficos de tarefas dos processos de negócio.
Para a BPMN, um modelo de processo de negócios é uma rede de objetos gráficos, denominados de 
atividades, e do fluxo de controle, que define a ordem de execução.
As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vêm investindo em 
sistemas que automatizam a gestão de processos de negócio (execução, controle e monitoração). 
Esses sistemas são os denominados BPMS (Business Process Management Suite), que dão suporte ao 
mapeamento, execução, monitoração e controle dos processos de negócio de uma organização.
Tipicamente, inclui:
• o mapeamento dos processos de negócio ponta-a-ponta;
• desenho dos fluxos e formulários eletrônicos;
• definição de workflow;
• regras de negócio;
• integradores;
• monitoração em tempo real das atividades; e
• alertas.
É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente 
executados como modelados, contribuindo para os objetivos da organização.
Os softwares utilizados na operacionalização e gerenciamento de processos de negócio são um dos 
principais facilitadores da gestão do conhecimento referente ao processo, sendo considerada a maior 
facilidade para obtenção, distribuição e análise dos dados.
Há algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares 
BPMS, que, quando disponíveis, aumentam a capacidade dos gestores e demais envolvidos com o processo 
em estabelecer uma troca de imagens e idéias, nos ambientes onde ocorre a geração do conhecimento.
 Observação
A solução BPMS não propõe a substituição dos sistemas existentes na 
organização os conhecidos como “sistemas legados”, e sim disponibiliza um 
ambiente de integração de sistemas de informação, que permite definir:
124
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
• fluxo de execução;
• regras;
• eventos;
• demais especificações necessárias à operação e gerenciamento do 
processo de negócio.
Dessa forma, permite atender a outra característica do processo de negócio: a de ser 
extremamente dinâmico, permitindo, por exemplo, uma substituição rápida e simples de um 
software por outro, necessária quando uma empresa parceira da organização é substituída, 
demandando a integração com um novo software disponível no ambiente computacional do 
novo parceiro.
De acordo com vários autores, um BPMS completo teria os seguintes módulos ou funcionalidades:
• Funcionalidades mínimas para uma solução poder se classificar como BPMS:
— ferramenta de modelagem e desenho do processo;
— engenho de execução do processo;
— orquestração de web services;
— interface de workflow para usuários.
• Para ter um produto mais completo, seria necessário:
— suporte para regras de negócio complexas;
— Business Activity Monitoring (BAM);
— controle de versão dos documentos anexados a instâncias do processo.
• E para um produto completo, seria acrescentado de:
— Enterprise Service Bus (ESB);
— Repositório de metadados;
— Uma suite de business intelligence.
125
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Um BPD é formado por um conjunto de quatro elementos gráficos, que são:
• objetos de fluxo;
• objetos de conexão;
• raias (swimlanes); e
• artefatos.
8.2.1 Objetos de fluxo
Um BPD apresenta três objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo são os 
principais elementos gráficos para definir o comportamento de um processo de negócio.
8.2.1.1 Evento
Um evento é algo que “acontece” no decurso de um processo de negócio. Esses eventos afetam o 
fluxo do processo e normalmente têm uma causa (trigger) ou um impacto (resultado).
Somente os eventos têm a capacidade de iniciar ou terminar um processo, porém não executam 
tarefas nesse. Os eventos ainda podem forçar a execução ou desviar para uma determinada atividade.
Há três tipos de eventos, com base em quando eles afetam o fluxo: evento de início, evento 
intermediário e evento de fim, com notação apresentada na figura 69.
BPMN BPMN
Evento início
Evento intermediário
Evento fim
Figura 69 – Símbolos de eventos da BPMN
126
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
O evento início define a inicialização em um processo. O evento intermediário define um evento 
intermediário em um processo. Já o evento fim define o término de um evento em um processo.
Um processo pode ser iniciado por diferentes circunstâncias. Essas circunstâncias são chamadas de 
gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador.
8.2.1.2 Atividade
Uma atividade organiza e especifica participação de comportamentos subordinados, tais como, as 
sub-atividades ou ações, para refletir o controle e o fluxo de dados de um processo.
As atividades são usadas nos diagramas de atividades para vários propósitos de modelagem: para a 
modelagem do desenvolvimento de uma aplicação típica, para modelagem de um processo de negócio 
ou para modelar um workflow.
Durante a criação, ou em edições mais tarde, uma atividade pode ser definida como um elemento 
composto. Contudo, quando se cria uma atividade composta, é possível usar também o elemento 
atividade estruturada, que foi criada para esse propósito.
A especificação da OMG UML1 estabelece:
• Uma atividade específica à coordenação da execução de comportamentos subordinados, usando 
um controle e modelo de fluxo de dados.
• Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque 
outros comportamentos no modelo irão concluir a execução, ou porque os objetos e os dados 
ficam disponíveis, ou porque ocorrem eventos externos para o fluxo.
• O fluxo de execução é modelado como atividades, os nós são ligados por arestas. Um nó pode ser 
a execução de um comportamento do subordinado, como um cálculo aritmético, uma chamada 
para uma operação, ou a manipulação do conteúdo do objeto.
• Atividades podem formar hierarquias invocando outras atividades, em última análise, para resolver 
as ações individuais. Em um modelo orientado a objetos, as atividades são geralmente chamadas 
indiretamente de métodos vinculados às operações que estejam diretamente invocadas.
• As atividades podem descrever processos de computação. Nesse contexto, são os métodos 
correspondentes às operações nas classes. As atividades podem ser aplicadas à modelagem 
organizacional para a Engenharia de processos de negócio e workflow.
• Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de 
uma tarefa, mas também de fora do sistema, como uma chamada de cliente.
1 UML Superestrutura Especificação, versão 2.1.1, p. 318.
127
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
• As atividades também podem ser utilizadas para a modelagem de sistema de informação, para 
especificar os processos ao nível do sistema. As atividades podem incluir ações de vários tipos 
(funções primitivas, operações aritméticas etc.).
Uma atividade é representada por um retângulo de bordas arredondadas e é um termo genérico para o 
trabalho que a empresa realiza. Uma atividade pode ser atômica (tarefa) ou não atômica(composta – subprocesso).
analysis Diagrama Estrutura de Versão
Atividade Sub_processo
+
Figura 70 – Atividade atômica e não atômica
8.2.1.3 Gateway
Utilizado para controlar a divergência e convergência da sequência de fluxos, determina as decisões tradicionais 
de bifurcação, fusão e união de caminhos. Marcadores internos indicam o tipo de controle do comportamento.
analysis Diagrama Estrutura de Versão
Figura 71 – Elemento gateway
Gateways são os mecanismos padronizados na notação BPMN para desvios. Eles controlam como 
o processo diverge ou converge, ou seja, representam pontos de controle para caminhos dentro do 
processo. Eles separam e juntam o fluxo de um processo por meio do fluxo de sequência.
8.2.2 Objetos de conexão
Os objetos de fluxo são conectados ao diagrama pelos objetos de conexão, para criar o esqueleto 
estrutural básico de um processo de negócio.
Um BPD tem três objetos de conexão: fluxo de sequência, fluxo de mensagem e associação.
128
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
8.2.2.1 Fluxo de sequência
Um fluxo de sequência é usado para mostrar a ordem (sequência) que as atividades são realizadas 
em um processo.
A figura 72 mostra um exemplo de fluxo de sequência.
BPMN BPMN
Atividade 1
Fluxo de sequência
Atividade 2
Figura 72 – Fluxo de sequência
8.2.2.2 Fluxo de mensagem
Um fluxo de mensagem é usado para mostrar mensagens entre dois participantes do processo 
(entidades empresariais ou papéis de negócio) que enviam e recebem mensagens.
BPMN BPMN
Atividade 1
Fluxo de mensagem
Atividade 2
Figura 73 – Fluxo de mensagem
8.2.2.3 Associação
Uma associação é usada para associar dados, textos e outros artefatos com os objetos de fluxo. 
Associações são utilizadas para mostrar as entradas e saídas de atividades.
analysis Diagrama Visão Estrutura de Versão
Activity2
Documento
IntermediateEvent3
Figura 74 – Associação
129
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
A figura 75 mostra um exemplo de um pedaço de um processo utilizando os elementos apresentados.
StartEvent
YES
Repeat for Each Supplier
EndEvent
No
class BPMN
Limite do tempo excedeu
Marca que mostra que o 
subprocesso tem loop
Evento intermediário 
para um time out
Send RFQ Receive 
Quote
Add 
Quote
Figura 75 – Exemplo de um processo
8.2.3 Raias (Swimlanes)
Swimlanes é um mecanismo para organizar atividades em categorias visuais separadas, que 
organizam as diversas capacidades ou responsabilidades. Os objetos swimlanes do BPD são:
• Pool;
• Lane.
Swinlanes ou raias ajudam a dividir e organizar atividades em diferentes categorias visuais em um 
diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades.
Pools são utilizados quando o diagrama envolve duas entidades empresariais e são separados fisicamente 
no diagrama. As atividades dentro de grupos separados são consideradas processos autocontidos.
Os fluxos de sequência não podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem 
como mecanismo para mostrar a comunicação entre dois participantes em pools diferentes.
8.2.3.1 Pool
Pool representa um participante em um processo (pessoa, área, empresa, outro processo etc.). Atua 
como um container gráfico para o particionamento de um conjunto de atividades de um ou mais 
processos de um participante.
130
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
class BPMN
<<
Po
ol
>>
Cl
ie
nt
e
Figura 76 – Exemplo de um diagrama com pool
8.2.3.2 Lane
Lane é uma subpartição dentro de um pool que vai se estender a todo comprimento do pool, 
tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar 
atividades.
As lanes são elementos que são posicionados dentro de pools para indicar mais de um perfil que 
colaboram para a execução de um processo. Lanes criam subpartições para os objetos dentro de um 
pool. Essas participações são usadas para agrupar elementos do processo.
São frequentemente usadas para separar as atividades associadas com uma função ou papel de uma 
determinada empresa. Os fluxos de sequência podem atravessar as fronteiras das lanes dentro de um 
pool.
O fluxo de mensagem não pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.
class BPMN
<<
Po
ol
>>
HE
LP
DE
SK
Cl
ie
nt
e
CA
C
Figura 77 – Uma pool com duas lanes
A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma 
lane cada.
131
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
class BPMN
<<
Po
ol
>>
<<
Po
ol
>>
PA
CI
EN
TE
Co
ns
ul
tó
rio
 M
éd
ic
o
Ocorre 
doença
Envia 
pedido 
médico
Envia 
pedido 
médico
Recebe 
pedido 
sintomas
Recebe 
pedido 
sintomas
Envia 
sintomas
Envia 
sintomas
Recebe 
receita
Recebe 
receita
Eu quero ver 
o médico
O médico 
pede sintomas
Eu me sinto 
doente
Pegue sua receita 
para comprar os 
remédios
Figura 78 – Exemplo de pools e lanes juntas
8.2.4 Artefatos
A notação BPMN permite aos modeladores o uso de extensões de notação. Um número qualquer 
de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de 
negócio sendo modelado.
A versão corrente do BPMN predefine três tipos de artefatos BPD:
• objeto de dados;
• grupo; e
• anotação.
Os modeladores podem criar seus próprios tipos de artefatos, que podem adicionar mais detalhes 
sobre como o processo é executado.
A figura 79 mostra um diagrama com lanes dentro de uma pool e com adicionamento de artefatos.
132
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
<<Group>>
Informações 
pagamento
E-mail 
requisição 
aprovação
class BPMN
Ad
m
in
ist
ra
çã
o
W
eb
 S
er
vi
ce
Ge
re
nc
ia
m
en
to
Prepara ordem 
de pagamento
+
Aprova 
requisição
Despacha para 
aprovação
Estas atividades 
podem ser iniciadas 
ao mesmo tempo
Figura 79 – Uso de artefatos no BPD
8.2.4.1 Objeto de dados
São mecanismos para mostrar que dados são requeridos ou produzidos pelas atividades. São 
conectados às atividades a partir das associações.
BPMN BPMN
Objetos de dados
Anotações
<<Group>>
Grupos
Figura 80 – Artefatos do BPD
8.2.4.2 Grupo
Um grupo pode ser usado para documentação, mas não afeta o fluxo de mensagens.
8.2.4.3 Anotação
É um mecanismo para um modelador colocar textos de informações adicionais no diagrama.
133
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
8.3 Conclusão do BpMN
Um objetivo-chave da BPMN foi criar uma ponte entre a notação da modelagem de processos de 
negócios e a modelagem de linguagens orientadas para TI, que irá implementar os processos dentro de 
um sistema de gestão de processos de negócios.
 Observação
Os objetos gráficos da BPMN, apoiados por um rico conjunto de atributos 
de objeto, foram mapeados para o Business Process Execution Language 
for Web Services (BPEL4WS v 1.1), o padrão de fato para a execução do 
processo.
 Resumo
Esta unidade mostrou os conceitos envolvidos com a modelagem de 
negócios que precede a modelagem de sistemas de informação.
Mostrou também que a UML propõe uma notação e um padrão de 
modelagem voltados para a especificação das regras de negócio de uma função 
e processo de negócio de uma organização. A OMG também vem propondo o 
uso da nova notação denominada BPMN, que está sendo preparada para novas 
ferramentas de automação de aplicações a partir dos modelos de negócio.
O uso dessa combinação tem como grande objetivo colocar a área de 
desenvolvimento de sistemas totalmente casada com ás áreas de negócio e 
construindo aplicações que agreguem valor ao negócio.
Com relação às organizações, elas estão descobrindo que a modelagem 
de processos de negócio pode ser uma excelenteferramenta para disseminar 
o conhecimento organizacional.
Uma vez que as organizações passam a compreendê-lo como um recurso, 
a modelagem de processos de negócio pode tornar-se uma excelente fonte 
para a vantagem competitiva.
Processos de negócio estruturados na cooperação, integração e no 
alinhamento entre todas as áreas organizacionais constituem o segredo de 
sucesso de uma organização.
Atualmente, o modelo de caso de uso de negócio pode ser aplicado 
nos modelos de desenvolvimento em cascata, na fase de levantamento 
134
Unidade IV
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
de requisitos de negócio, e no modelo iterativo RUP, na fase de iniciação, 
também para modelagem dos requisitos de negócio que precedem as 
definições e especificações dos modelos dos sistemas de informação da 
organização.
 Exercícios
Questão 1. Os autores definem que processos de negócio são um conjunto de atividades previamente 
estabelecidas cujo objetivo é determinar como o trabalho será realizado em uma organização por uma 
área de negócio. Diz-se que uma estrutura de processos de negócio mal concebida pode por em risco 
a eficiência e a eficácia da organização por meio dos produtos e serviços gerados e disponibilizados. 
Considerando os conceitos sobre processos de negócio, analise as afirmações a seguir e assinale a 
alternativa incorreta:
A) Uma função de negócio é a mesma coisa que um processo de negócio, já que ambos representam 
o conjunto de atividades de uma organização.
B) Processos de negócio são atividades transfuncionais previamente estabelecidas para tratar um 
determinado negócio da organização.
C) Um sistema de informação bem estruturado implementa processos de negócio de uma empresa 
ou organização.
D) Uma Função de Negócio representa a estrutura funcional da Organização, já que um “Processo 
de Negócio” é um conjunto de atividades ou ações que são transfuncionais, isto é, atravessam 
diversas áreas ou funções de negócio.
E) Os processos de negócio devem funcionar de forma alinhada em relação a toda a estrutura 
organizacional, pois somente dessa forma será possível atingir os objetivos transversais de 
qualquer organização.
Resposta: Alternativa A.
Alguns autores definem processo de negócio ou processo organizacional como sendo um conjunto 
de atividades. Nesse conjunto, uma organização deve ser estruturada com o objetivo de produzir valor 
para os seus clientes.
Análise das alternativas
A) Incorreta. Função de negócio é uma representação de uma estrutura dentro de uma 
organização. Por exemplo: o departamento financeiro é uma função de negócio; já um sistema 
financeiro (processo de negócio financeiro), atua em diversas áreas da empresa. Quando se 
mapeia o processo de negócio financeiro, torna-se necessário entender diversas áreas ou 
135
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
funções da empresa, que, de alguma forma, utilizam ou precisam tratar com as informações 
financeiras da empresa.
B) Correta. Os processos de negócio estão diretamente ligados aos negócios da empresa e independem 
da estrutura organizacional. Normalmente atravessam as fronteiras das funções de negócio.
C) Correta. Um sistema de informação automatiza atividades dos processos de negócio, e, se ficarem 
estritamente ligados a uma função da empresa, não serão eficazes na busca de valor para a 
instituição.
D) Correta. uma função de negócio representa uma estrutura funcional de uma empresa, por 
exemplo: área de TI, área de Logística etc. E um processo de negócio seria a venda de carros de 
luxo de uma montadora de veículos.
E) Correta. A venda de carros de luxo de uma montadora possuirá atividades espalhadas por toda a estrutura 
de uma montadora: área de marketing, design de veículos, linha de produção, e assim por diante.
Questão 2. Na atualidade, com propósito de se ter sistemas de informações abrangentes e que 
agreguem valor ao negócio de uma organização, evolue-se para duas visões complementares: a modelagem 
de negócio e a modelagem de sistemas de informação. Normalmente, as modelagens de negócio e de 
sistemas (software) são desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A 
modelagem de negócios trata todas as atividades envolvidas com o negócio, e a modelagem de sistemas 
verifica o aspecto de automação a partir do modelo de negócio. Ambas devem possuir boa definição, 
pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do 
sistema. Considerando os conceitos sobre Arquitetura de negócio, Arquitetura de Software e exemplos 
apresentados nesta unidade, analise as afirmações a seguir e assinale a alternativa incorreta:
A) Para a modelagem de negócio, utiliza-se a notação BPMN, a qual surgiu como um padrão alternativo à 
UML, já que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software.
B) A modelagem de negócio com BPMN é gráfica, porém, para representar as atividades existentes 
nos processos de negócio, seus símbolos são um pouco diferentes da UML.
C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991.
D) Pode-se afirmar que o processo de modelagem de negócios “é um conjunto estruturado de 
atividades, desenhado para produzir um resultado específico para um cliente ou um mercado em 
particular”.
E) A modelagem de negócio leva em consideração que um processo é “uma ordenação específica 
de atividades de trabalho, por meio do tempo e do espaço, com começo, fim e entradas e saídas 
claramente identificadas: é uma estrutura para ação”.
Resolução desta questão na plataforma.
136
FIGURAS e ILUSTRAçõeS
Figura 2
Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a 
objetos, São Paulo: Makron Books, 1998.
Figura 3
Exemplo de uma aplicação da AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados 
a objetos, São Paulo: Makron Books, 1998.
Figura 57
Processos de negócio. Disponível em: <http://www.trainning.com.br/analistadenegocios_bpm_artigo.
asp>. Acesso em: 14 mai. 2012.
Figura 59
Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC). PAUL, R. J.; 
SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência 
de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação, 
Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
Figura 60
O relacionamento entre Engenharia de processo de negócio e Engenharia de software. RUP. Rational 
Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.
Figuras 61 e 62
Processo iterativo após o surgimento da modelagem de negócio e Modelagem de negócio como fase 
integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample 
Chapter. 2002.
Figura 63
Integração entre modelagem de negócio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de 
negócio com base nas extensões de penker e eriksson para casos de uso. Portugal. 2004.
Figura 64
O esforço da modelagem de negócios e requisitos. RUP. Rational Unified Process. Rational Software 
Corporation, versão 2002.05.00, 2001.
137
ReFeRêNCIAS
BRANCO, I. V. C. Modelagem de processos organizacionais integrada às aplicações práticas de 
aprendizagem organizacional e compeências conversacionais. Dissertação de Mestrado da UCB, 
Brasilia, Brasil, 2007.
BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – guia do usuário. Rio de Janeiro: Editora Campus, 2000.
COCKBURN, A. Escrevendo casos de uso eficazes – um guia prático para desenvolvedores de software. 
Tradução de Roberto Vedoato. 1ª ed. Porto Alegre: Bookman, 2005.
DALAL, N. et al. Toward an integrated framework for modeling enterprise processes. Communications 
of the ACM, v. 47, nº 3, 2004.
ERIKSON, H.; PENKER,M. Business modeling with UML: business patterns at work. John Wiley & Sons, 2000.
HUCKVALE, T.; OULD, M. Process modeling: why, what and how., New York, EUA: Jonh Wiley, 1993.
FURLAN, J. D. Modelagem de objetos através da UML, São Paulo: Makron Books, 1998.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianápolis, EUA: 
Addison Wesley, 1999.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language – user guide. Massachusetts, 
EUA: Addison Wesley, 1999.
LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. Rio de Janeiro: LTC, 2001.
MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004.
OMG. Object management Group. Disponível em: <http://www.uml.org/>. Acesso em: 17 ago. 2005.
PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais 
da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e 
Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
PFLEEGER, S. L. Engenharia de software – teoria e prática. São Paulo: Prentice hall, 2004.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Editora Campus, 1994.
REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books, 2000.
138
RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de Penker e 
Eriksson para casos de uso. Portugal, 2004.
RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.
SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo: 
Best Seller, 1990.
SZILAGYI, D. C. Modelagem de processos de negócio – um comparativo entre BPML e UML. Dissertação 
de Mestrado da Pontifícia Universidade Católica – São Paulo, 2010.
YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998.
WIDRIG, D.; LEFFINGWELL, D. Managing software requirements: a use case approach. 2ª ed. Addison 
Wesley, 2003.
139
140
141
142
143
144
Informações:
www.sepi.unip.br ou 0800 010 9000