Wikibpm Modelagem de Processos

7/24/2019 Wikibpm Modelagem de Processos

1/53

BPM Beyond Process Modelling


2/53


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 e

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 de

conhecimentos que pode ser partilhada pelosplayers no mercado.


3/53


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 ObjectManagement 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 Definio Exemplo

Business

Process

Modeling(BPM)

BPM uma abordagem utilizada para identificar,desenhar, documentar, mensurar, monitorar econtrolar tanto processo de negciosautomatizados quanto no-automatizados com o

objetivo de alcanar resultados que estejamalinhados com as metas estratgicas daorganizao. ABPMP CBOK

No aplicvel

Modelo

Um modelo pode ser entendido como umarepresentao explcita e externa de parte darealidade vista por pessoas que desejam usar omodelo para: entender, mudar, gerenciar econtrolar esta parte da realidade de algumaforma. Pidd (1999).

Desenho com a representaode uma rede hidrulica de uma

casa

Modelo deProcesso

Modelo de processo um conjunto de atividadesenvolvidas na criao de representaes de umprocesso novo ou de um j existente. ABPMPCBOK

Passo-a-passo de como secozinha um arroz.

Notaode

modelode

processos

Conjunto de sinais com que se faz essarepresentao ou designao. DicionrioMichaellis BPMN, UML, IDEF

A figura a seguir exemplifica as definies apresentadas anteriormente:


4/53


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

1.3.Motivaes e Benefcios Esperados

Segundo Vernadat apudChaulhoub (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 (anlise econmica,

organizacional etc.);

Possibilitar a realizao de simulaes;


5/53


Tomar melhores decises em relao organizao e s operaes

empresariais;

Controlar, coordenar ou monitorar os processos empresariais.

Segundo Rashid M. Khan, em seu artigo WhatStandards 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 e a capacidade de resposta rpida snecessidades 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 esseembasamento.


6/53


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 integral e completa do processo real, masfreqentemente focar na representao 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 suaperformance 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 uma avaliao das normas e cumprimento das

obrigaes;


7/53


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 livrespara 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 soessenciais para a criao de modelos robustos.


8/53


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 a quantidade

necessria para criar o Modelo versus Utilidade do modelo versusTempo 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 a todos, corrigindo e

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.


9/53


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.


10/53


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 ealgumas 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 especialsobre 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:


11/53


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


12/53


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 comunicaocom 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


13/53


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 no-

funcional) *

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")


14/53


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


15/53


Principais objetos da notao BPMN:

Tabela 2 Principais objetos da notao BPMN (FONTE: Stephen A. White)

Elemento Descrio Notao

Evento

Um evento o que acontece durante a

execuo do processo. Esses eventos

afetam o fluxo do processo e geralmente tem

uma causa (gatilho) ou um impacto

(resultado). Existem trs tipos de eventos,

baseados quando eles afetam o fluxo. So

eles: incio, intermedirio e finalstico.

Atividade

A atividade um termo genrico que

representa o trabalho que a empresa

executa. Os tipos de atividades que so

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.

Gateway

O Gateway usado para controlar as

divergncias e convergncias da seqncia

do fluxo. Desse modo, esse elementodetermina a ramificao no processo, fuso,

e a juno de trilhos diferentes do fluxo.

Seqncia do fluxo

A seqncia do fluxo usada para

demonstrar a ordem de como as atividades

sero executadas no fluxo do processo.

Mensagem do fluxo

A mensagem do fluxo usada para mostrar

o fluxo de mensagens presentes entre dois

participantes do processo que a envia e a

recebe. Em BPMN, duas raias distintas

representam participantes diferentes do

processo.

Associao

Uma associao usada para associar

informaes aos objetos do fluxo. Textos e

diagramas podem ser associados a tais

objetos.


16/53


Raias

Uma raia representa um participante do

processo, podendo ser representado por

uma raia de piscina atravs de uma

representao grfica que contm um

conjunto de atividades que podem

apresentar relao com outras raias,geralmente em um contexto de B2B.

Lane

A Lane uma subpartio pertencente a

uma determinada raia do fluxo e se estende

por todo o comprimento da raia, tanto

verticalmente quanto horizontalmente. Lanes

so usadas para organizar e categorizar

atividades.

Objeto de dados

Os objetos de dados so considerados

artefatos j que no apresentam nenhumefeito direto sobre a seqncia ou sobre as

mensagens do fluxo, mas ele prove algumas

informaes de como as atividades so

executadas.

Grupo (caixa em volta de um

conjunto de objetos em uma

mesma categoria)

um grupo de atividades que pertence a

uma mesma categoria. Esse agrupamento

no afeta a seqncia do fluxo ou as suas

atividades. O nome da categoria aparece no

diagrama como o rtulo do grupo. Categorias

podem ser utilizadas para a documentao

ou anlise de efeitos. Grupos so formadoscom o objetivo de destacar visualmente

categorias de objetos no fluxo

Anotaes em texto

Anotaes 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.


17/53


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 epermitindo 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.


18/53


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 eaquisio 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 algunsmtodos de modelagem, conforme a Figura 6.


19/53


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;


20/53


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 osistema 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


21/53


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 dosmtodos ou ferramentas do Computer-Aided Software Engineering

(CASE), mas que possa ser usado em conjunto com essas

ferramentas e mtodos;

c. Prover a tcnica de modelagem que tenham as seguintes

