• Introdução
• Revisão Teórica
• Notações de modelagem
  > BPMN > IDEF > ARIS > UML 2.0
• Referências
• Download do material

Conhecimento & Insights > Wiki BPM > Modelagem em Processos

 

 

3.1. Apresentação

O Business Process Modeling Notation (BPMN) é uma representação gráfica especificada para processos de negócio de workflow. Elaborado pela Business Process Management Initiative (BMPI.org), teve a sua primeira versão publicada em novembro de 2002. Desde 2005 esta notação de modelagem é atualizada pela Object Management Group (OMG™), , após a fusão desta com a BPMI. Em seguida foi lançada a versão 1.1 sobre a notação, mas, dada a necessidade de atualização e algumas pequenas alterações, foi publicada a versão 1.2. Atualmente está sendo produzida a versão 2.0, que vai apresentar grandes mudanças em seu escopo original, objetivando uma maior coerência para essa notação.
Após a sua publicação, o BPMN emergiu como o principal padrão de modelagem utilizado pelos especialistas no tema. Além disso, pesquisas feitas revelam que as organizações apresentam um interesse especial sobre esse padrão de modelagem. Utilizado para comunicar uma variedade de informações para uma ampla variedade de telespectadores, o BPMN é projetado para cobrir vários tipos de modelagem, permitindo a criação de processos de ponta à ponta da cadeia. A sua estrutura de elementos permite ao leitor a fácil distinção entre as seções de um diagrama BPMN.
O BPMN apóia os conceitos de modelagem que são aplicáveis aos processos de negócio. Isto significa que outros tipos de modelagens feitas por organizações sem o foco em negócio fogem ao escopo de atuação desta representação. Abaixo seguem alguns exemplos de modelos que não estão no escopo de atuação do BPMN:

• Estruturas organizacionais e recursos;
• Modelos de funções de departamentos;
• Modelos de dados e informações;
• Modelos de estratégia empresarial;
• Modelos regras de negócios.

3.2. Visão geral de BPMN

Hoje existem três modelos básicos para a modelagem no padrão BPMN:

• Processos privados de negócios (interno);
• Processos abstratos (público);
• Processos colaborativos (global).

 

 

 

Abaixo os modelos básicos para modelagem BPMN são detalhados.

Processos Privados de Negócios (interno)

Os processos privados de negócios referem-se a uma organização específica e são do tipo de processos que têm sido chamados de workflow ou processos BPM. Ao modelar esse tipo de processos, serão 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 informação, passa-se a permitir a travessia entre raias, de forma a demonstrar as iterações existentes entre processos privados de negócio distintos.

Figura 2 – Exemplo de Processos privados de negócio

 

Processos Abstratos (público)

Os processos abstratos representam a interação entre os processos internos da organização e um processo ou participante externo a essa organização. Somente as atividades que são utilizadas na comunicação com o exterior do processo do negocio estão inclusos nesse tipo de modelo básico.Todos os outros processos internos não são mostrados nos processos abstratos. Assim, os processos abstratos mostram para o mundo exterior a seqüência de mensagens que são necessárias na interação com outro processo ou participante externo. Além 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 colaboração se refere à interação entre duas ou mais entidades de negocio. Essa interação é definida como uma seqüência de atividades que representa as trocas de mensagem entre os envolvidos. Um único processo de colaboração pode ser mapeado em várias linguagens, como ebXML, BPSS, RosettaNet. Esse modelo pode ser realizado em um ou mais processos, indicando os locais onde há comunicação 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 são 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 estão os tipos de processos de negócio que pode ser modelado com BPMN (aqueles com asterisco não podem ser mapeados para uma linguagem executável).

• Processo privado de atividade de alto nível (repartição não-funcional) *
• Processo de negócio privado detalhado
  AS-IS ou processo de negócio antigo
  TO-BE ou processos de negócios novos
• Duas ou mais interações de processos de negócio privados detalhados
• Detalhamento do relacionamento de processos de negócios privados com processos abstratos
• Detalhamento do relacionamento de processo de negócios 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 notação BPMN:

Figura 5 – Exemplo de Modelagem em BMPN

 

Principais objetos da notação BPMM:

Tabela 2 – Principais objetos da notação BPMN (FONTE: Stephen A. White)

