Wikibpm Modelagem de Processos

BPM Beyond Process Modelling
Introduo
1.1.Contextualizao
A partir dos anos 90 as empresas passaram a estruturar-se atravs da

gesto por processos, buscando uma maior integrao e eficincia de
suas operaes. A gesto por processos est calcada em modelos de
processos e notaes de processos. O primeiro representa a um conjunto
de atividades que expressa um processo na empresa e o segundo seria a
regra para a representao dessas das atividades no processo. Assim
sendo, algumas empresas comearam a enxergar essa iniciativa de
gesto
por
processo
com
uma
boa
oportunidade
de
mercado
comearam a prestar servios em Business Process Management e

softwares,
criando
seus
prprios
padres
de
modelagem.
Em
conseqncia disso, o mercado passou a apresentar uma srie de

notaes para modelagem, mas que representavam um grande problema
para as organizaes, j que no apresentavam uma linguagem comum
na modelagem de seus processos. Este fato acabava por criar uma srie
de rudos ao tentar integrar processos modelados em linguagens
diferentes, j que notaes diferentes dificultam a comparabilidade entre
processos, alm de inibir a utilizao de modelos de referencia e
benchmarking na melhoria dos processos.
O interesse atual na abordagem de notaes e modelagem de processos
fez com que inmeras expectativas surgissem no mercado. Quer se trate
de Business Process Reengineering (BPR), Business Process Management
(BPM), Activity Based Costing (ABC), ou Business Activity Monitoring
(BAM), a notao de processos e a sua modelagem participam cada uma
destas abordagens. A chegada de padres de modelagem j est
resultando na
racionalizao
de
processos,
criando
uma base
conhecimentos que pode ser partilhada pelos players no mercado.
de
Dado esse cenrio, comearam a surgir alguns grupos na tentativa de

unificar as notaes existentes. Em junho de 2005 foi criado o Business
Modeling & Integration (BMI), Domain Task Force (DTF), atravs da fuso
entre o Business Process Management Initiative (BPMI.org) e o Object
Management Group (OMG). Com essa unio, alguns padres de
modelagem foram criados, sendo o Business Process Management
Notation (BPMN) um dos mais importantes.
1.2.Definies
Abaixo seguem algumas definies que sero utilizadas no decorrer desse

wiki.
Tabela 1 Definies (FONTE: ELO Group)
Conceito
Business
Process
Modeling
(BPM)
Modelo
Modelo de
Processo
Notao
de
modelo
de
processos
Definio
BPM uma abordagem utilizada para identificar,
desenhar, documentar, mensurar, monitorar e
controlar tanto processo de negcios
automatizados quanto no-automatizados com o
objetivo de alcanar resultados que estejam
alinhados com as metas estratgicas da
organizao. ABPMP CBOK
Um modelo pode ser entendido como uma
representao explcita e externa de parte da
realidade vista por pessoas que desejam usar o
modelo para: entender, mudar, gerenciar e
controlar esta parte da realidade de alguma
forma. Pidd (1999).
Modelo de processo um conjunto de atividades

envolvidas na criao de representaes de um
processo novo ou de um j existente. ABPMP
CBOK
Conjunto de sinais com que se faz essa

representao ou designao. Dicionrio
Michaellis
Exemplo
No aplicvel
Desenho com a representao

de uma rede hidrulica de uma
casa
Passo-a-passo de como se
cozinha um arroz.
BPMN, UML, IDEF
A figura a seguir exemplifica as definies apresentadas anteriormente:
Figura 1 Princpio da modelagem de processo (FONTE: ELO Group)
1.3.Motivaes e Benefcios Esperados
Segundo Vernadat apud Chaulhoub (2004), a modelagem de processos

de negcios apresenta os seguintes benefcios e motivaes:
Representar como so realizadas as atividades dentro da empresa,
possibilitando um melhor entendimento de como ela funciona;
Armazenar conhecimentos adquiridos e know-how organizacional
para uma possvel reutilizao no futuro;
Racionalizar e assegurar os fluxos de informao;
Projetar/reprojetar e detalhar uma parte da empresa, contemplando
aspectos
funcionais,
comportamentais,
informacionais,
organizacionais ou estruturais;
Analisar diferentes aspectos da empresa
organizacional etc.);
Possibilitar a realizao de simulaes;
(anlise econmica,
Tomar melhores decises em relao organizao e s operaes

empresariais;
Controlar, coordenar ou monitorar os processos empresariais.
Segundo Rashid M. Khan, em seu artigo What Standards Really Matter

For BPM, a modelagem e notao de processos podem trazer alguns
benefcios para a organizao, como por exemplo:
Promover o padro de terminologias e definies dos processos de
negcio. Isso acelera o entendimento dos processos, maximizando
a sua compreenso
a capacidade de
resposta
rpida s
necessidades dos clientes;

A utilizao de uma linguagem padro e amplamente utilizada pelo
mercado permite s empresas desenvolver, manter e atualizar seus
processos de forma mais simples e rpida;
Capacidade de integrao entre processos de negcios que estejam
modelados na mesma linguagem. Caso haja processos que estejam
modelados em notaes diferentes, a interao entre eles pode ser
prejudicada;
Outro grande benefcio da padronizao de uma linguagem a
facilidade que as empresas tm de migrar de uma notao baseada
em BPM para a outra. Se h uma insatisfao com algum tipo de
linguagem especfica, a organizao pode adequar-se a outra que
segue o mesmo padro em BPM.
Ao facilitar a compreenso e auxiliar a navegao entre sistemas
em BPM, este padro ir reduzir os custos de realizao dos
processos e, assim, trazer vantagens para o consumidor final;
Algumas linguagens em BPM tm uma forte base matemtica
envolvida em sua estrutura. Assim, notaes baseadas em clculos,
como o BPEL estruturado sobre o Pi Calculus, minimiza as chances
de erros
se comparado a linguagens que no apresentam esse
embasamento.
Reviso Terica sobre Modelagem de Processos

Abaixo seguem algumas opinies de principais autores sobre modelagem
de processos.
2.1.) ABPMP BPM CBOK e a Viso de Modelagem de Processos
O objetivo da modelagem de processos criar uma representao de um

processo, descrito de maneira precisa, das atividades que esto sendo
executadas na organizao. No entanto, um modelo nem sempre ser
uma
representao
freqentemente
integral
focar
na
completa
representao
do
processo
real,
mas
das
principais
atividades.
Portanto, deve-se ter ateno em at que ponto um simples diagrama

ser suficiente para representar um determinado processo.
Modelos de processos tm muitas vantagens na gesto de operaes
empresariais, tais como a melhoria da comunicao atravs da criao de
uma representao visvel e o estabelecimento de uma perspectiva
comum e compartilhada, facilitando a compreenso do leitor. Na gesto
de processo de negcios, os modelos so os meios pelos quais as
organizaes gerenciam seus processos, analisando a sua performance e
definindo mudanas. Eles expressam o foco do negocio da organizao e
especificam os recursos que permitem a efetiva operao do negcio:
pessoas, informaes, equipamentos, automao, finanas, energia etc.
Alguns dos motivos mais comuns para a criao de modelos de processo
so os seguintes:
Documentar claramente um processo existente;
Ajudar nos treinamentos atravs das atribuies de cada ator
presentes nos processos;
Usar
como
obrigaes;
uma
avaliao
das
normas
cumprimento
das
Compreender o comportamento do processo sob a ao de

diferentes cargas ou sob alguma mudana antecipada;
Servir de base para anlise na identificao de oportunidades para
melhoria;
Suportar o design de um novo processo ou uma nova abordagem
para um processo j existente;
Fornecer uma base para a comunicao e discusso organizacional;
Descrever requisitos para uma nova operao da empresa.
2.2) Paul Harmon e a Viso de Modelagem de Processos
O objetivo da modelagem de processos simplificar, destacar, clarificar e

