modelagem de processos unidade iv

103

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

ModelageM de Processos

Unidade IV7 MODELAGEM DA ARQUITETURA DE NEGÓCIO

7.1 Introdução

Processos de negócio são atividades previamente estabelecidas que têm como objetivo determinar a forma como o trabalho é realizado numa organização.

Constituem um conjunto de ações, relacionadas entre si de forma lógica e coerente, a fim de promover uma saída favorável à organização, tanto em termos internos como externos.

Uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia de uma empresa por meio dos produtos e serviços que gera e disponibiliza.

Dada a similaridade das suas composições, função de negócio e processo de negócio são conceitos que frequentemente suscitam dúvidas entre as pessoas interessadas em formar um melhor entendimento a respeito dos elementos de uma arquitetura de negócios.

Ambos são “coisas que a empresa faz”, entretanto, os processos são transfuncionais (ou horizontais), já que perpassam diversas barreiras funcionais dentro da organização (por exemplo: adquirir bem, alienar bem, contratar funcionário), enquanto que as funções, que em conjunto descrevem a missão da empresa, são verticais (por exemplo: contabilidade, vendas, logística).

Um outro aspecto relevante, e que pode representar uma mais valia na implementação dos processos de negócio numa organização, tem a ver com a implementação de um sistema de informação bem estruturado.

A existência de uma boa rede de informação, entre todos os intervenientes nos processos de negócio da organização, é condição sine qua non, uma vez que permite a comunicação em tempo real, tornando possível uma adequada tomada de decisão, resultante do ajuste contínuo de procedimentos que irá repercutir em toda a dinâmica organizacional e, consequentemente, na excelência dos seus resultados.

Desse modo, quando se fala em processos de negócio, a abrangência é enorme, pois o seu âmbito de atuação é transversal e atua em todas as áreas da organização, com elevado impacto na qualidade dos serviços e/ou produtos, na redução de custos e no desenvolvimento do próprio negócio.

Por outro lado, a existência de uma interface entre os processos de negócio e uma rede de sistemas de informação constituem fatores-chave fundamentais, quer para a generalidade dos negócios dos tempos de hoje, quer para a produção de indicadores e instrumentos de controle efetivo para uma constante monitorização das atividades da organização.

104

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Assim, como a Figura 57 sugere, pode-se definir processos de negócio como um conjunto de atividades desenvolvidas a partir de um objetivo predefinido que irá concretizar-se num resultado específico, em termos de produto ou serviço que se pretenda realizar.

Pessoas Equipamento Informação

Objetivo ResultadoProcessos de negócio

Que tarefas específicas?

Qual a prioridade?

Quais os procedimentos?

Figura 57 – Processos de negócio

7.2 Modelagem de negócio

Para compreender uma organização, é necessário entender seus processos de negócio. Profissionais da Tecnologia da Informação se empenham em construir soluções que têm por finalidade auxiliar a empresa na conquista de maior espaço no mercado globalizado.

Nesse contexto, os processos são avaliados e, sempre que possível, informatizados, de forma a promover vantagens competitivas a partir do alinhamento estratégico entre o sistema e o negócio da empresa.

Para a OMG (Object Management Group, 2005), um processo de negócio corresponde a um conjunto coeso de atividades que criam um resultado, o qual garante a criação de valor a um cliente externo ou interno à empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de negócio e que se desenvolve a partir de um determinado evento de negócio.

Segundo Laudon e Laudon (2001), um processo de negócio refere-se à maneira pela qual o trabalho é organizado, coordenado e focado, para produzir um produto ou serviço de valor.

De um lado, processos de negócios são fluxos de trabalhos concretos de materiais, informações e conhecimentos. De outro, referem-se também à maneira singular de as organizações coordenarem trabalho, informação e conhecimento, e de como a gerência prefere coordenar o trabalho.

Já a modelagem de negócio é uma técnica de modelagem de alto nível, que surgiu das dificuldades identificadas pelos analistas de sistemas.

105

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


É uma abstração voltada à realidade dos administradores, assim, estudiosos e pesquisadores da área de TI criaram uma técnica de modelagem de alto nível denominada de modelagem de negócio, que hoje é parte integrante no processo de desenvolvimento de software e que serviu para facilitar a comunicação com as pessoas que fazem parte do negócio mas não possuem conhecimentos de Engenharia de software.

Observação

Os autores Michael Hammer e James Champy afirmam:

Um processo de negócio é uma coleção de atividades que usam um ou mais tipos de entrada e criam uma saída que seja de valor para o cliente. Um processo de negócio tem um objetivo e é afetado por eventos que ocorrem no mundo externo ou em outros processos.

Lembrete

A técnica de modelagem de negócio é profundamente relacionada à arquitetura de negócios.

Observação

Já o autor Thomas Davenport aponta que o processo de modelagem de negócios:

[...] é um conjunto estruturado de atividades, desenhado para produzir um resultado especificado para um cliente ou um mercado em particular. Isso implica forte ênfase sobre como o trabalho é feito dentro da organização, em contraste com o foco no produto. Um processo é então uma ordenação específica de atividades de trabalho, por meio do tempo e do espaço, com começo e fim e entradas e saídas claramente dentificadas: uma estrutura para ação.

7.2.1 Conceitos de negócio

Funções de negócio são estruturas conceituais idealizadas que servem para descrever a missão de uma organização. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantêm estáveis ao longo do tempo, mesmo diante de reorganizações da empresa.

Como são perenes, as funções representam um ponto de referência (conceitos comuns) ao se descrever diferentes negócios, que de outra forma exibiriam variações significativas.

106

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

A Figura 58 exemplifica o relacionamento dentro de uma organização entre as funções de negócio e os processos de negócio a partir das atividades organizacionais e atividades de processos.

act Business Process Model

Função de negócio

Atividade de negócio

Atividade componente do processo

Processo de negócio

Subprocesso componente de processo

Figura 58 – Função de negócio, processo de negócio e seus relacionamentos

Como exemplo da aplicação dessa definição, temos o fato de que a função contabilidade de uma empresa define o contador, a função gerencial define o gerente e assim por diante.

Funções de negócio são também alocadas a unidades ou áreas organizacionais específicas (que exercerão os diferentes papéis) e são envolvidas e acionadas no decorrer do “comportamento” do negócio.

A Figura 58 mostra que uma função corresponde a uma série de atividades relacionadas, envolvendo uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da missão da empresa.

As atividades de negócio que compõem uma função de negócio são relacionadas entre si por “afinidade”, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque são sequenciais ou paralelas na realização do trabalho associado a um resultado final comum.

Observação

A arquitetura de negócio busca uma visão conceitual e única de uma atividade ou funcionalidade, de forma que se possa identificar quando e como ela se repete nos diversos processos de negócio, a fim de determinar