Elemento	Descrição	Notação
Evento	Um evento é o que “acontece” durante a execução do processo. Esses eventos afetam o fluxo do processo e geralmente tem uma causa (gatilho) ou um impacto (resultado). Existem três tipos de eventos, baseados quando eles afetam o fluxo. São eles: início, intermediário e finalístico.
Atividade	A atividade é um termo genérico que representa o trabalho que a empresa executa. Os tipos de atividades que são parte do modelo de processos são: processos, sub-processos, e tarefas. Tarefas e sub-processos tem a forma de retângulos com as pontas arredondadas. Os processos são modelados dentro de raias.
Gateway	O Gateway é usado para controlar as divergências e convergências da seqüência do fluxo. Desse modo, esse elemento determina a ramificação no processo, fusão, e a junção de trilhos diferentes do fluxo.
Seqüência do fluxo	A seqüência do fluxo é usada para demonstrar a ordem de como as atividades serão 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.
Associação	Uma associação é usada para associar informações aos objetos do fluxo. Textos e diagramas podem ser associados a tais objetos.
Raias	Uma raia representa um participante do processo, podendo ser representado por uma raia de piscina através de uma representação gráfica que contém um conjunto de atividades que podem apresentar relação com outras raias, geralmente em um contexto de B2B.
Lane	A Lane é uma subpartição pertencente a uma determinada raia do fluxo e se estende por todo o comprimento da raia, tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar atividades.
Objeto de dados	Os objetos de dados são considerados artefatos já que não apresentam nenhum efeito direto sobre a seqüência ou sobre as mensagens do fluxo, mas ele prove algumas informações de como as atividades são 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 não afeta a seqüência do fluxo ou as suas atividades. O nome da categoria aparece no diagrama como o rótulo do grupo. Categorias podem ser utilizadas para a documentação ou análise de efeitos. Grupos são formados com o objetivo de destacar visualmente categorias de objetos no fluxo
Anotações em texto	Anotações em texto é um mecanismo utilizado pelo modelador com o objetivo de prover informações adicionais ao leitor do diagrama em BPMN.

 

3.2. Considerações Finais

 

O grande sucesso do BPMN está calcado em três pilares. O primeiro é o fato de ser uma linguagem de fácil compreensão a todos os envolvidos com processos. Assim, tanto usuário de negócios 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 integração entre as mesmas.

O segundo está no fato do BPMN apresentar uma serie de recursos que torna possível a modelagem de processos simples até os mais complexos. Esses recursos são opcionais, mas, se utilizados, permitem a modelagem em um nível bastante refinado, agregando várias informações técnicas e permitindo o mapeamento automático para padrões de execução de processos, como o BPEL.

Por fim, o terceiro pilar do sucesso desta notação de modelagem está calcado em uma sólida fundamentação matemática. Construído baseado no conceito do Pi-Calculus, uma derivação do Cálculo de Processos para a representação de processos dinâmicos e móveis, o que permitiu uma grande solidez em seu conceito e aceitação no mercado.

Outra questão relevante é o fato do BPMN ter a capacidade de detalhar diversos modelos em seqüência. No entanto, deve-se ter cuidado, pois, quanto mais subprocessos combinados, como, por exemplo, três ou mais subprocessos trocando informações entre si, mais se dificulta a leitura do seu diagrama e, por conseqüência, a sua compreensão. Recomenda-se que se tenha bastante cuidado a fim de facilitar a leitura do processo.

 

 

As informações abaixo estão fortemente baseadas no site www.idef.com e o artigo Integration Definition For Function Modeling (IDEFØ), do National Institute of Standards and Technology.

4.1. Apresentação

O IDEF (Integration DEFinition) é um padrão de modelagem para softwares. Ele tem uma abrangência de utilização para a modelagem de simulação, informações, análise à orientação ao objeto e design e aquisição de conhecimento. Teve a sua criação iniciada na década de 70, e foi finalizado durante os anos 80. O IDEF surgiu a partir do padrão de modelagem ICAM (Integrated Computer-Aided Manufacturing), criado pelas forças armadas norte americanas.

Apresenta uma estratégia abrangente que permite a representação empresarial e organizacional de forma integrada e, por isso, tem se transformado em um dos principais padrões. Ele é dividido em alguns métodos de modelagem, conforme a figura 6.

Figura 6 – Métodos IDEF (FONTE: Mayer, 1995 Apud Paim, 2002)

Abaixo está à descrição de alguns desses métodos:
IDEFØ – Modelagem funcional;
IDEF1 – Modelagem de informações;
IDEF2 – Modelagem para simulação;
IDEF3 – Modelagem para a descrição e captura de processos;
IDEF4 – Modelagem orientada por objetos;
IDEF5 – Modelagem para a descrição de ontologia;
IDEF6 – Modelagem para a racionalização de descrições;
IDEF7 – Modelagem para a auditoria de sistemas de informação;
IDEF8 – Modelagem de projetos de sistemas com interação humana;
IDEF9 – Modelagem para identificação de restrições nos processos;
IDEF10 – Modelagem de artefatos de informação;
IDEF12 – Modelagem para projeto organizacional;

Conforme analisado acima, o IDEF apresenta algumas notações voltadas para a modelagem de processos. As descrições abaixo serão focadas no IDEFØ e IDEF3.

4.2. IDEFØ – Modelagem funcional

