BPM Beyond Process Modelling

Transcrição

1

2 Introdução 1.1.Contextualização A partir dos anos 90 as empresas passaram a estruturar-se através da gestão por processos, buscando uma maior integração e eficiência de suas operações. A gestão por processos está calcada em modelos de processos e notações de processos. O primeiro representa a um conjunto de atividades que expressa um processo na empresa e o segundo seria a regra para a representação dessas das atividades no processo. Assim sendo, algumas empresas começaram a enxergar essa iniciativa de gestão por processo com uma boa oportunidade de mercado e começaram a prestar serviços em Business Process Management e softwares, criando seus próprios padrões de modelagem. Em conseqüência disso, o mercado passou a apresentar uma série de notações para modelagem, mas que representavam um grande problema para as organizações, já que não apresentavam uma linguagem comum na modelagem de seus processos. Este fato acabava por criar uma série de ruídos ao tentar integrar processos modelados em linguagens diferentes, já que notações diferentes dificultam a comparabilidade entre processos, além de inibir a utilização de modelos de referencia e benchmarking na melhoria dos processos. O interesse atual na abordagem de notações e modelagem de processos fez com que inúmeras expectativas surgissem no mercado. Quer se trate de Business Process Reengineering (BPR), Business Process Management (BPM), Activity Based Costing (ABC), ou Business Activity Monitoring (BAM), a notação de processos e a sua modelagem participam cada uma destas abordagens. A chegada de padrões de modelagem já está resultando na racionalização de processos, criando uma base de conhecimentos que pode ser partilhada pelos players no mercado.

3 Dado esse cenário, começaram a surgir alguns grupos na tentativa de unificar as notações existentes. Em junho de 2005 foi criado o Business Modeling & Integration (BMI), Domain Task Force (DTF), através da fusão entre o Business Process Management Initiative (BPMI.org) e o Object Management Group (OMG ). Com essa união, alguns padrões de modelagem foram criados, sendo o Business Process Management Notation (BPMN) um dos mais importantes. 1.2.Definições Abaixo seguem algumas definições que serão utilizadas no decorrer desse wiki. Tabela 1 Definições (FONTE: ELO Group) Conceito Definição Exemplo Business Process Modeling (BPM) Modelo BPM é uma abordagem utilizada para identificar, desenhar, documentar, mensurar, monitorar e controlar tanto processo de negócios automatizados quanto não-automatizados com o objetivo de alcançar resultados que estejam alinhados com as metas estratégicas da organização. ABPMP CBOK Um modelo pode ser entendido como uma representação explícita e externa de parte da realidade vista por pessoas que desejam usar o modelo para: entender, mudar, gerenciar e controlar esta parte da realidade de alguma forma. Pidd (1999). Não aplicável Desenho com a representação de uma rede hidráulica de uma casa Modelo de Processo Modelo de processo é um conjunto de atividades envolvidas na criação de representações de um processo novo ou de um já existente. ABPMP CBOK Passo-a-passo de como se cozinha um arroz. Notação de modelo de processos Conjunto de sinais com que se faz essa representação ou designação. Dicionário Michaellis BPMN, UML, IDEF A figura a seguir exemplifica as definições apresentadas anteriormente:

4 Figura 1 Princípio da modelagem de processo (FONTE: ELO Group) 1.3.Motivações e Benefícios Esperados Segundo Vernadat ² apud Chaulhoub (2004), a modelagem de processos de negócios apresenta os seguintes benefícios e motivações: Representar como são realizadas as atividades dentro da empresa, possibilitando um melhor entendimento de como ela funciona; Armazenar conhecimentos adquiridos e know-how organizacional para uma possível reutilização no futuro; Racionalizar e assegurar os fluxos de informação; Projetar/reprojetar e detalhar uma parte da empresa, contemplando aspectos funcionais, comportamentais, informacionais, organizacionais ou estruturais; Analisar diferentes aspectos da empresa (análise econômica, organizacional etc.); Possibilitar a realização de simulações;