107

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


a generalização dos conceitos de tarefas comuns, identificando atividades compartilhadas e administrando seu reuso por meio da distribuição dos componentes que as suportam.

Da mesma forma, os sistemas de informação que suportam tais funções estarão focados em aspectos específicos do funcionamento do negócio, independentemente da forma como a empresa está organizada.

As atividades são direcionadas a dados e são “iniciadas” por transações ou solicitações de dados. Elas são a porção ativa das funções e tendem a ser repetitivas e formalizadas.

Observação

É importante notar:

• Uma maneira de se diferenciar o conceito de funções e atividades é que, geralmente, as funções são gerenciadas e atividades são realizadas.

• Funções são gerenciais e atividades são operacionais.

Já um processo de negócio é definido como a sequência completa de um comportamento de negócio, provocado por algum evento, que produz um resultado significativo para o negócio e que, de preferência, tenha foco no cliente.

No percurso do processo, desde o evento inicial até a produção de um determinado resultado, várias funções do negócio podem estar envolvidas. Assim, diz-se que os processos são elementos transfuncionais, já que perpassam diversas funções dentro da organização.

Se uma função é composta de atividades que representam um papel ou razão de existir da organização, os processos de negócio “executam” essas atividades de forma que, individualmente ou combinadas, realizem o trabalho de uma determinada função.

Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema

Antes de entrarmos em duas notações de modelagem de processos seria interessante analisarmos os resultados obtidos com a aplicação da modelagem apresentada no artigo Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges e Wolber Neves, apresentado no VI Simpósio Internacional de Melhoria de Processos de Software, em São Paulo, em 2004.

108

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

No item resultados obtidos, os autores afirmam:

A aplicação da modelagem de processos de negócio trouxe resultados bastante positivos. A execução dessa etapa antes da realização do levantamento dos requisitos do sistema foi um fator de redução de riscos, tanto para o cliente quanto para o fornecedor.

O cliente pôde ter uma visão melhor do seu negócio, identificando as áreas que realmente seriam beneficiadas pela construção do sistema, evitando assim o desperdício de recursos.

Foi interessante observar que, durante as oficinas, o cliente pôde perceber que determinados processos não estavam sendo executados da melhor forma. Diante desta percepção, alguns processos foram remodelados, evitando que o sistema fosse construído sobre uma base operacional deficiente.

Para o fornecedor, a execução da modelagem de processos de negócio resultou em maior facilidade na gestão dos requisitos do sistema. Muitas das constantes mudanças que ocorrem durante o desenvolvimento de um sistema decorrem da inexistência de um consenso entre os representantes do cliente sobre a melhor forma de se executar um processo.

A modelagem de processos de negócio fez com que esse consenso fosse alcançado antes do início do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente.

A identificação dos casos de uso do sistema (UML) também foi bastante facilitada. Como passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam ser mais proativos nessa atividade, contribuindo com sugestões e ponderações baseadas em conhecimento mais sólido.

Esta proatividade mostrou-se especialmente útil nas primeiras oficinas, já que naquele momento os representantes do cliente ainda não estavam totalmente seguros com a metodologia de levantamento dos requisitos.

Outro benefício trazido pela modelagem de processos de negócio diz respeito à rastreabilidade dos requisitos. Uma característica de qualidade importante para uma especificação de requisitos é a facilidade em se determinar os resultados do desenvolvimento que serão afetados por cada requisito (rastreabilidade para frente), bem como a origem de cada um (rastreabilidade para trás).

Como os requisitos foram derivados diretamente do modelo de processos de negócio, a rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo de negócio que o gerou.

Um ponto importante no desenvolvimento de um sistema, especialmente quando seu porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal de se

109

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte são entregues em menor tempo do que um único módulo que contemple todas as funções.

Isto é importante tanto do ponto de vista técnico quanto do de negócio, já que muitas vezes o cliente não dispõe de recursos para construir todo o sistema de uma só vez, e a priorização de requisitos dentro de um módulo único não é uma tarefa simples.

Esse foi também um ponto em que a modelagem de processos de negócio foi benéfica. Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria composto por três produtos. Após a modelagem, percebeu-se que o número de produtos era realmente três, mas a composição dos mesmos foi bastante modificada. Dois dos produtos foram agrupados em um único, e um produto de controle de fluxo de trabalho (workflow) foi identificado.

Apenas um produto permaneceu conforme tinha sido concebido no início. A divisão inicial dos produtos espelhava a divisão funcional da empresa, o que não se mostrou uma boa idéia do ponto de vista de sistemas. A modelagem de processos de negócio fez com que cliente e fornecedor percebessem que duas das áreas eram muito integradas, o que justificaria um único produto para atendê-las.

Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as áreas funcionais, o que justificaria um produto genérico para este fim, e não a inserção de funcionalidades correlatas em um dos produtos específicos para determinada área.

Após a divisão dos produtos, um deles foi escolhido para ser especificado e construído. Seria necessário, portanto, realizar uma estimativa do tamanho do produto em pontos de função, para orçar-se a fase de elaboração. O melhor conhecimento da organização, conseguido por meio da modelagem de processos de negócio, também foi fundamental para que essa estimativa fosse bem próxima da contagem oficial de pontos de função, realizada alguns meses depois (após o fim da elaboração).

Percebeu-se inclusive que a aproximação do número real foi maior do que em projetos em que a modelagem de processos de negócio não foi usada.

Como último resultado importante, podemos citar o artefato resultante da modelagem de processos de negócio. Esse documento é importante para o cliente, já que é a documentação dos processos da organização. Mas também do ponto de vista do fornecedor o documento foi de grande utilidade, pois serviu para dar uma visão geral às pessoas que entravam no projeto depois de seu início. Foi uma forma simples e barata de integrar novas pessoas à equipe.

Adaptado de: <www.simpros.com.br>. Acesso em: 13 jul. 2012.

110

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

7.2.2 Extensão de negócio da UML

Segundo Paul e Serrano (2003), o estudo sobre processo de negócio não deve ser isolado, sendo importante seu relacionamento com a área de TI, pois ela é considerada sua grande modificadora.

O processo de negócio geralmente confia no suporte fornecido pelos Sistemas de Informação (SI) para a realização de suas atividades.

Similarmente, esses sistemas dependem da infraestrutura de comunicação, normalmente oferecido por rede de computadores (RC).

A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informação e redes de computadores, no qual mudanças ocorridas em alguns dos domínios devem afetar os demais.

Processo1 Processo2

SI1

TIRC1 RCn

SI2 SIn

Processon

...

Figura 59 – Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC)

De acordo com Dalal et al (2004), muitas técnicas para modelagem dos processos empresariais, incluindo DFDs (Diagramas de Fluxo de Dados), Idef0 (Definições Integradas para Modelagem por Funções, em nível 0) e diagramas de casos de uso de negócio, têm suas raízes nos processos de desenvolvimento de software.