caractersticas:


22/53


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.


23/53


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 (AS-

IS) 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,


24/53


pois o outputde uma determinada atividade tambm utilizado como o

inputpara 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 oseqenciamento 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))


25/53


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 depolticas 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 descriesdo 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 o 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.


26/53


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, ecomo o fluxo dela na seqncia do processo de manufatura. A segunda

dimenso permite a transio completa de um objeto para um

determinado processo. Ambas as dimenses contm unidade 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 produzidopelos 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:


27/53


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 dodiagrama. 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 conjuntoestreito 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 estatsticasassociadas 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.


28/53


Como resultado, os modelos e as descries nunca pretendem

representar todas as possibilidades ou comportamentos de um sistema.

Estes focam em um conjunto restrito de caractersticas de sistemas eacabam 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, e super modelos que incluem tudo que possa ser

necessrio. Este balanceamento mantido com a famlia de mtodos doIDEF provendo mecanismos explcitos para integrao de resultados de

aplicaes de mtodos individuais.


29/53


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 eanalisados.

Essa metodologia foi desenvolvida objetivando a integrao dos processos

de negcios de uma organizao. O primeiro passo para o

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.


30/53


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.


31/53


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.


32/53


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.


33/53


Figura 14 Objetos de modelagem do Organograma (FONTE: Chalhoub)

Figura 15 Exemplo de Objetos de organograma (FONTE: Chalhoub)


34/53


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 a linha continua representa hierarquizao, relao de

superioridade.

A figura abaixo um exemplo de representao do VAC no ARIS.


35/53


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 osrecursos por elas consumidos e/ou gerados (relatrios, informaes,

sistemas, meios de comunicao, conhecimentos etc.), alm dos

indivduos e/ou unidades organizacionais 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.


36/53


Figura 18 Objetos de modelagem de EPC (FONTE: Chalhoub)

Abaixo um exemplo de EPC.


37/53


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.


38/53


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.


39/53


Figura 21 VAC desdobrado em EPC e FAD (FONTE: Chalhoub)

6.7Consideraes finais


40/53


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 algumastarefas, 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


41/53


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.


42/53


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 pararepresentar 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

Diagramas de estrutura Diagrama de classe

Utilizado para mostrar as

entidades do mundo real,

elementos de analise e

concepo, classes de

implementao e seus

relacionamentos.


43/53


Diagramas de estrutura Diagrama de objetos

Utilizado para mostrar um

exemplo especifico ou

ilustrao de objetos e suas

ligaes. Pode ser utilizadopara indicar condies para

eventos, como um teste ou

operao de chamada.

Diagramas de estruturaDiagrama de estrutura

composta

Utilizado para mostrar

como alguma coisa feita.

Especialmente utilizado

para estruturas complexas.

Diagramas de estrutura Diagrama de implantao

Utilizado para mostrar o

tempo de execuo de um

sistema, plataforma de

hardware, softwares e seus

ambientes (como sistemas

operacionais e mquinas

virtuais)

Diagramas de estrutura Diagrama de componentes

Utilizado para mostrar a

organizao e seus

relacionamentos no que

tange seus sistemas

Diagramas de estrutura Diagrama de pacotes

Utilizado para organizar os

elementos de modelos e

mostrar a dependncia

entre eles

Diagrama de

comportamentoDiagrama de atividades

Utilizado para demonstrar o

fluxo de dados e/ ou o

controle de trabalho de

comportamento

Diagrama de Diagrama de casos de uso Utilizado para mostrar os


44/53


comportamento servios que os atores

podem solicitar de um

sistema

Diagrama de

comportamento

Diagrama de mquina /

protocolo do diagrama de

mquina

Utilizado para mostrar o

ciclo de vida de um

determinado objeto, ou a

seqncia de objetos, ou a

sua interface de suporte.

Diagrama de interao Diagrama overview

Utilizado para demonstrar

vrios cenrios de

interaes (seqncia decomportamento) para um

conjunto de elementos

trabalhando em conjunto

para realizar uma meta

(colaborao)

Diagrama de interao Diagrama de seqncia

Utilizado em concentrar nas

trocas de mensagens entreum grupo de objetos e a

ordem de mensagens

Diagrama de interao Diagrama de comunicao

Utilizado em concentrar nas

mensagens entre grupo de

objetos e as relaes entre

objetos

Diagrama de interao Diagrama de tempo

Utilizado para mostrar as

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.


45/53


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 ediagramas 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.


46/53


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 daclasse invoice desempenha o papel do currentBill.

A figura acima ilustra dois casos diferentes de Suppliers e seus Invoices.

Em um caso o Supplierace1 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.


47/53


Tabela 4 Tipos de Diagrama UML (FONTE: ELO Group)

Tipo de Diagrama Descrio

Diagrama de classes

Apresenta classes, associaes,

agregaes e generalizaes

Organizar as classes de gerao de

cdigos em ferramentas UML

Diagrama de objetos

Mostra um exemplo especifico de gesto

Considera quais instncias se tem em

execuo (tambm utilizado no diagramade comunicao)

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 especificaque 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, estesdiagramas ajudam a 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


48/53


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.


49/53


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-losfelizes, 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


50/53


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 e 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.


51/53


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.


52/53


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


53/53


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 terico-

conceitual, 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

Documents

Transcript of Wikibpm Modelagem de Processos