Criado a partir de uma linguagem gráfica bem estabelecida, o Structured Analysis and Design Technique (SADT), o IDEFØ é um método concebido para a modelagem de decisões, ações e atividades de uma organização ou sistema. Essa notação foi encomendada pelas Forças Aéreas dos Estados Unidos para exercer a função de desenvolver um método de modelagem e de comunicação das funcionalidades de um sistema. Efetivamente os modelos IDEFØ ajudam a organizar as análises dos consumidores. Esse padrão de modelagem é útil para estabelecer o escopo de análise, especialmente em análises funcionais. Como uma ferramenta de comunicação, o IDEFØ auxilia o modelador a identificar quais as funções são realizadas, o que é necessário para as realizações de algumas funções, o que um sistema atual faz de correto e o que o sistema faz de errado. Assim, os modelos IDEFØ são freqüentemente criados como uma das primeiras tarefas do desenvolvimento de um sistema.

O método IDEFØ tem um conceito básico que endereça cada necessidade discutida anteriormente. O Conceito básico do IDEFØ são os seguintes, conforme abaixo.

Célula de Modelagem de Representação Gráfica

A representação gráfica da "caixa e seta" de um diagrama do IDEFØ funciona como uma caixa e as suas interfaces ou de suas funções como setas entrando ou saindo da caixa. Para expressar as funções, caixas operam simultaneamente com outras caixas, como interfaces, através de setas indicando quando e como as operações são desencadeadas e controladas. A base de sintaxe para o modelo IDEFØ é mostrada na figura abaixo.

Figura 7 – Esquema do modelo IDEFØ

 

Objetivos e Aplicação
Os principais objetivos desse padrão de modelagem são:

a. Prover recursos para uma completa e consistente modelagem de funções (atividades, ações, processos, operações) requeridas por um sistema ou empresa, e as funções de relacionamento e dados (informação ou objetos) que suportam a integração entre estas funções.
b. Prover uma técnica de modelagem que seja independente dos métodos ou ferramentas do Computer-Aided Software Engineering (CASE), mas que possa ser usado em conjunto com essas ferramentas e métodos;
c. Prover a técnica de modelagem que tenham as seguintes características:
d. Genérica (para análise de sistemas com diferentes propósitos, escopo e complexidade);
e. Precisa e rigorosa (para produzir corretamente modelos utilizáveis);
f. Concisa (para facilitar a compreensão, comunicação, consenso e validação)
g. Conceitual (para a representação dos requerimentos das funções físicas ou de implementações organizacionais);
h.  Flexível (para suportar as várias fases do ciclo de vida de um projeto).

A utilização desse padrão de modelagem é fortemente recomendada em projetos que:

a. Requerem técnicas de modelagem para a análise, desenvolvimento, re-engenharia, integração ou aquisição de informações de sistemas;
b.Incorporam sistemas ou técnicas de modelagem empresarial para análises de processos de negócio ou metodologia de software de engenharia.

As especificações desse padrão de modelagem são aplicáveis quando sistemas ou técnicas de modelagem empresarial são aplicados aos seguintes itens:

a. Projetos que necessitem o IDEFØ como técnica de modelagem;
b. Desenvolvimento de ferramentas para softwares automatizados para a implementação da técnica de modelagem IDEFØ.

As especificações desse padrão não são aplicáveis aos projetos que necessitam de técnicas de modelagem funcionais.

Pontos fortes e fracos do IDEFØ

A principal força do IDEFØ baseia-se no fato de ter sido comprovada a sua eficiência no detalhamento das atividades de um sistema. As atividades podem ser descritas por suas entradas, saídas, controles e mecanismos. Além disso, as descrições das atividades de um sistema podem ser facilmente refinadas em maior detalhe até o quanto for necessária para a tomada de decisão. Com isso, um dos problemas observados nessa notação é o fato de ser, às vezes, tão conciso que apenas o desenvolvedor ou alguém que participou da modelagem tenha a completa compreensão do modelo.

A natureza hierárquica do IDEFØ favorece a construção de modelos (AS-IS) que tenham uma representação e interpretação top-down, mas que se baseiam na análise de processo bottom-up. De forma geral, o modelador deve agrupar atividades intimamente relacionadas ou até com funcionalidades similares. Através desse processo de agrupamento, a hierarquia surge. Caso se esteja tratando de uma organização que está começando a construir a sua hierarquia, geralmente chamada de modelagem TO-BE, a construção top-down é mais indicada. Assim, constrói-se a idéia mais macro e depois se passa aos níveis mais detalhados. Quando se fala de uma organização 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 nível mais agregado. Este processo continua até que se chegue ao nível mais desejável de agregação.