De acordo com as orientações da UML 2.0 Superstructure Specification, disponibilizada a partir de outubro de 2004 pela OMG, os casos de uso são meios de especificar os requisitos de um sistema de informação.

Todavia, quando casos de uso documentam processos de negócio de uma organização, o Sistema sob Discussão (SsD), do inglês System under Discussion (SuD), é a própria organização.

Os stakeholders ou atores de negócio são os acionistas da companhia, clientes, vendedores e as agências governamentais regulamentadoras. Os atores primários incluem os clientes da companhia e talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele não faz reEngenharia, ou seu projeto novamente (COCKBURN, 2005).

Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um conjunto de sequências de ações, incluindo variantes realizadas pelo sistema para produzir um resultado observável do valor de um ator.

111

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Além disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado. Também fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas do domínio e servem para ajudar a validar a arquitetura e para verificar o sistema à medida que ele evolui durante seu desenvolvimento (BOOCH et al, 2000).

Quando utilizados para representar processos de uma organização, os casos de uso são identificados como casos de uso de negócio.

Em outras palavras, um caso de uso de negócio representa o que a organização faz (BOGGS e BOGGS, 2002). O escopo de um caso de uso pode abranger uma escala de assuntos:

• Uma empresa ou uma linha de negócio: este nível de modelo é utilizado para descrever como os sistemas se integram.

• Um sistema individual: este é o nível mais utilizado na abordagem por casos de uso.

• Um simples subsistema simples ou componente: este nível descreve os mecanismos de implementação de um elemento do modelo.

• Para descrever um processo de trabalho de um negócio.

• Para focar discussão sobre futuros requisitos de software.

• Para ser os requisitos funcionais de um sistema.

• Para documentar o projeto do sistema.

• Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribuído.

O modelo de casos de uso de negócio é um modelo das funções pretendidas do negócio. É usado como base para identificar papéis e produtos liberados na organização.

Os casos de uso de negócios são identificados e possivelmente resumidos no início da fase de iniciação, para ajudar a definir o escopo do projeto (RUP, 2001).

Quadro 8 – Propriedades de um caso de uso de negócio

Nome da propriedade Descrição

Nome O nome do caso de uso de negócio.

Breve descrição Uma breve descrição do papel e da finalidade do caso de uso de negócios.

Metas Uma especificação das metas ou objetivos mensuráveis do caso de uso de negócios.

Metas de desempenho Uma especificação das métricas relevantes ao caso de uso de negócios e uma definição das metas de utilização dessas métricas.

112

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Fluxo de trabalho

Uma descrição textual do fluxo de trabalho representado pelo caso de uso de negócios. O fluxo deve descrever o que o negócio faz para oferecer vantagens a um ator de negócio, e não como esse negócio resolve os problemas. A descrição deve ser compreensível para qualquer pessoa dentro do negócio.

Categoria Se o caso de uso de negócios pertence à categoria central, suporte ou gerenciamento.

Risco Uma especificação dos riscos de executar e/ou implementar o caso de uso de negócios.

Possibilidades Uma descrição do potencial de melhoria estimado do caso de uso de negócios.

Proprietário do processo Uma definição de quem é o proprietário do processo de negócios: a pessoa que gerencia e planeja as mudanças.

Requisitos especiais As características do caso de uso de negócio não cobertas pelo fluxo de trabalho conforme descrito.

Pontos de extensãoUma lista dos locais dentro do fluxo de eventos do caso de uso de negócios em que um comportamento adicional pode ser inserido por meio do relacionamento de extensão.

Relacionamentos Os relacionamentos (como associações de comunicação, relacionamentos de inclusão e de extensão) dos quais o caso de uso participa.

Diagramas de atividades Esses diagramas mostram a estrutura do fluxo de trabalho.

Diagramas de casos de uso Esses diagramas mostram os relacionamentos que envolvem o caso de uso.

Ilustrações do fluxo de trabalho Resultados ou esboços manuscritos provenientes das sessões de encenação.

Adaptado de: RUP, 2001.

De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negócio podem ser demonstrados conforme o quadro 9.

Quadro 9 – Componentes do diagrama de caso de uso de negócio

Nome Notação Descrição

Ator de negócioUm ator de negócio representa um papel desempenhado em relação ao negócio por alguém ou algo no ambiente do negócio.

Caso de uso de negócio

Um caso de uso de negócios define uma instância de negócio, no qual cada instância é uma sequência de ações realizada por um negócio que produz um resultado de valor observável para um determinado ator de negócio.

Modelo de caso de uso de negócio

O modelo de casos de uso de negócios é um modelo das funções pretendidas do negócio. É usado como base para identificar papéis e produtos liberados na organização.

113

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Generalização de ator

Um relacionamento de generalização de uma classe de ator de negócio (descendente) com outra classe de ator de negócios (ascendente) indica que o descendente herda o papel que o ascendente pode assumir em um caso de uso de negócios.

Associação de comunicação

Uma associação de comunicação entre um caso de uso e um ator indica que uma instância do caso de uso e uma instância do ator irão interagir.

Relacionamento de extensão “extensão”

Um relacionamento de extensão é aquele que se estabelece entre um caso de uso de extensão e um caso de uso base, especificando como o comportamento definido para o caso de uso de extensão pode ser inserido no comportamento definido para o caso de uso de base. Ele é inserido implicitamente, ou seja, a extensão não é exibida no caso de uso base.

Relacionamento de inclusão “inclusão”

Um relacionamento de inclusão é aquele que se estabelece entre um caso de uso base e um caso de uso de inclusão, especificando como o comportamento definido para o caso de uso de inclusão é inserido de forma explícita no comportamento definido para o caso de uso base.

Generalização de casos de uso

Uma generalização de casos de uso é um relacionamento de um caso de uso filho com um caso de uso pai, especificando como um filho pode adotar todo o comportamento e as características descritas para o pai.

Diagrama de casos de usoUm diagrama de casos de uso mostra os atores de negócios, os casos de uso de negócios, os pacotes de casos de uso e seus relacionamentos.

De acordo com o RUP (2001), a projeção realizada pela Engenharia de negócio é fundamental para a realização do sistema.

As atividades do negócio e os relacionamentos identificados entre elas, bem como a atuação dos envolvidos, determinarão os objetivos a serem alcançados pelo software a ser desenvolvido.

A Figura 60 apresenta uma conexão entre essas duas áreas.

Proposta para informatização

Proposta de software

Engenharia de software

Engenharia de processo de negócio

Modelo de negócio

Figura 60 – O relacionamento entre Engenharia de processo de negócio e Engenharia de software

114

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

7.2.3 Visões de modelos de negócio