comunicar.
O autor no destaca uma notao especfica para a modelagem de um
processo, justificando que se deve escolher um determinado padro de
notao que deixe as idias mais claras possveis para o leitor,
ressaltando que qualquer notao de difcil compreenso e muito
complexa contraproducente.Ao mesmo tempo, importante permitir
que qualquer pessoa da organizao consiga compreender os diagramas
de processos de forma clara e, para tal, faz-se necessrio focar num
mesmo conjunto de convenes. Acredita-se que a essncia central dos
elementos que a notao BPMN disponibiliza hoje o que h de melhor.
Por outro lado, quando encontrada alguma situao que no
facilmente expressada pelo BPMN, s vezes as pessoas se sentem livres
para ampliar informalmente o BPMN para ter certeza de que um
determinado ponto de vista foi expresso da forma mais clara possvel.
2.3) ROSEMANN e PIDD e o Principio de Modelagem
Muitos autores tm discutido sobre a viso dos princpios de modelagem.

Neste mbito, alguns confirmam que os princpios de modelagem so
essenciais para a criao de modelos robustos.
H uma grande dificuldade na modelagem de processos de negcios e isto

se d pelo fato das pessoas terem percepes diferentes para o mesmo
problema.
Para
minimizar
essas
divergncias,
busca-se
modelar
processos simples, que no incluem a complexidade da realidade.

Abaixo segue a viso de dois autores sobre o principio de modelagem.
Viso de ROSEMANN
1. Aderncia: norteia quanto proximidade que se est da realidade

modelada. Tcnicas de levantamento e validao de modelos de
processos so aplicadas para aumentar a aderncia e compatibilizar
as diferentes percepes acerca de como o processo realmente .
2. Relevncia ou suficincia: todo objeto representado em um
modelo deve ter um propsito, ou seja, um modelo s deve conter
informaes relevantes. Por isso, a definio do que ou no
relevante deve ser cautelosa.
3. Custo/benefcio:
este
princpio
visa
analisar
quantidade
necessria para criar o Modelo versus Utilidade do modelo versus

Tempo de uso do modelo.
4. Clareza: este princpio um dos mais importantes, pois se
relaciona capacidade de ser entendido e usado pelos usurios.
5. Comparabilidade: para que os processos sejam comparveis
preciso
aplicar
os
mesmos
mtodos
todos,
corrigindo
uniformizando a nomenclatura e os nveis de detalhamento para

que fiquem homogneos.
6. Estruturao sistemtica: este princpio est ligado capacidade
de integrar modelos representando diversos aspectos da realidade
e, nesse sentido, capacidade desses modelos de se conectarem
metodologicamente.
Viso de PIDD
1. Modele simples, pense complicado;

2. Seja parcimonioso, comece pequeno e v adicionando;
3. Divida e conquiste, evite megamodelos;
4. Use metforas, analogias e similaridades;
5. No se apaixone por dados;
6. A construo do modelo deve ser esclarecedora.
Notaes de modelagem: BPMN
4.1 Apresentao
O Business Process Modeling Notation (BPMN) uma representao

grfica especificada para processos de negcio de workflow. Elaborado
pela Business Process Management Initiative (BMPI.org), teve a sua
primeira verso publicada em novembro de 2002. Desde 2005 esta
notao de modelagem atualizada pela Object Management Group
(OMG), , aps a fuso desta com a BPMI. Em seguida foi lanada a
verso 1.1 sobre a notao, mas, dada a necessidade de atualizao e
algumas pequenas alteraes, foi publicada a verso 1.2. Atualmente est
sendo produzida a verso 2.0, que vai apresentar grandes mudanas em
seu escopo original, objetivando uma maior coerncia para essa notao.
Aps a sua publicao, o BPMN emergiu como o principal padro de
modelagem utilizado pelos especialistas no tema. Alm disso, pesquisas
feitas revelam que as organizaes apresentam um interesse especial
sobre esse padro de modelagem. Utilizado para comunicar uma
variedade de informaes para uma ampla variedade de telespectadores,
o BPMN projetado para cobrir vrios tipos de modelagem, permitindo a
criao de processos de ponta ponta da cadeia. A sua estrutura de
elementos permite ao leitor a fcil distino entre as sees de um
diagrama BPMN.
O BPMN apia os conceitos de modelagem que so aplicveis aos
processos de negcio. Isto significa que outros tipos de modelagens feitas
por organizaes sem o foco em negcio fogem ao escopo de atuao
desta representao. Abaixo seguem alguns exemplos de modelos que
no esto no escopo de atuao do BPMN:
Estruturas organizacionais e recursos;
Modelos de funes de departamentos;
Modelos de dados e informaes;
Modelos de estratgia empresarial;
Modelos regras de negcios.
4.2 Viso geral de BPMN
Hoje existem trs modelos bsicos para a modelagem no padro BPMN:

1. Processos privados de negcios (interno);
2. Processos abstratos (pblico);
3. Processos colaborativos (global).
Abaixo os modelos bsicos para modelagem BPMN so detalhados.
Processos Privados de Negcios (interno)
Os processos privados de negcios referem-se a uma organizao
especfica e so do tipo de processos que tm sido chamados de workflow
ou processos BPM. Ao modelar esse tipo de processos, sero utilizadas
raias de executores ou suporte e nelas representado um determinado
fluxo de atividades. O fluxo de atividades est contido em apenas uma
nica raia, mas quando se trata de fluxo de informao, passa-se a
permitir a travessia entre raias, de forma a demonstrar as iteraes
existentes entre processos privados de negcio distintos.
Figura 2 Exemplo de Processos privados de negcio
Processos Abstratos (pblico)

Os processos abstratos representam a interao entre os processos
internos da organizao e um processo ou participante externo a essa
organizao. Somente as atividades que so utilizadas na comunicao
com o exterior do processo do negocio esto inclusos nesse tipo de
modelo bsico.Todos os outros processos internos no so mostrados nos
processos abstratos. Assim, os processos abstratos mostram para o
mundo exterior a seqncia de mensagens que so necessrias na
interao com outro processo ou participante externo. Alm disso, eles
podem ser representados dentro de uma raia de executores ou suporte e
modelados dentro de um nico diagrama BPMN para mostrar o fluxo de
mensagem com outras entidades. Caso o processo abstrato esteja dentro
de um processo privado de negocio eles podem ser representados em um
mesmo diagrama.
Figura 3 Exemplo de Processos Abstratos
Processos Colaborativos (global)

O processo de colaborao se refere interao entre duas ou mais
entidades de negocio. Essa interao definida como uma seqncia de
atividades que representa as trocas de mensagem entre os envolvidos.
Um nico processo de colaborao pode ser mapeado em vrias
linguagens, como ebXML, BPSS, RosettaNet. Esse modelo pode ser
realizado em um ou mais processos, indicando os locais onde h
comunicao entre eles. No caso de ser em um nico modelo, cada raia
de executor ou suporte representa cada um dos participantes. Assim

sendo, se estivermos tratando de um processo privado e que esteja sendo
modelado no mesmo diagrama BPMN, devem-se associar as atividades
que so comuns a ambos os processos.
Figura 4 Exemplo de Processos Colaborativos
Tipos de Diagramas de BPMN

Dentro e entre cada um desses modelos de processos de BPMN, muitos
outros tipos de diagramas podem estar sendo criados. A seguir esto os
tipos de processos de negcio que pode ser modelado com BPMN (aqueles
com asterisco no podem ser mapeados para uma linguagem executvel).
Processo privado de atividade de alto nvel (repartio nofuncional) *
Processo de negcio privado detalhado