Um problema com IDEFØ é a tendência de esses modelos serem interpretados como uma representação de atividades em seqüência. Apesar do IDEFØ não ser utilizado para a modelagem de atividades em seqüência, é fácil fazê-la. As atividades podem ser colocadas em uma seqüência 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 também é utilizado como o input para outra, deixando as conexões entre as atividades um conceito bem claro. Assim, mesmo sem intenção, o raciocínio de seqüenciamento de atividade pode ser embutido no modelo IDEFØ. Nos casos em que o seqüenciamento de atividades não é incluído no modelo, os leitores tendem a acrescentar esse tipo de interpretação. Esta situação anômala poderia ser considerada um ponto fraco da IDEFØ. No entanto, para corrigi-la iria resultar na corrupção dos princípios básicos sobre os quais se assenta IDEFØ e, conseqüentemente, perderia a eficácia comprovada do método.

Abaixo segue uma estrutura do diagrama do IDEFØ:

 

Figura 8 – Estrutura do diagrama do IDEFØ (FONTE: Integration Definition For Function Modeling (IDEFØ))

 

4.3. IDEF3 – Modelagem para a descrição e captura de processos

O IDEF3, Método de Captura de Descrição de Processo, provê um mecanismo para o armazenamento e documentação de processos. O IDEF3 captura a relação dos precedentes e das casualidades entre as situações e eventos em uma forma natural ao domínio dos especialistas, provendo um método estruturado para expressar o conhecimento de um sistema, processo, ou trabalhos de uma organização. O IDEF3 pemite:

• Registrar dados crus resultantes de fatos encontrados em entrevistas em atividades de análise de sistemas.
• Determinar o impacto nos recursos de informações de uma organização baseados nos principais cenários de operação de uma empresa.
• Documentar os procedimentos para decisões que afetam o estado e o ciclo de vida de um dado crítico e compartilhado, particularmente manufatura, engenharia, e definição da manutenção de dados de produtos.
• Gerenciar a configuração de dados e mudança das definições de políticas de controle.
• Produzir a concepção de sistema e o design de análise de trade-offs.
• Prover a geração de modelos de simulação.

 

 

 

 

 

 

 

O IDEF3 tem a capacidade de compreender os aspectos comportamentais de um sistema existente ou sugerido e captura todas as informações temporais, incluindo processos empresariais. Os resultados das descrições do IDEF3 provêem a estruturação da base do conhecimento para construir modelos analíticos e de design. Infelizmente, linguagens de simulação (por exemplo: SIMAN, SLAM, GPSS, WITNESS) constroem modelos matemáticos, enquanto o IDEF3 constrói descrições estruturadas. Essas descrições capturam as informações do que um sistema de fato realiza ou vai realizar e ainda provê à organização uma série de visões dos diferentes usuários do sistema.

Existem dois modos para descrição do IDEF3:o fluxo de processo e a transição da rede do estado do objeto. A descrição do fluxo de processo captura o conhecimento de “como as coisas funcionam” em uma organização, por exemplo, a descrição de que acontece com uma parte, e como é o fluxo dela na seqüência do processo de manufatura. A segunda dimensão permite a transição completa de um objeto para um determinado processo. Ambas as dimensões contêm unidade de informações que compõem a descrição do sistema. As entidades dos modelos, como eles são chamados, formam a base das unidades de descrição do IDEF3. Os diagramas resultantes e textos compreendem o que é denominado “descrição        ”, em oposição ao foco do que é produzido pelos outros modelos IDEF, cujos produtos são um “modelo”. 

No IDEF3, o processo de descrição do fluxo de processos capta a descrição de um processo e a rede de relações que existe entre os processos dentro do contexto de um cenário em que eles estão contidos. O intuito desta descrição é mostrar como as coisas funcionam em uma determinada organização quando vistas como sendo parte de um problema particular, resolvendo ou demonstrando uma situação recorrente. O desenvolvimento de um processo deste tipo consiste em expressar fatos, coletados a partir do domínio de especialistas, em termos descritivos da construção de cinco blocos básicos.

O exemplo a seguir ilustra como os blocos de construção do método IDEF3 podem descrever o cenário tipicamente encontrado em indústria de manufatura. A situação a ser descrita está baseada em um processo de pintura e de inspeção, relacionados com a aplicação de uma tinta em um módulo que se tornará um elemento de um pesado equipamento de construção. A figura abaixo é a representação gráfica do exemplo, que está baseado na entrevista de um supervisor de pintura de uma fábrica.

Abaixo segue exemplo de um diagrama do IDEF3:

 

Figura 9 – Exemplo de diagrama IDEF3

 

As caixas maiores são chamadas de “Unit Of Behavior” (UOB). As linhas são as conexões entre as UOBs e é isso que define o fluxo lógico do diagrama. As pequenas caixas no canto inferior esquerdo definem os mecanismos que introduzem o fluxo lógico do diagrama.

 

4.4. Considerações finais