O modelo de negócios é a forma pela qual uma empresa cria valor para todos os seus principais públicos de interesse.

Sua utilização ajuda a ver de forma estruturada e unificada os diversos elementos que compõem todas as formas de negócios da organização.

O modelo de negócio de uma empresa é composto por 5 principais elementos:

• Modelo de proposta de valor: é a forma pela qual a empresa define qual é o seu diferencial no mercado, a forma pela qual é única e se destaca de todas as demais empresas que participam desse mesmo mercado.

• Modelo de interface com o consumidor: é o que escreve onde, quando e como uma empresa interage com os seus consumidores. Essa interação pode se dar por meio de lojas, embalagens de produtos, comerciais, SAC, website etc.

• Modelo de operação: é como que uma empresa faz para levar o seu produto até o seu consumidor. Esse modelo deve prever todos as etapas necessária para viabilizar sua produção, passando por logística, até chegar às mãos de quem compra o seu produto ou serviço.

• Modelo estratégico: é a descrição de como uma empresa irá atingir os seus objetivos estratégicos. Nesse modelo é onde visualiza-se a missão de uma empresa, sua visão, seus valores e todas as competências necessárias para que a empresa funcione de forma adequada.

• Modelo econômico: é onde se demonstra a viabilidade financeira de uma empresa. Esse modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a sustentabilidade.

7.3 OCL e sua utilização na modelagem de processo de negócio

A OCL (Object Constraint Language) é uma notação que permite se dar mais precisão nas especificações ou modelos que usam a UML.

Lembrete

A OCL é baseada na lógica e matemática discreta. Assim como a UML, é uma linguagem de modelagem e não uma linguagem de programação. É uma linguagem de modelos tipada. Inicialmente, a OCL era uma extensão para a UML, agora é parte da UML padrão.

115

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Por que a OCL?

• Um diagrama UML, tal como o diagrama de classes, é tipicamente não refinado o suficiente para permitir-se ter todos os aspectos relevantes de uma especificação.

• Há a necessidade de se descrever restrições adicionais sobre os objetos de um modelo.

• A linguagem natural é inerentemente ambígua.

• Linguagens formais tradicionais são dificíeis para usuários de negócio ou modeladores de sistemas.

• A OCL é uma linguagem formal que permanece simples para ler e escrever.

Quando se deve usar a OCL?

• A linguagem OCL é usada para expressar condições constantes de restrições de especificações para sistemas que estão sendo modelados.

• Para especificar invariantes nas classes e tipos no modelo de classes.

• Para especificar tipos invariantes para estereótipos.

• Para descrever pré e pós-condições nas operações e métodos.

• Para especificar restrições nas operações.

A OCL é suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10.

Quadro 10 – Diagramas com suporte OCL

Tipo de diagrama Versão da UML Como o suporte é provido

Use case (caso de uso) UML 2.0

Restrições para o comportamento associado com os casos de uso como expressões OCL. Por exemplo, uma interação escolhida como um comportamento.

Classes (classe, namespace e comunicação) UML 1.5 e 2.0 Restrições na criação de objetos são

suportadas.

Interação (sequência e comunicação) UML 2.0Restrições de invariância de estado para linhas de vida e restrições dos operandos de fragmentos combinados como expressões OCL.

Máquina de estado UML 2.0 Condições de guarda de transições como expressões OCL.

Como os modelos de negócio são suportados pelos diagramas de casos de uso a OCL, esses apoiarão as restrições das pré e pós-condições para execução de um caso de uso de negócio.

116

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

7.4 Integração com o desenvolvimento de software

Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma série de fases, cada uma focando diferentes partes do negócio ou sistema. Existem duas abordagens para a modelagem de negócio em um ambiente iterativo:

• Primeiro, terminar toda a modelagem de negócio e, na sequência, iniciar as atividades iterativas (análise, design, codificação, teste e implantação).

• Alternativamente, pode-se incluir a modelagem de negócio nas iterações (BOGGS e BOGGS, 2002).

Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo “cascata”, a modelagem de negócio surge nas fases iniciais.

As razões pelas quais isso ocorre é que a modelagem de negócio determina o contexto para o projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negócio nos processos de desenvolvimento de software.

Modelagem de negócio

Análise

Implantação Design

Teste Implementação

Figura 61 – Processo iterativo após o surgimento da modelagem de negócio

Modelagem de negócio

Análise

Implantação Design

Teste Implementação

Figura 62 – Modelagem de negócio como fase integrante do processo iterativo

7.4.1 Processo de desenvolvimento de software

Existem inúmeros caminhos para reproduzir modelos de negócio dentro dos processos de desenvolvimento de software, incluindo o uso de outras notações tais como Idef0 (modelagem funcional), ou mesmo descrições textuais do processo.

117

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


No entanto, a UML é um padrão bem definido, suportado por muitas técnicas. É a linguagem de modelagem dominante, usada em sistemas de informação orientados a objeto.

A UML é na atualidade o padrão que possui a melhor definição, suportada por muitas ferramentas e, dessa forma, tornou-se a linguagem de modelagem dominante na aplicação da tecnologia da orientação a objetos.

Além disso, pode ser utilizada para a modelagem de negócio e também para a modelagem de outros sistemas, ou seja, para aqueles que não serão utilizados para o desenvolvimento de softwares (OMG, 2005).

Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negócio são: business use-case e business object model. Diagramas num modelo de negócio ajudarão a compreender o que a organização fornece de valor, dentro de um relacionamento.

Enquanto a maioria dos diagramas da UML foca no sistema que será construído, o modelo de casos de uso de negócio se concentra no negócio em torno desse sistema (BOGGS e BOGGS, 2002).

O modelo de caso de uso de negócio consiste na interação entre atores e casos de uso, para demonstrar a sequência de eventos necessários na realização de um trabalho.

Juntos, atores e casos de uso descrevem o que está envolvido nas atividades do negócio e também como ele ocorre (WIDRIG e LEFFINGWELL, 2003).

7.4.2 Arquitetura de negócio e arquitetura de software

Um dos principais esforços da investigação relacionada com a Engenharia de software tem sido a definição e representação de modelos que descrevam os processos de software, garantindo que esses correspondam fidedignamente às necessidades efetivas (em forma e conteúdo) dos processos de negócio.

Deparamo-nos então com duas realidades complementares: a modelagem dos processos de negócio e a modelagem do software, que também podem ser chamadas de arquitetura de negócio e arquitetura de software, na qual esta última tem cada vez mais a necessidade de estar em sintonia com toda a abrangência do negócio (RODRIGUES, 2004).

As modelagens de negócio e de sistema (software) são frequentemente desenvolvidas como parte de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definição, pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema (PENKER e ERIKSSON, 2000).