o AS-IS ou processo de negcio antigo *
o TO-BE ou processos de negcios novos
Detalhamento dos processos de negcios privados com interaes

com um ou mais entidades externas (ou processos "caixa preta")
Duas ou mais interaes de processos de negcio privados

detalhados
Detalhamento do relacionamento de processos de negcios privados

com processos abstratos
Detalhamento do relacionamento de processo de negcios privados

com processos colaborativos
Dois ou mais processos abstratos *
Relacionamento de processos abstratos com processos

colaborativos*
Processo colaborativo apenas (por exemplo, ebXML BPSS ou

RosettaNet)*
Abaixo segue um modelo de processo com a notao BPMN:
Figura 5 Exemplo de Modelagem em BMPN
Principais objetos da notao BPMN:

Tabela 2 Principais objetos da notao BPMN (FONTE: Stephen A. White)
Elemento
Descrio
Notao
Um evento o que acontece durante a

execuo
do
processo.
Esses
eventos
afetam o fluxo do processo e geralmente tem
Evento
uma
causa
(gatilho)
ou
um
impacto
(resultado). Existem trs tipos de eventos,

baseados quando eles afetam o fluxo. So
eles: incio, intermedirio e finalstico.
A atividade um termo genrico que

representa
trabalho
que
empresa
executa. Os tipos de atividades que so
Atividade
parte
do
modelo
de
processos
so:
processos, sub-processos, e tarefas. Tarefas

e sub-processos tem a forma de retngulos
com as pontas arredondadas. Os processos
so modelados dentro de raias.
O Gateway usado para controlar as

divergncias e convergncias da seqncia
Gateway
do fluxo.
Desse
modo,
esse
elemento
determina a ramificao no processo, fuso,

e a juno de trilhos diferentes do fluxo.
Seqncia do fluxo
seqncia
do
fluxo
usada
para
demonstrar a ordem de como as atividades

sero executadas no fluxo do processo.
A mensagem do fluxo usada para mostrar

o fluxo de mensagens presentes entre dois
Mensagem do fluxo
participantes do processo que a envia e a

recebe. Em BPMN, duas raias distintas
representam
participantes
diferentes
do
processo.
Uma associao usada para associar
Associao
informaes aos objetos do fluxo. Textos e

diagramas podem ser associados a tais
objetos.
Uma raia representa um participante do

processo, podendo ser representado por
uma
Raias
raia
de
representao
conjunto
de
apresentar
piscina
atravs
grfica
que
atividades
relao
com
de
contm
que
outras
uma
um
podem
raias,
geralmente em um contexto de B2B.
A Lane uma subpartio pertencente a

uma determinada raia do fluxo e se estende
Lane
por todo o comprimento da raia, tanto

verticalmente quanto horizontalmente. Lanes
so usadas para organizar e categorizar
atividades.
Os objetos de dados so considerados

artefatos j que no apresentam nenhum
Objeto de dados
efeito direto sobre a seqncia ou sobre as

mensagens do fluxo, mas ele prove algumas
informaes de como as atividades so
executadas.
um grupo de atividades que pertence a

uma mesma categoria. Esse agrupamento
Grupo (caixa em volta de um
no afeta a seqncia do fluxo ou as suas

atividades. O nome da categoria aparece no
conjunto de objetos em uma
diagrama como o rtulo do grupo. Categorias
mesma categoria)
podem ser utilizadas para a documentao

ou anlise de efeitos. Grupos so formados
com o objetivo de destacar visualmente
categorias de objetos no fluxo
Anotaes
Anotaes em texto
em
texto
um
mecanismo
utilizado pelo modelador com o objetivo de

prover informaes adicionais ao leitor do
diagrama em BPMN.
4.3 Consideraes finais
O grande sucesso do BPMN est calcado em trs pilares. O primeiro o

fato de ser uma linguagem de fcil compreenso a todos os envolvidos
com processos. Assim, tanto usurio de negcios quanto profissionais de
TI conseguem facilmente ler um processo em BPMN. Assim, o BPMN se
torna uma linguagem comum entre a maioria dos departamentos da
empresa, aumentando a integrao entre as mesmas.
O segundo est no fato do BPMN apresentar uma serie de recursos que

torna possvel a modelagem de processos simples at os mais complexos.
Esses recursos so opcionais, mas, se utilizados, permitem a modelagem
em um nvel bastante refinado, agregando vrias informaes tcnicas e
permitindo o mapeamento automtico para padres de execuo de
processos, como o BPEL.
Por fim, o terceiro pilar do sucesso desta notao de modelagem est
calcado em uma slida fundamentao matemtica. Construdo baseado
no conceito do Pi-Calculus, uma derivao do Clculo de Processos para a
representao de processos dinmicos e mveis, o que permitiu uma
grande solidez em seu conceito e aceitao no mercado.
Outra questo relevante o fato do BPMN ter a capacidade de detalhar
diversos modelos em seqncia. No entanto, deve-se ter cuidado, pois,
quanto mais subprocessos combinados, como, por exemplo, trs ou mais
subprocessos trocando informaes entre si, mais se dificulta a leitura do
seu diagrama e, por conseqncia, a sua compreenso. Recomenda-se
que se tenha bastante cuidado a fim de facilitar a leitura do processo.
IDEF
As informaes abaixo esto fortemente baseadas no site www.idef.com e
o artigo Integration Definition For Function Modeling (IDEF), do National
Institute of Standards and Technology.
5.1 Apresentao
O IDEF (Integration DEFinition) um padro de modelagem para

softwares. Ele tem uma abrangncia de utilizao para a modelagem de
simulao, informaes, anlise orientao ao objeto e design e
aquisio de conhecimento. Teve a sua criao iniciada na dcada de 70,
e foi finalizado durante os anos 80. O IDEF surgiu a partir do padro de
modelagem ICAM (Integrated Computer-Aided Manufacturing), criado
pelas foras armadas norte americanas.
Apresenta uma estratgia abrangente que permite a representao
empresarial e organizacional de forma integrada e, por isso, tem se
transformado em um dos principais padres. Ele dividido em alguns
mtodos de modelagem, conforme a Figura 6.
Figura 6 Mtodos IDEF (FONTE: Mayer, 1995 Apud Paim, 2002)
Abaixo est descrio de alguns desses mtodos:

IDEF Modelagem funcional;
IDEF1 Modelagem de informaes;
IDEF2 Modelagem para simulao;
IDEF3 Modelagem para a descrio e captura de processos;
IDEF4 Modelagem orientada por objetos;
IDEF5 Modelagem para a descrio de ontologia;
IDEF6 Modelagem para a racionalizao de descries;
IDEF7 Modelagem para a auditoria de sistemas de informao;
IDEF8 Modelagem de projetos de sistemas com interao humana;
IDEF9 Modelagem para identificao de restries nos processos;
IDEF10 Modelagem de artefatos de informao;
IDEF12 Modelagem para projeto organizacional;
Conforme analisado acima, o IDEF apresenta algumas notaes voltadas

para a modelagem de processos. As descries abaixo sero focadas no
IDEF e IDEF3.
5.2 IDEF Modelagem funcional
Criado a partir de uma linguagem grfica bem estabelecida, o Structured