5 Tomar melhores decisões em relação à organização e às operações empresariais; Controlar, coordenar ou monitorar os processos empresariais. Segundo Rashid M. Khan, em seu artigo What Standards Really Matter For BPM, a modelagem e notação de processos podem trazer alguns benefícios para a organização, como por exemplo: Promover o padrão de terminologias e definições dos processos de negócio. Isso acelera o entendimento dos processos, maximizando a sua compreensão e a capacidade de resposta rápida às necessidades dos clientes; A utilização de uma linguagem padrão e amplamente utilizada pelo mercado permite às empresas desenvolver, manter e atualizar seus processos de forma mais simples e rápida; Capacidade de integração entre processos de negócios que estejam modelados na mesma linguagem. Caso haja processos que estejam modelados em notações diferentes, a interação entre eles pode ser prejudicada; Outro grande benefício da padronização de uma linguagem é a facilidade que as empresas têm de migrar de uma notação baseada em BPM para a outra. Se há uma insatisfação com algum tipo de linguagem específica, a organização pode adequar-se a outra que segue o mesmo padrão em BPM. Ao facilitar a compreensão e auxiliar a navegação entre sistemas em BPM, este padrão irá reduzir os custos de realização dos processos e, assim, trazer vantagens para o consumidor final; Algumas linguagens em BPM têm uma forte base matemática envolvida em sua estrutura. Assim, notações baseadas em cálculos, como o BPEL estruturado sobre o Pi Calculus, minimiza as chances de erros se comparado a linguagens que não apresentam esse embasamento.

6 Revisão Teórica sobre Modelagem de Processos Abaixo seguem algumas opiniões de principais autores sobre modelagem de processos. 2.1.) ABPMP BPM CBOK e a Visão de Modelagem de Processos O objetivo da modelagem de processos é criar uma representação de um processo, descrito de maneira precisa, das atividades que estão sendo executadas na organização. No entanto, um modelo nem sempre será uma representação integral e completa do processo real, mas freqüentemente focará na representação das principais atividades. Portanto, deve-se ter atenção em até que ponto um simples diagrama será suficiente para representar um determinado processo. Modelos de processos têm muitas vantagens na gestão de operações empresariais, tais como a melhoria da comunicação através da criação de uma representação visível e o estabelecimento de uma perspectiva comum e compartilhada, facilitando a compreensão do leitor. Na gestão de processo de negócios, os modelos são os meios pelos quais as organizações gerenciam seus processos, analisando a sua performance e definindo mudanças. Eles expressam o foco do negocio da organização e especificam os recursos que permitem a efetiva operação do negócio: pessoas, informações, equipamentos, automação, finanças, energia etc. Alguns dos motivos mais comuns para a criação de modelos de processo são os seguintes: Documentar claramente um processo existente; Ajudar nos treinamentos através das atribuições de cada ator presentes nos processos; Usar como uma avaliação das normas e cumprimento das obrigações;

7 Compreender o comportamento do processo sob a ação de diferentes cargas ou sob alguma mudança antecipada; Servir de base para análise na identificação de oportunidades para melhoria; Suportar o design de um novo processo ou uma nova abordagem para um processo já existente; Fornecer uma base para a comunicação e discussão organizacional; Descrever requisitos para uma nova operação da empresa. 2.2) Paul Harmon e a Visão de Modelagem de Processos O objetivo da modelagem de processos é simplificar, destacar, clarificar e comunicar. O autor não destaca uma notação específica para a modelagem de um processo, justificando que se deve escolher um determinado padrão de notação que deixe as idéias mais claras possíveis para o leitor, ressaltando que qualquer notação de difícil compreensão e muito complexa é contraproducente.ao mesmo tempo, é importante permitir que qualquer pessoa da organização consiga compreender os diagramas de processos de forma clara e, para tal, faz-se necessário focar num mesmo conjunto de convenções. Acredita-se que a essência central dos elementos que a notação BPMN disponibiliza hoje é o que há de melhor. Por outro lado, quando é encontrada alguma situação que não é facilmente expressada pelo BPMN, às vezes as pessoas se sentem livres para ampliar informalmente o BPMN para ter certeza de que um determinado ponto de vista foi expresso da forma mais clara possível. 2.3) ROSEMANN e PIDD e o Principio de Modelagem Muitos autores têm discutido sobre a visão dos princípios de modelagem. Neste âmbito, alguns confirmam que os princípios de modelagem são essenciais para a criação de modelos robustos.