Rodrigues (2004), ao avaliar o contexto da modelagem de negócio para a modelagem de sistema, especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domínios seja estabelecida de forma suave e sem sobressaltos.

118

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

A Figura 63 mostra a integração proposta por Rodrigues (2004).

Modelagem do processo Modelagem de sistema

O que existe para fazer a ponte efetiva entre modelagem de negócio e sistema?

Figura 63 – Integração entre modelagem de negócio e sistema

No RUP (2001), a integração entre negócio e sistema tem início nas primeiras atividades da iteração do ciclo de desenvolvimento do sistema, definida como iniciação.

Nesse momento, a maior parte dos esforços, para as disciplinas Modelagem de Negócios e Requisitos, é utilizada com o propósito de obter as informações necessárias para a condução do projeto e elaboração do software.

A Figura 64 demonstra, no detalhe, o esforço necessário na fase inicial da iteração, a partir do desenho de visão geral do RUP.

Fases

Iniciação ElaboraçãoDisciplinas

Modelagem de negócios

Concentração de esforços nas fases iniciais.

Requisitos

Construção Transição

Figura 64 – O esforço da modelagem de negócios e requisitos

A Figura 64 mostra que as disciplinas de Modelagem de Negócios e Requisitos do Sistema são perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP.

Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia é o gerenciamento de processos de negócio ou business process management.

119

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Saiba mais

Vale a pena conferir o documento Business Process Management Enabled by SOA, da IBM de 2009, em que o gerenciamento de processos de negócio é mais frequentemente associado com o ciclo de vida de um de processos de negócios. O ciclo de vida de processo de negócio abrange identificar e melhorar os processos que proporcionam capacidade de negócios para implantar e gerenciar os seus processos quando estiver operacional.

O que é frequentemente esquecido é a gestão do desempenho do processo depois que é operacional. De certa forma, essa é provavelmente a fase mais importante do ciclo de vida de processos. Depois que um processo de negócio é implantado, ele deve ser gerenciado, e, para gerenciar o processo de negócio, deve-se ter visibilidade do desempenho de processos.

Quando um processo não atingir mais o seu desempenho de seus objetivos, é hora de voltar ao ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria adicionais.

Subjacente, BPM é também governança. Governança é um componente essencial de BPM porque fornece a estrutura que garante que a estratégia de negócios e metas sejam implementadas no nível operacional.

A estrutura de governança também permite negócio e alinhamento de TI, fornecendo mecanismos que aumentem a colaboração e cooperação entre os dois mundos, os processos de negócio e a tecnologia da informação.

8 A MODELAGEM DE pROCESSOS DE NEGÓCIO

8.1 Visão Erikson e penker

Antes que a OMG se preocupasse com a modelagem de negócios com a linguagem UML, os autores Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negócio, o qual apresenta:

• Uma visão de mais alto nível, visando identificar a situação do negócio que será abordada.

• Nessa visão, deve-se definir o contexto e o escopo, sendo que:

— o contexto é o que está relacionado, qual a situação, descrição do problema; e

— o escopo é até onde vai, contorno ou limite.

120

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

• Essa visão pode incluir FCSs (Fatores Críticos de Sucesso).

• As metas e objetivos (do original Goal) podem ser decompostos em diferentes níveis, como, estratégico/tático/operacional, sendo que:

— o objetivo é qualificável; e

— a meta é quantificável.

Nesse modelo, os processos de negócio:

• possuem uma meta;

• possuem entradas e saídas específicas;

• usam recursos;

• possuem um número de atividades, realizadas em alguma ordem, que podem ser vistas como subprocessos;

• afetam mais de uma unidade da organização;

• criam valor para algum consumidor (interno ou externo).

A figura 65 apresenta os elementos ou símbolos propostos para o modelo de Erikson e Penker.

<<processo>>

<<processo>> <<processo>> <<processo>>

Processo A

Subprocesso A1 Subprocesso A1 Subprocesso A1

Atividade A2a

Atividades podem ser entendidas como processos atômicos

Atividade A2b Atividade A2c

Figura 65 – Notação de Erikson e Penker para modelagem de negócio

121

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


As atividades ou processos atômicos são:

• Diretas: diretamente envolvidas na criação do produto ou serviço, que é o valor criado pelo processo.

• Indiretas: dá suporte às atividades diretas, como manutenção, administração etc.

• Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como inspeção, controle, revisão e validação.

A figura 66 ilustra os passos de um processo de negócio nesta notação.

<<processo>>

Processo contendo 3 subprocessos: dois atômicos e um composto

<<processo>>

Furação

Fazer furo

Calibrar Ligar furadeira

FurarLer instrução

Figura 66 – Passos de um processo

A figura 67 mostra um exemplo de um processo de negócio com recepção e emissão.

<<processo>>

Demanda do cliente por ação

Ordem de

compra

Ordem de

venda

Administração de compra de

ação

Administração de venda de

ação

Compra de ação no mercado

Venda de ação no mercado

<<processo>>

<<processo>>

Figura 67 – Processo de recepção e emissão

122

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Como novo exemplo, a figura 68 apresenta um modelo de processo de furação de chapas em uma indústria qualquer.

<<processo>>

<<achieve>>

<<information>>

instruções de fucação <<physical>>

chapa perfurada

<<physical>>chapa de aço

furação

<<goal>>chapas furadas por dia: Meta Quantitativa

Valor = 100

Figura 68 – Exemplo de um processo de furação de chapa

A notação de Erikson e Penker ainda hoje é utilizada, e algumas ferramentas Case, tal como a ferramenta EA, mantêm essa notação.

8.2 A modelagem de processos de negócio com a BpM

A notação BPMN surgiu como um padrão alternativo à UML, também sendo gráfica, porém seus símbolos são um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada especificamente para modelar processos de negócio. Essa notação não oferece qualquer suporte para modelar dados, atores, estados de ciclo de vida, ou sistemas.

Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativa oriunda da OMG que lançou a especificação 1.0 ao público em maio de 2004.

Tanto a UML como a BPMN são notações mantidas pela OMG.

Os objetivos do esforço do grupo que desenvolveu o BPMN são:

• Fornecer uma notação que seja fácil.

• Ser compreensível por todos os usuários de negócios.

• Envolver os analistas de negócio, os desenvolvedores, os técnicos responsáveis pela aplicação dos sistemas que irão executar os processos e as pessoas de negócios.

123

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado para a criação de modelos gráficos de tarefas dos processos de negócio.

Para a BPMN, um modelo de processo de negócios é uma rede de objetos gráficos, denominados de atividades, e do fluxo de controle, que define a ordem de execução.

As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vêm investindo em sistemas que automatizam a gestão de processos de negócio (execução, controle e monitoração). Esses sistemas são os denominados BPMS (Business Process Management Suite), que dão suporte ao mapeamento, execução, monitoração e controle dos processos de negócio de uma organização.