Analysis and Design Technique (SADT), o IDEF um mtodo concebido
para a modelagem de decises, aes e atividades de uma organizao
ou sistema. Essa notao foi encomendada pelas Foras Areas dos
Estados Unidos para exercer a funo de desenvolver um mtodo de
modelagem e de comunicao das funcionalidades de um sistema.
Efetivamente os modelos IDEF ajudam a organizar as anlises dos
consumidores. Esse padro de modelagem til para estabelecer o
escopo de anlise, especialmente em anlises funcionais. Como uma
ferramenta de comunicao, o IDEF auxilia o modelador a identificar
quais as funes so realizadas, o que necessrio para as realizaes de
algumas funes, o que um sistema atual faz de correto e o que o
sistema faz de errado. Assim, os modelos IDEF so freqentemente
criados como uma das primeiras tarefas do desenvolvimento de um
sistema.
O mtodo IDEF tem um conceito bsico que enderea cada necessidade
discutida anteriormente. O Conceito bsico do IDEF so os seguintes,
conforme abaixo.
Clula de Modelagem de Representao Grfica
A representao grfica da "caixa e seta" de um diagrama do IDEF
funciona como uma caixa e as suas interfaces ou de suas funes como
setas entrando ou saindo da caixa. Para expressar as funes, caixas
operam simultaneamente com outras caixas, como interfaces, atravs de
setas indicando quando e como as operaes so desencadeadas e
controladas. A base de sintaxe para o modelo IDEF mostrada na figura

abaixo.
Figura 7 Esquema do modelo IDEF
Objetivos e Aplicao
Os principais objetivos desse padro de modelagem so:
a. Prover recursos para uma completa e consistente modelagem de
funes (atividades, aes, processos, operaes) requeridas por
um sistema ou empresa, e as funes de relacionamento e dados
(informao ou objetos) que suportam a integrao entre estas
funes.
b. Prover uma tcnica de modelagem que seja independente dos
mtodos ou ferramentas do Computer-Aided Software Engineering
(CASE), mas que possa ser usado em conjunto com essas
ferramentas e mtodos;
c. Prover
tcnica
caractersticas:
de
modelagem
que
tenham
as
seguintes
a. Genrica (para anlise de sistemas com diferentes propsitos,

escopo e complexidade);
b. Precisa e rigorosa (para produzir corretamente modelos
utilizveis);
c. Concisa (para facilitar a compreenso, comunicao, consenso
e validao)
d. Conceitual (para a representao dos requerimentos das
funes fsicas ou de implementaes organizacionais);
e. Flexvel (para suportar as vrias fases do ciclo de vida de um
projeto).
A utilizao desse padro de modelagem fortemente recomendada em
projetos que:
a. Requerem tcnicas de modelagem para a anlise, desenvolvimento,
re-engenharia, integrao ou aquisio de informaes de sistemas;
b. Incorporam sistemas ou tcnicas de modelagem empresarial para
anlises de processos de negcio ou metodologia de software de
engenharia.
As especificaes desse padro de modelagem so aplicveis quando
sistemas ou tcnicas de modelagem empresarial so aplicados aos
seguintes itens:
a. Projetos que necessitem o IDEF como tcnica de modelagem;
b. Desenvolvimento de ferramentas para softwares automatizados
para a implementao da tcnica de modelagem IDEF.
As especificaes desse padro no so aplicveis aos projetos que
necessitam de tcnicas de modelagem funcionais.
Pontos fortes e fracos do IDEF

A principal fora do IDEF baseia-se no fato de ter sido comprovada a sua
eficincia no detalhamento das atividades de um sistema. As atividades
podem ser descritas por suas entradas, sadas, controles e mecanismos.
Alm disso, as descries das atividades de um sistema podem ser
facilmente refinadas em maior detalhe at o quanto for necessria para a
tomada de deciso. Com isso, um dos problemas observados nessa
notao o fato de ser, s vezes, to conciso que apenas o
desenvolvedor ou algum que participou da modelagem tenha a completa
compreenso do modelo.
A natureza hierrquica do IDEF favorece a construo de modelos (ASIS) que tenham uma representao e interpretao top-down, mas que se
baseiam na anlise de processo bottom-up. De forma geral, o modelador
deve
agrupar
atividades
intimamente
relacionadas
ou
at
com
funcionalidades similares. Atravs desse processo de agrupamento, a

hierarquia surge. Caso se esteja tratando de uma organizao que est
comeando a construir a sua hierarquia, geralmente chamada de
modelagem TO-BE, a construo top-down mais indicada. Assim,
constri-se a idia mais macro e depois se passa aos nveis mais
detalhados. Quando se fala de uma organizao que j apresenta uma
arquitetura consolidada, geralmente chamada de modelagem AS-IS,
observa-se que as atividades podem ser descritas para, em seguida,
serem combinadas em um nvel mais agregado. Este processo continua
at que se chegue ao nvel mais desejvel de agregao.
Um problema com IDEF a tendncia de esses modelos serem
interpretados como uma representao de atividades em seqncia.
Apesar do IDEF no ser utilizado para a modelagem de atividades em
seqncia, fcil faz-la. As atividades podem ser colocadas em uma
seqncia da esquerda para a direita dentro de uma ordem e conectada
com os fluxos. natural ordenar as atividades da esquerda para a direita,
pois o output de uma determinada atividade tambm utilizado como o

input para outra, deixando as conexes entre as atividades um conceito
bem claro. Assim, mesmo sem inteno, o raciocnio de seqenciamento
de atividade pode ser embutido no modelo IDEF. Nos casos em que o
seqenciamento de atividades no includo no modelo, os leitores
tendem a acrescentar esse tipo de interpretao. Esta situao anmala
poderia ser considerada um ponto fraco da IDEF. No entanto, para
corrigi-la iria resultar na corrupo dos princpios bsicos sobre os quais
se assenta IDEF e, conseqentemente, perderia a eficcia comprovada
do mtodo.
Abaixo segue uma estrutura do diagrama do IDEF:
Figura 8 Estrutura do diagrama do IDEF (FONTE: Integration Definition For Function Modeling (IDEF))
5.3 IDEF3 Modelagem para a descrio e captura de processos
O IDEF3, Mtodo de Captura de Descrio de Processo, prov um

mecanismo para o armazenamento e documentao de processos. O
IDEF3 captura a relao dos precedentes e das casualidades entre as
situaes e eventos em uma forma natural ao domnio dos especialistas,
provendo um mtodo estruturado para expressar o conhecimento de um
sistema, processo, ou trabalhos de uma organizao. O IDEF3 pemite:
Registrar
dados
crus
resultantes
de
fatos
encontrados
em
entrevistas em atividades de anlise de sistemas.
Determinar o impacto nos recursos de informaes de uma

organizao baseados nos principais cenrios de operao de uma
empresa.
Documentar os procedimentos para decises que afetam o estado e

o ciclo de vida de um dado crtico e compartilhado, particularmente
manufatura, engenharia, e definio da manuteno de dados de
produtos.
Gerenciar a configurao de dados e mudana das definies de

polticas de controle.
Produzir a concepo de sistema e o design de anlise de trade-offs.
Prover a gerao de modelos de simulao.
O IDEF3 tem a capacidade de compreender os aspectos comportamentais

de um sistema existente ou sugerido e captura todas as informaes
temporais, incluindo processos empresariais. Os resultados das descries
do IDEF3 provem a estruturao da base do conhecimento para
construir modelos analticos e de design. Infelizmente, linguagens de
simulao (por exemplo: SIMAN, SLAM, GPSS, WITNESS) constroem
modelos
matemticos,
enquanto
IDEF3
constri
descries
estruturadas. Essas descries capturam as informaes do que um

sistema de fato realiza ou vai realizar e ainda prov organizao uma
srie de vises dos diferentes usurios do sistema.
Existem dois modos para descrio do IDEF3:o fluxo de processo e a

transio da rede do estado do objeto. A descrio do fluxo de processo
captura o conhecimento de como as coisas funcionam em uma
organizao, por exemplo, a descrio de que acontece com uma parte, e
como o fluxo dela na seqncia do processo de manufatura. A segunda
dimenso
permite
determinado
processo.
transio
Ambas
completa
as
de
dimenses
um
objeto
contm
para
unidade
um
de
informaes que compem a descrio do sistema. As entidades dos