8 Há uma grande dificuldade na modelagem de processos de negócios e isto se dá pelo fato das pessoas terem percepções diferentes para o mesmo problema. Para minimizar essas divergências, busca-se modelar processos simples, que não incluem a complexidade da realidade. Abaixo segue a visão de dois autores sobre o principio de modelagem. Visão de ROSEMANN 1. Aderência: norteia quanto à proximidade que se está da realidade modelada. Técnicas de levantamento e validação de modelos de processos são aplicadas para aumentar a aderência e compatibilizar as diferentes percepções acerca de como o processo realmente é. 2. Relevância ou suficiência: todo objeto representado em um modelo deve ter um propósito, ou seja, um modelo só deve conter informações relevantes. Por isso, a definição do que é ou não relevante deve ser cautelosa. 3. Custo/benefício: este princípio visa analisar a quantidade necessária para criar o Modelo versus Utilidade do modelo versus Tempo de uso do modelo. 4. Clareza: este princípio é um dos mais importantes, pois se relaciona à capacidade de ser entendido e usado pelos usuários. 5. Comparabilidade: para que os processos sejam comparáveis é preciso aplicar os mesmos métodos a todos, corrigindo e uniformizando a nomenclatura e os níveis de detalhamento para que fiquem homogêneos. 6. Estruturação sistemática: este princípio está ligado à capacidade de integrar modelos representando diversos aspectos da realidade e, nesse sentido, à capacidade desses modelos de se conectarem metodologicamente.

9 Visão de PIDD 1. Modele simples, pense complicado; 2. Seja parcimonioso, comece pequeno e vá adicionando; 3. Divida e conquiste, evite megamodelos; 4. Use metáforas, analogias e similaridades; 5. Não se apaixone por dados; 6. A construção do modelo deve ser esclarecedora.

10 Notações de modelagem: BPMN 4.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 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:

11 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. 4.2 Visão geral de BPMN Hoje existem três modelos básicos para a modelagem no padrão BPMN: 1. Processos privados de negócios (interno); 2. Processos abstratos (público); 3. 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

12 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

13 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ãofuncional) * Processo de negócio privado detalhado o AS-IS ou processo de negócio antigo * o TO-BE ou processos de negócios novos Detalhamento dos processos de negócios privados com interações com um ou mais entidades externas (ou processos "caixa preta")

14 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

15 Principais objetos da notação BPMN: 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.

16 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. 4.3 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.

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

18 IDEF As informações abaixo estão fortemente baseadas no site e o artigo Integration Definition For Function Modeling (IDEFØ), do National Institute of Standards and Technology. 5.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.

19 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;

20 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 IDEF 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

21 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:

22 a. Genérica (para análise de sistemas com diferentes propósitos, escopo e complexidade); b. Precisa e rigorosa (para produzir corretamente modelos utilizáveis); c. Concisa (para facilitar a compreensão, comunicação, consenso e validação) d. Conceitual (para a representação dos requerimentos das funções físicas ou de implementações organizacionais); e. 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 seguintes itens: aos 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.

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

24 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Ø))

25 5.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.

26 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:

27 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. 5.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.

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

29 Notação de modelagem: ARIS AS informações abaixo estão fortemente baseadas em Paim (2002) e Chaloub (2004). 6.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.

30 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. 6.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.

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

32 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) 6.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.

33 Figura 14 Objetos de modelagem do Organograma (FONTE: Chalhoub) Figura 15 Exemplo de Objetos de organograma (FONTE: Chalhoub)

34 6.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.

35 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. 6.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.

36 Figura 18 Objetos de modelagem de EPC (FONTE: Chalhoub) Abaixo um exemplo de EPC.

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

38 6.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.

39 Figura 21 VAC desdobrado em EPC e FAD (FONTE: Chalhoub) 6.7Considerações finais

40 Notação de modelagem: UML 2.0 As informações abaixo estão fortemente baseadas em UML 2 for Dummies, de Michael Jesse. 7.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

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

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

43 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 Diagrama de casos de uso Utilizado para mostrar os

44 comportamento 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.

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

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

47 Tabela 4 Tipos de Diagrama UML (FONTE: ELO Group) Tipo de Diagrama Descrição Diagrama de classes Apresenta classes, associações, agregações e generalizações Organizar as classes de geração de códigos em ferramentas UML Mostra um exemplo especifico de gestão Diagrama de objetos Considera quais instâncias se tem em execução (também utilizado no diagrama de comunicação) Descreve o comportamento antes e depois de executado Mostrar a configuração para a rodada de teste Diagrama de objetos/classes híbrido Mostra exemplos de uma classe especifica que são de difícil compreensão. 7.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

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

49 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

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

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

52 Referencias Instituições e Conferências Livros e Artigos Bussiness Process Change, Paul Harmon UML 2 for Dummies, Michael Jesse Afonso, Fernanda Chalhoub, Avaliação do Supply-Chain Operations Reference-Model (SCOR) como um Modelo de Referência de Processos voltado para o Gerenciamento de