Tipicamente, inclui:

• o mapeamento dos processos de negócio ponta-a-ponta;

• desenho dos fluxos e formulários eletrônicos;

• definição de workflow;

• regras de negócio;

• integradores;

• monitoração em tempo real das atividades; e

• alertas.

É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização.

Os softwares utilizados na operacionalização e gerenciamento de processos de negócio são um dos principais facilitadores da gestão do conhecimento referente ao processo, sendo considerada a maior facilidade para obtenção, distribuição e análise dos dados.

Há algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares BPMS, que, quando disponíveis, aumentam a capacidade dos gestores e demais envolvidos com o processo em estabelecer uma troca de imagens e idéias, nos ambientes onde ocorre a geração do conhecimento.

Observação

A solução BPMS não propõe a substituição dos sistemas existentes na organização os conhecidos como “sistemas legados”, e sim disponibiliza um ambiente de integração de sistemas de informação, que permite definir:

124

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

• fluxo de execução;

• regras;

• eventos;

• demais especificações necessárias à operação e gerenciamento do processo de negócio.

Dessa forma, permite atender a outra característica do processo de negócio: a de ser extremamente dinâmico, permitindo, por exemplo, uma substituição rápida e simples de um software por outro, necessária quando uma empresa parceira da organização é substituída, demandando a integração com um novo software disponível no ambiente computacional do novo parceiro.

De acordo com vários autores, um BPMS completo teria os seguintes módulos ou funcionalidades:

• Funcionalidades mínimas para uma solução poder se classificar como BPMS:

— ferramenta de modelagem e desenho do processo;

— engenho de execução do processo;

— orquestração de web services;

— interface de workflow para usuários.

• Para ter um produto mais completo, seria necessário:

— suporte para regras de negócio complexas;

— Business Activity Monitoring (BAM);

— controle de versão dos documentos anexados a instâncias do processo.

• E para um produto completo, seria acrescentado de:

— Enterprise Service Bus (ESB);

— Repositório de metadados;

— Uma suite de business intelligence.

125

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Um BPD é formado por um conjunto de quatro elementos gráficos, que são:

• objetos de fluxo;

• objetos de conexão;

• raias (swimlanes); e

• artefatos.

8.2.1 Objetos de fluxo

Um BPD apresenta três objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo são os principais elementos gráficos para definir o comportamento de um processo de negócio.

8.2.1.1 Evento

Um evento é algo que “acontece” no decurso de um processo de negócio. Esses eventos afetam o fluxo do processo e normalmente têm uma causa (trigger) ou um impacto (resultado).

Somente os eventos têm a capacidade de iniciar ou terminar um processo, porém não executam tarefas nesse. Os eventos ainda podem forçar a execução ou desviar para uma determinada atividade.

Há três tipos de eventos, com base em quando eles afetam o fluxo: evento de início, evento intermediário e evento de fim, com notação apresentada na figura 69.

BPMN BPMN

Evento início

Evento intermediário

Evento fim

Figura 69 – Símbolos de eventos da BPMN

126

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

O evento início define a inicialização em um processo. O evento intermediário define um evento intermediário em um processo. Já o evento fim define o término de um evento em um processo.

Um processo pode ser iniciado por diferentes circunstâncias. Essas circunstâncias são chamadas de gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador.

8.2.1.2 Atividade

Uma atividade organiza e especifica participação de comportamentos subordinados, tais como, as sub-atividades ou ações, para refletir o controle e o fluxo de dados de um processo.

As atividades são usadas nos diagramas de atividades para vários propósitos de modelagem: para a modelagem do desenvolvimento de uma aplicação típica, para modelagem de um processo de negócio ou para modelar um workflow.

Durante a criação, ou em edições mais tarde, uma atividade pode ser definida como um elemento composto. Contudo, quando se cria uma atividade composta, é possível usar também o elemento atividade estruturada, que foi criada para esse propósito.

A especificação da OMG UML1 estabelece:

• Uma atividade específica à coordenação da execução de comportamentos subordinados, usando um controle e modelo de fluxo de dados.

• Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque outros comportamentos no modelo irão concluir a execução, ou porque os objetos e os dados ficam disponíveis, ou porque ocorrem eventos externos para o fluxo.

• O fluxo de execução é modelado como atividades, os nós são ligados por arestas. Um nó pode ser a execução de um comportamento do subordinado, como um cálculo aritmético, uma chamada para uma operação, ou a manipulação do conteúdo do objeto.

• Atividades podem formar hierarquias invocando outras atividades, em última análise, para resolver as ações individuais. Em um modelo orientado a objetos, as atividades são geralmente chamadas indiretamente de métodos vinculados às operações que estejam diretamente invocadas.

• As atividades podem descrever processos de computação. Nesse contexto, são os métodos correspondentes às operações nas classes. As atividades podem ser aplicadas à modelagem organizacional para a Engenharia de processos de negócio e workflow.

• Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de uma tarefa, mas também de fora do sistema, como uma chamada de cliente.

1 UML Superestrutura Especificação, versão 2.1.1, p. 318.

127

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


• As atividades também podem ser utilizadas para a modelagem de sistema de informação, para especificar os processos ao nível do sistema. As atividades podem incluir ações de vários tipos (funções primitivas, operações aritméticas etc.).

Uma atividade é representada por um retângulo de bordas arredondadas e é um termo genérico para o trabalho que a empresa realiza. Uma atividade pode ser atômica (tarefa) ou não atômica (composta – subprocesso).

analysis Diagrama Estrutura de Versão

Atividade Sub_processo

+

Figura 70 – Atividade atômica e não atômica

8.2.1.3 Gateway

Utilizado para controlar a divergência e convergência da sequência de fluxos, determina as decisões tradicionais de bifurcação, fusão e união de caminhos. Marcadores internos indicam o tipo de controle do comportamento.

analysis Diagrama Estrutura de Versão

Figura 71 – Elemento gateway

Gateways são os mecanismos padronizados na notação BPMN para desvios. Eles controlam como o processo diverge ou converge, ou seja, representam pontos de controle para caminhos dentro do processo. Eles separam e juntam o fluxo de um processo por meio do fluxo de sequência.

8.2.2 Objetos de conexão

Os objetos de fluxo são conectados ao diagrama pelos objetos de conexão, para criar o esqueleto estrutural básico de um processo de negócio.

Um BPD tem três objetos de conexão: fluxo de sequência, fluxo de mensagem e associação.

128

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

8.2.2.1 Fluxo de sequência

Um fluxo de sequência é usado para mostrar a ordem (sequência) que as atividades são realizadas em um processo.

A figura 72 mostra um exemplo de fluxo de sequência.

BPMN BPMN