De forma geral, a proposta dos modelos e descrições é ajudar a tomar decisões. Cada tipo de modelo ou descrição foca em um relativo conjunto estreito de relacionamentos e características de sistemas, compreendendo um ponto de vista particular ou uma perspectiva global do sistema. Modelos de análises, por exemplo, são utilizados para determinar requerimentos existentes ou antecipar a sua concepção. Design de modelos servem para facilitar a otimização de recursos desejáveis de design para um conjunto de requerimentos de sistemas. Modelos de simulação provem um perspectiva de várias medidas e estatísticas associadas ao desempenho do sistema que podem ser geradas para examinar uma característica especifica de desempenho sobre um conjunto restrito de condições operacionais. Cada modelo e as decisões geradas através da sua construção têm uma relativa ponderação em direção ao nível global das decisões do sistema, criando uma competição de decisões dentro e entre tipos de modelos que eventualmente emergem, necessitando análises de trade-offs.

Como resultado, os modelos e as descrições nunca pretendem representar todas as possibilidades ou comportamentos de um sistema. Estes focam em um conjunto restrito de características de sistemas e acabam ignorando os aspectos que não são pertinentes na tomada de decisão.

A família de métodos do IDEF busca um balanceamento favorável entre métodos especiais de aplicações efetivas limitadas a tipos de problemas específicos, e “super modelos” que incluem tudo que possa ser necessário. Este balanceamento é mantido com a família de métodos do IDEF provendo mecanismos explícitos para integração de resultados de aplicações de métodos individuais.X

 

 

 

AS informações abaixo estão fortemente baseadas em Paim (2002) e Chaloub (2004).

5.1. Apresentação

A ferramenta ARIS Toolset é utilizada para suportar a metodologia ARIS de Modelagem de Processos de Negócios e está fundamentada na utilização de diversos modelos e objetos, através dos quais os processos de negocio de uma data organização podem ser representados e analisados.

Essa metodologia foi desenvolvida objetivando a integração dos processos de negócios de uma organização. O primeiro passo para o desenvolvimento desta arquitetura foi a criação de um modelo que contivesse as principais características para se descrever um processo de negócio.  O resultado foi um modelo complexo, sendo necessária, assim, a divisão em partes para interpretar o todo.  Desta forma, criou-se uma divisão em vistas.  Estas “vistas” são inter-relacionadas de forma que os modelos possam ser analisados holisticamente e sem redundância.

Os modelos podem ser agrupados em cinco vistas: Organização, Função, Dados, Saída e Controle.

Figura 10 – Aris House (FONTE: Organização dos Modelos, Scheer, 1998, p. 1)

 

Nesta metodologia os principais modelos são: Cadeia de Valor Agregado - VAC; Diagrama de Objetivos - DO; Árvore de Funções - FT; Organograma - ORG; Diagrama de Entidades e Relacionamento - ERM; Estrutura de Conhecimento - KSD; Diagrama de Função - FAD; e Cadeia de Processos Orientada por Eventos - EPC, sendo este bastante importante para a visão de processos.  Cada um destes modelos tem objetivos próprios, mas são utilizados de forma inter-relacionada, na lógica da metodologia.

 

 

5.2. Diagrama de Objetivos

Em muitos casos, os projetos de modelagem estão ligados a discussões estratégicas que orientam processos. Baseado nisso, antes de realizar qualquer atividade de modelagem de processos, como analisá-los e redesenhá-los, é necessário conhecer os objetivos estratégicos da empresa.

Assim, esse diagrama permite que os objetivos organizacionais sejam definidos e hierarquizados. Além disso, podem ser identificados no modelo os fatores críticos para que sejam alcançados esses objetivos, e também as atividades ou processos relacionados a esse objetivo.

Abaixo está a representação dos principais objetos utilizados nesse modelo.

Figura 11 – Objetos de modelagem do “Diagrama de Objetivos” (FONTE: Chalhoub)

 

De acordo com a situação em que o objeto está envolvido, ele pode assumir diferentes significados. Nesse diagrama, o objeto “função” é utilizado para representar atividades ou processos que estejam relacionados aos objetivos mapeados.

Além disso, a ligação presente entre os objetos desse diagrama também pode ter significados diferentes, de acordo com a sua disposição. Assim sendo, deve-se ter atenção não apenas nos objetos que compõe o diagrama, mas também nas ligações existentes entre eles.

A seguir seguem alguns exemplos de diagramas de objetos modelados no ARIS.

Figura 12 – Exemplo de hierarquização no diagrama de objetivos (FONTE: Chalhoub)

Figura 13 – Exemplo de relacionamento entre atividades, objetivos e fatores críticos (FONTE: Chalhoub)

 

5.3. Organograma - ORG

Este modelo tem como função representar a estrutura organizacional. Apresenta como propriedade a visualização das relações existentes entre as diversas áreas de uma organização, além 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)

 

5.4. Cadeia de Valor – VAC

 

Este modelo facilita à macro visão dos processos mapeados da organização, mostrando como eles se conectam, além de representar o fluxo de materiais e informações na empresa. De uma forma geral, esse modelo apresenta como é agregado valor durante a realização das atividades e processos na organização.