modelos, como eles so chamados, formam a base das unidades de
descrio do IDEF3. Os diagramas resultantes e textos compreendem o
que denominado descrio , em oposio ao foco do que produzido
pelos outros modelos IDEF, cujos produtos so um modelo.
No IDEF3, o processo de descrio do fluxo de processos capta a
descrio de um processo e a rede de relaes que existe entre os
processos dentro do contexto de um cenrio em que eles esto contidos.
O intuito desta descrio mostrar como as coisas funcionam em uma
determinada organizao quando vistas como sendo parte de um
problema
particular,
resolvendo
ou
demonstrando
uma
situao
recorrente. O desenvolvimento de um processo deste tipo consiste em

expressar fatos, coletados a partir do domnio de especialistas, em termos
descritivos da construo de cinco blocos bsicos.
O exemplo a seguir ilustra como os blocos de construo do mtodo
IDEF3 podem descrever o cenrio tipicamente encontrado em indstria de
manufatura. A situao a ser descrita est baseada em um processo de
pintura e de inspeo, relacionados com a aplicao de uma tinta em um
mdulo que se tornar um elemento de um pesado equipamento de
construo. A figura abaixo a representao grfica do exemplo, que
est baseado na entrevista de um supervisor de pintura de uma fbrica.
Abaixo segue exemplo de um diagrama do IDEF3:
Figura 9 Exemplo de diagrama IDEF3
As caixas maiores so chamadas de Unit Of Behavior (UOB). As linhas

so as conexes entre as UOBs e isso que define o fluxo lgico do
diagrama. As pequenas caixas no canto inferior esquerdo definem os
mecanismos que introduzem o fluxo lgico do diagrama.
De forma geral, a proposta dos modelos e descries ajudar a tomar

decises. Cada tipo de modelo ou descrio foca em um relativo conjunto
estreito de relacionamentos e caractersticas de sistemas, compreendendo
um ponto de vista particular ou uma perspectiva global do sistema.
Modelos de anlises, por exemplo, so utilizados para determinar
requerimentos existentes ou antecipar a sua concepo. Design de
modelos servem para facilitar a otimizao de recursos desejveis de
design para um conjunto de requerimentos de sistemas. Modelos de
simulao provem um perspectiva de vrias medidas e estatsticas
associadas ao desempenho do sistema que podem ser geradas para
examinar
uma
caracterstica
especifica
de
desempenho
sobre
um
conjunto restrito de condies operacionais. Cada modelo e as decises

geradas atravs da sua construo tm uma relativa ponderao em
direo ao nvel global das decises do sistema, criando uma competio
de decises dentro e entre tipos de modelos que eventualmente
emergem, necessitando anlises de trade-offs.
Como
resultado,
os
modelos
as
descries
nunca
pretendem
representar todas as possibilidades ou comportamentos de um sistema.

Estes focam em um conjunto restrito de caractersticas de sistemas e
acabam ignorando os aspectos que no so pertinentes na tomada de
deciso.
A famlia de mtodos do IDEF busca um balanceamento favorvel entre
mtodos especiais de aplicaes efetivas limitadas a tipos de problemas
especficos,
super
modelos
que incluem tudo
que
possa
ser
necessrio. Este balanceamento mantido com a famlia de mtodos do

IDEF provendo mecanismos explcitos para integrao de resultados de
aplicaes de mtodos individuais.
Notao de modelagem: ARIS

AS informaes abaixo esto fortemente baseadas em Paim (2002) e
Chaloub (2004).
6.1 Apresentao
A ferramenta ARIS Toolset utilizada para suportar a metodologia ARIS

de Modelagem de Processos de Negcios e est fundamentada na
utilizao de diversos modelos e objetos, atravs dos quais os processos
de negocio de uma data organizao podem ser representados e
analisados.
Essa metodologia foi desenvolvida objetivando a integrao dos processos
de
negcios
de
uma
organizao.
primeiro
passo
para
desenvolvimento desta arquitetura foi a criao de um modelo que

contivesse as principais caractersticas para se descrever um processo de
negcio. O resultado foi um modelo complexo, sendo necessria, assim,
a diviso em partes para interpretar o todo. Desta forma, criou-se uma
diviso em vistas. Estas vistas so inter-relacionadas de forma que os
modelos possam ser analisados holisticamente e sem redundncia.
Os modelos podem ser agrupados em cinco vistas: Organizao, Funo,
Dados, Sada e Controle.
Figura 10 Aris House (FONTE: Organizao dos Modelos, Scheer, 1998, p. 1)
Nesta metodologia os principais modelos so: Cadeia de Valor Agregado VAC; Diagrama de Objetivos - DO; rvore de Funes - FT; Organograma
- ORG; Diagrama de Entidades e Relacionamento - ERM; Estrutura de
Conhecimento - KSD; Diagrama de Funo - FAD; e Cadeia de Processos
Orientada por Eventos - EPC, sendo este bastante importante para a viso
de processos. Cada um destes modelos tem objetivos prprios, mas so
utilizados de forma inter-relacionada, na lgica da metodologia.
6.2 Diagrama de Objetivos
Em muitos casos, os projetos de modelagem esto ligados a discusses

estratgicas que orientam processos. Baseado nisso, antes de realizar
qualquer atividade de modelagem de processos, como analis-los e
redesenh-los, necessrio conhecer os objetivos estratgicos da
empresa.
Assim, esse diagrama permite que os objetivos organizacionais sejam

definidos e hierarquizados. Alm disso, podem ser identificados no modelo
os fatores crticos para que sejam alcanados esses objetivos, e tambm
as atividades ou processos relacionados a esse objetivo.
Abaixo est a representao dos principais objetos utilizados nesse
modelo.
Figura 11 Objetos de modelagem do Diagrama de Objetivos (FONTE: Chalhoub)
De acordo com a situao em que o objeto est envolvido, ele pode

assumir diferentes significados. Nesse diagrama, o objeto funo
utilizado
para
representar
atividades
ou
processos
que
estejam
relacionados aos objetivos mapeados.

Alm disso, a ligao presente entre os objetos desse diagrama tambm
pode ter significados diferentes, de acordo com a sua disposio. Assim
sendo, deve-se ter ateno no apenas nos objetos que compe o
diagrama, mas tambm nas ligaes existentes entre eles.
A seguir seguem alguns exemplos de diagramas de objetos modelados no
ARIS.
Figura 12 Exemplo de hierarquizao no diagrama de objetivos (FONTE: Chalhoub)
Figura 13 Exemplo de relacionamento entre atividades, objetivos e fatores crticos (FONTE: Chalhoub)
6.3 Organograma - ORG
Este modelo tem como funo representar a estrutura organizacional.

Apresenta como propriedade a visualizao das relaes existentes entre
as diversas reas de uma organizao, alm das suas estruturas internas.
Os objetos comuns utilizados nesse modelo e um exemplo seguem
abaixo.
Figura 14 Objetos de modelagem do Organograma (FONTE: Chalhoub)
Figura 15 Exemplo de Objetos de organograma (FONTE: Chalhoub)
6.4 Cadeia de Valor VAC
Este
modelo
facilita
macro
viso
dos
processos
mapeados
da
organizao, mostrando como eles se conectam, alm de representar o