Atividade 1Fluxo de sequência

Atividade 2

Figura 72 – Fluxo de sequência

8.2.2.2 Fluxo de mensagem

Um fluxo de mensagem é usado para mostrar mensagens entre dois participantes do processo (entidades empresariais ou papéis de negócio) que enviam e recebem mensagens.

BPMN BPMN

Atividade 1Fluxo de mensagem

Atividade 2

Figura 73 – Fluxo de mensagem

8.2.2.3 Associação

Uma associação é usada para associar dados, textos e outros artefatos com os objetos de fluxo. Associações são utilizadas para mostrar as entradas e saídas de atividades.

analysis Diagrama Visão Estrutura de Versão

Activity2

Documento

IntermediateEvent3

Figura 74 – Associação

129

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


A figura 75 mostra um exemplo de um pedaço de um processo utilizando os elementos apresentados.

StartEvent

YES

Repeat for Each Supplier

EndEvent

No

class BPMN

Limite do tempo excedeu

Marca que mostra que o subprocesso tem loop

Evento intermediário para um time out

Send RFQ Receive Quote

Add Quote

Figura 75 – Exemplo de um processo

8.2.3 Raias (Swimlanes)

Swimlanes é um mecanismo para organizar atividades em categorias visuais separadas, que organizam as diversas capacidades ou responsabilidades. Os objetos swimlanes do BPD são:

• Pool;

• Lane.

Swinlanes ou raias ajudam a dividir e organizar atividades em diferentes categorias visuais em um diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades.

Pools são utilizados quando o diagrama envolve duas entidades empresariais e são separados fisicamente no diagrama. As atividades dentro de grupos separados são consideradas processos autocontidos.

Os fluxos de sequência não podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem como mecanismo para mostrar a comunicação entre dois participantes em pools diferentes.

8.2.3.1 Pool

Pool representa um participante em um processo (pessoa, área, empresa, outro processo etc.). Atua como um container gráfico para o particionamento de um conjunto de atividades de um ou mais processos de um participante.

130

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

class BPMN

<<Po

ol>>

Clie

nte

Figura 76 – Exemplo de um diagrama com pool

8.2.3.2 Lane

Lane é uma subpartição dentro de um pool que vai se estender a todo comprimento do pool, tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar atividades.

As lanes são elementos que são posicionados dentro de pools para indicar mais de um perfil que colaboram para a execução de um processo. Lanes criam subpartições para os objetos dentro de um pool. Essas participações são usadas para agrupar elementos do processo.

São frequentemente usadas para separar as atividades associadas com uma função ou papel de uma determinada empresa. Os fluxos de sequência podem atravessar as fronteiras das lanes dentro de um pool.

O fluxo de mensagem não pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.

class BPMN

<<Po

ol>>

HELP

DESK

Clie

nte

CAC

Figura 77 – Uma pool com duas lanes

A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma lane cada.

131

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


class BPMN

<<Po

ol>>

<<Po

ol>>

PACI

ENTE

Cons

ultó

rio M

édic

o

Ocorre doença

Envia pedido médico

Envia pedido médico

Recebe pedido

sintomas

Recebe pedido

sintomas

Envia sintomas

Envia sintomas

Recebe receita

Recebe receita

Eu quero ver o médico

O médico pede sintomas

Eu me sinto doente

Pegue sua receita para comprar os

remédios

Figura 78 – Exemplo de pools e lanes juntas

8.2.4 Artefatos

A notação BPMN permite aos modeladores o uso de extensões de notação. Um número qualquer de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de negócio sendo modelado.

A versão corrente do BPMN predefine três tipos de artefatos BPD:

• objeto de dados;

• grupo; e

• anotação.

Os modeladores podem criar seus próprios tipos de artefatos, que podem adicionar mais detalhes sobre como o processo é executado.

A figura 79 mostra um diagrama com lanes dentro de uma pool e com adicionamento de artefatos.

132

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

<<Group>>Informações pagamento

E-mail requisição aprovação

class BPMN

Adm

inist

raçã

oW

eb S

ervi

ceGe

renc

iam

ento

Prepara ordem de pagamento

+

Aprova requisição

Despacha para aprovação

Estas atividades podem ser iniciadas ao mesmo tempo

Figura 79 – Uso de artefatos no BPD

8.2.4.1 Objeto de dados

São mecanismos para mostrar que dados são requeridos ou produzidos pelas atividades. São conectados às atividades a partir das associações.

BPMN BPMN

Objetos de dados

Anotações

<<Group>>Grupos

Figura 80 – Artefatos do BPD

8.2.4.2 Grupo

Um grupo pode ser usado para documentação, mas não afeta o fluxo de mensagens.

8.2.4.3 Anotação

É um mecanismo para um modelador colocar textos de informações adicionais no diagrama.

133

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


8.3 Conclusão do BpMN

Um objetivo-chave da BPMN foi criar uma ponte entre a notação da modelagem de processos de negócios e a modelagem de linguagens orientadas para TI, que irá implementar os processos dentro de um sistema de gestão de processos de negócios.

Observação

Os objetos gráficos da BPMN, apoiados por um rico conjunto de atributos de objeto, foram mapeados para o Business Process Execution Language for Web Services (BPEL4WS v 1.1), o padrão de fato para a execução do processo.

Resumo

Esta unidade mostrou os conceitos envolvidos com a modelagem de negócios que precede a modelagem de sistemas de informação.

Mostrou também que a UML propõe uma notação e um padrão de modelagem voltados para a especificação das regras de negócio de uma função e processo de negócio de uma organização. A OMG também vem propondo o uso da nova notação denominada BPMN, que está sendo preparada para novas ferramentas de automação de aplicações a partir dos modelos de negócio.

O uso dessa combinação tem como grande objetivo colocar a área de desenvolvimento de sistemas totalmente casada com ás áreas de negócio e construindo aplicações que agreguem valor ao negócio.

Com relação às organizações, elas estão descobrindo que a modelagem de processos de negócio pode ser uma excelente ferramenta para disseminar o conhecimento organizacional.

Uma vez que as organizações passam a compreendê-lo como um recurso, a modelagem de processos de negócio pode tornar-se uma excelente fonte para a vantagem competitiva.

Processos de negócio estruturados na cooperação, integração e no alinhamento entre todas as áreas organizacionais constituem o segredo de sucesso de uma organização.

Atualmente, o modelo de caso de uso de negócio pode ser aplicado nos modelos de desenvolvimento em cascata, na fase de levantamento

134

Unidade IV

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

de requisitos de negócio, e no modelo iterativo RUP, na fase de iniciação, também para modelagem dos requisitos de negócio que precedem as definições e especificações dos modelos dos sistemas de informação da organização.

Exercícios