No VAC, os principais objetos são: função, unidade organizacional e cluster. Os objetos de unidade organizacional e de função já foram apresentados anteriormente, mas o último ainda apresenta uma pequena diferença daquele apresentado, sendo demonstrado no exemplo abaixo. Já o cluster é entendido por um conjunto de dados e informações. Abaixo segue a ilustração 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 estão inter-relacionados através da ligação existente entre eles. As ligações tracejadas entre os objetos representam uma lógica temporal entre eles, um predecessor do outro, enquanto a linha continua representa hierarquização, relação de superioridade.

A figura abaixo é um exemplo de representação do VAC no ARIS.

 

Figura 17 – Exemplo de VAC – Cadeia de Suprimentos de Petróleo (FONTE: Chalhoub)

Uma das vantagens do VAC é permitir a navegação logicamente estruturada entre os processos mais detalhados da organização, denominados EPC (Event Driven Process Chain). A interligação entre o VAC e o EPC, que será mais bem detalhado no próximo item, garante a consistência de interligação dos processos entre as diversas áreas organizacionais.

Portanto, o VAC disponibiliza uma visão agregada dos processos que permeiam toda a estrutura organizacional, permitindo que os EPCs sejam acessados a partir de um macro processo.

 

5.5. Cadeia de Processos Orientada por Eventos – EPC

 

Este modelo representa a integração das diversas visões do ARIS: função, dados, organização e saídas na vista de controle. Sua principal finalidade é a modelagem detalhada dos processos da organização. São encadeadas seqüencialmente 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” (relatórios, informações, sistemas, meios de comunicação, conhecimentos etc.), além dos indivíduos e/ou unidades organizacionais responsáveis pela sua realização, utilizando operadores lógicos para descrever a lógica de encadeamento das atividades.

Abaixo seguem os objetos do EPC utilizados com maior freqüência.

Figura 18 – Objetos de modelagem de “EPC” (FONTE: Chalhoub)

Abaixo um exemplo de EPC.

Figura 19 – Exemplo de EPC (FONTE: Chalhoub)

 

Através desse modelo é possível visualizar todos os insumos que participam do processo, sejam eles clientes, fornecedores ou atores, bem como os produtos por eles gerados.

 

5.6. Diagrama de Função – FAD

Esse modelo é utilizado quando se deseja mapear os insumos necessários para a execução de uma atividade e os resultados por ela gerados.

Uma das diretrizes para a modelagem nesse diagrama é evitar carregá-lo com muita informação, já que tornará o modelo de difícil leitura e compreensão. Opta-se, nesse caso, por desmembrar os modelos em outros menores, reduzindo a sua complexidade.

Os objetos utilizados no FAD são os mesmos do EPC e, por isto, não necessita de uma descrição 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 não é um recurso especifico para esse diagrama, sendo utilizado também 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)

 

 

 

 

 

As informações abaixo estão fortemente baseadas em UML 2 for Dummies, de Michael Jesse.

6.1. Apresentação

A primeira informação que devemos saber é porque o UML existe. O UML (Unified Modeling Language) é um padrão de modelagem que permite a integração de um conjunto de diagramas, que foi desenvolvido para auxiliar os desenvolvedores de softwares e sistemas a realizar algumas tarefas, tais como especificação, documentação, simulação e teste e visualização.

O UML foi originalmente desenvolvido com a intenção de promover a comunicação e produtividade para os desenvolvedores de sistemas orientados a objetos. Entretanto, o poder do UML permitiu a sua utilização em qualquer tipo de sistema e de desenvolvimento de software. Assim, esse padrão de modelagem também tem sido utilizado na modelagem de negócios.

Além disso, o UML tem a propriedade de ser de fácil compreensão, permitindo ao modelador focalizar no que realmente é importante, evitando que a distração com detalhes de menor importância e que podem ser suprimidos em outro momento. Após ter construído um modelo, essa notação permite que se faça alguns testes para verificar a qualidade do mesmo, sem que seja necessário o desenvolvimento do sistema propriamente dito, ou seja, sem aumento de custos.

A modelagem UML também suporta a visão de um sistema sob múltiplas vistas. Assim como se pode ter um mapa político, um mapa de relevo ou um roteiro, é possível ter um mesmo mapa que apresente diagramas com distintas finalidades e com diferentes tipos de diagramas, enfatizando diferentes visões 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 mínimo, 13 diagramas e alguns outros semi-oficiais. Dado isso, algumas confusões podem surgir, já que o UML permite que o modelador troque alguns elementos entre modelos.

 

 

 

6.2. Visão geral de UML