fluxo de materiais e informaes na empresa. De uma forma geral, esse
modelo apresenta como agregado valor durante a realizao das
atividades e processos na organizao.
No VAC, os principais objetos so: funo, unidade organizacional e
cluster. Os objetos de unidade organizacional e de funo j foram
apresentados anteriormente, mas o ltimo ainda apresenta uma pequena
diferena daquele apresentado, sendo demonstrado no exemplo abaixo.
J o cluster entendido por um conjunto de dados e informaes. Abaixo
segue a ilustrao dos objetos utilizados no VAC.
Figura 16 Objetos de modelagem de VAC (FONTE: Chalhoub)
O objetivo do VAC representar o fluxo de processos, sendo desenhado

como estes processos organizacionais esto inter-relacionados atravs da
ligao existente entre eles. As ligaes tracejadas entre os objetos
representam uma lgica temporal entre eles, um predecessor do outro,
enquanto
linha
continua
representa
hierarquizao,
relao
superioridade.
A figura abaixo um exemplo de representao do VAC no ARIS.
de
Figura 17 Exemplo de VAC Cadeia de Suprimentos de Petrleo (FONTE: Chalhoub)
Uma das vantagens do VAC permitir a navegao logicamente

estruturada
entre
os
processos
mais
detalhados
da
organizao,
denominados EPC (Event Driven Process Chain). A interligao entre o

VAC e o EPC, que ser mais bem detalhado no prximo item, garante a
consistncia de interligao dos processos entre as diversas reas
organizacionais.
Portanto, o VAC disponibiliza uma viso agregada dos processos que
permeiam toda a estrutura organizacional, permitindo que os EPCs sejam
acessados a partir de um macro processo.
6.5 Cadeia de Processos Orientada por Eventos EPC
Este modelo representa a integrao das diversas vises do ARIS: funo,

dados, organizao e sadas na vista de controle. Sua principal finalidade
a modelagem detalhada dos processos da organizao. So encadeadas
seqencialmente as atividades realizadas em um dado processo, bem
como os eventos que as motivam, associando-se a cada atividade os
recursos por elas consumidos e/ou gerados (relatrios, informaes,
sistemas,
meios
indivduos
e/ou
de
comunicao,
unidades
conhecimentos
organizacionais
etc.),
alm
dos
responsveis
pela
sua
realizao, utilizando operadores lgicos para descrever a lgica de

encadeamento das atividades.
Abaixo seguem os objetos do EPC utilizados com maior freqncia.
Figura 18 Objetos de modelagem de EPC (FONTE: Chalhoub)
Abaixo um exemplo de EPC.
Figura 19 Exemplo de EPC (FONTE: Chalhoub)
Atravs desse modelo possvel visualizar todos os insumos que

participam do processo, sejam eles clientes, fornecedores ou atores, bem
como os produtos por eles gerados.
6.6 Diagrama de Funo FAD
Esse modelo utilizado quando se deseja mapear os insumos necessrios

para a execuo de uma atividade e os resultados por ela gerados.
Uma das diretrizes para a modelagem nesse diagrama evitar carreg-lo
com muita informao, j que tornar o modelo de difcil leitura e
compreenso. Opta-se, nesse caso, por desmembrar os modelos em
outros menores, reduzindo a sua complexidade.
Os objetos utilizados no FAD so os mesmos do EPC e, por isto, no
necessita de uma descrio mais detalhada. Abaixo segue uma figura
exemplificando o uso do FAD.
Figura 20 Exemplo de FAD (FONTE: Chalhoub)
O desmembramento de um processo em FADs no um recurso

especifico para esse diagrama, sendo utilizado tambm na modelagem de
EPCs, por exemplo.
A figura abaixo exemplifica o link entre EPCs, VACs e FADs na modelagem
de processos.
Figura 21 VAC desdobrado em EPC e FAD (FONTE: Chalhoub)
6.7Consideraes finais
Notao de modelagem: UML 2.0

As informaes abaixo esto fortemente baseadas em UML 2 for
Dummies, de Michael Jesse.
7.1 Apresentao
A primeira informao que devemos saber porque o UML existe. O UML

(Unified Modeling Language) um padro de modelagem que permite a
integrao de um conjunto de diagramas, que foi desenvolvido para
auxiliar os desenvolvedores de softwares e sistemas a realizar algumas
tarefas, tais como especificao, documentao, simulao e teste e
visualizao.
O UML foi originalmente desenvolvido com a inteno de promover a
comunicao e produtividade para os desenvolvedores de sistemas
orientados a objetos. Entretanto, o poder do UML permitiu a sua utilizao
em qualquer tipo de sistema e de desenvolvimento de software. Assim,
esse padro de modelagem tambm tem sido utilizado na modelagem de
negcios.
Alm disso, o UML tem a propriedade de ser de fcil compreenso,
permitindo ao modelador focalizar no que realmente importante,
evitando que a distrao com detalhes de menor importncia e que
podem ser suprimidos em outro momento. Aps ter construdo um
modelo, essa notao permite que se faa alguns testes para verificar a
qualidade do mesmo, sem que seja necessrio o desenvolvimento do
sistema propriamente dito, ou seja, sem aumento de custos.
A modelagem UML tambm suporta a viso de um sistema sob mltiplas
vistas. Assim como se pode ter um mapa poltico, um mapa de relevo ou
um roteiro, possvel ter um mesmo mapa que apresente diagramas com
distintas finalidades e com diferentes tipos de diagramas, enfatizando
diferentes vises do sistema que esteja modelando, de acordo com o tipo

de diagrama UML a ser utilizado.
Hoje existem diversos diagramas em UML. Oficialmente existem, no
mnimo, 13 diagramas e alguns outros semi-oficiais. Dado isso, algumas
confuses podem surgir, j que o UML permite que o modelador troque
alguns elementos entre modelos.
7.2 Viso geral de UML
Uma das propriedades do UML, como j foi mencionada, o fato de

apresentar diversos diagramas, entretanto, no necessrio saber todos.
A Figura 22 um bom esquema que exemplifica os diagramas em UML.
Figura 22 Esquema de diagrama em UML (FONTE: Wikipedia)
A figura est baseada em setas que apontam para um diagrama mais

geral, em um nvel maior de abstrao. Quanto mais abaixo da figura,
mais especifico o diagrama. As setas tracejadas indicam uma
interdependncia entre alguns diagramas no que tange a reutilizao das
caractersticas de outros diagramas.
Embora no parea to claro, h diferentes modos de organizar os

diagramas em UML e, assim, ajudar na compreenso de qual a melhor
maneira de utiliz-los.
Ainda segundo a Figura 22, ela utiliza a tcnica de organizao baseada
em generalizaes (movendo para baixo atravs de nveis de abstrao) e
especializaes (movendo para baixo atravs de uma mesma hierarquia
na direo de um detalhe mais concreto).
Os diagramas em UML ainda podem ser divididos em trs categorias:
Diagramas de estrutura: utiliza-se esse tipo de diagrama para
representar os blocos de construo de recursos de sistemas que
no mudam com o tempo. Este diagrama responde a seguinte
pergunta: o que est l?
Diagramas comportamentais: utiliza-se esse tipo de diagrama para
mostrar como o sistema responde a alteraes ou como evolui ao
longo do tempo.
Diagramas de interao: utilizado para descrever as trocas de
mensagens dentro de uma colaborao (um grupo de objetos
colaborando entre si) para atingir uma determinada meta. Esses
diagramas,
na
realidade,
so
um
tipo
de
diagramas
comportamentais.
Tabela 3 Categorias e diagramas UML
Categoria
Tipo de diagrama
Descrio
Utilizado para mostrar as
entidades do mundo real,
Diagramas de estrutura
Diagrama de classe
elementos de analise e
concepo, classes de
implementao e seus
relacionamentos.
Utilizado para mostrar um

exemplo especifico ou
ilustrao de objetos e suas
Diagrama de objetos
ligaes. Pode ser utilizado