Questão 1. Os autores definem que processos de negócio são um conjunto de atividades previamente estabelecidas cujo objetivo é determinar como o trabalho será realizado em uma organização por uma área de negócio. Diz-se que uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia da organização por meio dos produtos e serviços gerados e disponibilizados. Considerando os conceitos sobre processos de negócio, analise as afirmações a seguir e assinale a alternativa incorreta:

A) Uma função de negócio é a mesma coisa que um processo de negócio, já que ambos representam o conjunto de atividades de uma organização.

B) Processos de negócio são atividades transfuncionais previamente estabelecidas para tratar um determinado negócio da organização.

C) Um sistema de informação bem estruturado implementa processos de negócio de uma empresa ou organização.

D) Uma Função de Negócio representa a estrutura funcional da Organização, já que um “Processo de Negócio” é um conjunto de atividades ou ações que são transfuncionais, isto é, atravessam diversas áreas ou funções de negócio.

E) Os processos de negócio devem funcionar de forma alinhada em relação a toda a estrutura organizacional, pois somente dessa forma será possível atingir os objetivos transversais de qualquer organização.

Resposta: Alternativa A.

Alguns autores definem processo de negócio ou processo organizacional como sendo um conjunto de atividades. Nesse conjunto, uma organização deve ser estruturada com o objetivo de produzir valor para os seus clientes.

Análise das alternativas

A) Incorreta. Função de negócio é uma representação de uma estrutura dentro de uma organização. Por exemplo: o departamento financeiro é uma função de negócio; já um sistema financeiro (processo de negócio financeiro), atua em diversas áreas da empresa. Quando se mapeia o processo de negócio financeiro, torna-se necessário entender diversas áreas ou

135

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


funções da empresa, que, de alguma forma, utilizam ou precisam tratar com as informações financeiras da empresa.

B) Correta. Os processos de negócio estão diretamente ligados aos negócios da empresa e independem da estrutura organizacional. Normalmente atravessam as fronteiras das funções de negócio.

C) Correta. Um sistema de informação automatiza atividades dos processos de negócio, e, se ficarem estritamente ligados a uma função da empresa, não serão eficazes na busca de valor para a instituição.

D) Correta. uma função de negócio representa uma estrutura funcional de uma empresa, por exemplo: área de TI, área de Logística etc. E um processo de negócio seria a venda de carros de luxo de uma montadora de veículos.

E) Correta. A venda de carros de luxo de uma montadora possuirá atividades espalhadas por toda a estrutura de uma montadora: área de marketing, design de veículos, linha de produção, e assim por diante.

Questão 2. Na atualidade, com propósito de se ter sistemas de informações abrangentes e que agreguem valor ao negócio de uma organização, evolue-se para duas visões complementares: a modelagem de negócio e a modelagem de sistemas de informação. Normalmente, as modelagens de negócio e de sistemas (software) são desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A modelagem de negócios trata todas as atividades envolvidas com o negócio, e a modelagem de sistemas verifica o aspecto de automação a partir do modelo de negócio. Ambas devem possuir boa definição, pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema. Considerando os conceitos sobre Arquitetura de negócio, Arquitetura de Software e exemplos apresentados nesta unidade, analise as afirmações a seguir e assinale a alternativa incorreta:

A) Para a modelagem de negócio, utiliza-se a notação BPMN, a qual surgiu como um padrão alternativo à UML, já que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software.

B) A modelagem de negócio com BPMN é gráfica, porém, para representar as atividades existentes nos processos de negócio, seus símbolos são um pouco diferentes da UML.

C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991.

D) Pode-se afirmar que o processo de modelagem de negócios “é um conjunto estruturado de atividades, desenhado para produzir um resultado específico para um cliente ou um mercado em particular”.

E) A modelagem de negócio leva em consideração que um processo é “uma ordenação específica de atividades de trabalho, por meio do tempo e do espaço, com começo, fim e entradas e saídas claramente identificadas: é uma estrutura para ação”.

Resolução desta questão na plataforma.

136

FIGURAS e ILUSTRAçõeS

Figura 2

Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998.

Figura 3

Exemplo de uma aplicação da AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998.

Figura 57

Processos de negócio. Disponível em: <http://www.trainning.com.br/analistadenegocios_bpm_artigo.asp>. Acesso em: 14 mai. 2012.

Figura 59

Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC). PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.

Figura 60

O relacionamento entre Engenharia de processo de negócio e Engenharia de software. RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.

Figuras 61 e 62

Processo iterativo após o surgimento da modelagem de negócio e Modelagem de negócio como fase integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.

Figura 63

Integração entre modelagem de negócio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de penker e eriksson para casos de uso. Portugal. 2004.

Figura 64

O esforço da modelagem de negócios e requisitos. RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.

137

ReFeRêNCIAS

BRANCO, I. V. C. Modelagem de processos organizacionais integrada às aplicações práticas de aprendizagem organizacional e compeências conversacionais. Dissertação de Mestrado da UCB, Brasilia, Brasil, 2007.

BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – guia do usuário. Rio de Janeiro: Editora Campus, 2000.

COCKBURN, A. Escrevendo casos de uso eficazes – um guia prático para desenvolvedores de software. Tradução de Roberto Vedoato. 1ª ed. Porto Alegre: Bookman, 2005.

DALAL, N. et al. Toward an integrated framework for modeling enterprise processes. Communications of the ACM, v. 47, nº 3, 2004.

ERIKSON, H.; PENKER, M. Business modeling with UML: business patterns at work. John Wiley & Sons, 2000.

HUCKVALE, T.; OULD, M. Process modeling: why, what and how., New York, EUA: Jonh Wiley, 1993.

FURLAN, J. D. Modelagem de objetos através da UML, São Paulo: Makron Books, 1998.

JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianápolis, EUA: Addison Wesley, 1999.

JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language – user guide. Massachusetts, EUA: Addison Wesley, 1999.

LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. Rio de Janeiro: LTC, 2001.

MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004.

OMG. Object management Group. Disponível em: <http://www.uml.org/>. Acesso em: 17 ago. 2005.

PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.

PFLEEGER, S. L. Engenharia de software – teoria e prática. São Paulo: Prentice hall, 2004.

RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Editora Campus, 1994.

REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books, 2000.

138

RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de Penker e Eriksson para casos de uso. Portugal, 2004.

RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.

SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo: Best Seller, 1990.

SZILAGYI, D. C. Modelagem de processos de negócio – um comparativo entre BPML e UML. Dissertação de Mestrado da Pontifícia Universidade Católica – São Paulo, 2010.

YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998.

WIDRIG, D.; LEFFINGWELL, D. Managing software requirements: a use case approach. 2ª ed. Addison Wesley, 2003.

Informações:www.sepi.unip.br ou 0800 010 9000

modelagem de processos unidade iv

Documents