Uma das propriedades do UML, como já foi mencionada, é o fato de apresentar diversos diagramas, entretanto, não é necessário 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 nível maior de abstração. Quanto mais abaixo da figura, mais especifico é o diagrama. As setas tracejadas indicam uma interdependência entre alguns diagramas no que tange a reutilização das características de outros diagramas.
Embora não pareça tão claro, há diferentes modos de organizar os diagramas em UML e, assim, ajudar na compreensão de qual é a melhor maneira de utilizá-los.
Ainda segundo a Figura 22, ela utiliza a técnica de organização baseada em generalizações (movendo para baixo através de níveis de abstração) e especializações (movendo para baixo através de uma mesma hierarquia na direção de um detalhe mais concreto).
Os diagramas em UML ainda podem ser divididos em três categorias:

• Diagramas de estrutura: utiliza-se esse tipo de diagrama para representar os blocos de construção de recursos de sistemas que não 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 alterações ou como evolui ao longo do tempo.
• Diagramas de interação: é utilizado para descrever as trocas de mensagens dentro de uma colaboração (um grupo de objetos colaborando entre si) para atingir uma determinada meta. Esses diagramas, na realidade, são um tipo de diagramas comportamentais.

 

 

 

 

 

Tabela 3 – Categorias e diagramas UML

Categoria	Tipo de diagrama	Descrição
Diagramas de estrutura	Diagrama de classe	Utilizado para mostrar as entidades do mundo real, elementos de analise e concepção, classes de implementação e seus relacionamentos.
Diagramas de estrutura	Diagrama de objetos	Utilizado para mostrar um exemplo especifico ou ilustração de objetos e suas ligações. Pode ser utilizado para indicar condições para eventos, como um teste ou operação de chamada.
Diagramas de estrutura	Diagrama de estrutura composta	Utilizado para mostrar como alguma coisa é feita. Especialmente utilizado para estruturas complexas.
Diagramas de estrutura	Diagrama de implantação	Utilizado para mostrar o tempo de execução de um sistema, plataforma de hardware, softwares e seus ambientes (como sistemas operacionais e máquinas virtuais)
Diagramas de estrutura	Diagrama de componentes	Utilizado para mostrar a organização e seus relacionamentos no que tange seus sistemas
Diagramas de estrutura	Diagrama de pacotes	Utilizado para organizar os elementos de modelos e mostrar a dependência entre eles
Diagrama de comportamento	Diagrama de atividades	Utilizado para demonstrar o fluxo de dados e/ ou o controle de trabalho de comportamento
Diagrama de comportamento	Diagrama de casos de uso	Utilizado para mostrar os serviços que os atores podem solicitar de um sistema
Diagrama de comportamento	Diagrama de máquina / protocolo do diagrama de máquina	Utilizado para mostrar o ciclo de vida de um determinado objeto, ou a seqüência de objetos, ou a sua interface de suporte.
Diagrama de interação	Diagrama “overview”	Utilizado para demonstrar vários cenários de interações (seqüência de comportamento) para um conjunto de elementos trabalhando em conjunto para realizar uma meta (colaboração)
Diagrama de interação	Diagrama de seqüência	Utilizado em concentrar nas trocas de mensagens entre um grupo de objetos e a ordem de mensagens
Diagrama de interação	Diagrama de comunicação	Utilizado em concentrar nas mensagens entre grupo de objetos e as relações entre objetos
Diagrama de interação	Diagrama de tempo	Utilizado para mostrar as mudanças em tempo real ou sistemas de trabalho.

 

Pelo fato do UML ser bastante dinâmico, existem outras maneiras de categorizar os seus diagramas. Abaixo seguem as três categorias:

• Diagramas estáticos: Semelhante à dos diagramas estruturais, estes diagramas mostram a estática do sistema.
• Diagramas dinâmicos: Esses diagramas mostram como um determinado sistema evolui ao longo do tempo. Esta categoria abrange os diagramas de máquina 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, interação e atividades.

 

 

 

 

 

6.3. Diagrama de Classes e Diagrama de objetos

O UML tem dois principais diagramas estáticos: diagrama de classes e diagramas de objetos. O diagrama de classes mostra as classes e as associações, agregações e generalizações. 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 são utilizados com fins específicos.

Quando se usa uma ferramenta de modelagem UML, deve-se ter bastante atenção sobre os diferentes tipos de diagramas que ele suporta. Caso não se tenha atenção a esse detalhe e não se tenha suporte para o diagrama de objetos, então 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 também são os mais úteis diagramas que se pode produzir porque o código gerado pela ferramenta UML é baseado no diagrama de classes.

Os diagramas de objetos puros mostram simplesmente os casos e links de objetos e as conexões 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 instância da classe Supplier chamado ace1 faz link com duas instâncias da classe Invoice, A1 e A2. Ambas as instâncias A1 e A2 são contas que foram enviadas no passado, porque eles desempenham o papel de pastBill. Estes dois Invoices foram pagos a partir de uma instância da classe SupplierAccount chamada aceAcc. Outra instância da classe Supplier, generalAirF, está ligada a um conjunto diferente de invoices. A partir do diagrama visto, percebe-se que a instância 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 não tem uma currentBill. No outro caso, generalAirF tem um current Bill.
Os diagramas de objetos são 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 são bons para mostrar aos gerentes o que está acontecendo.