para indicar condies para
eventos, como um teste ou
operao de chamada.
Utilizado para mostrar
Diagrama de estrutura
como alguma coisa feita.
composta
Especialmente utilizado
para estruturas complexas.
Utilizado para mostrar o
tempo de execuo de um
sistema, plataforma de
Diagrama de implantao
hardware, softwares e seus

ambientes (como sistemas
operacionais e mquinas
virtuais)
Utilizado para mostrar a
Diagrama de componentes
organizao e seus
relacionamentos no que
tange seus sistemas
Utilizado para organizar os
Diagrama de pacotes
elementos de modelos e
mostrar a dependncia
entre eles
Utilizado para demonstrar o
Diagrama de
comportamento
Diagrama de atividades
fluxo de dados e/ ou o
controle de trabalho de
comportamento
Diagrama de
Diagrama de casos de uso
Utilizado para mostrar os
comportamento
servios que os atores

podem solicitar de um
sistema
Utilizado para mostrar o
Diagrama de
comportamento
Diagrama de mquina /
ciclo de vida de um
protocolo do diagrama de
determinado objeto, ou a
mquina
seqncia de objetos, ou a
sua interface de suporte.
Utilizado para demonstrar
vrios cenrios de
interaes (seqncia de
Diagrama de interao
Diagrama overview
comportamento) para um
conjunto de elementos
trabalhando em conjunto
para realizar uma meta
(colaborao)
Utilizado em concentrar nas
Diagrama de interao
Diagrama de seqncia
trocas de mensagens entre

um grupo de objetos e a
ordem de mensagens
Utilizado em concentrar nas
Diagrama de interao
Diagrama de comunicao
mensagens entre grupo de

objetos e as relaes entre
objetos
Utilizado para mostrar as
Diagrama de interao
Diagrama de tempo
mudanas em tempo real

ou sistemas de trabalho.
Pelo fato do UML ser bastante dinmico, existem outras maneiras de

categorizar os seus diagramas. Abaixo seguem as trs categorias:
Diagramas estticos: Semelhante dos diagramas estruturais,

estes diagramas mostram a esttica do sistema.
Diagramas
dinmicos:
Esses
diagramas
mostram
como
um
determinado sistema evolui ao longo do tempo. Esta categoria

abrange os diagramas de mquina e os diagramas de tempo.
Diagramas
funcionais:
Estes
mostram
os
detalhes
do
comportamento e algoritmos de como um determinado sistema se

comporta. Esta categoria abrange os diagramas de casos de uso,
interao e atividades.
7.3 Diagrama de Classes e Diagrama de objetos
O UML tem dois principais diagramas estticos: diagrama de classes e

diagramas de objetos. O diagrama de classes mostra as classes e as
associaes, agregaes e generalizaes. J o diagrama de objetos puro
mostra apenas os casos de classes e seus links com outras instancias.
Obviamente, podem ser mostrados classes e objetos no mesmo esquema,
mas isso raramente feito. Esses diferentes diagramas so utilizados com
fins especficos.
Quando se usa uma ferramenta de modelagem UML, deve-se ter bastante
ateno sobre os diferentes tipos de diagramas que ele suporta. Caso no
se tenha ateno a esse detalhe e no se tenha suporte para o diagrama
de objetos, ento a ferramenta de modelagem provavelmente deve
permitir que se coloque objetos no diagrama de classes.
A maior parte do tempo se utiliza o diagrama de classes, que fornecem a
mais ampla forma de mostrar aquilo que estamos modelando. Eles
tambm so os mais teis diagramas que se pode produzir porque o
cdigo gerado pela ferramenta UML baseado no diagrama de classes.
Os diagramas de objetos puros mostram simplesmente os casos e links de
objetos e as conexes entre eles. No caso de modelos muito complexos,
geralmente aparecem muitos casos e links em um nico diagrama. Mas, o
diagrama de classes seria muito simples. A figura abaixo exemplifica isto.
Figura 23 Diagrama de classes
Uma instncia da classe Supplier chamado ace1 faz link com duas
instncias da classe Invoice, A1 e A2. Ambas as instncias A1 e A2 so
contas que foram enviadas no passado, porque eles desempenham o
papel de pastBill. Estes dois Invoices foram pagos a partir de uma
instncia da classe SupplierAccount chamada aceAcc. Outra instncia
da classe Supplier, generalAirF, est ligada a um conjunto diferente de
invoices. A partir do diagrama visto, percebe-se que a instncia b4 da
classe invoice desempenha o papel do currentBill.
A figura acima ilustra dois casos diferentes de Suppliers e seus Invoices.
Em um caso o Supplier ace1 no tem uma currentBill. No outro caso,
generalAirF tem um current Bill.
Os diagramas de objetos so bons para mostrar um exemplo simples do
que se entende por um diagrama de classe. Por vezes, existem um ou
dois diagramas de classes para um projeto de software: eles so bons
para mostrar aos gerentes o que est acontecendo.
Ainda pode-se construir um diagrama de objetos/classes hbrido. Alguns
acham isso mais til quando se quer mostrar as classes e tambm
mostrar um exemplo ou dois casos de uso de algumas dessas classes.

Tabela 4 Tipos de Diagrama UML (FONTE: ELO Group)
Tipo de Diagrama
Descrio
Apresenta classes, associaes,
agregaes e generalizaes
Diagrama de classes
Organizar as classes de gerao de
cdigos em ferramentas UML
Mostra um exemplo especifico de gesto
Considera quais instncias se tem em
execuo (tambm utilizado no diagrama
de comunicao)
Diagrama de objetos
Descreve o comportamento antes e depois
de executado
Mostrar a configurao para a rodada de
teste
Diagrama de objetos/classes hbrido
Mostra exemplos de uma classe especifica

que so de difcil compreenso.
7.4 Diagrama de casos de uso
Os diagramas UML aproveitam a potncia da teoria de orientao por

objeto e das tcnicas de anlise e desenho, enquanto outros centralizam
no detalhamento de projeto e construo. Em ambos os casos, estes
diagramas
ajudam
realizar
uma
tarefa
ou
se
comunicar
com
funcionrios na organizao.
No entanto, o desenvolvimento prtico no apenas uma atividade
interna, sobretudo no atual clima de competio e de presso para
diminuir os oramentos. Se o objetivo permanecer no negcio, preciso
captar e entender as exigncias de seus clientes e suas necessidades, e
fazer um produto ou sistema que eles querem. Casos de uso e diagramas
de casos de uso so as funcionalidades do UML que apiam o

recolhimento e a anlise centrados nos requisitos dos usurios iniciado
nos objetivos e metas de seus clientes.
Casos de uso podem manter-se focados em seus usurios e objetivos
prticos sobre sistemas de produo que entregam valor aos seus
clientes, sejam eles clientes internos ou externos.
O Caso de uso tem um fim especfico em que o usurio pode realmente
utilizar o sistema. O Caso de uso atinge seu grande poder principalmente
por simplificar e organizar: quando se identifica e organiza o uso de
casos, possvel pintar uma imagem clara do que o sistema tem de fazer.
Essa imagem clara pode ser mostrada aos clientes, usurios, gestores
e demais interessados, que podem ajudar a compreender os defeitos e
acertos do sistema, favorecendo o processo de desenvolvimento.
Identificando o pblico
Para se obter uma imagem fiel do propsito que o sistema quer atingir,
necessrio identificar para quem o sistema (seu cliente) e quem utiliza o
sistema (os usurios).
Lembrando que os usurios e os clientes geralmente no so o mesmo
grupo de pessoas. Mesmo quando eles so as mesmas pessoas, esta
distino benfica para pensar a diferena de papis entre os usurios e
os clientes
Clientes: So pessoas ou organizaes que, em ltima instncia,