Ainda pode-se construir um diagrama de objetos/classes híbrido. Alguns acham isso mais útil quando se quer mostrar as classes e também mostrar um exemplo ou dois casos de uso de algumas dessas classes.

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

 

 

6.4. Diagrama de casos de uso

Os diagramas UML aproveitam a potência da teoria de orientação por objeto e das técnicas de análise e desenho, enquanto outros centralizam no detalhamento de projeto e construção. Em ambos os casos, estes diagramas ajudam a realizar uma tarefa ou se comunicar com funcionários na organização.

No entanto, o desenvolvimento prático não é apenas uma atividade interna, sobretudo no atual clima de competição e de pressão para diminuir os orçamentos. Se o objetivo é permanecer no negócio, é preciso captar e entender as exigências de seus clientes e suas necessidades, e fazer um produto ou sistema que eles querem. Casos de uso e diagramas de casos de uso são as funcionalidades do UML que apóiam o recolhimento e a análise centrados nos requisitos dos usuários iniciado nos objetivos e metas de seus clientes.

Casos de uso podem manter-se focados em seus usuários e objetivos práticos sobre sistemas de produção que entregam valor aos seus clientes, sejam eles clientes internos ou externos.

O Caso de uso tem um fim específico em que o usuário 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, é possível pintar uma imagem clara do que o sistema tem de fazer. Essa imagem clara pode ser mostrada aos clientes, usuários, gestores e demais interessados, que podem ajudar a compreender os defeitos e acertos do sistema, favorecendo o processo de desenvolvimento.

Identificando o público

Para se obter uma imagem fiel do propósito que o sistema quer atingir, é necessário identificar para quem o sistema é (seu cliente) e quem utiliza o sistema (os usuários). 

Lembrando que os usuários e os clientes geralmente não são o mesmo grupo de pessoas. Mesmo quando eles são as mesmas pessoas, esta distinção é benéfica para pensar a diferença de papéis entre os usuários e os clientes

• Clientes: São pessoas ou organizações que, em última instância, pertencem a sua equipe. Eles devem ser satisfeitos para que se possa receber um pagamento. Seu time pode ter uma relação contratual com eles (clientes externos), ou podem ser uma parte da sua própria estrutura de gestão (clientes internos). Quando estamos desenvolvendo uma organização, considere a organização como seus pais o seu cliente. 
• Os clientes dos seus clientes: Quando se fala sobre clientes (por oposição aos seus clientes), geralmente se refere aos clientes do seu cliente. Estas são as pessoas ou organizações que compram coisas a partir do seu cliente. Se o seu sistema não torná-los felizes, o seu cliente está insatisfeito. 
• Usuários: Ao se referir aos usuários de um sistema, eles podem ser os clientes do seu cliente, ou eles podem ser os trabalhadores da organização de seu cliente que se relaciona de alguma forma com o sistema. Muitos sistemas têm usuários de todos os tipos: os seus clientes, clientes dos seus clientes, e as pessoas que trabalham desenvolvendo o sistema. Usuários chegam a se sentir mais próximo dos sistemas e acabam obtendo impressões mais fortes. As tarefas dos usuários são especificar o que o sistema deve automatizar, as necessidades dos usuários são o que o sistema tem de realizar.

 

 

 

 

 

 

 

 

 

Assim sendo, os atores de um sistema, considerando que os atores não são uma pessoa especifica, mas o papel que uma determinada pessoa exerce e que não devemos usar nomes individuais. Dentro do UML a notação de um ator é tradicionalmente uma figura bastão ou pode também ser utilizada uma caixa com o rótulo escrito «Actor», conforme pode ser visto na figura abaixo:

Figura 24 – Exemplo da representação 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 não-humanos (outros sistemas, bases de dados e dispositivos). Esta pequena convenção visual irá ajudá-lo a distingui-las rapidamente. 

 

 

6.5. Considerações finais

Pode-se empregar os diagramas em UML para mostrar informações 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 idéias pode ser bastante útil através das respostas de simples questões sobre os sistemas que se deseja modelar:

1. Quem utiliza o sistema?  Mostre os atores (aqueles que vão 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 lógica e o diagrama de componentes para mostrar a estrutura física do sistema.
3. Onde estão localizados os componentes do sistema? Indique os seus planos sobre para onde seu sistema vai estar e evoluir no diagrama de implantação.
4. Quando é que acontecem eventos importantes no sistema? Mostre o que provoca a reação dos objetos e o trabalho através dos diagramas de estado e interação.
5. Porque é que este sistema está fazendo as coisas que ele faz? Identifique os objetivos dos usuários 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 comunicação para mostrar as interações em um nível suficiente para detalhar a concepção e implementação.