pertencem a sua equipe. Eles devem ser satisfeitos para que se
possa receber um pagamento. Seu time pode ter uma relao
contratual com eles (clientes externos), ou podem ser uma parte da
sua prpria estrutura de gesto (clientes internos). Quando estamos
desenvolvendo uma organizao, considere a organizao como
seus pais o seu cliente.
Os clientes dos seus clientes: Quando se fala sobre clientes (por

oposio aos seus clientes), geralmente se refere aos clientes do
seu cliente. Estas so as pessoas ou organizaes que compram
coisas a partir do seu cliente. Se o seu sistema no torn-los
felizes, o seu cliente est insatisfeito.
Usurios: Ao se referir aos usurios de um sistema, eles podem ser

os clientes do seu cliente, ou eles podem ser os trabalhadores da
organizao de seu cliente que se relaciona de alguma forma com o
sistema. Muitos sistemas tm usurios de todos os tipos: os seus
clientes, clientes dos seus clientes, e as pessoas que trabalham
desenvolvendo o sistema. Usurios chegam a se sentir mais
prximo dos sistemas e acabam obtendo impresses mais fortes. As
tarefas dos usurios so especificar o que o sistema deve
automatizar, as necessidades dos usurios so o que o sistema tem
de realizar.
Assim sendo, os atores de um sistema, considerando que os atores no

so uma pessoa especifica, mas o papel que uma determinada pessoa
exerce e que no devemos usar nomes individuais. Dentro do UML a
notao de um ator tradicionalmente uma figura basto ou pode
tambm ser utilizada uma caixa com o rtulo escrito Actor, conforme
pode ser visto na figura abaixo:
Figura 24 Exemplo da representao de atores em UML
Recomenda-se que seja utilizada a figura com a forma humana para

todos os atores humanos e a classe de caixa para atores no-humanos
(outros
sistemas,
bases
de
dados
dispositivos).
Esta
pequena
conveno visual ir ajud-lo a distingui-las rapidamente.
Pode-se empregar os diagramas em UML para mostrar informaes

diferentes, em tempos diferentes e com finalidades diferentes. Existem
diversos frameworks, como Zachman ou DODAF (Department of Defenses
Architecture Framework), que auxiliam os desenvolvedores de sistemas a
organizar e comunicar diferentes aspectos de seus sistemas. Um simples
framework para organizar as idias pode ser bastante til atravs das
respostas de simples questes sobre os sistemas que se deseja modelar:
1. Quem utiliza o sistema?
Mostre os atores (aqueles que vo
utilizar o sistema) nos diagramas de casos de uso (mostrando os

efeitos do sistema).
2. Do que o sistema feito? Desenhe o diagrama de classes para
mostrar a estrutura lgica e o diagrama de componentes para
mostrar a estrutura fsica do sistema.
3. Onde esto localizados os componentes do sistema? Indique
os seus planos sobre para onde seu sistema vai estar e evoluir no
diagrama de implantao.
4. Quando que acontecem eventos importantes no sistema?
Mostre o que provoca a reao dos objetos e o trabalho atravs dos
diagramas de estado e interao.
5. Porque que este sistema est fazendo as coisas que ele
faz? Identifique os objetivos dos usurios do sistema e capture-os
em casos reais. O UML foi desenvolvido justamente para esse fim.
6. Como esse sistema vai trabalha? Mostre as partes do diagrama

de estrutura e utiliza o diagrama de comunicao para mostrar as
interaes em um nvel suficiente para detalhar a concepo e
implementao.
Referencias
Instituies e Conferncias
www.idef.com
Livros e Artigos
Bussiness Process Change, Paul Harmon
UML 2 for Dummies, Michael Jesse
Afonso, Fernanda Chalhoub, Avaliao do Supply-Chain Operations Reference-Model

(SCOR) como um Modelo de Referncia de Processos voltado para o Gerenciamento de

Cadeias de Suprimentos: Aplicao em um Estudo de Caso no Setor de leo & Gas [Rio
de Janeiro] 2004.
Rashid M. Khan, What Standards Really Matter For BPM
ABPMP BPM CBOK
Stephen A. White, Introduction to BPMN
Rafael Paim Cunha Santos, Engenharia de Processos: anlise do referencial tericoconceitual, instrumentos, aplicaes e casos [Rio de Janeiro] 2002
PIDD, Just Modeling Through: A Rough Guide to Modeling
BPMN 1-1 Specification

Wikibpm Modelagem de Processos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Wikibpm Modelagem de Processos

Enviado por

Direitos autorais:

Formatos disponíveis

BPM Beyond Process Modelling

BPM Beyond Process Modelling

A partir dos anos 90 as empresas passaram a estruturar-se atravs da

comearam a prestar servios em Business Process Management e

conseqncia disso, o mercado passou a apresentar uma srie de

conhecimentos que pode ser partilhada pelos players no mercado.

BPM Beyond Process Modelling

Dado esse cenrio, comearam a surgir alguns grupos na tentativa de

Abaixo seguem algumas definies que sero utilizadas no decorrer desse

Modelo de processo um conjunto de atividades

Conjunto de sinais com que se faz essa

Desenho com a representao

BPMN, UML, IDEF

A figura a seguir exemplifica as definies apresentadas anteriormente:

BPM Beyond Process Modelling

Figura 1 Princpio da modelagem de processo (FONTE: ELO Group)

1.3.Motivaes e Benefcios Esperados

Segundo Vernadat apud Chaulhoub (2004), a modelagem de processos

BPM Beyond Process Modelling

Tomar melhores decises em relao organizao e s operaes

Segundo Rashid M. Khan, em seu artigo What Standards Really Matter

necessidades dos clientes;

se comparado a linguagens que no apresentam esse

BPM Beyond Process Modelling

Reviso Terica sobre Modelagem de Processos

2.1.) ABPMP BPM CBOK e a Viso de Modelagem de Processos

O objetivo da modelagem de processos criar uma representao de um

Portanto, deve-se ter ateno em at que ponto um simples diagrama

BPM Beyond Process Modelling

Compreender o comportamento do processo sob a ao de

2.2) Paul Harmon e a Viso de Modelagem de Processos

O objetivo da modelagem de processos simplificar, destacar, clarificar e

2.3) ROSEMANN e PIDD e o Principio de Modelagem

Muitos autores tm discutido sobre a viso dos princpios de modelagem.

BPM Beyond Process Modelling

H uma grande dificuldade na modelagem de processos de negcios e isto

processos simples, que no incluem a complexidade da realidade.

1. Aderncia: norteia quanto proximidade que se est da realidade

necessria para criar o Modelo versus Utilidade do modelo versus

uniformizando a nomenclatura e os nveis de detalhamento para

BPM Beyond Process Modelling

1. Modele simples, pense complicado;

BPM Beyond Process Modelling

Notaes de modelagem: BPMN

O Business Process Modeling Notation (BPMN) uma representao

BPM Beyond Process Modelling

Estruturas organizacionais e recursos;

Modelos de funes de departamentos;

Modelos de dados e informaes;

Modelos de estratgia empresarial;

Modelos regras de negcios.

4.2 Viso geral de BPMN

Hoje existem trs modelos bsicos para a modelagem no padro BPMN:

Figura 2 Exemplo de Processos privados de negcio

BPM Beyond Process Modelling

Processos Abstratos (pblico)

Figura 3 Exemplo de Processos Abstratos

Processos Colaborativos (global)

BPM Beyond Process Modelling

de executor ou suporte representa cada um dos participantes. Assim

Figura 4 Exemplo de Processos Colaborativos

Tipos de Diagramas de BPMN

Processo privado de atividade de alto nvel (repartio nofuncional) *

Processo de negcio privado detalhado