P. 1
Modelagem de Processos e UML

Modelagem de Processos e UML

|Views: 572|Likes:
Publicado porjonhnn

More info:

Published by: jonhnn on Dec 13, 2011
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

08/13/2013

pdf

text

original

MODELAGEM DE PROCESSOS E LINGUAGEM DE MODELAGEM UNIFICADA: UMA ANÁLISE CRÍTICA

Leonardo Silva Sciammarella Vicente

TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAÇÃO DOS PROGRAMAS DE PÓS-GRADUAÇÃO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS

NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA DE PRODUÇÃO

Aprovada por:

__________________________________________ Prof. Heitor Mansur Caulliraux, Dsc.

__________________________________________ Prof. Renato Flórido Cameira, Dsc.

__________________________________________ Prof. Eber Assis Schmitz, Dsc.

RIO DE JANEIRO, RJ – BRASIL MARÇO DE 2004

VICENTE, LEONARDO SILVA SCIAMMARELLA Modelagem de Processos e Linguagem de Modelagem Unificada (UML) uma análise crítica [Rio de Janeiro] 2004 XIV, 176 p. 29,7 cm (COPPE/UFRJ. M.Sc., Engenharia de Produção, 2004) Tese - Universidade Federal do Rio de Janeiro, COPPE 1. Modelagem de Processos 2. UML I. COPPE/UFRJ II. Título (série)

ii

DEDICATÓRIA

A todos aqueles que me ajudaram ao longo de minha vida e contribuíram direta ou indiretamente na elaboração desse trabalho, destacando-se minha mãe, Maria Alice, meu pai, Duarte (in memorian), minhas irmãs, Luciana e Tatiana e meu amor, Fernanda. Amo vocês.

iii

Tem como principal objetivo analisar as técnicas de modelagem de processos de negócio e de sistemas e propor uma metodologia de modelagem de processos e requisitos de negócio que possa apoiar uma especificação e projeto de um sistema de negócio que integre de forma consistente os requisitos de negócio com os requisitos de sistemas. iv .Resumo da Tese apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.) MODELAGEM DE PROCESSOS E LINGUAGEM DE MODELAGEM UNIFICADA (UML): UMA ANÁLISE CRÍTICA Leonardo Silva Sciammarella Vicente Fevereiro/2004 Orientador: Heitor Mansur Caulliraux Programa: Engenharia de Produção Essa dissertação apresenta os principais conceitos relacionados à Engenharia de Processos de Negócio e à Linguagem de Modelagem Unificada (Unified Modeling Language – UML).Sc.

) PROCESS MODELING AND UNIFIED MODELING LANGUAGE (UML): A CRITICAL ANALYSIS Leonardo Silva Sciammarella Vicente February/2004 Advisor: Heitor Mansur Caulliraux Department: Production Engineering This work presents the main concepts related to the Business Process Engineering and to the Unified Modeling Language (UML).Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M. v . It has as main objective to analyze the techniques of systems modeling and business process modeling and to define a methodology of business processes and requirements modeling that can support a specification and project of a business system that integrates of consistent form the business requirements with the systems requirements.Sc.

.........2...............................................................................................2..................... 34 A Vista de Dados ......................................................1 3..................2........................3.......2.......22 Arquiteturas e Metodologias de Modelagem de Processos de Negócio ................................................................................1 2...............................2 3......................................4 OBJETIVO GERAL ................6 MÉTODO DE TRABALHO ..................3........................2......... 28 ARIS (Architecture of Integrated Information Systems)....................................................7 3 ENGENHARIA DE PROCESSOS DE NEGÓCIO .....................................31 As Vistas da Metodologia ARIS e seus Modelos..............3 3.....1 1.............. X ÍNDICE DE TABELAS ..............................5 3..............................1 3........................................2 3........................15 PRINCÍPIOS...................................SUMÁRIO ÍNDICE DE FIGURAS ........................................4 OBJETIVOS DELIMITAÇÕES E MÉTODO DE TRABALHO ....41 APLICAÇÕES DA EPN........................................................43 Indicadores de Desempenho.......................................5..........2 3..............................................21 Ferramentas de Modelagem de Processos de Negócio ...............................................................................................................1 3....................................................................................3 A VISÃO POR PROCESSOS ......25 CIMOSA (Computer Integrated Manufacturing Open System Architecture) ..43 Gestão do Conhecimento.......5............................................................................2 CONCEITOS DE MODELAGEM DE PROCESSO DE NEGÓCIO E MODELOS TRADICIONAIS .........................4 3..............1 JUSTIFICATIVA DO TRABALHO .... 39 3...............................................2.............................................1 3..............................................3...................................................................2...XII LISTA DE SIGLAS.........43 Análises Organizacionais ................................................2.............................................3 2................................. 36 A Vista de Organização...................6 2....................................5.............. FERRAMENTAS E METODOLOGIAS DE MODELAGEM DE PROCESSOS DE NEGÓCIO 20 Princípios de Modelagem ....................................................2 3.......................................................................... XIII 1 INTRODUÇÃO...........................1 3..................... 29 3..........................2 3................. 26 IDEF (Integrated DEFinition) .........5.......3.......................................................................................................................................6 DELIMITAÇÕES DO TRABALHO .....................................................................4 3.......3 3.............................3 3.............................................................................10 3..............................3 ESTRUTURA DO TRABALHO.................................44 Gestão da Cadeia de Suprimento ...............3 3..................3.............2 2...........................................................................5 NÍVEL DE AGREGAÇÃO DA MODELAGEM DE PROCESSOS DE NEGÓCIO ........................................................2............................................................................................ 38 A Vista de Processos ..........................................................................................................................4 3...........................1 1....................................................................................................31 Conceitos de Modelagem de Processo de Negócio .........6 OBJETIVOS ESPECÍFICOS .............3.44 vi ..................................3.....................................3.....1 3....3 2 CONSIDERAÇÕES INICIAIS ......5.....................................2......................................3...................44 Gerência Eletrônica de Documentos (GED) e Workflow..................2 1.................34 A Vista de Funções ..........

..........6.........2 3...............................3 3.....57 O Paradigma da Orientação a Objeto .........7 4............5..........................................5........5 4......................69 Diagramas de Casos de Uso...53 Redução de Tempo e Custos dos Processos ........................6 3.......52 Padronização dos Processos .......53 CONSIDERAÇÕES FINAIS ....................................5..64 Blocos de Construção............................................................................2..............................................................6............................................................55 4...................8 3.............45 Projetos de Sistemas de Informação....46 GANHOS GERAIS ESPERADOS COM A EPN .........69 Vista de Implantação ............................................2..........45 Modelos de Negócios Eletrônicos ..........2 4...........6 4...45 Benchmarking..............................52 Melhoria do Fluxo de Informações ...............................2 4........................4 3.....................5.............................................5 4........55 PRINCIPAIS CONCEITOS BÁSICOS DA ORIENTAÇÃO A OBJETO – VISÃO GERAL .72 Diagramas de Objetos ...........................................53 UNIFIED MODELING LANGUAGE (UML) ...5.............................5 4.........................................................4 4.................................4................................1 3..........................................................................................3 DEFINIÇÃO E HISTÓRICO DA UML ..........61 Acoplamento e Coesão ...............................................66 Mecanismos da UML....................................................1 4...................................4 4.....5......................................................................................................4........................4.....................................1 4.......6 4...................6....................6 3...........................................................76 vii .............................2............................................3 4...............................................5 3........................70 Diagramas de Classes ............................57 Objeto e Classe..................................................................................................................2 4.................................6.........................5.................................................................................10 3...................................................................................................3..............6.......3 4.60 Encapsulamento .......................5...........1 4.........5..................................6......................................2 4.60 Polimorfismo .................................7 4 Organização da Documentação Técnica..................................11 3..................................................6.....................................60 Herança ......53 Melhoria da Gestão Organizacional .VISÃO GERAL.......2...................................7 3....................................................................................................................2.............4 4...............2..............................................................................................................66 ARQUITETURA DA UML......5...........45 Implantação dos Sistemas Integrados de Gestão..................6..52 Uniformização de Entendimentos sobre a Forma de Trabalho...5................................................69 MODELOS DA UML ..................................................................................................68 Vista de Projeto .............................................1 4...........9 3...............................................53 Aumento da Conceituação Organizacional sobre Processos ....................62 CONCEITOS BÁSICOS DA UML..................................................................................69 Vista de Implementação...................................67 Vista de Caso de Uso........................................................................................................61 OBJETIVOS DA UML .......1 4....68 Vista de Processo.................................................2..........................6................6 3...............................................................................................................3 4..................................3 4...................................................................45 Uniformização de entendimentos e integração organizacional ........................................................59 Mensagem....................................................64 Regras da UML ...........................................................2 4..................................................................................................................................

............90 Modelagem de Negócio e Diagrama de Classes ...............................................2 4................................................................ 122 6....... 118 Elaboração...........................................................2 5.....2 6......88 Modelagem de Negócio e Diagramas de Atividades .2...................6........................................... 78 4.........................................................................................2 5.................2.......106 MODELAGEM DE PROCESSO DE NEGÓCIO E O RATIONAL UNIFIED PROCESS (RUP) ..........................3.......................................................................................................... 112 Processo Centrado na Arquitetura .......................................................2.............107 6.................................................................2................................................................4 6.....................................................................................1.....................2 4....... 113 6.................................1.......................3 6 MODELAGEM DE PROCESSOS DE NEGÓCIO COM UML: ANÁLISE CRÍTICA DOS MODELOS ............................................ 122 Transição..........................................................................................................107 PROCESSOS PRODUTIVOS DE DESENVOLVIMENTO DE SISTEMAS ..............1 4.....................2......................................1 6....6 4.............1 5...................2................8 5 FERRAMENTAS DE MODELAGEM DE SOFTWARE COM UML................6................3 CONSIDERAÇÕES FINAIS ......2........................................... 120 Construção ..........................................................................................................................................92 Diagrama de Gráficos de Estados...........76 Diagramas de Seqüência ........2........................2....................................................................... 77 Diagramas de Colaboração.2 6..4 5......................................................................99 Vista de Visão do Negócio..............1.....................98 EXTENSÕES DA UML PARA MODELAGEM DE NEGÓCIO .......................................................3 5...........1 5.4...........2..................................................................................4 Diagramas de Interação................3 5....................6.........................81 Diagramas de Componentes................7 Diagramas de Gráficos de Estados ....................2....105 CONSIDERAÇÕES FINAIS .......................83 CONSIDERAÇÕES FINAIS ................3............7..................2 5.6...........1.....2..........................5 4...................................4................................. 82 Diagramas de Implantação ....1....7..........................................................................................1.........87 Modelagem de Negócio e Diagrama de Casos de Uso...............1 6..............................................1 4....104 Vista de Comportamento do Negócio ................ 82 4.........86 EPN E UML: CONTEXTUALIZAÇÃO DA UML NA MODELAGEM DE PROCESSOS DE NEGÓCIO............................................................................3...................................................97 Modelagem de Negócio e Diagramas de Interação .............3.....................................................79 Diagramas de Atividades...............................110 Principais Características do RUP ..............1 6................................80 Diagramas de Implementação......2........6.........................................3 6....6...........................1...........................................................................................................................2.............4 5...........................................................1 5....................................................123 viii ........4.................6...................................1 PRINCIPAIS ETAPAS PARA MODELAGEM DE PROCESSOS DE NEGÓCIO.................................... 112 Desenvolvimento Iterativo e Incremental.............................................................6..2 6..............3 O Ciclo de Vida de um Sistema no RUP..........................111 Processo Orientado a Casos de Uso ...............................................................................87 5............................7 4...............................102 Vista de Estrutura do Negócio..............101 Vista de Processos de Negócio .....1.............................................................................................................118 Concepção.................3 6...2 6..............117 Fases da Metodologia .........................5 5...

......2....................2 8......................2 8........................................1.......................2.1 9......1.1 8..................................................................................1 7....................2...1...................... 160 8.1..............124 7.........1 DESCRIÇÃO DO CASO DA EMPRESA DO SETOR FARMACÊUTICO ......1 7...... 153 Identificação e Modelagem de Casos de Uso ........................................................................................................2....... 144 Modelagem dos Objetivos do Negócio ................................1....................2................1..............1.........................................138 8.............169 10 REFERÊNCIAS BIBLIOGRÁFICAS ....................150 Modelagem dos Objetivos do Negócio ...................1 8.......149 Modelagem e Levantamento de Requisitos de Negócio..139 O Caso do Produto TelVip ..............................................................................2.............2 8 MODELAGEM DE NEGÓCIO PARA SISTEMAS – PRINCIPAIS FASES A ARTEFATOS ................................ 146 8................................ 155 Modelagem do Diagrama de Classes ............... 144 Levantamento de Requisitos Funcionais e Não Funcionais ........1......................................5 8....................................................................1....................1........1.............124 Modelagem e Levantamento de Requisitos de Negócio.........................2 DESCRIÇÃO DO CASO DA EMPRESA DE TI .....1 8.2 CONCLUSÕES .............................................................1................................................2...................................................143 Modelagem e Levantamento de Requisitos de Negócio...........................2......................... 150 Modelagem dos Processos de Negócio .....2 8............................................. 151 Levantamento de Requisitos Funcionais e Não Funcionais................3 8..............1....................2......3 9 CONSIDERAÇÕES FINAIS ...1..3 8...............1................128 CONSIDERAÇÕES FINAIS ....................................................................136 CASOS DE APLICAÇÃO DA METODOLOGIA PROPOSTA..........2...............................................138 Componentização e Padronização de Processos de Negócio ...2................................................ 144 Modelagem dos Processos de Negócio .............4 8.....7 PROPOSTA METODOLÓGICA DE MODELAGEM DE PROCESSOS E REQUISITOS DE NEGÓCIO PARA DESENVOLVIMENTO DE SISTEMAS..................162 CONCLUSÕES E PERSPECTIVAS DE DESENVOLVIMENTO ...............170 ix ...................................... 146 Identificação e Modelagem de Casos de Uso............163 PERSPECTIVAS DE DESENVOLVIMENTO ..................1...........1 8..............................................................................................1 8...1........4 8..................................................................163 9......

...........75 FIGURA 24: DIAGRAMA DE OBJETOS ..............................................................................49 FIGURA 18: COMPONENTES DE PROCESSOS E DE SISTEMAS ........................................................................................72 FIGURA 22: NOTAÇÃO DE UMA CLASSE ....................68 FIGURA 20 – DIAGRAMAS DA UML ............................84 FIGURA 32: EXEMPLO DE CASO DE USO DE NEGÓCIO ................................................................82 FIGURA 30: DIAGRAMA DE IMPLANTAÇÃO ................................81 FIGURA 29: DIAGRAMA DE COMPONENTES .........94 FIGURA 36: EPC DE ALTO NÍVEL COM PACOTES ......................................................................................................................................................................................................................46 FIGURA 17: PROJETO DE SISTEMAS COM ENGENHARIA SIMULTÂNEA .................................................................................................................. ................................ÍNDICE DE FIGURAS FIGURA 1: VISÃO FUNCIONAL X VISÃO POR PROCESSOS ................................................................................................................................................16 FIGURA 2: INTEGRAÇÃO DA CADEIA DE SUPRIMENTOS .35 FIGURA 11: EXEMPLO DE DIAGRAMA DE ÁRVORE DE FUNÇÃO ............................................................................................................................................................................................95 x .............................................................41 FIGURA 15: ENGENHARIA DE PROCESSOS DE NEGÓCIO E APLICAÇÕES .....................................................................................................................................................................................................................................................90 FIGURA 34: RELAÇÃO ENTRE EPC E DIAGRAMA DE ATIVIDADES ......29 FIGURA 9: METAMODELO DE PROCESSO DE NEGÓCIO..................................................................................................................................................................................................................................................35 FIGURA 12: MODELO DE DADOS COM CLUSTERS E ERM..........................................................................................................................38 FIGURA 14: EXEMPLO DE EPC ..........................................................................................................................................................................................................................................................................................70 FIGURA 21: DIAGRAMAS DE CASOS DE USO .......51 FIGURA 19 ARQUITETURA DE UM SISTEMA .........................................................................78 FIGURA 26: DIAGRAMA DE COLABORAÇÃO ......................32 FIGURA 10: EXEMPLO DE DIAGRAMA DE OBJETIVOS ...............................28 FIGURA 8: AS VISTAS E NÍVEIS DE IMPLEMENTAÇÃO DA METODOLOGIA ARIS...20 FIGURA 5: COMPARAÇÃO DE FERRAMANETAS DE MODELAGEM DE PROCESSOS .................80 FIGURA 28: DIAGRAMA DE ATIVIDADES ..................................43 FIGURA 16: ARQUITETURA DE PROCESSOS DE NEGÓCIO COM DESDOBRAMENTO PARA SISTEMAS DE INFORMAÇÃO...............................................76 FIGURA 25: DIAGRAMA DE SEQÜÊNCIA........................................79 FIGURA 27: DIAGRAMA DE GRÁFICO DE ESTADOS ......................................................................................................................................................................................................................24 FIGURA 7: O CUBO CIMOSA.................37 FIGURA 13: EXEMPLO DE ORGANOGRAMA......................................................73 FIGURA 23: DIAGRAMA DE CLASSES ........................................................................18 FIGURA 3: AS TENDÊNCIAS ORGANIZACIONAIS..................................................................................................................89 FIGURA 33: NÍVEIS DE DETALHAMENTO ENTRE CASOS DE USO E EPC..........................................................................................................................................................83 FIGURA 31: COMPARAÇÃO DAS FERRAMENTAS DE MODELAGEM DE SOFTWARE .........................................19 FIGURA 4: EVOLUÇÃO DE CONCEITOS E SISTEMAS DE INTEGRAÇÃO ...............92 FIGURA 35: ESTRUTURA DO OEPC...................................................23 FIGURA 6: MÉTODO DE ANÁLISE DE ADEQUAÇÃO DAS FERRAMENTAS DE MODELAGEM A UM PROJETO ....

.......................................................102 FIGURA 43: DIAGRAMA DE PROCESSOS ................................150 FIGURA 60: PROCESSO DE MANUTENÇÃO .......................................146 FIGURA 58: PARTE DO DIAGRAMA DE CASOS DE USO DO PRODUTO TELVIP.............................................................................................................................. ......FIGURA 37: DIAGRAMA DE CLASSES AGRUPADO NUM PACOTE .......96 FIGURA 39: EPC CAPTURAR REQUISITOS DETALHADO COM ATRIBUTOS E OPERAÇÕES .............................................................................160 FIGURA 64: DIAGRAMA DE CLASSES PARA ELABORAÇÃO DO SISCOM................109 FIGURA 48: MODELO CASCATA DE DESENVOLVIMENTO DE SOFTWARE .........129 FIGURA 55: DERIVAÇÃO DE CASOS DE USO A PARTIR DE PROCESSOS DE NEGÓCIO ..............................................................105 FIGURA 46: PROCESSO DE MODELAGEM DE NEGÓCIO.153 FIGURA 62: DIAGRAMA DE CASOS DE USO PARA ELABORAÇÃO DO SISCOM...................................108 FIGURA 47: PROCESSO DE MODELAGEM DE NEGÓCIO COM DESDOBRAMENTO PARA SISTEMAS ....................114 FIGURA 49: UM PROCESSO ITERATIVO E INCREMENTAL ....127 FIGURA 54: FLUXO DE MODELAGEM E LEVANTAMENTO DE REQUISITOS DE NEGÓCIO .............117 FIGURA 52: DIAGRAMA DE PROCESSOS MOSTRANDO A RELAÇÃO ENTRE PROCESSOS DE NEGÓCIO E SISTEMAS FONTE: ADAPTADA DE ERIKSSON E PENKER (1999) ...................................................115 FIGURA 50: ABORDAGEM ITERATIVA E INCREMENTAL ........................................................................................................................................................................143 FIGURA 57: PARTE DO PROCESSO DE ATIVAÇÃO DO TELVIP.................................................................................................................................................................96 FIGURA 40: COMPARAÇÃO ENTRE EPC E DIAGRAMA DE ESTADOS ............................................................................97 FIGURA 41: DIAGRAMA DE ATIVIDADES E ESTEREÓTIPOS DE PROCESSOS DE NEGÓCIO .....104 FIGURA 45: DIAGRAMA ORGANIZACIONAL ........................................................................161 xi ............................103 FIGURA 44: DIAGRAMA DE LINHA DE MONTAGEM .....................................95 FIGURA 38: EPC DE NÍVEL INTERMEDIÁRIO COM CLASSE....................................101 FIGURA 42: DIAGRAMA DE OBJETIVOS E PROBLEMAS .131 FIGURA 56: ELABORAÇÃO DE UMA ESPECIFICAÇÃO DE PROCESSOS E REQUISITOS DE NEGÓCIO............115 FIGURA 51: ESTRUTURA DO RUP......................................................152 FIGURA 61: FAD ALOCAR MÃO-DE-OBRA...................................................................................................................................................... ....................................................................125 FIGURA 53: ANÁLISE COMPARADA ENTRE ETAPAS DE MODELAGEM DE PROCESSOS DE NEGÓCIO E DE DESENVOLVIMENTO DE SISTEMAS ........................147 FIGURA 59: DIAGRAMA DE OBJETIVOS DO PROCESSO DE MANUTENÇÃO ............................................................................................................................................157 FIGURA 63: ATIVIDADE “ALOCAR MÃO-DE-OBRA” E CLASSES ASSOCIADAS” .................................................................................................................................................................

................................156 TABELA 6: PROCESSO DE MANUTENÇÃO (EPC X CASOS DE USO X DIAGRAMA DE CLASSES)........16 TABELA 2: MODELO FURPS DE CLASSIFICAÇÃO DE REQUISITOS .....134 TABELA 4: COMPARAÇÃO ENTRE O EPC X CASOS DE USO X DIAGRAMA DE CLASSE..................COMPARAÇÃO: ORGANIZAÇÃO FUNCIONAL VS ORIENTADA POR PROCESSOS .................................159 xii .................120 TABELA 3: FASES E ARTEFATOS DA METODOLOGIA PROPOSTA .....................................................ÍNDICE DE TABELAS TABELA 1 ..136 TABELA 5: LISTA DE ATIVIDADES E EXECUTORES CANDIDATOS A CASOS DE USO E ATORES ........................................

Knowledge Management MER .Object Management Group OMT .Function Allocation Diagram GED .Business Process Management System B2B .Object State Transition Network xiii .Gerência Eletrônica de Documentos IDEF .Engenharia de Software FAD .Component-Based Development CIM .Arquitetura Integrada de Sistemas ARIS .Integrated DEFinition KM .Business to Customer CASE .Ordens de Trabalho OSTN .Engenharia de Processos de Negócios ERP .Component Object Model CORBA .Computer Integrated Manufacturing CIMOSA .Computer Integrated Manufacturing Open System Architecture COM .Business Process Management BPMS .LISTA DE SIGLAS AIS .Computer Aided Software Enginneering CBD .object-Oriented Event-Driven Process Chain OMG .Object-Oriented Software Enginneering OT .Arquitecture of integrated Information System BPM .Business to Business B2C .Common Object Request Broker Architecture CRM .Object Modeling Technique OOSE .Modelo de Entidades e Relacionamentos OE – Order Entry oEPC .Entreprise Java Beans EPC – Event-Driven Process Chain EPN .Enterprise Resources Planning ES .Customer Relationship Management EAI – Enterprise Application Integration EJB .

Tecnologia da Informação UML .Sistemas Integrados de Gestão SISCOM .Unifed Modeling Language VAC .Sistema de Controle e Manutenção SCM .PCP – Planejamento e Controle da Produção PPM .Value Added Chain xiv .Supply Chain Management TI .Process Performance Management RUP .Rational Unified Process SA – Sistema de Aprovisionamento SIG .

o crescimento das organizações virtuais que estão diretamente relacionadas ao comércio eletrônico e a formação de cadeias de valores e. por fim. Diante desse contexto. as organizações estão demandando a todo o momento mais dinâmica. a aceleração do processo de inovação e criação de novos produtos. A constatação desse ambiente pode ser observado em diversas obras de diversos autores. buscando alcançar seus objetivos estratégicos através da redução de custos e do tempo de atendimento ao cliente. entre outras ações que podem contribuir para a sustentação da competitividade no longo prazo. através de parcerias com outras organizações. tais fatores e tendências incluem a globalização. Tais mudanças podem ser observadas no dia a dia através dos jornais impressos ou online. integração. PROENÇA (1999) faz uma abordagem dinâmica no que se refere às estratégias organizacionais frente às mudanças ambientais. através dos telejornais. como pode ser observado por SANTOS (2002). tendo que se adaptarem. quase que em tempo real. O autor coloca que para se construir uma vantagem competitiva desejável por um longo prazo é importante analisar a estratégia de forma dinâmica e não sob uma perspectiva estática e pontual de um determinado momento. às mudanças do ambiente no qual estão inseridas. Segundo DAVENPORT (2000). das revistas e dos livros especializados em negócios que permitem a observação de fatores e tendências do mercado que norteiam as tomadas de decisões das organizações.1 Considerações Iniciais As constantes e crescentes transformações no mundo dos negócios estão tornando o mercado cada vez mais competitivo e estão levando as organizações a repensarem suas estratégias de atuação dentro de seus respectivos nichos.1 INTRODUÇÃO 1. 1 . através do aumento da taxa de inovação com a conseqüente redução no tempo de desenvolvimento de novos produtos. a necessidade do realinhamento horizontal corporativo para suportar com maior eficiência os processos de transações internos e externos à empresa. flexibilidade e inovação para se manterem competitivas. o surgimento de modelos de negócio com rápida percepção e resposta às necessidades do cliente.

a integração da função manufatura com projeto. a dinâmica ao menor tempo de resposta as mudanças do ambiente.” (CAMEIRA. a dinâmica das organizações é um elemento fundamental para justificar projetos organizacionais mais aderentes. de automação e de comunicação. diante de soluções cada vez mais modernas e baseadas na Tecnologia da Informação (TI). com do sua uso acumulativo. relacionando a integração ao desenvolvimento de sistemas. quanto a nível técnico com a capacidade de modificar rapidamente as tecnologias e as características de projeto que compõem o produto oferecido. VERNADAT (1996). 2002) considera que diante da complexidade do ambiente de negócios. Este mesmo autor destaca a relação do conceito de hiper-integração com a DIFI. Também pode-se observar em CAMEIRA (2003) o conceito de hiper-integração desenvolvido e sustentado pelos quadros conceituais: Engenharia de Processos. ressalta as mudanças e tendências do ambiente de atuação das organizações como: a integração de mercados com a formação dos blocos econômicos com áreas de livre comércio. conseqüência da TI. centros de desenvolvimento e fornecedores e. por fim.1). a importância e a necessidade das organizações apresentarem flexibilidade tanto a nível gerencial com a reorganização dos processos de negócios e estruturas organizacionais.. a integração dos componentes de hardware e software de diversos fornecedores.GALBRAITH (apud SANTOS. em função das tendências do mercado e das customizações para clientes. de integração. Em certos níveis de acúmulo. mas também qualitativo. por exemplo. Este mesmo autor também ressalta. 2003. p. modificando o ambiente de forma não apenas incremental. incremental. Tecnologia da Informação (TI) e Modelos de Negócio Tecnologicamente Habilitados. de capacidade armazenamento e processamento de informações. o resultado de um movimento não apenas quantitativo. a flexibilidade a rápida reconfiguração do fluxo 2 . O autor define hiper-integração como: “.. este movimento provoca mudanças do contexto no qual a TI é aplicada.

voz e imagem e surgem sistemas de informação que buscam a não replicação de dados e a integração organizacional. os quais são desenvolvidos novos softwares e hardwares com capacidade de armazenamento de dados e processamento de informações cada vez maior. através da banda larga. uma maior vazão de dados. pode-se citar a Tecnologia da Informação que tem sido referenciada em diversas obras de diversos autores como. fica difícil considerar um negócio sem a presença da TI que deve ser pensada de maneira sistêmica com os processos de uma organização (CAMEIRA. 1. econômica. por exemplo. do desenvolvimento de sistemas de informação que possibilitem.2 Justificativa do Trabalho Diante do cenário abordado acima. DAVENPORT (1994. financeira. entre outros. Essa sinergia entre sistemas de informação e 3 .de informações suportado pelos processos hiper-integrados e por uma Arquitetura Integrada de Sistemas (AIS) baseada em componentes e em agentes inteligentes e. possibilitam. surge a Internet que passa a ser encarada como um grande meio de comunicação que possibilita o aumento do fluxo de informações e a integração virtual intra e interorganizacional. cultural. tecnológica. considerando. entre outros fatores que fazem da TI um pré-requisito fundamental para a subsistência das organizações. Dentro dos fatores tecnológicos que motivam tais transformações. Todas essas mudanças no ambiente de negócio e as ações que as organizações estão tomando para se adaptarem as diversas configurações de cenários a que estão expostas em seus cotidianos. Nesse contexto. Esta tese não se propõe a analisar todos esses fatores. o fator tecnológico como habilitador das transformações na maneira de se fazer negócios. 2000) e HAMMER e CHAMPY (1994) que atribuem a TI um papel fundamental para se realizar a reengenharia de processos. a integração funcional de uma organização suportada pelos seus processos de negócio. através do fluxo de informações horizontal. social. por fim. a inovação como conseqüência da hiper-integração dos processos. são suportadas por diversos fatores de ordem política. 2003). da capacidade de dinamicidade de resposta ao ambiente e da flexibilidade de redesenho. por exemplo. precisamente. destaca-se a relevância da TI e mais. principalmente. novos meios e tecnologias de transmissão em telecomunicações que. dentre os citados acima. Como conseqüência da evolução da TI.

Porém. conceitos e técnicas de modelagem de processos e de sistemas que possam contemplar essa necessidade. de forma breve. quais são as delimitações a que se restringe o trabalho e quais são os objetivos principais e específicos do mesmo.3 Estrutura do Trabalho Esse tópico tem como principal objetivo descrever a estrutura do trabalho mostrando. a maneira como a pesquisa foi conduzida. Assim. O capítulo 4 busca apresentar as principais características e objetivos da UML. metodologias e conceitos serão tratados neste trabalho com o intuito de esclarecer e facilitar a conversão da estratégia desejada em processos de negócio e. Diante da necessidade de dinâmica. Muitas empresas apresentam dificuldades para desenvolverem processos de negócios e sistemas com qualidade e em tempo hábil para se manterem competitivas no mercado. 2000).processos de negócio deve existir com um dos principais objetivos para realizar de forma eficiente a estratégia de uma organização.. bem como a Unifed Modeling Language (UML) enquanto uma linguagem padrão para elaboração de estrutura de projetos de software (JACOBSON et al. integração. alguns de seus ganhos e algumas de suas aplicações como. 4 . a dissertação apresenta um breve quadro conceitual sobre Engenharia de Processos de Negócio (EPN) ressaltando alguns princípios. Dessa forma. as empresas estão buscando novas tecnologias. ou seja. metodologias e ferramentas de modelagem de processo. o desenvolvimento de sistemas de informação. flexibilidade e inovação. dando destaque para os tipos de modelos que a compõem e qual o papel de cada modelo dentro da lógica de um processo de desenvolvimento de software. o trabalho tem como base um referencial teórico que leva em consideração a Engenharia de Processos de Negócios (EPN) e sua relação com o desenvolvimento de sistemas de informação. adiante em sistemas de informação. No capítulo 3. 1. No capítulo 2 será mostrado o método de trabalho utilizado. algumas tecnologias. por exemplo. os conteúdos dos capítulos envolvidos nessa dissertação. a realização da estratégia desejada através do uso da TI e processos de negócio não é uma tarefa fácil e direta. Essa compreensão do papel de cada modelo ajuda a entender como os requisitos e os processos de negócio podem ser levantados. analisados e implantados pela UML.

através dos modelos de processos e dos modelos da UML.O capítulo 5 tem como objetivo relacionar os dois capítulos anteriores. Por fim. a transição de requisitos de negócio para a análise e desenvolvimento de sistemas. mostrando as principais vantagens e desvantagens de se utilizar a UML para modelagem de processos de negócio. Além disso. O capítulo 6 apresenta conceitos referentes a metodologias de modelagem de processos de negócio para desenvolvimento de sistemas e também apresenta uma metodologia de desenvolvimento de software denominado de Rational Unified Process (RUP). 5 . O capítulo 9 apresenta as conclusões finais do trabalho mostrando seus principais resultados e perspectivas para desdobramentos de trabalhos futuros. O capítulo 7 tem como objetivo elaborar uma metodologia de modelagem de processos orientada para desenvolvimento de sistemas que mostra. buscando comparar os modelos de processos com os modelos da UML. o capítulo 10 apresenta as referências bibliográficas utilizadas na elaboração do trabalho. A idéia dessa metodologia é tentar estabelecer um elo entre os processos de negócio e a análise / levantamento de requisitos de negócio para desenvolvimento de sistemas O capítulo 8 apresenta a aplicação de metodologia proposta através da utilização de casos levantados a partir de dados reais. mostra também uma proposta de extensão da UML para modelagem de processos de negócio.

suas delimitações e.2 Objetivos Específicos Esse trabalho apresenta alguns objetivos específicos que darão suporte para a realização do objetivo geral colocado acima. o método de trabalho adotado durante a pesquisa. por fim.1 Objetivo Geral Este trabalho tem como objetivo desenvolver uma proposta de metodologia de modelagem de processos e requisitos de negócio orientada para desenvolvimento de sistemas de negócio com base em dois quadros conceituais envolvendo a Engenharia de Processos de Negócio (EPN) e a Unified Modeling Language (UML) e seus modelos. 6 . • Analisar e relacionar os modelos tradicionais da EPN com os modelos da UML. a saber: • Apresentar um breve quadro conceitual referente à Engenharia de Processos de Negócio. 2. abordando suas principais aplicações. Portanto. é importante colocar as delimitações inerentes a cada área com o intuito de focar a tese para a realização de seus objetivos. mostrando de que maneira a UML pode contribuir para a formulação de uma metodologia de modelagem de processos voltada para sistemas. 2. metodologias e arquiteturas de referência para modelagem de processos. além dos processos de desenvolvimento de software.2 OBJETIVOS DELIMITAÇÕES E MÉTODO DE TRABALHO Este capítulo tem como principal finalidade definir os principais objetivos da tese. 2. • Apresentar um quadro conceitual referente à UML e seus modelos. mostrando o papel deles dentro da metodologia de modelagem de processos.3 Delimitações do Trabalho O presente trabalho tem seu framework conceitual na relação entre a Engenharia de Processos de Negócio e a Engenharia de Software.

objetivos e procedimentos técnico utilizados. toda estratégia de pesquisa apresenta vantagens e desvantagens. ajudam a afunilar o escopo da mesma. Além disso. a pesquisa pode ser classificada como aplicada e com relação à abordagem do problema em análise. onde o pesquisador tende a analisar seus dados intuitivamente. em oposição a fenômenos contemporâneos. Analisando as características dos diferentes tipos de pesquisa e considerando as principais questões que se pretende investigar. do controle que o pesquisador tem sobre os eventos comportamentais efetivos e do foco em fenômenos históricos.4 Método de Trabalho Esse tópico tem como principal objetivo descrever o tipo de pesquisa utilizada para elaborar essa dissertação. 2. forma. p. pois. não se pretende detalhar os tipos metodologias orientadas a objeto. Conforme pode ser observado em YIN (2001. Além disso. No que tange à Engenharia de Software. A ênfase será dada ao desdobramento referente ao Projeto de Sistemas de Informação.Com relação á Engenharia de Processos de Negócio. interessando a este texto o entendimento de que forma essas tecnologias podem contribuir para uma metodologia de modelagem de processos orientada para sistemas. justificando sua escolha e apresentando suas principais características de natureza. desdobramentos da EPN como a Gestão do Relacionamento com o Cliente. vale ressaltar que não será analisado nenhum tipo de linguagem de programação de desenvolvimento de software. 19). dependendo do tipo de questão da pesquisa. considera que nem tudo pode ser quantificável e traduzido em números e que existe uma relação subjetiva e dinâmica entre o mundo real e o objeto de estudo. a pesquisa pode se caracterizar como qualitativa. por exemplo. pois. além de mostrar as principais etapas realizadas durante a pesquisa. nem as ferramentas que suportam a modelagem orientada a objeto. a pesquisa realizada buscou uma 7 . Dentro do contexto proposto para o trabalho. Re-projeto Organizacional. Gestão da Cadeia de Suprimentos. a Gestão do Conhecimento. foi possível concluir que quanto a sua natureza. As delimitações citadas acima visam tornar factível o desenvolvimento da dissertação bem como suas conclusões. Workflow e GED e Implantação de Sistemas Integrados de Gestão. Gestão de Indicadores de Desempenho. não serão detalhados. é importante ressaltar que nem todos os conceitos abordados por ela serão aprofundados na dissertação.

Isto é particularmente valioso para responder questões do tipo quem. de acordo com as classificações propostas por GIL (1991). 65). a metodologia de pesquisa adotada foi realizada nas seguintes etapas (REMENYI et al. porque e como dentro da gestão da pesquisa. tendo que por algumas vezes retornar e reavaliar as evidências bibliográficas e práticas levantadas no que se refere ao tipo e relevância dos dados a serem levantados e a forma de análise dos mesmos (YIN. o autor não participou ativamente destes fenômenos. procurando transferir o 8 . A partir das classificações citadas acima. é importante ressaltar que durante a pesquisa e o desenvolvimento dos casos. visa proporcionar maior familiaridade com o problema com vistas a torná-lo explícito. como sendo exploratória com relação aos seus objetivos. algumas evidências levantadas apontavam para a reformulação de algumas questões iniciais e o surgimento de novas questões. 1998): 1. quando as fronteiras entre o fenômeno e o contexto não são muito evidentes. pois. Como estratégia de pesquisa. com relação aos procedimentos técnicos usados na dissertação. pois apesar de ter existido algum grau de interação com as equipes de indivíduos que faziam parte dos casos. podendo ser classificada. Os casos apresentados na dissertação proporcionaram a contextualização real da aplicação experimental da metodologia de modelagem de processos e requisitos de negócio orientado para desenvolvimento de sistemas de negócio. e que múltiplas fontes de evidência são usadas..melhor compreensão do foco abordado pela tese. Esta reformulação nas questões relevantes levou o autor redefinir o projeto de pesquisa. YIN (2001). Porém. Estudo da bibliografia com a utilização de livros e artigos referentes ao tema abordado na tese. Buscou-se com esse estudo subsídios e bases teóricas para realizar uma pesquisa que agregue valor ao trabalho. não tomando parte ou exercendo influência sobre o comportamento dos fenômenos estudados. Além disso. o estudo de caso pode ser definido como uma pesquisa empírica que investiga um fenômeno contemporâneo dentro de um contexto da vida real. a pesquisa pode ser classificada como sendo do tipo estudo de caso e não participante. entrevistas com pessoas que tiveram experiências práticas com o problema pesquisado e análise de casos que estimulem a compreensão. p. envolve levantamento bibliográfico. 2001.

apresentando o problema tratado. mostrando suas principais características e seus desdobramentos como. 4. da metodologia de modelagem de processos de negócio e levantamento de requisitos para construção de sistemas corporativos da empresa e demais dados relevantes para uma melhor descrição dos problemas enfrentados dentro do escopo abordado. 3. Para tornar essa análise consistente foi utilizado como base todo o leque bibliográfico explorado durante a pesquisa e as evidências levantadas nos casos. Redação e elaboração da documentação final. 2. através de estudo de casos em organizações.conhecimento contido no estado-da-arte para o estudo de caso contemplado na tese. Levantamento de dados ou evidências. 9 . as contribuições realizadas e propostas de pesquisas futuras. o desenvolvimento de sistemas de informação. o estudo bibliográfico ajudará a guiar e se necessário ajustar o tema proposto. Fazer a análise dos dados coletados buscando uma melhor compreensão dos problemas contidos dentro do tema proposto. O próximo capítulo inicia o desenvolvimento da dissertação com uma revisão literária do tópico Engenharia de Processos de Negócios (EPN). as conclusões oriundas dos conhecimentos adquiridos com o estado-da-arte e daqueles adquiridos com os casos. os resultados obtidos. por intermédio da documentação da organização e de entrevistas com seus profissionais. Além disso. por exemplo.

uma organização ou. diversos são os quadros conceituais abordados por muitos autores que estão relacionados com a EPN como. etc.. por exemplo) opera.. p. até.”. 2000). 1996). etc. 1994) que para muitos.3 ENGENHARIA DE PROCESSOS DE NEGÓCIO Segundo SANTOS (2002. 10 . análise e melhoria dos processos dentro e entre organizações. apesar de ter sido mal aplicada em muitas empresas. a Reengenharia (DAVENPORT. a EPN tem como um dos seus principais objetivos o mapeamento dos processos de negócio que envolve parte ou a totalidade dos relacionamentos de uma ou mais organizações com o intuito de compreender as inter-relações existentes entre os objetos envolvidos com o(s) processo (s) de negócio em questão. ainda podem ser citados quadros como o Controle de Qualidade Total (FALCONI.. Em CAMEIRA e CAULLIRAUX (2000) pode-se encontrar a seguinte definição de EPN: “. como são realizados os processos. suas interfaces. 1996a. um conjunto de organizações (uma cadeia de suprimento.”. por exemplo.1). quem realiza as diversas atividades. 1996b. HAMMER. Independente do quadro conceitual abordado. Teoria das Restrições (STEIN. como a informação flui através desses processos. no início da década de 90... a grande responsável pela difusão da visão orientada a processos.a EPN é uma técnica muito utilizada quando se deseja entender ou mapear como uma parte de uma organização. 1996).. CHAMPY. uma arquitetura (framework) para entendimento. Sistema Toyota de Produção (SHINGO. SHINGO. 1994. Dentro da Engenharia de Produção. quais os recursos são utilizados.. permitindo entender as cadeias de valor existentes. a Engenharia de Processos de Negócio (EPN) pode ser definida como “. foi.

Para entender melhor esses conceitos. com relação ao desempenho global. Uma co- responsabilidade dos atores nesta organização. p. durante sua duração. com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes”. que formaliza o seu objetivo global (um nível de qualidade. Uma responsabilidade local de cada grupo de atores ao nível de sua própria atividade.” (ZARIFIAN apud SALERNO. p. as características de um processo seriam: Uma organização estruturada. (DAVENPORT.Existem diversos conceitos atrelados à definição de processo de negócio. 1993) “Uma cooperação de atividades distintas para a realização de um objetivo global. com início e fim. um prazo de entrega etc.105) Segundo SALERNO (1999. Uma organização que materializa e estrutura transversalmente a interdependência das atividades do processo. a saber: “Um processo é um grupo de atividades realizadas numa seqüência lógica. Um processo é repetido de maneira recorrente dentro da empresa.104). A um processo correspondem: Um desempenho (performance).). e com inputs e outputs claramente identificados”. orientado para o cliente final que lhes é comum. é importante citar algumas das definições de processo de negócio encontradas na literatura. 1994) “Um processo é uma ordem específica de atividades de trabalho que são realizadas através do tempo com um lugar definido. 1999. (HAMMER e CHAMPY. modelada em termos e trocas entre as 11 .

Um desempenho global. mas outros não. Os processos estão intrinsecamente 12 . ao mesmo tempo. demanda de investimentos. Esses indicadores seriam a única referência de avaliação sobre o resultado do processo. Fatores de desempenho ligados aos pontos críticos: são pontos privilegiados de reflexão sobre a gestão econômica do processo e sobre os principais instrumentos de ação. O processo se desenrola segundo uma temporalidade organizável e mensurável.: chegada de um pedido) e outro o fecha (entrega). Entradas tangíveis (produtos. dão o custo de um processo. necessários e úteis ao processo. mas a utilização racional dos recursos que são. É possível que alguns recursos fiquem dedicados a um processo. É um ponto de partida para a construção da organização. “processos podem ser melhor entendidos se percebidos como uma estruturação-coordenação-disposição lógicotemporal de ações e recursos com o objetivo de gerar um ou mais produto(s)/serviço(s) para os clientes da organização. deve ser explicitado em desempenhos locais para cada atividade. faturas. pedidos. Esta organização se constitui pela ligação ao cliente final. etc. medido por alguns (poucos) indicadores. Saídas: o resultado do processo. dado que um evento detona o processo (ex.atividades constitutivas. Pontos críticos podem ser atividade ou coordenações. Um desenrolar temporal. podendo ter um uso variado. Custo dos recursos globais.). Recursos: não é o somatório de recursos locais. o único critério de coresponsabilidade entre os atores. etc.) ou intangíveis (decisão de lançar novo produto. valorizados.

Os processos podem estar em diferentes níveis de abstração ou detalhamento. serem transversais a forma através da qual a organização se estruturou (por função. por produto. por exemplo. entre outras. dentro das organizações. 2002. uma normalização e certificação da qualidade através das séries ISO. melhorias dos processos em questão. financeiros e outros). redução de custos e do lead-time de produção. por conseqüência. VERNADAT (1996) coloca que os principais objetivos da modelagem de processos são: Uniformização do entendimento da forma de trabalho. Explicitação do conhecimento sobre os processos.relacionados aos fluxos de objetos na organização. possuírem um responsável por seu desempenho global e responsáveis locais direcionados ao andamento de suas partes-constituintes e. também. orientado para produtos.). simulações computacionais de diversos cenários.40). uma estruturação para ação para a geração de valor” (SANTOS. 13 . cujas finalidades básicas são: representação. por eixo geográfico etc. gerando integração. horizontalmente. comumente. p. assim. o know how organizacional. são. relacionado a atividade finalísticas ou de apoio. Análise e melhoria do fluxo de informações. Realização de análises organizacionais e de indicadores (processos. Aos processos cabe o desenvolvimento ou desenrolar dos fluxos de objetos enquanto às funções ou unidade organizacionais cabe a concentração de conhecimentos por semelhança. Os processos são a organização em movimento. almejando. armazenando. Com os modelos de processos de negócios mapeados é possível realizar análises e. a EPN tem por base modelos de processos. SANTOS et al (2002) analisa que diante da necessidade de se mapear processos para uma melhor compreensão da organização como um todo. clientes e mercados. seleção e desenvolvimento de sistemas integrados de gestão orientado a processos. análise e melhoria da forma que o trabalho é realizado nas organizações.

é importante se definir padrões na forma como as pessoas estão modelando os processos. é importante definir uma ferramenta de modelagem. é possível melhorar a gestão 14 . Melhoria do fluxo de informações – através da modelagem de processos é possível identificar as informações de entrada e saída necessárias para a execução das atividades que estabelecem interfaces entre unidades organizacionais de uma mesma empresa ou de empresas diferentes. Cabe ressaltar que é importante o envolvimento de pessoas que possam garantir a consistência da padronização entre os diversos modelos trabalhados por diversas pessoas de várias áreas de uma organização. isso facilita sobremaneira a legibilidade e a homogeneidade dos modelos trabalhados. suportada ferramentas e modelos que permitem a visualização do trabalho executado pelas unidades organizacionais.Realização de simulações. Padronização dos processos . 2002): Uniformização de entendimentos sobre a forma de trabalho – através da difusão da visão por processos. por exemplo. como estes objetos estarão dispostos no modelo. os modelos que serão utilizados. entre outros aspectos que ajudam a formular um referencial de conformidade. Destaca-se o papel da TI com a utilização de sistemas de informação como. facilitando a uniformização do entendimento sobre a forma de trabalho. Gestão da organização. Nesse sentido. os objetos dos modelos que serão utilizados. é possível se criar uma visão holística e homogênea do negócio por parte de todos os envolvidos em uma organização ou até mesmo em um conjunto de organizações. pois. apoiando tomada de decisões. os sistemas de workflow que apóiam a automatização dos processos e do fluxo de informação. SANTOS (2002) citou os principais resultados da aplicação da EPN nas organizações podem ser citados os seguintes (SANTOS. Melhoria da gestão organizacional – relacionando-se os processos modelados aos indicadores de desempenho de uma organização.

torna-se possível identificar as melhorias diretamente ligadas a maior eficiência organizacional com a redução de tempo e custos. a EPN fundamenta-se na visão por processos e na modelagem dos processos de negócio para retratar parte das variáveis que compõem um determinado ambiente de negócio real. devido à falta de visão processual. avaliação.organizacional através de práticas de monitoração. Porém. 3. Como exemplo.1 A Visão por Processos Conforme foi possível observar acima. Na figura e na tabela abaixo podem ser visualizados os contrastes entre a lógica processual e funcional: 15 . o que gera um indicador positivo para a área de compras. como pode ser observadas em ANTUNES. De uma maneira geral. Aumento da conceituação organizacional sobre processos – como conseqüência da aplicação de métodos e práticas relacionadas à EPN. gerando o desenvolvimento e o aprimoramento organizacional. controle. esta pode gerar distorções de percepção. a visão por processos busca a integração dos ótimos locais para atingir os ótimos globais. No que tange a visão funcional.. as organizações passam a aplicar práticas baseadas em processos. até o momento. substituindo ou no mínimo complementando a visão funcional vigente. recursos e métricas envolvidas nos processos. pode-se tomar como base uma compra em grande quantidade de um determinado produto. em boa parte das organizações presente no mercado de trabalho. essa grande quantidade de produto pode gerar um aumento do custo de estocagem que venha a invalidar o ganho proporcionado pela área de compras. JR. CAULLIRAUX e NEVES (1998).. reduzindo o custo por unidade adquirida. etc. e Redução de tempo e custos dos processos – com a modelagem das operações.

externos as organizações). unidades organizacionais. Jr. a possibilidade de navegação pelos processos em qualquer direção seja das atividades aos 16 . etc. TEUFEL (1998). por fim. o foco dado em clientes iniciais e finais (clientes. apud SANTOS (2002. Neves (1998) Tabela 1 . Caulliraux. a possibilidade de se realizar uma análise das funções de uma organização a partir de uma seqüência lógica e temporal das atividades mapeadas. uma classificação consistente metodologicamente dos objetos e uma hierarquia entre os modelos e.Comparação: Organização Funcional vs Orientada por Processos Organização Funcional Organização por Processos Consumidor como uma variável criadora Objetivos ajustados pelos consumidores de ‘distúrbio’ Estruturas organizacionais rígidas Foco no projeto organizacional Estruturas organizacionais flexíveis Foco no projeto do comportamento Controle flexível do processo por gerentes Controle do Processo por gerentes de de fluxo de trabalhos (Workflow) coordenação Fonte: KELLER.). preferencialmente. 27) CAMEIRA e CAULLIRAUX (2000) colocam como principais características da visão por processos. a articulação de diversos objetos que compõem os processos (dados. recursos. p.Organização Processos Processo 1 Função A Função B Função C Produtos Processo 2 M ercado Atividades ou Operações Figura 1: Visão Funcional X Visão por Processos Fonte: RUMMLER e BRACHE (1994) apud Antunes..

permitiu a drástica redução dos custos de transferência de informação e o aumento da velocidade e da qualidade das comunicações dentro e fora das organizações. aumentando apenas a velocidade com os quais os processos são realizados. influencia de maneira drástica o comportamento da sociedade como um todo. por natureza. evitando. É de extrema importância que as empresas procurem entender a lógica da forma como seus resultados são obtidos e ajustar as atividades e a tecnologia empregada de modo a otimizar o emprego dos recursos e a eficiência geral dos processos. tanto na área de computação quanto na área de telecomunicações. Para entender essa lógica de funcionamento é necessário um estudo do trabalho para analisar a maneira pela qual ele é realizado e quais são os recursos envolvidos na execução do mesmo. portanto. facilitando as quebras das barreiras funcionais. ao seu negócio. Dessa forma. desta forma. Independente do porte. Além disso. vale ressaltar que a TI se aplicada em processos problemáticos.macro-processos (abordagem botton up) ou dos macro-processos para as atividades (abordagem top down). a TI proporciona desde mudanças na forma individual de trabalhar até a forma pela qual as organizações se relacionam em processos interorganizacionais. grandes investimentos em tecnologia na automação de processos que geram pouco ou nenhum valor para o cliente da empresa e. Na realização do trabalho. alterando a vida das pessoas e das diversas organizações das quais elas fazem parte. pode não representar ganho de eficiência. influenciando de maneira significativa na execução e gestão do trabalho. A Tecnologia da Informação. Além disso. o surgimento de novas 17 . a TI tem um papel importantíssimo dentro dos processos empresariais. A evolução da Tecnologia da Informação (TI). É necessário que a empresa defina seus processos chaves escolhendo cuidadosamente os processos a serem tratados para que possa garantir um resultado realmente importante para o seu negócio. Estes mesmos autores também relacionam a visão por processos à TI enquanto habilitadora da integração do fluxo de informações que proporciona o encadeamento e o link das atividades realizadas pelas diversas áreas de uma empresa. é importante que uma organização considere em seus planejamentos o uso eficaz e eficiente da TI. do mercado e da sua cultura organizacional.

Conforme pode ser visto na figura abaixo. utilizando os seus recursos 18 . Produtos Acabados. etc. Assim. uma empresa também deve se preocupar com a sua cadeia de suprimentos e procurar se posicionar da melhor maneira possível dentro dela. Faturas Figura 2: Integração da Cadeia de Suprimentos Fonte: NEVES (1999. terceirizando atividades e processos que não são chaves e não estão ligados às suas competências centrais. é importante para uma empresa que deseja manter ou ganhar mercado nos dias de hoje considerar a visão por processos dentro de sua estrutura organizacional. Knowledge Management (KM). Esses processos que formam toda a cadeia podem ser chamados de processos colaborativos. 6) Nesse contexto. etc. Fornecedor de MP Indústria Distribuição Varejo => Matéria-prima. podem compartilhar informações. cada empresa pode focar seus recursos em processos chaves e se especializar em determinada etapa do processo de produção que agora passa a estar espalhado pela cadeia de suprimento.tecnologias e conceitos como Supply Chain Management (SCM). Produtos Intermediários. Termos de Pagamentos. processos e responsabilidades com 1 Negócios realizados através da Internet. Deve reduzir custos através de parcerias com outras empresas. Sendo assim. Como visto anteriormente. a visão por processos busca derrubar os “muros” funcionais e proporcionar uma melhor integração entre as áreas de uma empresa. de um ambiente de negócio colaborativo. conhecimentos. p. => Créditos. => Capacidades. Tempos de Entrega. as empresas dentro. Customer Relationship Management (CRM) e E-business1 está permitindo que a lógica por processos seja aplicada tanto para integrar áreas de uma mesma empresa quanto para integrar as empresas que venham a fazer parte de uma mesma cadeia ou rede de valor.

seus parceiros. 19 . buscando adquirir vantagens competitivas para a cadeia como um todo e não somente para uma empresa. A figura abaixo mostra a evolução da visão orientada a processos desde a tradicional organização por função até o dinâmico ambiente colaborativo do e-business. Na figura abaixo é possível visualizar essa evolução de conceitos e tecnologias relacionados à integração organizacional. pelos sistemas Enterprise Resources Planning (ERP) com a integração intra-organizacional e pelos sistemas de Gestão da Cadeia de Suprimento (Supply Chain Management – SCM) que buscam fazer o elo entre todos os sistemas ERP das empresas que formam a cadeia. passando por conceitos e tecnologias abordadas pela Manufatura Integrada por Computador (ou Computer Integrated Manufacturing – CIM). em uma integração interorganizacional. Fonte: IDS Scheer AG (2000) Essa relação direta da visão por processos com TI pode ser comprovada através do histórico relacionado aos sistemas integrados de gestão (SIG). e-Economia A PARTIR Comunidades Orientadas por Processos ‘Cooperação dinâmica com e-Business’ Organizações Funcionais ‘Muros’ Organizações Orientadas por Processos ‘Sistemas Logísticos Integrados’ Redes de Processos Específicos ‘Planejamento integrado e implementação com SCMs’ Figura 3: As Tendências Organizacionais.

é importante entender alguns princípios de modelagem e as principais metodologias de modelagem de processos que suportam a visão por processos. 20 . p.Supply Chain Management JIT MRP/ MRPII TOC JIT MRP/ MRPII TOC JIT MRP/ MRPII TOC CIM ERP CIM CIM ERP Empresa 1 ERP Empresa 2 Empresa N Figura 4: Evolução de conceitos e sistemas de integração Fonte: CAMEIRA (1999.3) Como citado anteriormente. serão mostradas algumas das principais arquiteturas de modelagem de processos de negócio utilizadas no mercado. por fim. Sendo assim. Ferramentas e Metodologias de Modelagem de Processos de Negócio Nesse tópico serão abordados alguns dos princípios de modelagem citados e considerados por alguns autores como base para a criação de um modelo claro e eficiente.2 Princípios. diante de um ambiente complexo torna-se necessária a existência de modelos que facilitem a compreensão e gestão da realidade. 3. será vista uma análise de mercado das ferramentas de modelagem de processos e uma proposta de metodologia de seleção de uma ferramenta e.

Divida e conquiste. um modelo é uma representação externa e explícita de parte da realidade vista pela pessoa que deseja usar aquele modelo para entender. os principais princípios de modelagem são: Modele simples. Re-usabilidade. Simplicidade versus adequação. é importante seguir alguns princípios de modelagem que são citados por alguns autores como pode ser observado abaixo. gerenciar e controlar parte daquela realidade.1 Princípios de Modelagem Segundo PIDD (1999). podem ser encontrados os seguintes princípios de modelagem: Separação de focos para reduzir a complexidade.2. Visualização do modelo. Seja parcimonioso. Separação do comportamento e funcionalidade. Rigor na representação.3. 21 . pense complicado. para que um modelo possa ser eficaz e eficiente é necessário que ele represente de forma clara e objetiva a situação a que está disposto a explicitar. Separação de dados e controle. Modularidade. comece com pouco e acrescente. mudar. Descasamento entre processos e recursos. evite mega-modelos. Decomposição funcional. Use metáforas. Generalidades do modelo. Conformidade. Porém. Para isso. analogias e similaridades. Não se apaixone pelos dados. Para PIDD (1999). Em VERNADAT (1996). Gestão da complexidade.

importante a existência de ferramentas suportadas por arquiteturas / metodologias que sirvam de referência para a modelagem. A seguir serão mostradas brevemente algumas dessas ferramentas e metodologias. Clareza dos modelos para melhor compreensão dos usuários.2. Relevância ou suficiência no nível de detalhamento dos modelos de acordo com o objetivo fim da modelagem. pressupondo-se a utilização da mesma linguagem de modelagem com os mesmos objetos. Assim. Porém. portanto. Estruturação sistemática dos modelos que devem apresentar. 3.2 Ferramentas de Modelagem de Processos de Negócio Como mencionado anteriormente. integração entre diferentes pontos de vista de uma mesma realidade. o processo de seleção e compra de uma ferramenta de modelagem deve 22 .Para ROSEMANN (apud SCHEER. metodologias e aplicações citadas acima necessitam de ferramentas de modelagem que tenham capacidades e funcionalidades suficientes para a realização dos objetivos de um projeto específico. para que haja uma modelagem consistente e de fácil entendimento é necessário que tais princípios sejam aplicados de maneira eficaz proporcionando uma modelagem uniforme e integrada sendo. Custo / benefício de se criar um modelo analisando o quão útil será e quanto tempo será utilizado. 1998) e AALST (apud SANTOS 2002) pode-se encontrar os seguintes princípios de modelagem: Aderência á realidade. através de uma metodologia consistente. a visão por processos é habilitada e realizada através da TI e de suas ferramentas informáticas. Capacidade de comparabilidade entre modelos diferentes. É importante observar que os princípios de modelagem apresentam relações de interdependência e muitos são complementares. Porém. mesma metodologia e níveis de detalhamento homogêneos. todas as arquiteturas.

seguir alguns critérios que permitam comparações que apóiem na tomada de decisão. podendo ser levadas em consideração no processo de seleção e compra. a facilidade de utilização da mesma. Conforme pode ser observado na figura abaixo. o Gartner Group. o tempo estimado de vida útil dessa ferramenta dentro da organização. algumas consultorias como. A escolha da ferramenta deve levar em consideração uma série de fatores como o escopo do projeto ou dos projetos em que será utilizada. Mercado de Modelagem/Análise de Processos de Negócios Pioneiros Líderes Capacidade de suporte Atores do Nicho Visionários Figura 5: Comparação de Ferramanetas de Modelagem de Processos Fonte: Gartner Group (2002) 23 . por exemplo. realizam análises de ferramentas de modelagens de processos segundo alguns critérios. a política do fornecedor com relação à manutenção e atualização da ferramenta. a existência de base de dados. entre outros fatores que devem ser levados em conta.

ferramentas disponíveis Escolha de ferramenta Definição dos objetivos Análise de adequação Conhecimento em modelagem Figura 6: Método de Análise de Adequação das Ferramentas de Modelagem a um Projeto Fonte: BASTOS. Com uma base de dados associada é possível armazenar e integrar modelos e objetos de forma consistente. variando de ferramentas de uso específico a uso mais geral e a capacidade de suporte ao mercado.O Gartner Group utiliza dois critérios para a classificação das ferramentas. que são a abrangência da visão relacionada aos possíveis desdobramentos e aplicações em que a ferramenta pode ser utilizada. a possibilidade de criação de filtros. CAMEIRA e BASTOS (2000) demonstram uma proposta de método de análise e adequação das ferramentas de modelagem a um projeto com a definição dos objetivos do projeto. mecanismos de busca. Além desse método. etc. classificação e seleção de ferramentas de modelagem. conforme pode ser observado na figura abaixo: Verificação de possibilidades. 2 Nessa etapa do método os autores ressaltam que a experiência e o conhecimento em modelagem contribui significativamente nessa análise de adequação da ferramenta ao projeto em questão.8) Os mesmos autores ainda citam outros critérios que julgam importante para avaliar uma ferramenta de modelagem como: Existência de base de dados – O primeiro critério e corte utilizado pelos autores está relacionado à existência de base de dados nas ferramentas de modelagem. a verificação de ferramentas disponíveis no mercado para o cumprimento dos objetivos. além de proporcionar outras funcionalidades como a geração e análise de diversos tipos de relatórios de modelos e objetos armazenados. a análise de adequação da ferramenta ao escopo do projeto2 e a escolha da ferramenta. os autores propõem outros critérios para análise. p. Em complemento a figura acima. CAMEIRA (2000. 24 .

permitindo uma crítica automática na criação dos modelos.). a ferramenta ARIS Toolset foi selecionada como base de estudo para o desenvolvimento da metodologia proposta. Live Model (Intellicorp). Visio Professional e Casewise.114 a p. entre outros critérios que lhe proporcionaram esse status. Scheer GmbH.O segundo critério utilizado foi a existência de um referencial metodológico intrínseco a ferramenta. Scheer GmbH. System Architect (Popkin) e Visio Professional.2. Um outro trabalho interessante e detalhado sobre ferramentas de modelagem pode ser observado em SANTOS (2003. As principais ferramentas analisadas no trabalho foram as seguintes: Corel Draw (Corel Software). Considerando-se o resultado acima e que o objetivo deste trabalho é apresentar uma metodologia de modelagem de processos orientada para levantamento de requisitos de desenvolvimento de sistemas. Flow Charter (Micrografix). dando destaque à metodologia ARIS e alguns dos modelos utilizados por essa ferramenta. MicroSaint (Systems Modeling). funcionalidades (operacionais e de gestão) e de preço para as seguintes ferramentas: ARIS Toolset (IDS Prof. é importante entender algumas metodologias de modelagem. p. MS Power Point (Microsoft Corporation). por ser abrangente em termos de escopo de projeto. por uma metodologia. MS Power Point (Microsoft Corporation). a existência de um referencial metodológico significa um ponto de partida e uma referência para os usuários da ferramenta trabalharem de forma padronizada e homogênea.Existência de referencial metodológico . Ithink (High Performance Systems).3 Arquiteturas e Metodologias de Modelagem de Processos de Negócio Diante da necessidade de criação de vistas organizacionais apoiadas por modelos 25 .139) onde o autor faz análises comparadas de métodos. conforme será visto no próximo tópico. System Architect (Popkin). ARIS Tool Set (IDS Prof. aplicações. Todos os trabalhos citados neste tópico apontam a ferramenta de modelagem ARIS Toolset (IDS Prof.). is/Modeler (Modus Operandi). Além dessas vantagens.) como a melhor para a modelagem de processos por ser suportada por uma base de dados. de seus respectivos objetos e de seus relacionamentos. Dessa forma. Scheer GmbH. 3.

3. controlar ou monitorar o dia-a-dia de operações através do ciclo de vida dos produtos. diversas metodologias de modelagem empresarial relacionadas diretamente a EPN. padronizando módulos. novos modelos são criados e modelos existentes são melhorados ou pode também ser aplicada no ambiente de operações empresariais nos quais modelos são usados para suportar. trata-se de uma arquitetura cujo objetivo é ajudar as organizações a gerenciar mudanças e integrar suas facilidades e operações com vista a alcançar preço. a infraestrutura de integração e ciclo de vida do sistema CIM. qualidade e tempo de entrega competitivos. inter organizacional que facilita a uniformização de entendimentos por parte das pessoas envolvidas no projeto em questão. no qual.2. A partir dessas metodologias de referência é possível criar uma linguagem padrão intra ou. Pode ser aplicada tanto no ambiente de engenharia empresarial. conforme observado em VERNADAT (1996). dependendo do objetivo a ser alcançado por um projeto ou aplicação específica.3. tornando a modelagem empresarial mais uniforme. recurso e aspectos organizacionais. CIMOSA introduziu a idéia de arquitetura de sistemas abertos para CIM. foram desenvolvidas por diversas organizações de padronização com o intuito de facilitar o processo de modelagem empresarial através de metodologias pré-definidas que podem ser reutilizadas de maneira integral ou.1 CIMOSA (Computer Integrated Manufacturing Open System Architecture) Elaborada e documentada por um consórcio de empresas denominado AMICE. informação. integrada e consistente com os objetivos aos quais pretende realizar. Neste tópico será apresentada uma visão geral de algumas das principais metodologias desenvolvidas e utilizadas na busca de padrões de modelagem. através de melhoria contínua ou reengenharia. Apresenta uma arquitetura consistente tanto com a modelagem quanto com a integração empresarial como é requerido no ambiente CIM e que possui 3 componentes principais: estrutura de modelagem empresarial. servirem como ponto de referência para o desenvolvimento de uma metodologia própria e customizada.de todos os tipos. 26 . no caso de uma cadeia de organizações. descritos em termos de sua função.

A estrutura de modelagem apresentada por CIMOSA, conforme pode ser vista na figura abaixo, é conhecida como “CUBO CIMOSA” e se divide em arquitetura de referência e arquitetura particular. Em sendo tridimensional, a estrutura é caracterizada por três princípios ortogonais: Princípio da Derivação Esta dimensão é composta por três níveis cujo objetivo é o de dividir o modelo de negócio em diferentes níveis de abstração. No primeiro nível, denominado "Requirements Definition", devem ser registradas as necessidades do negócio de acordo com a visão dos usuários. No segundo nível, denominado "Design Specification", os requisitos definidos no primeiro nível são detalhados com o intuito de construir um modelo de negócio executável. No último nível, denominado "Implementation Description", acrescenta-se o nível anterior é detalhado para a implementação do modelo de negócio definido. Princípio da Instanciação Este princípio tem como base três vistas: genérica, parcial e particular. A

primeira vista, denominada de genérica, contém objetos e regras genéricas que juntos podem criar uma linguagem de modelagem para expressar modelos gerais ou particulares. A segunda vista, denominada de parcial, tem por objetivo a descrição de modelos gerais como, por exemplo, modelos relacionados a um determinado tipo de indústria que podem ser reutilizados e adaptados para um modelo particular. E, por fim, a vista particular que tem como objetivo a descrição de modelos específicos para uma determinada organização. As vistas genérica e parcial estão inseridas na arquitetura de referência e a última vista na arquitetura particular. Princípio da Geração Este princípio é composto por quatro vistas complementares: organização, recursos, informação e função. A vista de organização está relacionada à representação dos níveis organizacionais, autoridade e responsabilidade. A vista de recursos está relacionada aos seres humanos, máquinas e sistemas e suas capacidades de gerir e executar as funções do negócio. A vista de informação representa os objetos organizacionais e seus elementos de informação. E, por fim, a vista de função que representa numa lógica temporal o comportamento (processos, atividades e eventos) e as funções organizacionais. 27

Figura 7: O Cubo CIMOSA Fonte: (VERNADAT, 1996, p.45)

3.2.3.2 IDEF (Integrated DEFinition) A metodologia IDEF começou a ser criada no início dos anos 70 em um programa da força aérea dos Estados Unidos da América denominado de ICAM (Integrated Computer Aided Manufacturing). Inicialmente pensada para engenharia de sistemas, a IDEF com o passar dos anos foi agregando novos métodos relacionados a diversos aspectos organizacionais que não somente sistemas de informações. Assim, a IDEF é composta por sub-métodos como o IDEF 0 relacionado a modelagem funcional, o IDEF 1 para modelagem de informações, o IDEF 2 desenvolvido para suportar simulações, o IDEF 3 para descrição e captura de processos, IDEF 4 para modelagem orientada a objetos e IDEF 5 para descrição de ontologias. Ainda existem métodos que estão em desenvolvimento e outros que ainda serão desenvolvidos como, por exemplo,

28

o IDEF 14 para projeto de rede e o IDEF 12 para projeto organizacional. Como citado anteriormente, o método IDEF 3 está diretamente relacionado a modelagem de processos, sendo composto por dois modelos denominados de Fluxo de Processo (Process Flow) e o Rede de Transição de Estado de Objeto (Object State Transition Network (OSTN)). O primeiro modelo tem como objetivo descrever como as coisas são feitas dentro de um determinado processo de produção. O segundo modelo descreve os eventos, pelos quais um objeto passa em um determinado processo. É importante ressaltar que ambos os modelos possuem unidades de informação e podem, portanto, serem usados na descrição de sistemas de informação. (GROVER, 2000, p. 170/173), VERNADAT (1996, p. 136/143) e MAYER et. al, apud SANTOS, 2002) 3.2.3.3 ARIS (Architecture of Integrated Information Systems) A metodologia ARIS tem como principal objetivo, através de modelos, estabelecer uma visão holística, integrada e homogênea de uma organização, permitindo o desenvolvimento de sistemas de informação mais aderentes ao negócio. Com o intuito de reduzir a complexidade da modelagem das diversas partes que compõem uma organização, conforme pode ser observado na figura abaixo, a arquitetura se divide em cinco vistas (Organização, Função, Dados, Controle ou Processo e Saída) e cada vista se divide em três níveis (Definição de Requisitos, Projeto e Especificação e, por fim, Implementação).

Figura 8: As vistas e níveis de implementação da metodologia ARIS Fonte: Adaptação de SCHEER (1998, p. 41) apud SANTOS (2002, p. 120)

29

definindo os principais requisitos de negócio que darão suporte ao desenvolvimento das aplicações de TI. conforme será visto mais a frente. o Organograma. se inter-relacionam. dos principais conceitos e idéias da organização.. o cubo da arquitetura CIMOSA e também lembra muito. o nível Definição de Requisitos tem como principal objetivo descrever de forma estruturada a aplicação do negócio. No nível de Projeto e Especificação deve ser modelado após de “Definição e Requisitos”. através de modelos como a Cadeia de Eventos Orientados a Processos e Diagrama de Objetivos. Isto já não acontece 30 . dos requisitos de negócio definidos no nível anterior e dos requisitos funcionais da aplicação a ser desenvolvida. A subdivisão das vistas em três níveis faz lembrar. através da lógica da metodologia. através de. por exemplo. os estágios de desenvolvimento de sistemas de informação (BOOCH et al. É importante observar. entre os quais se destacam o Diagrama de Objetivos. a Cadeia de Valor Agregado. Por fim. a Cadeia de Eventos Orientados a Processos. o nível de Projeto e Especificação e principalmente o nível de Implementação possuem ciclos de vida mais reduzidos. modelos como os da UML. entre outros que. Neste nível. conforme pode ser visto em ARIS Methods (2000). como visto anteriormente. deve ocorrer a descrição. pois. mostrando de maneira consistente desde a concepção e do entendimento estratégico da organização até o nível de implantação dos componentes de TI que darão suporte operacional à estratégia concebida. Ou seja.Diversos são os modelos associados a cada vista. É nesse nível que deve ocorrer a descrição. o nível de Implementação com base nos modelos descritos no nível anterior define os componentes de software e hardware que irão compor a aplicação final. descrevendo de forma detalhada informações referentes à aplicação da TI. modelos da UML como o Diagrama de Componentes e de Implantação podem apoiar a modelagem. Com relação aos níveis de descrição e conforme pode ser observado em ARIS Methods (2000). que os níveis citados possuem ciclos de vida diferentes. se aproximando muito da visão de negócio do usuário. estão mais próximos da TI que se renova com muita freqüência num curto espaço de tempo. 1999). Diagrama de Caso de Uso. variando com a proximidade da aplicação da TI. Nesse nível.

3. Além disso. englobando. SANTOS.3. 3. 1993.2) e pelo fato do autor possuir alguma experiência de utilização da ferramenta em projetos envolvidos com modelagem de processos e desdobramentos afins. para exemplificar os modelos utilizados pela EPN para modelagem de negócio.3 Conceitos de Modelagem de Processo de Negócio e Modelos Tradicionais Nesse tópico serão descritos alguns dos principais conceitos envolvidos com a modelagem de um negócio. será utilizada nesse tópico a metodologia ARIS3 e alguns dos seus modelos. ZARIFIAN apud SALERNO. 1999. os conceitos relacionados a processos de negócio já citados em algumas das definições de alguns autores no início do capítulo. pois este está diretamente ligado à visão de negócio que não muda com mesma velocidade da TI. Essa metodologia foi escolhida pelo fato de ser suportada por uma ferramenta de modelagem considerada pelo Gartner Group como líder de mercado de análise e modelagem de processos de negócio (conforme foi apresentado no tópico 3.com o nível de Definição de Requisitos.1 Conceitos de Modelagem de Processo de Negócio Diversas são as definições de processo de negócio propostas por inúmeros autores que apresentam similaridades conceituais (HAMMER e CHAMPY. portanto. DAVENPORT. 1994.2. ERIKSSON E PENKER.3. SALERNO.3. 2000). 2002. 1999.3 31 . 3 A metodologia ARIS foi apresentada no tópico 3.

Com base na similaridade desses conceitos é possível elaborar um metamodelo4 como o elaborado por JACKOWSKI (2003). produto e mecanismos envolvidos na execução dos processos de negócio. 4 O conceito de metamodelo foi definido no capítulo 4. por exemplo. Figura 9: Metamodelo de Processo de Negócio Fonte: JACKOWSKI (2003) Também é importante ressaltar que esses conceitos relacionados à modelagem de negócio possuem relacionamentos entre si. por sua vez. os objetivos estão diretamente ligados à razão de existir dos processos de negócio. os recursos. um metamodelo pode ser utilizado como padrão para a criação de modelos de processos de negócio específicos. Conforme pode ser observado na figura abaixo. através do metamodelo. que pode ser representado. são utilizados na forma de insumo. podendo uma determinada regra definir a maneira de como os recursos são estruturados. Segundo o autor. entre outros tipos de relacionamentos que existem entre esses conceitos. 32 . é possível representar os conceitos de negócio. por um diagrama de classes da UML.

Esses conceitos representados por classes de objetos são descritos abaixo (JACKOWSKI, 2003, ERIKSSON E PENKER, 2000):

Processo de Negócio - O conceito de processo, conforme pode ser observado na figura acima, se relaciona com a maior parte dos demais conceitos e apresenta os atributos de descrição e de medidas. O primeiro atributo está relacionado com a descrição textual ou gráfica do processo, mostrando como o processo é executado e quais são os recursos de entrada (processados e consumidos pelo mesmo) e quais são os de saída. O segundo atributo está diretamente relacionado às métricas (indicadores) do processo, considerando fatores de qualidade, tempo, custo, entre outros. Além disso, é importante ressaltar que um processo pode ser desdobrado em subprocessos, representando vários níveis de detalhamento do negócio, está associado à pelo menos uma unidade organizacional responsável por sua gestão e controle, é composto por uma ou mais atividades que são executadas por trabalhadores ou sistemas do negócio, é regido por regras de negócio e, por fim, é iniciado a partir de eventos externos ou internos a organização e ao ser finalizado gera algum tipo de evento indicando que seu objetivo foi realizado.

Objetivos do Negócio - são propósitos gerais que um negócio pretende alcançar, podendo ser ramificados em sub-objetivos divididos, por exemplo, por áreas funcionais do negócio. Além disso, todo processo deve estar associado direta ou indiretamente à pelo menos um objetivo estratégico que pode ser definido por uma ou mais regras de negócio e corresponde ao estado em que o recurso estará ao final do processo. Também é importante destacar que a realização de um objetivo depende de problemas ou fatores críticos que limitam o seu alcance.

Recursos

(Objetos

de

Negócio)

-

são

elementos

que

apresentam

relacionamentos entre si como materiais, pessoas, informações ou produtos que são manipulados por processos de negócio e podem ser classificados como elementos físicos, abstratos e informacionais. Conforme definido no conceito de 33

processo, esses objetos podem ser de entrada (material ou informação) sendo transformado ou consumido pelo processo e podem ser de saída representando um resultado coerente com o objetivo do processo. É importante ressaltar que um objeto de saída de um processo pode fazer o papel de entrada de outro processo. Além disso, conforme pode ser visto na figura acima, um objeto de negócio pode ser fornecido por uma ou mais organizações externas ao negócio.

Regras de Negócio – constituem de afirmações que definem ou limitam alguns aspectos do negócio e representam o conhecimento do negócio. As regras determinam como o negócio deve se comportar, ou seja, como os processos de negócio devem ser executados e como os recursos utilizados são estruturados e se relacionam entre si. As regras podem ser definidas a partir de leis externas ou definidas internamente ao negócio, para que sejam alcançados os objetivos, podendo ser expressas tanto de forma textual como de forma gráfica através de modelos. 3.3.2 As Vistas da Metodologia ARIS e seus Modelos Conforme citado anteriormente, a arquitetura da metodologia se divide em cinco vistas (Organização, Função, Dados, Controle ou Processo e Saída) e cada vista se divide em três níveis (Definição de Requisitos, Projeto e Especificação e, por fim, Implementação). Nesse tópico serão descritos de maneira breve alguns dos modelos associados a cada vista e ao nível de Definição de Requisitos que representam os principais conceitos envolvidos com a modelagem de processos de negócio. 3.3.2.1 A Vista de Funções Segundo ARIS Methods (2001), uma função pode ser definida como uma tarefa técnica ou ação realizada sobre um objeto para suportar um ou mais objetivos de uma organização. De acordo com essa definição, pode-se concluir que a existência de uma função dentro de uma organização só faz sentido se esta estiver associada à pelo menos um objetivo organizacional desdobrado da estratégia de atuação definida. Assim, a ferramenta de suporte a metodologia, ARIS Toolset, apresenta no nível de Definição de Requisitos, conforme pode ser observado nas figuras abaixo, modelos como o Diagrama 34

de Objetivos e Diagrama de Árvore de Função que auxiliam na identificação e entendimento das relações entre as funções e objetivos e suas hierarquias.
Maximizar participação no mercado Reduzir Custos

Lotes de produção Aumentar índices de crescimento Melhorar qualidade Cumprir prazos de entrega Tamanho dos estoques

Penetrar mercado asiático

Controle de Produção

Figura 10: Exemplo de Diagrama de Objetivos Fonte: Adaptada de SCHEER (1999)
Processo de Negócio

Compra

Produção

Venda

Controle de Produção

Plano de Produção

Figura 11: Exemplo de Diagrama de Árvore de Função Fonte: O autor, adaptado de ARIS Methods (2001,p.42)

No exemplo de Diagrama de Objetivos, a função Controle de Produção, representada por um retângulo de bordas arredondadas, está associada aos objetivos, representados por pentágonos no formato de casa, de melhoria de qualidade e ao de cumprimento do prazo de entrega, que por sua vez estão associados aos objetivos hierarquicamente superiores maximizar participação no mercado e reduzir custos. Além 35

No exemplo. determinando para cada função as suas subfunções até que se chegue ao nível de função elementar que não deve ou não pode ser decomposta em unidades menores. em processo de produção que por sua vez é subdividido em processos de planejamento e controle da produção. é muito importante. os fatores críticos de sucesso lotes de produção e tamanho dos estoques devem ser considerados para alcançar os objetivos de cumprir prazo de entrega e reduzir custo.3. processos e objetivos estratégicos da organização. O principal modelo para realizar esse levantamento é o modelo de entidades e relacionamentos (MER) que tem como principal objetivo apresentar a estrutura de 36 . Através da identificação das funções associadas aos objetivos e de suas hierarquias. O Diagrama de Árvore de Função tem como principal objetivo permitir uma análise funcional orientada pelos objetivos associados às funções. as elipses associadas aos objetivos representam os fatores críticos de sucesso atrelados ao cumprimento dos objetivos. por exemplo. Para VERNADAT (1996). expressando de forma clara a especificação para aplicações que suportam as funções.disso. arquivos de banco de dados. que se realize uma modelagem semântica dos dados. conforme pode ser observado em ARIS Methods (2001). não estão no escopo dessa dissertação.2. (VERNADAT.2 A Vista de Dados A quantidade de dados processados e armazenados todos os dias dentro de uma organização é enorme. Assim. (ARIS Methods. Existem outros modelos associados à vista de funções e aos níveis de Projeto e Especificação e Implementação que não foram citados. pois. etc. a função processos de negócio se subdivide. 1996). sendo que a estruturação desses dados em informações pode variar desde uma pequena nota em um pedaço de papel até sofisticados arquivos eletrônicos como guias de usuários. torna-se possível saber quais são as funcionalidades que devem ser executadas para o alcance dos objetivos desejados. o principal objetivo de uma modelagem funcional é a descrição da funcionalidade e o comportamento de uma organização até o nível de detalhamento requerido pelo usuário. 2001). No exemplo. documentos técnicos. 3.

com base em SCHEER (1999) Podemos perceber que. que por sua vez estão relacionados por um losango amarelo que mostra o relacionamento que existe entre as duas entidades. (CHEN apud SILVA. então. Conforme pode ser observado na figura abaixo. poder-se-ia. utilizar o MER para detalhamento de cada cluster. os clusters ou objetos complexos de dados são representados pelos retângulos avermelhados. agregando conjunto de dados relacionados em objetos de dados complexos determinados como clusters. após o mapeamento de uma visão geral dos clusters necessários a uma aplicação.dados de uma determinada aplicação através da descrição das entidades de dados e seus relacionamentos. 37 . representadas por retângulos da cor azul. Modelo de Dados da Organização Modelos de Dados de Manufatura Modelo de Dados de Vendas Pedido do Cliente Cliente Envia Pedido Figura 12: Modelo de Dados com Clusters e ERM Fonte: O autor. enquanto que o MER relacionado ao cluster Pedido do Cliente está representado pelas entidades Cliente e Pedido. 2001) SCHEER (1999) propõe uma modelagem preliminar ao MER que proporcione uma visão macro dos dados que estariam relacionados a uma organização. como mostrado na figura acima.

Com a modelagem do organograma.2. 1996). Gerência de Operações Gerente de Operações Valter Luis Gerência de Manutenção de Processos Gerência de Novos Processos Gerente de Processos João Silva Coordenador do Produto X Claudio Reis Alexandre Figura 13: Exemplo de Organograma Fonte: O autor Uma característica importante da ferramenta ARIS Toolset está relacionado ao fato de que as conexões existentes entre os objetos guardam informações como. relacionamentos de hierarquia entre os objetos de um organograma. 2001. determina a forma como se dá a divisão do trabalho.3. pois. O principal modelo relacionado ao nível de Definição de Requisitos é o organograma que pode ser definido. segundo VERNADAT (1996). essas unidades funcionais são providas de tecnologias para executar um determinado trabalho (ARIS Methods. entre outras informações que agregam valor na análise de um negócio. Além disso. Para 38 . a hierarquia de responsabilidades e coordenação. VERNADAT. indicando quem é responsável pela área funcional e a quem se reporta na estrutura.3. é possível atribuir responsabilidades e determinar quem executará as funções e respectivamente os objetivos definidos na vista de funções.3 A Vista de Organização Uma organização pode ser considerada uma estrutura social complexa. A figura abaixo mostra um exemplo de organograma que pode ser modelado no ARIS Toolset. como uma estrutura hierárquica que define as áreas funcionais ou unidades organizacionais de competência identificadas em uma empresa. A modelagem e a análise da estrutura organizacional de uma empresa podem contribuir bastante na análise dos processos de negócio. por exemplo. constituída de unidades funcionais e que deve possuir regras e padrões para lidar com sua complexidade.

VAC). como eles se concatenam. é a responsável pela integração das demais vistas. O primeiro modelo. 1999). 39 . realizar análises mais precisas da estrutura organizacional.3. Um modelo de processo é normalmente construído com diversos objetos que se encontram nas demais vistas e representa o aspecto dinâmico e comportamental de uma organização (SCHEER.exemplificar. é o responsável por permitir a visão do fluxo de informação dos processos. os EPCs. VAC. Em suma. por exemplo) na organização. permitindo a visualização dos macroprocessos que permeiam a unidade organizacional. Cadeia de Processos Orientada a Evento (Event Driven Process Chain – EPC) e o Diagrama de Alocação de Funções (Function Alocation Diagram – FAD). A partir dele pode-se realizar a navegação logicamente estruturada pelos processos detalhados. Como modelos principais envolvidos na vista de processos. claramente. de forma independente à estrutura funcional prescrita pelos organogramas formais da empresa. ela apresenta como efetivamente a informação percorre as diversas áreas e como o trabalho é realizado. Essas linhas horizontais percorrem as diversas seções. como trafega a informação e os materiais (documentos. entre as diversas áreas. concatenando os diversos EPCs mapeados. 3. as linhas de processo horizontais à organização. é possível. a sua seqüência. a vista de processos ou de controle. pode-se citar a Cadeia de Valor Agregada (Value Added Chain . a linha que liga o João Silva ao cargo de “Gerente de Processos” possui a informação de que o João ocupa aquele cargo e a linha que liga o cargo “Coordenador do Produto X” a unidade organizacional “Gerência de Novos Processos” possui a informação de essa gerência é composta daquele cargo. Com informações relacionadas ao tipo de relacionamento existente entre os objetos. Em outras palavras. por intermédio de relatórios gerados pela ferramenta ARIS Toolset. garante a consistência na interligação dos processos entre seções e desenha.4 A Vista de Processos Segundo ARIS Methods (2001). A construção dos VACs. Facilita sobremaneira a visão macro dos processos mapeados.2. apresenta como é agregado o valor durante a realização das atividades e processos na organização.

Adicionalmente. etc. A partir do VAC poder-se-á acessar. Este modelo serve para representar tanto recursos. dentre os diversos modelos existentes nesta vista. bem como os eventos que as motivam. Além desses modelos. nem indicando conexão à outra seção ou divisão). na ferramenta ARIS Toolset. onde as atividades são representadas pelos objetos verdes. bem como os insumos necessários à realização do mesmo e os produtos por ele gerados. O EPC pode ser considerado. os eventos pelos objetos rosas. existe o FAD que normalmente é utilizado quando se deseja reduzir a complexidade do EPC quando este apresenta muitas informações. Isto pode ser observado na figura abaixo. O segundo modelo. através desse modelo é possível visualizar. vermelho. informações. conhecimentos e documentos necessários para a realização das atividades são representados pelos objetos. meios de comunicação. as interfaces de processos pelos objetos brancos no início e no final do processo e os sistemas. azul. para cada processo. roxo e branco do lado esquerdo das atividades respectivamente. pois. As figuras abaixo mostram um exemplo de um EPC e um exemplo de VAC ‘linkado’ a alguns dos seus EPCs que estão associados a FADs. 40 . sistemas. nem internamente à unidade organizacional. o mais importante.) e os indivíduos ou unidades organizacionais responsáveis pela sua realização. Dessa forma. seus executores. associando a cada atividade os recursos por elas consumidos (relatórios. explicita os links com outras unidades organizacionais e permite a visualização de pontos finais de processos (aonde ele não mais se desenvolve. através do VAC pode ser obtida uma visão agregada dos processos. as unidades organizacionais pelos objetos amarelos. encadeia seqüencialmente as atividades realizadas em um dado processo. utilizando operadores lógicos para descrever a lógica de encadeamento das atividades. qualquer EPC. como insumos e produtos gerados por uma atividade. EPC. clientes e fornecedores.

por exemplo. é o nível de agregação dos modelos que deve estar adequado o suficiente para a realização dos objetivos definidos no projeto. ter 41 .Interface de Processo Evento 1 Organizational unit Atividade Application system type OU Evento 2 Evento 3 Organizational unit Atividade Knowledge category Organizational unit Atividade Document Evento Evento OU Organizational unit Atividade Cluster Evento Interface de Processo Figura 14: Exemplo de EPC Fonte: O autor Macro-processo VAC Processo EPC Detalhamento (Processos) Atividade FAD Figura 14: Exemplo de VAC e EPCs associados Fonte: O autor. o nível de detalhamento dos modelos pode variar podendo. Dependendo do escopo do projeto. 3.4 Nível de Agregação da Modelagem de Processos de Negócio Um aspecto importante a ser considerado dentro de qualquer projeto que venha a envolver modelagem.

Se o objetivo da modelagem for. o nível de detalhamento dos modelos deve ser suficiente para a compreensão dos requisitos de negócio. os objetos e seus relacionamentos. o desenvolvimento de um sistema de informação. em que campos de que telas de um determinado sistema um usuário deve executar a atividade “registrar os dados de um cliente”. por exemplo. as pessoas que são entrevistadas ou que executam a modelagem podem apresentar níveis de conhecimento e de experiência diferentes refletindo no nível de agregação dos modelos. pois. mesmo dentro de um escopo definido podem existir níveis de detalhamento diferentes. existem alguns pontos balizadores que ajudam a identificar o nível de detalhamento adequado (CAMEIRA.um alto nível de detalhamento num projeto de desenvolvimento de sistemas de informações e um nível mais baixo no caso. por exemplo. por exemplo. 42 . funcionais e técnicos que serão necessários para o desenvolvimento e implantação do sistema. é importante saber identificar se o que está sendo descrito não é um procedimento como. Este mesmo autor coloca que apesar de ser uma variável fuzzy. por exemplo. No caso em que o objetivo da modelagem é o rápido entendimento dos macroprocessos de uma organização para definição. por exemplo. CAULLIRAUX. os processos modelados devem ter um grau de detalhamento mínimo para expressar de forma clara esse fluxo de informação e / ou materiais suportado por eles. um baixo nível de detalhamento pode ser suficiente. quanto modelos de dados como. de objetivos estratégicos. 2003 e CAMEIRA. Porém. 2000). o nível de detalhamento é uma variável fuzzy não existindo uma regra exata em sua definição. de um projeto para divulgação de processos referentes à procedimentos operacionais básicos ou em um projeto cujo objetivo é entender de forma rápida os macro-processos que compõem uma organização. os modelos da UML que definem. no caso de um desenvolvimento orientado a objeto. o entendimento do fluxo de informação que atravessa os processos operacionais de uma organização. Quando o objetivo da modelagem é. as classes. Esse processo de desenvolvimento de um sistema de informação engloba tanto modelos de processos de negócio. por exemplo. No caso em que um processo apresenta um alto grau de detalhamento sem necessidade. macros e detalhados. Para CAMEIRA (2003).

por exemplo. Identificados e implementados. validação e redesenho de processos de negócio. Idef 3 . (2002. Cimosa. o Process Performance Management (PPM).3. tais indicadores servem de base para atividade de monitoração da organização como um todo. 3.5 Aplicações da EPN A EPN tem como atividade central o levantamento. desenvolvido pela 43 . algumas ferramentas estão sendo desenvolvidas como. 2000 e SANTOS et al. Benchmarking Modelos de negócios eletrônicos Análises organizacionais . A partir dessa análise dos processos de negócio.5. p. podem ser identificadas diversas melhorias além do desdobramento de diversas frentes e aplicações conforme pode ser observado no texto e na figura abaixo: Integração organizacional Uniformização de entendimentos Sistemas Integrados de Gestão Projeto de sistemas de informação Indicadores de desempenho Gerência do conhecimento Representação. Nesse sentido. Cadeia de Suprimentos Workflow e Gerência de documentos Organização de documentação técnica Figura 15: Engenharia de Processos de Negócio e Aplicações Fonte: Adaptada de SANTOS e CAMEIRA.1 Análises Organizacionais Através da modelagem de processos é possível realizar projetos de organizações orientados pela visão por processos possibilitando reflexão sobre a estrutura organizacional existente e uma possível transição para uma nova estrutura como. a transição de estrutura funcional e muito hierarquizada para uma matricial e até mesmo para uma totalmente orientada por processos. por exemplo. apoiando as tomadas de decisão. modelagem.5.2 Indicadores de Desempenho A modelagem de processos facilita a identificação de indicadores de desempenho locais e globais diretamente relacionados a um determinado processo ou a uma área de uma organização. Análise e Melhorias de processos Redesenho de Processos MÉTODOS: Aris. 3) 3.

a competição se dá entre cadeias e não mais entre organizações. (DAVENPORT. 44 .4 Gerência Eletrônica de Documentos (GED) e Workflow Conforme pode ser observado em SILVA (2001). sendo de extrema importância a realização de parcerias e aquisições de organizações que possuam competências chave para contribuir com o desempenho global da cadeia. um outro desdobramento possível realizado através da modelagem de processos está relacionado a projetos de implantação de sistemas do tipo Workflow e Gerência Eletrônica de Documentos (GED) que tem como objetivo automatizar os processo de negócio e seus respectivos fluxos de informações.5. 3. os modelos originados pela modelagem dos processos representam de forma explícita parte do conhecimento de uma organização que pode ser armazenado. 3.3 Gestão do Conhecimento Através da modelagem dos processos é possível realizar análises dos conhecimentos necessários e disponíveis para a execução das atividades de uma organização.5. produção e distribuição de produtos ao mercado. que tem o intuito de realizar o acompanhamento automático dos indicadores dos processos durante a operação de Sistemas Integrados de Gestão. 2000) 3. passado e reutilizado por qualquer pessoa.IDS Scheer AG. Além disso. A metodologia de modelagem aplicada em um projeto como esse tem como base o desenho e redesenho dos fluxos de processos de negócios e o levantamento da documentação associada a esses fluxos.5 Gestão da Cadeia de Suprimento Como já citado anteriormente. a visão por processos pode ser expandida para além das fronteiras organizacionais sendo aplicada também em cadeias de suprimentos que envolvam diversas organizações que dentro de um cenário colaborativo interajam de maneira integrada através dos processos de fornecimento. Nesse cenário.5. podendo identificar gaps de conhecimento que podem ser preenchidos através de programas de treinamento e capacitações.

entre outros.10 Implantação dos Sistemas Integrados de Gestão A modelagem de processos pode ser usada para apoiar todo o processo de implantação de um Sistema Integrado de Gestão (SIG).5. ou até mesmo compará-los. por exemplo. os modelos de processos podem ser usados para a simulação dessas relações virtuais possibilitando o dimensionamento dos recursos necessários para a implantação desses modelos de negócios. 3. entre empresas e clientes (Business to Customer – B2C).7 Benchmarking Com seus modelos de processos mapeados.8 Modelos de Negócios Eletrônicos Com possibilidade de troca de informações via Internet. 3. baseados nas melhores práticas do mercado. a modelos de outras organizações com intuito de manter competitividade através do ganho de novos conhecimentos que podem gerar novas oportunidades de negócio. o que possibilita visão homogênea e integrada do negócio.5. diversos modelos de negócios virtuais surgem com o intuito de estabelecer vários tipos de relacionamentos entre empresas (Business to Business – B2B).5. procedimentos e manuais. No que tange a essa aplicação.9 Uniformização de entendimentos e integração organizacional A modelagem de processos permite a uniformização de entendimentos sobre a forma de trabalho e a integração das unidades organizacionais através da divulgação dos processos pela organização e da identificação das interfaces organizacionais. Através de modelos de processos com diferentes níveis de detalhamento.6 Organização da Documentação Técnica Uma outra aplicação da modelagem de processos está relacionada a organização da documentação técnica referente à elaboração e revisão de normas. 3.5. passando pela definição da 45 . uma certificação segundo as normas ISO. pode-se ter uma integração consistente entre documentos organizacionais para atender. uma organização pode compará-los com modelos de referências.5. caso tenha acesso.3. 3.

3. sendo. a fase de pós-implantação quando o SIG está em operação. A figura abaixo mostra essa estrutura e a seguir são descritos esses níveis. portanto. necessário o treinamento dos usuários finais do sistema baseado nos processos modelados.11 Projetos de Sistemas de Informação Dentro da Engenharia de Processos de Negócio existem algumas abordagens relacionadas ao desenvolvimento de sistemas de informação e. portanto.2.estratégia de implantação na fase de pré-implantação onde devem ser feitas análises com relação ao tempo de implantação total. por fim. e.3. custos e adaptações do sistema a organização e vice-versa. a fase de implantação propriamente dita onde serão implantados e testados com os usuários os módulos do SIG para verificar sua consistência com os processos modelados e com a estratégia definida na fase anterior.5. aos sistemas de software. Conforme pode ser observado em SCHEER (1998) a estrutura proposta apresenta cinco níveis com o desdobramento dos processos de negócio ao nível de implementação dos sistemas de informação e tem como base a metodologia de modelagem de processos ARIS apresentada no tópico 3. Fonte: SCHEER (1998) 46 . 3. Figura 16: Arquitetura de Processos de Negócio com Desdobramento para Sistemas de Informação.

gestão do conhecimento. materiais. portanto. está relacionado a técnicas de planejamento.No primeiro nível. Engenharia de Processo. simulação para teste de cenários propostos. Planejamento e Controle do Processo. os processos são modelados mostrando como a organização ou conjunto de organizações realiza as atividades relacionadas ao negócio em questão. instalação e operacionalização do sistema. etc. No próximo nível. Além disso. relacionado com o controle de execução dos processos definidos no primeiro nível e com a transição da documentação entre postos de trabalhos. Aplicações. controle e monitoração dos processos. Além disso. O segundo nível. servem de entrada para o controle exercido no nível dois. 47 . os dados (tempo de execução das tarefas.) obtidos nesse nível. definição de requisitos. O desenvolvimento de um sistema de informação baseado na visão por processos apresenta algumas vantagens como a possibilidade de se evitar sistemas redundantes pela organização. etc) estando. definindo capacidade de recursos. pessoal. suportar o projeto e análise de sistemas de informação. alocação de unidades organizacionais. com o intuito de dar suporte ao processamento de objetos de negócio definidos pelos processos modelados no nível um. Em VERNADAT (1996) pode ser observada uma outra abordagem dentro da EPN ligada ao desenvolvimento de sistemas de informação. análise de custos. existe a análise e o projeto de sistemas de aplicações diversas. A proposta do autor procura cobrir todas as fases de desenvolvimento de um sistema de informação. O autor desenvolveu uma estrutura voltada para a construção de sistemas integrados e modulares de manufatura com o intuito de modelar os processos de negócio. definição de implementação. etc. controle de qualidade. selecionar entidades funcionais que devem ser instaladas. a possibilidade de existência de base de dados única. a execução dessas aplicações se dá no nível três. projeto de especificações. Workflow do Processo. levando-se em consideração alguns desdobramentos da EPN como aplicação de modelos de referência. indicadores de desempenho e outros aspectos que servem de parâmetros para a melhoria contínua dos processos definidos no nível anterior. ocorre a gestão do fluxo dos objetos de negócio (informação. passando pelo planejamento estratégico. No último e quarto nível. variando dos mais simples até sistemas corporativos. atender aos requisitos dos usuários. prever o desempenho do sistema e automatizar a produção de códigos do sistema de informação a ser implantado.

entre outros).integrada e consistente. na qual vários requisitos (X-abilities) são consideradas parte do processo de desenvolvimento de produtos (manufatura. No que tange a modelagem de dados. Um outro fator importante em que a EPN pode contribuir com o desenvolvimento de sistemas de informações. Esses requisitos não servem somente para se atingir as funcionalidades básicas do produto. qualidade. "Engenharia Simultânea é uma metodologia de desenvolvimento de produtos. reduzindo o tempo de desenvolvimento de produto e de sistemas de informação. a Unified Modeling Language (UML)5. por exemplo. mas também as informações e dados necessários para o desenvolvimento do sistema. Além disso. pode reduzir o redução do lead time 5 O detalhamento da UML e de seus modelos pode ser visto no capítulo 4.al (2002). é possível compreender o conceito de Engenharia Simultânea. também é importante ressaltar o conceito de Engenharia Simultânea enquanto habilitadora na redução do tempo de desenvolvimento de um sistema de informação. facilita o processo de desenvolvimento. etc. 48 . De acordo com a definição abaixo. 1996) Conforme pode ser observado em CAMEIRA et. 1992 apud PRASAD. a utilização de uma ferramenta Computer Aided Software Enginneering (CASE) que suporte uma linguagem padrão como. serviço. maior eficiência no fluxo de informações que atravessa a organização ou a cadeia na qual está inserida. Nesse tipo de aplicação é importante que sejam modelados não somente os processos. está relacionado à identificação de componentes de processos que podem ser reutilizados para a criação e lançamento de um novo produto no mercado. a utilização do conceito de Engenharia Simultânea no processo de desenvolvimento de um sistema de informação somado a padronização e construção de componentes de processos de negócio associados a componentes de sistema. mas para definir um produto que atenda todas as necessidades dos clientes" (HARTLEY.

49 . em função de sinais do ambiente de atuação das organizações. Figura 17: Projeto de Sistemas com Engenharia Simultânea Fonte: SANTOS (2002. A figura abaixo facilita a compreensão do que foi colocado acima. dotando de flexibilidade a (re)construção de processos e sistemas a eles associados. com o apoio de uma boa ferramenta de modelagem que possa realizar a componentização de processos de negócio. de forma bastante granularizada. e a implementação de um novo sistema de informação. é possível obter as seguintes vantagens: Formalização e padronização da modelagem de processos — isto ocorre devido à possibilidade de associar ‘pedaços’ de processos semelhantes.entre a percepção da necessidade de mudança. Armazenamento de representações reutilizáveis de processos — visando que estas representações possam ser reutilizadas em futuras modelagens. p 115) Conforme é possível observar em CAMEIRA (2003). para dois produtos diferentes comercializados. a identificação do ‘pedaço’ de processo que delimitará um componente de software. Por exemplo. que sejam baseados em sistemas. Auxilia. portanto. funções semelhantes em um sistema que controla os processos de roteamento de equipes de manutenção.

busca-se facilitar o entendimento dos relacionamentos que um sistema deverá suportar. por assim dizer. dotam a organização de maior capacidade de refletir. na cadeia. as necessidades de ajustes decorrentes de variações do ambiente competitivo no qual se insere a organização. Maior facilidade para o gerenciamento dos processos — o uso de ferramentas de modelagem leva a uma maior simplicidade do gerenciamento e manutenção dos processos. pois o foco da ação está. bem como da capacidade de ação sobre eles. à visão do negócio. de produtos ou serviços entregues ao mercado. internamente e externamente. conseqüentemente. a realização da estratégia e dos objetivos do negócio. usualmente de árdua implantação e complexa manutenção. No limite facilita. em seus processos. é diminuído. os esforços futuros em EPN e Engenharia de Sistemas poderão produzir retornos mais substanciais. por desdobramento até o nível de sistema. através dos modelos da UML. dos fluxos de informação entre uma determinada área da organização e suas áreas conexas. apoiados por sistemas e. padronização. armazenamento e conseqüente reutilização. etc. Por exemplo. A partir desta relação. somadas.. Reflexos diretos em custos. minorados. com modelos ‘tradicionais’ da Engenharia de Processo. com a descrição dos processos e suas relações com a estrutura organizacional. 50 .Isto é conseguido relacionando-se a visão de sistemas. o tempo total de desenvolvimento e operacionalização de processos. facilita sobremaneira a operacionalização de sistemas de Workflow. Aumento da flexibilidade frente às variações da demanda — esta maior facilidade e esta capacidade de reutilização. Melhoria das interfaces processuais — refere-se à facilidade de integração sistêmica dos processos. Apoio à melhoria dos processos e do desenvolvimento de sistemas de suporte à operação — a partir da formalização. ‘componentizado’. quais os atributos de uma dada atividade. Aceleração da capacidade de desenvolvimento e de adequação dos sistemas que suportam os produtos e serviços — talvez a principal vantagem.

o autor coloca que após a implantação do primeiro sistema componentizado baseado em processos com grande número de atividades iguais.piloto) C on urar fig RI Serv iço qu e s er tes a é á t do d fam i a a íl Telef ni o a C C R-R N T Ex ecutar t s t e e fim f m de -a. implementação e gerenciamento dos processos nas empresas ocorra de forma mais flexível. em sua arquitetura.N Estornar O rder E ntry par c or e ã a r ç o Centr de o C o urar nfig C onf g. Solu ão de ç Pend c ia ên s Delete c. 11010100 Export control V. Becker V. 51 . reque st Delete c. 11010100 00001001 11001000 10101010 . podendo reaproveitar os componentes de software criados anteriormente.. Dado que processos são suportados por sistemas e a construção destes foi historicamente orientada funcionalmente. request po s. Delete c.RI Verifi ar c e is tê a de x nc i a i f c il dad RI es E PC M ro ac Problem as no a nd ent ge am o do t s t e e fi -a-fim m Tax item Ex s tem i a i f c il dad es de RI N ão ex s tem i a i f c il dad es de RI CC R Intern io l ac na C C R-RI Chamar componente TelefoniaSatélite Componente TelefoniaSatélite chamado Conclusão Técnica (Telefonia e Satélite . 11010100 00001001 11001000 10101010 ... Dessa forma. Analyze c.pi oto) ni l Não e is t x e Anún io c / n I tercepta ã ç o do ti o PAA p Confi u a ã gr ç o PAA Ex is t Anú o e nc i / Interc e ptação do ti o PAA p C onf g a i ur r pl taf r m a o a de a núncio / intercepta ã ç o Pendê a s nc i no te t se prelim inar Tes te prelim inar re alizad c om o s uc ess o Pr og ram ação R egistrar e D espa h c o c on lu ã do c s o (AT) teste pr li inar em Com po nte ne Tel foni e a Sat lit é e cham o ad Não h v e ou em s ã d is o e O TS p a ar o ac e s o s GIC.pil to) a i o Pend c ia ên resolv d a i Centro Local V f ic a s e há er i r necess id e de ad ex te nsão d e s erv ç o i Teste Preliminar (piloto) N ão exis te necess id e de ad e te ã x ns o de serv ç o i C entr o Loc a l Ex is t e nec ess d ad de i e ex te nsão de ser v ço i Coorde nar ex e u ã d c ç o a ex t n ão no es s outro C L´ s s C on exão fí ic a p/ s ex te nsão d e s erv . Um exemplo interessante que pode ser citado são os sistemas ERP que apesar proporcionarem a integração do fluxo de informação transversal à organização.. inquiry pos. 11010100 Houve emissão de OTS para o acesso Chamar componente genérico Sistema Suporte de Telefonia Não houve emissão de OTS para o acesso Rede internacional configurada C riação da Order E ntry Corr e ã d ç o a Or d Ent y er r ( Á ea d M ercad r e o) Configure produc t Order E ntry c riad a Aná e d lis a O rder E ntry G IC-N N ecess ida de de ut li aç ã i z o da Rede E1 Todos o s ite d OE ns a es tã OK o Verif c ar se i Si tem s a dado da OE s por t de e s ão s uf c ie e s p/ Su i nt o a al c a fac .. Stark Configuração de Rede de Serviço (Telefonia .-i age ndad o Verifi ar a c fam a do íli s erv iço que s er t s ta á e do S tem is a S upor t e Serv iço Pend c ia ên r esolvid a CC R.piloto) Veloc d i ade é ab o aix de 2 M One customer Check production costs 1:1 inquiry Product position 1:2 Check decreases and increases Conditions Customer Delivery date Delivery place Quantity Unit Organization EPC M ac ro Tes t e Preli n ar mi ( pi ot ) l o Conc u são l do te t se preli n ar mi r egi tr do s a Prepa ã do raç o C ent o Loc a r l ( p o) ilot Velocid ade é ac im d 2 M e a e ex is t ex te e nsão de serv ç o i Problem s a durant o e age am e o nd nt c om o c lie e nt Pr o gram a ão ç e Despac h o (AT) Téc ni o de c C am po Terc eiri a z da Agend e am nto c / c i ent p l e / r eal z . Bernardy T. mostrando a relação entre processos de negócio.piloto) Implantação de CPE (Telefonia) Use Case Actor Organiza tional unit Org. do CL Com po nte ne genéri o c c ham do a V f ic a s e er i r dad da OE são os s ufi ie c ntes p/ pr e a ç ã d CL par o o C orreç ã da o O rder E ntry ( Área de M ercado) EPC M ro ac Houve em ss ão i de O TSpa a r o acess o Não h v e ou e is s ã de m o OTS para o ac ess o R ed E1 e c onfi ur d g aa Pr ice infor mation [c om pleted] Convey export chec k Dad d os a O E n s ão ão s uf c e nt s p/ i i e prep do CL .. limitando qualquer implantação de inovação em termos de processos de negócio. 11010100 00001001 11001000 10101010 . 11010100 Conclusão do teste preliminar registrado Pr o gram a ão ç e Despac h o (AT) C ent o r L a oc l Ex ecutar c on õ para ex es o c ircuit o Testar fiaç õ e es ex t n õe es s R egi trar s c onclu ão s da pre para ã ç o d C e r o Lo a o nt c l Verif c ar i v elo ida c de e ex te nsão de serv ç o i Sis t m a e Suport e Serv iço Pr epa ç ão do ra C ent o Loc a r l (pil to) o Veloc d i ade é ac m a de 2 M e i ex s te ex t nsão i e de serv ç o i C ent o r L a oc l C ent o r L a oc l Agend c om o ar c lient d p e ata / realização d o tes t pr lim e e inar Veloc d a é i de ac m a de 2 M e i ex s te ex t ns ão i e de s erv ç o i T te es Prelim inar (pil to) o Request item 1 Check price Configuração de Funcionalidades de Serviço (Telefonia . Sales processing Windows client Análise da Order Entry (piloto) Order Entry aceita (integral ou parcialmente) Verificar localização do Centro de Cliente Determine customer request Applicatio n frame M. 11010100 00001001 11001000 10101010 . rede Verifi ar se c é ne es sário c Config ç ão E1 ura aprov s o n i i ar red E1 e Da dos da O E não s ã o s uf c ie s p/ i nte alocar a c . inquiry pos. inquiry pos.i Telef ni o a S v ç o qu er i e s er testa é á do da fam a íli Sat li e ét As s is t n a ê ci Téc ni a c Ex ecutar e s e t t i f m a-fi de m Sat li e ét Sistema Suporte de Telefonia RI c onf g i urad a Problem s a na real z a ã i ç o do tes t e i f m a-fi m EPC M a r o c GIC. Read c. texts Delete c. request pos.N R ed e int r n o na e ac i l c onfig a da ur Age ndarte te s i f m a-fi m Solução de P endên a s ci C on lu ão c s do t s t e e prelim inar regis t ad r o 1:3 Check value-added tax Tes te fim a f m .. reque st Analyze c. n° Acesso obtido Rede E1 configurada M. uma visão por processos..pi oto) ni l Dad d OE os a s ão s ufi ie s c nte p/ alocar fac . re f de Solução de Pend ência s G IC-N N ecess ida de de confi u a ã gr ç o de R e de de S vço er i R ed E1 e c on urad fig a Ac e s o s obti o d EPC M ac ro É necess ár o i aprov s o n i i ar red E1 e N ão é nec ess á rio aprov s o n i i ar r ed E1 e Épos s í e v l faz erv al d ão i aç parc ia l Pend ência resolv d a i Não é poss í el fa er v z v al da ão i ç par ia c l Preparação do Centro Local (piloto) C i ur r C CR -R NT onf g a RTD C Verifi ar se c Si tem a s hou e em s são v i por t de e de OTS pa ra Su Telef ni o a o aces s o Centr de o c i ent n l e o ex t r o r e i i ar C onf g a ã E1 Aprov s ion i ur ç o R ed E1 e G C -N I E PC M ro ac Ac ei ar t Or d Ent y er r ( n tegr l o i a u parc a lm en ) i te Or d Ent y er r ac ei a ( n t gra t i e l ou p a lm e arc i nte) GIC -N Es o r n t en t ar i s não OKpara c orr ç ão e GIC. inquiry pos.. 11010100 00001001 11001000 10101010 . texts Read c. Modify c. reque st Read c.. Modify c. Bernardy User input Editor Check GIC-N Marketing Precheck Sales processing Production planing Centro de cliente no exterior Centro de cliente no Brasil Identificar a próxima fase do processo de telefonia Sistema Suporte de Telefonia Application server 00001001 11001000 10101010 . Como exemplo. realizad a Customer inquiry [texts determ ined] Customer inquiry positions Article Date One customer inquiry position 00001001 11001000 10101010 ..piloto) Open cus tomer inquiry Custom er inquir y [created] Customer text (created) Cus tomer r eques t [product configured] Custo mer Customer n° Create custo mer data Delete custo mer data Cha nge custo mer data Analyze c. Analyze c.. d teste i o pr el m i inar OK Ac o na Téc n i r ico de C a po o m u terc eirizad p a / v s ita ao c li nte i e Solic t ar t s te i e c ont n ad i uid e c om Cent o r Loca l Reali ar z tes e t preli inar m EP M ro C ac N ecess ida de de config ç ão ura de fun o nal d es ci i ad de s erv ç o i Téc ni o de c C am po Confi ura ã g ç o PAA Verifi ar c ex is tê a nc i de a nc io nú Terc eiri a z da EPC M ac ro RI configurada Não existem facilidades de RI C onf g a ã i ur ç o de Rede d e Serv iço (T elefo a . Na figura abaixo é possível visualizar a situação descrita acima. request pos. muitas vezes as organizações acabam ficando "engessadas" tendo que se adaptar aos sistemas de informação.i reali a z do c om s u e so c s At v ar i e t c nicam e ent o s er iço v At v aç ã i o téc nica d c ir uit o c o conc u íd l a Create c. inquieries Customer inquiry positions Create c. o desenvolvimento do segundo passa a ser focado apenas nas diferenças.Segundo CAMEIRA (2003) a componentização de processo pode reduzir os tempos de desenvolvimento dos sistemas de informação. modelos da UML e componentes de software.. Stark Master data GIC-N Customer requests Human resource Necessidade de utilização de acesso Necessidade de utilização da Rede E1 Necessidade de configuração de Rede de Serviço Necessidade de configuração de funcionalidades de serviço Necessidade de implantação de CPE Customer order Master data administration Obtenção de Acesso Facilidades de Rede (Telefonia . pois identificado padrões de comportamento e soluções implementadas pelos processos de negócio é possível criar uma biblioteca de componentes de processo e relacioná-los a componentes de software.. 11010100 Pend c ia ên resolv d a i Processo Central (“chama” os processos componentizados) Banco de Dados de Processos Componentizados Conjunto de Modelos da UML Figura 18: Componentes de Processos e de Sistemas Fonte: CAMEIRA (2003) Uma outra discussão atual que vem ocorrendo sobre processos de negócio é a respeito da criação de novas arquiteturas de sistemas que possibilitem a definição. r e o r de Telef ni Anal s ar i O rder E ntry Or d Ent y er r c orrigi a d Ex istem itens d O E a que nã o es t o O K ã Customer text Customer text (read) (modified) Customer text (created) Custom reques t er [ex port control executed] Proces s documents G IC-N Regis t ar r obj ções e Verifi ar se é c p s í e f z er os v l a v ali ação d parcia l Determine price P ric e infor m ation [Bas e price determ ined] Determine s urcharges / disc ounts Determine taxes Tax information Customer inquiry texts Create c.N Sol ç ão d u e Pend ênc a is Tes te fim f m -a. request po s. Article Article n° 00001001 11001000 10101010 . Super vise customer order Velocidade é acima de 2 M e existe extensão de serviço EPC M ro ac Velocidade é abaixo de 2 M C onf g i uraç ã de o Fu o na de nc i lida s de Se iç o rv (T elefon . a questão é como fazer para que os sistemas retratem. possibilitando que a organização se oriente para processos. Read c. texts Modify customer text Componente genérico chamado EPC M acr o Fac il da s i de O bten ã ç o de Rede de Acess o (T elefo a . d R e i e de r ed e n I tern io l n tern io l ac na i ac na R ed e n tern io l i ac na c onfi ur d g aa nfig Config ç ão E1 C o urar ura R ed E1 e Centr o Loca l C L da pla rm a tafo Confi ura ã g ç o de Rede d e Serv iço (Telef ni ) o a Dados d a OE s ão s ufi ie c ntesp/ prep. 00001001 11001000 10101010 .. eles não permitem que estes mesmos processos sejam alterados e gerenciados com facilidade. request po s. request pos. da ta Customer inquiry Date Create c....

pode proporcionar para uma organização.Essa discussão gira em torno do que foi considerado por SMITH e FINGAR (2003) como a terceira onda do Business Process Management (BPM)6. das informações trocadas nas interfaces organizacionais. Os autores afirmam que os novos sistemas criados a partir dessa nova onda. 3. teriam suas arquiteturas centradas em processos e poderiam ser totalmente desenvolvidos sem precisar dos processos de desenvolvimento de software tradicionais inerentes a Engenharia de Software. onde os processos de negócio são o foco principal para o desenvolvimento de sistemas de informação tendo influência direta nas arquiteturas dos sistemas.1 Uniformização de Entendimentos sobre a Forma de Trabalho A modelagem de processos. a difusão das relações de trabalho entre as diversas unidades organizacionais que passam a entender melhor e a ter uma visão homogênea do negócio. 2003). Analisado os principais desdobramentos da EPN o próximo tópico vai mostrar os principais ganhos gerados pela utilização da EPN. principalmente. fica clara a importância da visão por processos possibilitada e suportada pela TI na automatização desse fluxo e no melhor entendimento. 3.6 Ganhos Gerais Esperados com a EPN A EPN em suas diversas aplicações pode gerar alguns ganhos importantes para as organizações. 6 As duas primeiras ondas foram respectivamente a Administração Científica e a Reengenharia de Processos.6. 3. 52 .2 Melhoria do Fluxo de Informações Considerando-se que um dos principais objetivos da modelagem de processos é a identificação do fluxo de informações que corta uma organização. através da visão por processos. conforme citado nos tópicos a seguir (SANTOS. idealmente realizada com uma mesma ferramenta e notação.6.

pois.5 Redução de Tempo e Custos dos Processos A modelagem de processos proporciona a oportunidade de identificação e melhoria de problemas relacionados ao seqüenciamento das atividades. é uma premissa básica para a consolidação e alavancagem da visão por processos dentro da organização que passa a trabalhar orientada total ou parcialmente a processos.6.6. entre outros que estão diretamente relacionados à redução de tempo e custos operacionais.4 Melhoria da Gestão Organizacional A associação dos processos modelados com indicadores de desempenho locais e globais proporciona melhorias na gestão organizacional em termos de monitoramento. controle e coordenação do trabalho. entre outras. diante de um referencial de conformidade com uma mesma linguagem de modelagem (modelos com uma mesma notação) compreendida por todos.7 Considerações Finais Este capítulo procurou mostrar os principais conceitos.6. atividades que não agregam valor ao produto final.3. 3. 3. 3. ferramentas.6. Dentre os principais conceitos apresentados a capítulo procurou focar no entendimento e importância da utilização da visão por processos e da tecnologia da informação para a modelagem de um negócio. fica mais fácil definir um padrão de modelagem e representação dos processos de negócio. Dentre as aplicações da EPN.6 Aumento da Conceituação Organizacional sobre Processos Este ganho está relacionado diretamente a todos os demais ganhos. ressaltando a importância da integração e 53 . metodologias. foi dado destaque ao desdobramento para desenvolvimento de sistemas de informação. 3.3 Padronização dos Processos Este ganho está diretamente relacionado à uniformização do entendimento da forma de trabalho. alocação de recursos. pois. aplicações e ganhos da Engenharia de Processos de Negócio.

será descrito no próximo capítulo os conceitos e modelos associados a Unified Modeling Language (UML). 54 . considerada pela Object Management Group (OMG) como linguagem padrão de desenvolvimento de sistemas de software. seus processos e os sistemas que o suportam.do alinhamento entre a estratégia concebida para um negócio. Para entender melhor a relação entre a EPN e sistemas de informação.

construir. visualizar.1 Definição e Histórico da UML A UML é uma linguagem para especificar. bem como para modelagem de negócio e outros sistemas que não são softwares. Ela representa uma coleção das melhores práticas de engenharia que tem sido aprovadas com sucesso na modelagem de sistemas complexos e de grande escala (OMG Unified Modeling Language Specification. Para LARMAN (2000) a UML é uma notação para modelagem de sistemas.. A definição acima talvez seja a definição mais completa sobre a UML. 2003). construção e documentação de artefatos que fazem parte do processo de elaboração da estrutura de projetos de sistemas complexos de software (BOOCH et al. apresenta vocabulário e regras 55 . Em sendo uma linguagem. usando conceitos orientados a objeto. Independente da definição é possível observar que a UML é antes de tudo uma linguagem de modelagem. mostrando seus principais modelos e os papéis destes dentro de um processo de modelagem orientado para o desenvolvimento de sistemas de software. existem outras definições de outros autores.4 UNIFIED MODELING LANGUAGE (UML) Este capítulo tem com principal objetivo apresentar o histórico e descrever as principais características e conceitos atrelados a Unified Modeling Language (UML). 2000). especificação. Porém. Segundo BEZERRA (2002) a UML pode ser definida como uma linguagem de modelagem visual com um conjunto de notações e semântica correspondente para representar visualmente uma ou mais perspectivas de um sistema. 4. e documentar artefatos (documentos) de sistemas de softwares. a saber: A UML é definida como uma linguagem padrão para a visualização.

muitas linguagens e métodos foram desenvolvidos e muitos usuários tiveram problemas de encontrar uma linguagem que pudesse cobrir todos os aspectos relacionados ao desenvolvimento de uma arquitetura de software (FOWLER e SCOTT. suportar arquiteturas de diversos níveis de complexidade dentro de diversos domínios de desenvolvimento de sistemas. indicando quais artefatos serão produzidos. através de uma única semântica e notação. que eram até então considerados e reconhecidos como os principais métodos orientados a objeto. A UML tem como principal motivação para sua criação a necessidade dentro da comunidade de desenvolvimento de softwares da existência de uma linguagem padrão que possa. 2000). porém. A criação e o momento da criação dos modelos vai depender da metodologia adotada que além da presença da UML deve também apresentar os principais passos do processo de desenvolvimento. a UML por si só não associa e não relaciona seus modelos com uma metodologia / processo de desenvolvimento de software. o Object-Oriented Software Enginneering (OOSE) de Ivar Jacobson. Além disso. e criaram o Método Unificado apresentado à comunidade de software em Outubro de 1995 na conferência de OOPSLA 95.próprias que orientam a criação e a leitura de modelos bem formatados. resolveram em outubro de 1994 juntar seus métodos. percebendo essa dificuldade. por exemplo. 56 . surgem na primeira metade da década de 90 diversas propostas de técnicas de modelagem de sistemas orientados a objeto como. Logo. Object Modeling Technique (OMT) com a participação de James Rumbaugh. a “Guerra dos Métodos” parecia ter chegado ao fim. durante a conferência. Esse período que durou de 1889 a 1994 ficou conhecido como “Guerra dos Métodos”. com a junção dos três principais métodos num esforço de estabelecer um único. A partir desse momento. Diante da necessidade da existência de uma linguagem padrão e com o surgimento das técnicas de análise orientada a objetos na década de 90. pelo fato de não ser um método. anunciaram a compra da empresa Objectory pela Rational Software e que Ivar Jacobson iria se juntar à equipe. o Método Booch de Grady Booch. os especialistas Grady Booch e Jim Rumbaugh. já citados acima. pois. ambos funcionários da empresa Rational Software. quem irá produzi-los e de que maneira esses artefatos irão medir e controlar o projeto como um todo. entre outros. não indicando quais modelos devem ser criados e nem quando criá-los dentro de um projeto de desenvolvimento de software.

de forma breve. diversas modificações propostas por diversos colaboradores de diversas empresas foram feitas na UML com o intuito de torná-la mais clara e útil.org). a UML tem como principal base para seu desenvolvimento à orientação a objeto e. as principais características da orientação a objeto.5 lançada em março de 2003 e sua especificação pode ser obtida gratuitamente no site da OMG (www. A idéia de se criar um sistema com a tecnologia de objeto teve alguns pensadores dentre os quais pode-se citar Alan Kay. trabalharam seu método sob o novo nome de Unified Modeling Language (UML).1 foi escolhida pela OMG como linguagem padrão qualquer tipo de desenvolvimento de sistema orientado a objeto. a Smalltalk uma das linguagens pioneiras no mundo dos objetos. antes de falar sobre a linguagem UML cabe ressaltar. diversas organizações submeteram a OMG propostas para um padrão de metodologias e dentre essas propostas estava a versão 1. Atualmente. por isso. 4. mas logo em seguida a UML já então na versão 1. gerando com isso a elaboração de novas versões. 4.0 da UML da Rational. um dos pais do paradigma da 7 O OMG é um consórcio internacional de empresas que define e ratifica padrões na área da orientação a objeto (www. Assim. alguns especialistas da comunidade de metodologia orientada a objeto ainda relutavam contra a UML enquanto padrão e foi necessária a criação de uma força de trabalho conhecida como Object Management Group (OMG)7 para julgar e definir um método único orientado a objeto.Em 1996 os três especialistas. conhecidos também como os três amigos.2 Principais Conceitos Básicos da Orientação a Objeto – Visão Geral Como foi possível observar acima. 57 .omg. Porém.1 O Paradigma da Orientação a Objeto A orientação a objeto tem sido foco de discussão dentro do meio de desenvolvimento de sistemas desde a década de 80 quando os objetos começaram a sair dos laboratórios de pesquisa e começaram a se concretizar no mercado sob a forma de linguagem de programação como. Houve ainda um pequeno período de discussão sobre os métodos analisados.2.omg. por exemplo.org). em janeiro de 1997. Desde então. a UML já se encontra na versão 1.

etc. Leonardo. Alan Kay conseguiu estabelecer alguns princípios da orientação a objeto. ser humano. faz seu pedido e fala o endereço de entrega. Classes são organizadas em hierarquia. anota o pedido. interagiria com outras células através de mensagens com o intuito de realizar um determinado objetivo. é um tipo de animal. Esses princípios podem ser observados no comportamento humano como. Através dessa analogia. Marcos) que colaboram entre si para que o objetivo final seja alcançado. que o paradigma da orientação a objeto apresenta uma conexão com o mundo real onde existe um elemento qualquer (pessoa. (BEZERRA. é o de entregar o produto no endereço especificado. através da chamada “analogia biológica”. até o momento pode-se confirmar os dois primeiros princípios listados acima. separa o produto e entrega-o a Marcos. João. o funcionamento de um sistema semelhante ao funcionamento de um ser vivo. Cada objeto pertence a uma determinada classe que.). agrupa objetos similares. João. confirmando o último princípio. por exemplo. o atendente. liga para a farmácia. João. o atendente. produto. Ou seja. incluindo Marcos. Em seguida. a saber. Além disso. etc. Objetos realizam tarefas através da requisição de serviços a outros objetos. denominado de objeto. no processo de entrega em domicílio de um remédio. por sua vez. através do exemplo acima. O comportamento esperado de qualquer entregador. que vislumbrou. que é considerado uma entidade autônoma que contem seus próprios dados que são manipulados através dos processos 58 . que também é mamífero. em sendo uma unidade autônoma. animal.. o produto chega às mãos do cliente pelo entregador. Nesse sistema. Finalmente. confirmando-se o quarto princípio. 2002): Qualquer coisa é um objeto. Nesse pequeno processo é possível observar que há diversos objetos (Leonardo. Classe é um repositório para comportamento associado ao objeto.orientação a objeto. confirmando o terceiro princípio de que Marcos em sendo considerado um objeto pertence à classe entregador. cada célula cada célula. um cliente. Nesse processo. Por fim. o entregador. o comportamento esperado pelo Marcos é o mesmo de qualquer outro entregador. Pode-se perceber.

pode ser denominada de classe de objetos ou simplesmente classe. um cliente. Uma classe para o autor pode ser definida como um agrupamento de objetos similares que apresentam os mesmos atributos e operações. evento. O mesmo autor considera que na terminologia da orientação a objeto uma idéia que forma na mente humana como. lugar. onde cada objeto tem tarefas específicas para realizar e que é através da interação e da troca de mensagens entre esses objetos que se realiza uma tarefa de âmbito maior onde todos contribuem para sua execução. pode-se dizer que a tecnologia de objetos permite a criação de um sistema de software com uma coleção de objetos. pode-se perceber que uma classe pode ser encarada como uma abstração das características de um conjunto de elementos (objetos) do mundo real. altura. Num projeto de desenvolvimento de sistemas. uma venda. alguns dos principais conceitos da orientação a objeto. Para o mesmo autor. Segundo BEZERRA (2002) um objeto pode ser representado por qualquer coisa do mundo real como. A seguir serão colocados. relatório ou conceito que possa ser aplicado a um sistema. um pedido de compra. tela. com outros objetos para alcançarem um objetivo comum. por sua vez.definidos para próprio objeto que. etc. 59 . Os atributos de um objeto definem os dados de um objeto. interage. coisa. 4. de forma breve. por exemplo. etc. uma classe. um fornecedor.2 Objeto e Classe Para AMBLER (1998) um objeto pode ser definido como qualquer indivíduo. Os objetos da idéia cavalo seriam cavalos com características diferentes como raça. deve representar uma abstração de apenas características relevantes do mundo real que venham a se enquadrar dentro do escopo do projeto. por exemplo. através de mensagens. enquanto que as operações definem as funcionalidades de um objeto determinando e que ele faz. Para FURLAN (1998) um objeto é uma ocorrência ou instância específica de uma classe e é um elemento do mundo real. A partir dessa analogia com o mundo real. Com as definições acima.2. uma classe é uma categoria de objetos semelhantes e caracteriza-se como uma planta baixa a partir da qual os objetos são criados. a idéia cavalo.

4. processa a ordem (operações) e entrega o produto final (mensagem de conclusão da ordem de produção). A única coisa que um objeto deve saber com relação a outros é qual é a sua interface. mantendo-se a autonomia dos objetos. ou seja.4. A lógica funciona como o funcionamento de uma indústria de manufatura. utiliza matéria prima (atributos). 4. quais tarefas realizam e o que eles conhecem. pode ser necessário reescrever demais partes do código. pode-se dizer que o encapsulamento restringe o acesso a esse comportamento por parte de outras classes ou objetos. pode-se citar como exemplo o desenvolvimento de kits de soquetes para porcas (objetos). Para que cada objeto execute suas operações é necessário que este receba um estímulo através de uma mensagem enviada por um outro objeto. ou seja.5 Polimorfismo O conceito de polimorfismo significa a capacidade de abstrair várias implementações diferentes através de uma única interface.4 Encapsulamento Partindo-se do pressuposto de que classes e objetos realizam operações e. onde um objeto pode enviar uma mensagem para objetos semelhantes que implementam sua interface de diversas formas. A grande vantagem de utilizar o conceito de encapsulamento é a de evitar um código de programação de acoplamento forte. Em termos de desenvolvimento de sistemas orientados a objeto. os objetos trocam mensagens entre si para realizarem alguma tarefa no sistema no qual estão inseridos. por exemplo. A maneira como eles implementam sua interface. onde o chão de fábrica recebe uma ordem de produção (mensagem enviada. Para melhor compreensão desse conceito.2.2. quando isso ocorre. possuem um comportamento. como eles realizam tais tarefas não interessam uns aos outros. pois.2. Esses soquetes (operações) 60 . por tanto.3 Mensagem Um outro conceito importante dentro da orientação ao objeto é o conceito de mensagem. ao se fazer uma mudança em uma parte do código. pelo PCP).

é importante que sejam desenvolvidas classes com baixo acoplamento e alta coesão. através de uma única interface que é o conector comum. estabelecendo-se uma hierarquia de classes. O conceito de coesão mede o quanto uma classe e suas operações fazem sentido. evitando-se dessa forma maiores esforços com manutenção do código de programação. Ao ser criada. 61 . várias porcas de diversos tamanhos ou classes diferentes de porcas poderão ser apertadas ou implementadas.apresentam diversos tamanhos cada um adequado a um tipo de porca (classe) e possuem na sua parte traseira um conector comum (mesma interface) que se acopla a uma chave de torção (objeto). pois. O principal objetivo é maximizar a coesão para assegurar um agrupamento consistente de operações na classe. 4. Tal conceito está diretamente relacionado com o conceito de encapsulamento que delimita esse nível de conhecimento entre classes e objetos. para desenvolver um sistema com um baixo custo e com uma manutenção simples. uma classe pode ser definida como uma abstração de um conjunto de objetos que apresentam características e comportamentos comuns. onde uma classe pode assumir o papel de classe pai ou superclasse e dar origem a uma classe filho ou subclasse. Ou seja. esses dois conceitos talvez sejam os conceitos mais importantes dentro da orientação a objeto.7 Acoplamento e Coesão Para AMBLER (1998). 4. a subclasse herda todas as propriedades e comportamentos da superclasse evitando-se replicar trechos do código de programação.2. A aplicação do conceito de polimorfismo está na aplicação de uma operação comum (polimórfica) que é a de girar uma chave de torção acoplada a um soquete que funciona para qualquer tamanho ou classe de porca. O conceito de acoplamento está diretamente relacionado ao quanto às classes estão interconectadas referindo-se ao quanto uma classe conhece da outra.2.6 Herança Como citado anteriormente. porém aplicada entre classes. O conceito de herança apresenta a mesma lógica de abstração.

porém sempre com a preocupação de não redefinir os principais conceitos para cada situação nova que aparece. Oferecer mecanismos de extensão e especialização dos principais conceitos: A filosofia da OMG com relação a UML está relacionada ao constante desenvolvimento da linguagem através da análise de novas necessidades e de novos domínios de aplicação que venham a surgir.4.3 Objetivos da UML Como pode ser observado em OMG Unified Modeling Language Specification (2003). Em sendo necessário tratar uma nova situação não contemplada pelos principais conceitos da linguagem. notações e restrições para um domínio de aplicação particular. mantendo a UML dentro de um mesmo padrão. 62 . sem ter que mudar os conceitos principais. portanto. os principais objetivos da UML são: Fornecer aos usuários uma linguagem de modelagem expressiva que ajude no desenvolvimento e na troca de modelos significativos: É importante que o padrão de Análise e Projeto Orientado a Objeto suporte uma linguagem de modelagem que possa fornecer aos usuários um conjunto de conceitos de modelagem que são aceitos por muito métodos e ferramentas de modelagens. podem criar novos conceitos e notações para atender situações não contempladas pelos conceitos principais e devem poder especializar conceitos. Dessa forma. bem suportados por uma linguagem padrão como a UML. os usuários da UML devem poder criar modelos usando os principais conceitos sem ter que utilizar os mecanismos de extensão para aplicações normais. a UML dispõe de mecanismos de extensão que possam suportar exceções. Tais conceitos são necessários em muitos projetos de diversas áreas de desenvolvimento e aplicação de sistemas sendo.

Esse metamodelo serve como referência de modelagem e ponto de partida para que os usuários da UML compreendam suas notações. permitindo a troca desses modelos entre usuários sem a perda de informações. os fornecedores de softwares de modelagem passam a ter que desenvolver ferramentas que suportem os modelos da UML. Logo. 2000). 63 . 8 Metamodelo pode ser definido como um diagrama que define a notação de uma linguagem. ajudando ao usuário na definição e criação de um modelo bem formado e sintaticamente correto. (Fowler e Scoot. Fornecer uma base formal para entendimento da linguagem de modelagem: A UML fornece através da utilização de um metamodelo8 expressado por diagramas de classes (um dos diagramas que compõem a UML) uma definição formal do formato estático de um modelo. Estimular o crescimento do mercado de ferramentas voltadas para orientação a objeto: Através a existência de uma linguagem de modelagem padrão.Suportar especificações que sejam independentes de qualquer linguagem de programação e processo de desenvolvimento: A UML pode suportar qualquer linguagem de programação razoável e vários métodos e processos de desenvolvimento e construção de modelos sem muita dificuldade. isso também leva a uma padronização e uma maior interoperabilidade entre as diversas ferramentas do mercado.

a leitura da notação e a criação dos modelos que formam a linguagem tornam-se mais fáceis. componentes e nós) que são as partes mais estáticas do modelo. alguns mecanismos comuns aplicados na UML. frameworks e padrões: A possibilidade de suportar esses conceitos faz com que a UML possa obter um melhor aproveitamento dos benefícios do desenvolvimento orientado a objeto e do reuso de práticas.1 Blocos de Construção Existem três tipos de blocos de construção que são os itens. explicados abaixo. modelos. resumidamente.4. os diagramas que agrupam coleções de itens. os itens comportamentais (interações 64 . colaborações. colaborações. Dentro dos itens. interfaces. arquiteturas.4 Conceitos Básicos da UML Definidos os principais objetivos da UML. tecnologias de implementação. Integrar a melhores práticas: A principal motivação para o desenvolvimento da UML tem sido integrar as melhores práticas de modelagem do mercado. códigos e arquiteturas comuns de projeto. casos de uso. Para uma melhor compreensão da linguagem. é importante entender que para compreendê-la é necessário conhecer o modelo conceitual da linguagem que tem como base três elementos principais: os blocos de construção básicos. esses três elementos serão. que são abstrações identificadas como cidadãos de primeira classe de um modelo. os relacionamentos. Com a compreensão desses elementos. domínios de aplicação. que reúnem os itens e. as regras que determinam como tais blocos podem ser combinados e. por fim. 4. classes ativas. englobando uma grande variedade de vistas baseadas em diferentes níveis de agregação.Suportar conceitos de desenvolvimento de alto nível como componentes. entre outros fatores que fazem da UML uma linguagem que passa a ser vista como uma integração das melhores práticas. ainda existe uma subdivisão sendo estes classificados em itens estruturais (classes. 4. por fim.

de atividades. O primeiro deles é a dependência que se caracteriza com um relacionamento semântico entre dois itens. O quarto e último tipo é a realização que é um relacionamento semântico em que um classificador especifica um contrato9 que o outro classificador garante executar. definindo o que deve ser feito pela operação e não o como. de componentes e de implantação. O terceiro tipo é a generalização que é um relacionamento de especialização / generalização nos quais nos os filhos (objetos dos elementos especializados) são substituíveis por objetos pais (objetos do elemento generalizado). de gráfico de estados. por exemplo. como terceiro e último elemento dos blocos de construção tem-se os diagramas da UML que são a representação gráfica de um conjunto de itens e relacionamentos e permitem a visualização de um sistema sob diferentes perspectivas que devem estar consistentes com as cinco vistas da arquitetura de um sistema complexo de software.. O segundo tipo é a associação que é um relacionamento estrutural que descreve um conjunto de conexões entre objetos como. Normalmente são expressos por mudanças de estado definidas por pré-condições e pós-condições (LARMAN. podendo ser encontrado entre interfaces e classes ou componentes que as realizam ou entre casos de uso e as colaborações que as realizam. Como no caso dos itens. 2000). 65 . de colaborações. os itens anotacionais (nota) que são partes explicativas dos modelos caracterizando-se por comentários para descrever. vista de projeto. por fim. Por fim. de casos de uso. vista de implementação e vista de implantação.e máquinas de estado) que são as partes dinâmicas dos modelos e representam o comportamento dos modelos no tempo e no espaço. nos quais a alteração do item independente pode alterar o item dependente. C. a UML inclui nove diagramas: diagrama de classes. esclarecer e fazer observações sobre qualquer elemento do modelo. vista de processo. de objetos. também existe uma subdivisão dos tipos de relacionamentos que podem existir entre os itens. 9 Um contrato pode ser definido como um documento que descreve o que uma operação se compromete a atingir. os itens de agrupamento (pacotes) que são as partes organizacionais dos modelos da UML caracterizando blocos em que os modelos podem ser decompostos e. a saber: vista de caso de uso. De acordo com essas visões. a agregação que é um tipo de relacionamento entre o todo e suas partes. de seqüências.

Como exemplo. Além disso. Para tal. Adornos – Um adorno pode ser considerado um tipo de especificação que ajuda a representar. integridade (como os itens se relacionam de forma integrada e consistente) e execução (o que significa executar ou simular um modelo dinâmico).3 Mecanismos da UML Dentro da UML existem quatro mecanismos básicos que ajudam na compreensão e simplificação da linguagem: Especificações – Para cada notação gráfica da linguagem existe uma especificação capaz de oferecer uma declaração textual da sintaxe e da semântica do bloco de construção em questão. Divisões comuns – Dentro da modelagem orientada a objeto existem 66 . muitos detalhes da respectiva notação.4. visibilidade (como os nomes podem ser vistos e utilizados pelos outros).4.2 Regras da UML Os blocos de construção citados anteriormente não podem ser aleatoriamente combinados sem que haja regras para facilitar a elaboração de modelos bem formados semanticamente consistente. 4.Os diagramas citados serão mais bem detalhados mais adiante mostrando seus papéis dentro do processo de desenvolvimento de um sistema e suas respectivas notações. Como exemplo. pode-se citar para o caso do item estrutural classe o sinal “+” que ao ser colocado na frente de uma operação indica que esta operação é pública e pode ser visualizada por outros objetos. a UML dispõe de regras semânticas para nomes (quais nomes podem ser atribuídos a coisas). escopo (o contexto que determina um significado específico para um nome). a arquitetura também citada acima será mais detalhada mostrando o relacionamento das vistas com os diagramas. pode-se citar o item estrutural classe que visualmente pode apresentar apenas parte de sua especificação que engloba a descrição de um conjunto completo de atributos. através de textos ou gráficos. 4. operações e comportamentos da classe.

com o terceiro mecanismo é possível ampliar as semânticas dos blocos de construção. sendo a primeira relacionada com as classes e objetos onde uma classe é uma abstração e um objeto é uma manifestação concreta dessa abstração e a segunda relacionada com a separação entre interface e implementação onde uma interface representa um contrato e a implementação representa a realização completa desse contrato. Para executar essas tarefas. permitindo a inclusão de novas regras ou modificar as já existentes. gerentes de projetos. considerando aspectos relacionados à estrutura. os autores da UML sugeriram a subdivisão de uma arquitetura de um sistema em cinco vistas (BOOCH et al. gestão e controle do projeto. por fim. a construção e a documentação de sistemas complexos de softwares. ao desempenho. Diante da necessidade de se visualizar um sistema sob várias perspectivas. mas todas elas estão interligadas de alguma forma: 67 . à funcionalidade. valores atribuídos e restrições. 2000).5 Arquitetura da UML Conforme definido anteriormente. Com o primeiro. etc. Com o segundo. o vocabulário da UML pode ser ampliado com a criação de novos blocos de construção derivados dos já existentes. cada vista tem um foco em determinado aspecto do sistema. 4. Conforme pode ser observado na figura abaixo e no texto abaixo.basicamente duas formas de divisão. ao comportamento. podem ser criadas novas informações na especificação de um bloco de construção e. a UML tem como principais objetivos a visualização. Mecanismos de extensão – Os mecanismos de extensão existem para oferecer certa flexibilidade a UML com o intuito de expressar todas as situações não contempladas pelos principais conceitos da linguagem. à reutilização. Existem três tipos de mecanismos: estereótipos. entre outros. programadores. à flexibilidade. Cabe ressaltar que esses mecanismos devem ser usados de maneira controlada para que a linguagem não seja descaracterizada a ponto de comprometer o seu principal objetivo de comunicação. a equipe (usuários do sistema.. a especificação. analistas.) envolvida no projeto de desenvolvimento deve visualizar o sistema sob diversas perspectivas para melhor entendimento.

Vista de Projeto

Vista da Implementação

Vista de Caso de Uso Vista do Processo Vista da Implantação

Figura 19 Arquitetura de um sistema Fonte: O autor, adaptada de BOOCH et al. (2000. p. 33)

4.5.1 Vista de Caso de Uso Essa vista descreve o sistema do ponto de vista de um agente externo ao sistema, ou seja, descreve comportamento do sistema sob o ponto de vista de seus usuários finais. Portanto, esta vista está diretamente relacionada com o levantamento de requisitos de negócios que deverão ser implementados pelo sistema, sendo criada inicialmente e servindo como base de direcionamento para a criação das demais vistas. Dentro da UML, modelos que estão relacionados são os diagramas de casos de uso que capturam o aspecto estático do sistema e os modelos que representam os aspectos dinâmicos do sistema como os diagramas de interação, diagramas de gráficos de estado e diagramas de atividades. 4.5.2 Vista de Projeto Nessa vista é dado ênfase aos aspectos que dão suporte estrutural e comportamental às funcionalidades do sistema, ou seja, os serviços que o sistema deverá fornecer aos seus usuários finais. Essas funcionalidades devem ser validadas e estar de acordo com os requisitos de negócio definidos na vista de caso de uso. Na UML, os principais modelos que constituem essa vista são os diagramas de classes e objetos que estão relacionados aos aspectos estáticos do sistema. Para representar os aspectos dinâmicos do sistema podem-se citar os mesmos diagramas da vista de casos de uso.

68

4.5.3 Vista de Processo Essa vista está relacionada aos processos que formam os mecanismos de concorrência (paralelismo) e sincronização do sistema, cuidando dos aspectos relacionados ao desempenho do sistema. Nesse caso, os aspectos estáticos e dinâmicos são capturados pelos mesmos modelos da vista de projeto, porém com ênfase nas classes ativas10 que representam esses processos. 4.5.4 Vista de Implementação Está relacionada à gestão da configuração das versões do sistema, composta por componentes e arquivos responsáveis pela montagem do sistema físico. Os aspectos estáticos dessa visão podem ser capturados pelos diagramas de componentes e os dinâmicos pelos mesmos modelos já citados anteriormente em outras vistas. 4.5.5 Vista de Implantação Corresponde à distribuição física do sistema abrangendo os nós que formam a topologia de hardware em que o sistema é executado. Com a UML, os aspectos estáticos do sistema são capturados em diagramas de implantação e os dinâmicos pelos mesmos modelos já citados anteriormente em outras vistas. Apesar da possibilidade de serem tratadas isoladamente de acordo com o aspecto do sistema que mais interessar, é importante destacar que dependendo da complexidade do projeto nem todas as vistas precisam ser construídas e que as vistas apresentam interações entre elas. Como exemplo, podem-se citar os nós da vista de implantação que possuem componentes da vista de implementação que nada mais são do que a realização física de classes, interfaces e colaborações originadas pelas vistas de projeto, processo e caso de uso.

4.6

Modelos da UML - Visão Geral
A arquitetura e as vistas que compõem um sistema de software, descritos no

tópico anterior, estão relacionados diretamente a uma série de documentos textuais ou
10

Classes ativas são classes que possuem objetos ativos que representam processos capazes de iniciar

atividades de controle.

69

gráficos que auxiliam na construção do sistema. Assim, qualquer processo de desenvolvimento de um sistema que venha a utilizar a UML como linguagem de modelagem gera diversos tipos de documentos que como visto anteriormente costumam ser chamados de artefatos de software ou simplesmente artefatos. Logo, o objetivo principal deste tópico é apresentar uma visão geral dos artefatos gráficos da UML, ou seja, dos diagramas que podem ser produzidos num processo de desenvolvimento de um sistema e suas principais notações. Na figura abaixo é possível visualizar os tipos de diagramas da UML.
Diagramas da UML

Diagramas de Interação

Diagramas de Casos de Uso

Diagramas de Objetos

Diagramas de Gráficos de Estado

Diagramas de Implementação

Diagramas de Sequência

Diagramas de Colaboração

Diagramas de Classes

Diagramas de Atividades

Diagramas Diagramas de de Componentes Implantação

Figura 20 – Diagramas da UML Fonte: O autor

4.6.1 Diagramas de Casos de Uso Esse diagrama da UML teve origem a partir da metodologia OOSE, proposta por Jacobson, com o intuito de documentar e formalizar os requisitos de sistema, que até então se encontravam apenas nas cabeças dos especialistas do negócio e dos analistas de sistema envolvidos com o planejamento do projeto. De uma maneira geral, pode-se dizer que um caso de uso é um conjunto de cenários que descrevem interações entre usuários (atores) e sistemas. Tais cenários representam diversas situações vivenciadas pelos usuários do sistema, incluindo caminhos alternativos para solução de erros e imprevistos que venham a aparecer no meio do processo de interação. Normalmente, um caso de uso é descrito textualmente podendo apresentar um formato básico que inclui pré e pós-condições que determina como, por exemplo, um sistema deve estar antes e depois da realização do caso de uso, inclui também um fluxo normal de eventos que descreve os principais passos para a realização de um caso de

70

uma instância de B pode incluir o comportamento especificado por A.uso e. significando que esse ator interage com o sistema. KULAK. por fim. Este relacionamento é representado no diagrama por uma seta pontilhada entre os casos de uso com o estereótipo “inclui”. 2000). O primeiro objeto seria o caso de uso que é representado por uma elipse contendo o seu nome no interior ou abaixo da elipse. Inclusão – indica que um determinado caso de uso apresenta uma seqüência de interações que pode ser reutilizada por demais casos de uso. Extensão – ocorre quando um comportamento opcional de um caso de uso tem que ser descrito. Generalização – uma generalização de um caso de uso (ou de um ator) A para um caso de uso (ou um ator) B indica que A é uma especialização de B. O segundo objeto é o ator que é representado por um stick man e significa um papel exercido por um usuário ou até mesmo por um outro sistema com relação ao sistema que se pretende desenvolver. tendo-se que se definir apenas as características de especialização de A. Este relacionamento é representado no diagrama por uma seta pontilhada entre os casos de uso com o estereótipo “estende”. entre atores e entre casos de uso e atores que podem ser de: Comunicação . WINTERS. para evitar repetição esse tipo de relacionamento pode ser utilizado. A herda todas as características de B. Logo. Assim. ou seja. quando existe um relacionamento de extensão de um caso de uso A para um caso de uso B. 1998.indica que um ator está relacionado a um determinado caso de uso. GUINEY. os fluxos de caminhos alternativos que ocorrem com menos freqüência incluindo situações incomuns que possam acontecer dentro de um caso de uso (SCHNEIDER. O terceiro objeto é o relacionamento entre casos de uso. Este diagrama apresenta basicamente quatro objetos que o constroem. Este relacionamento é representado no diagrama por uma linha reta que liga o ator ao caso de uso. Este relacionamento é representado por 71 .

bem como seus atributos. A figura abaixo mostra alguns diagramas de caso de uso e seus principais elementos: Sistema de Caixa Eletrônico Realizar Saque <<inclui>> Fornecer Identif icação Cliente Obter Extrato <<inclui>> Realizar Pagamento Cliente <<generaliza>> Realizar Pagamento em Dinheiro Cliente Realizar Pedido <<estende>> Requisitar Catálogo do Pedido Figura 21: Diagramas de Casos de Uso Fonte: O autor 4. é um retângulo que envolve apenas os casos de uso mantendo de fora os atores e representando a fronteira entre interior e o exterior do sistema. estes podem ser criados a partir de três perspectivas que podem ser utilizadas em conjunto ou não dependendo do processo de desenvolvimento adotado: Conceitual – Nessa perspectiva são levantados os principais conceitos que estão envolvidos no domínio que está sendo estudado e tais conceitos serão relacionados à classes que irão representá-los no diagrama. Por fim. operações.uma seta cheia que liga os casos de uso ou atores envolvidos.2 Diagramas de Classes Os diagramas de classes descrevem os tipos de objetos que existem dentro de um sistema. regras e os vários tipos de relacionamentos estáticos existentes entre eles. Não existe um 72 . que pode ser opcional. No que se refere ao desenvolvimento dos diagramas de classes. o último objeto.6.

não considerando a implementação. 2000). a notação definida pela UML para representar uma classe é um retângulo que pode. pode-se classificá-los em dois grupos: 73 . Implementação – Essa é a perspectiva mais utilizada e está relacionada diretamente com a codificação das classes projetadas. Conforme pode ser visto na figura abaixo. mas podem ser muito valiosas nos processos de modelagem e revisão dos modelos (FOWLER. os atributos e as operações da classe. É importante ressaltar que tais perspectivas não são definidas formalmente na UML. SCOTT. apresentar até três divisões delimitadas para o nome. Especificação – Nessa perspectiva o software passa a ser considerado sendo identificadas as interfaces de cada tipo de dados previsto. É importante ressaltar que os conceitos de interface e implementação são diferentes e que essa diferença é chave para uma boa programação orientada a objeto que deve ser voltada para a programação de interface de classe em vez de ser voltada para implementação. dependo da perspectiva adotada. Nome da Classe Atributos Operações Figura 22: Notação de uma classe Fonte: O autor Com relação aos tipos de relacionamentos estáticos entre as classes.comprometimento com a implementação podendo ser considerado independente do software e da linguagem de programação que serão utilizados.

direção de leitura e papéis – esse três recursos de notação definidos pela UML ajudam na compreensão do diagrama de classes. estabelecem o limite inferior e superior da quantidade de objetos aos quais um outro objeto pode estar associado. Ainda com relação ao tipo de relacionamento associação. dos quais podem ser destacados: Multiplicidades – representam a cardinalidade dos objetos envolvidos na associação. esse deve ser criado e removido juntamente com o objeto da qual ele faz parte. Agregação – significa que um determinado objeto do sistema é composto por outros objetos. existem diversos adornos que podem estar relacionados a uma associação. a direção de leitura é representada por uma seta ao lado do nome e. Nome de associação. Generalização – Esse tipo de relacionamento. 74 . Ocorre quando um tipo de objeto do sistema generaliza um comportamento comum.Associação – Esse tipo de relacionamento ocorre quando objetos de uma classe contêm referências ou usam serviços de outras classes. já citado anteriormente para casos de uso. Composição – significa um tipo de agregação mais forte. também existe entre classes e seus objetos. pois. O nome da associação é posicionado no meio da linha de associação. quando um objeto faz parte do outro. ou seja. por fim. ampliado ou modificado em um ou mais subtipos (classes filhos) mantendo as características de origem do supertipo (classe pai). nesse caso. ou seja. representam relações entre instâncias de classe. os papéis que as classes representam numa associação são colocados nas extremidades da linha de associação junto as suas respectivas classes. ou seja. é uma conexão entre objetos que possuem uma relação todo-parte entre si.

ou seja. uma mudança no elemento independente afeta o elemento dependente. Pedido Cliente códigoDoCliente limiteDeCrédito incluirPedido( ) Operações atenderPedido( ) 1 Agregação Associação Multiplicidade * Pedido. Todos esses relacionamentos ajudam na compreensão do domínio que está sendo estudado. Classes Associativas – esse relacionamento permite atributos e operações as associações. Na figura abaixo se pode encontrar um exemplo de um diagrama de classes com alguns desses elementos citados acima. mas devem ser utilizados com cautela para não comprometer o entendimento dos principais conceitos envolvidos no diagrama de classes.Dependência – é um relacionamento em que uma classe ou objeto é independente e a outra classe ou objeto é dependente. item quantidade Atributos Produto incluirItemPedido( ) calcularTotalPedido( ) Generalização Superclasse Chocolate Subclasse Empresa nome telefone endereço Papel contratante Nome da Associação Contrata Papel contratado Pessoa razãoSocial endereço Emprego salário dataContratação Classe Associativa Figura 23: Diagrama de Classes Fonte: O autor 75 . ocorrendo quando existem atributos e operações que não podem ser atribuídas a nenhuma das classes pertencentes à associação.

P.6. Esse tipo de diagrama é utilizado com pouca freqüência.4 Diagramas de Interação Diagramas de interação são modelados para representar os aspectos dinâmicos 76 .4.6.50 desconto = 15 item1: ItemPedido quantidade = 6 Pedido1:Pedido data = 13/09/2002 hora = 10:00am item2: ItemPedido quantidade = 20 produto12 : Produto nome = "Caneta ESF" descrição = "Caneta esferográfica 5mm" preçoUnitário = 1. um objeto é representado. conforme pode ser observado na figura abaixo. onde na parte superior está o nome do objeto e classe a que pertence e na inferior os atributos definidos pela classe do objeto. por um retângulo com duas divisões.35 desconto = 10 Figura 24: Diagrama de Objetos Fonte: BEZERRA (2002. produto20 : Produto nome = "Caderno M" descrição = "Caderno em espiral tamanho médio" preçoUnitário = 4. Com relação à notação.20 desconto = 2 item3: ItemPedido quantidade = 1 produto07 : Produto nome = "Esquadro" descrição = "Esquadro de acrílico 20cm" preçoUnitário = 2.129) 4. É um tipo de diagrama estrutural e estático tendo como principal objetivo representar um comportamento de um sistema em determinado momento exibindo as interações entre objetos conforme seus atributos e ligações. tendo utilidade para representar e facilitar o entendimento de algum tipo de relacionamento complexo de um diagrama de classes.3 Diagramas de Objetos Os diagramas de objetos ou diagramas de instâncias podem ser vistos como instâncias dos diagramas de classes da mesma forma que objetos são instâncias de classes. além de apresentar a mesma notação utilizada nos diagramas de interação que serão visto a seguir.

ou seja.4. outro. um stick man. Esse tipo de diagrama é representado dentro da UML pelos diagramas de seqüência que dá ênfase na ordem temporal das mensagens trocadas entre os objetos e pelo diagrama de colaboração que dá ênfase aos relacionamentos existentes entre os objetos que participam da execução de um caso de uso. assíncrona e de retorno). os objetos que estão envolvidos com a execução dos casos de uso e tem a mesma notação do diagrama de objetos. ou seja. mostrando como os sistemas agem internamente para que um determinado ator alcance seu objeto através da realização de um caso de uso. a criação de objetos que está relacionada à posição vertical dos objetos no diagrama.6. Para isso. as mensagens que são trocadas entre os objetos do diagrama sendo representadas por setas. a destruição dos objetos que é representada no diagrama por um “X” ao final dos focos de controle. indicando que os objetos não são mais necessários na interação. 4. podendo ser de quatro tipo (simples. 77 .dos sistemas. os objetos que existem desde do início da interação devem ser posicionados no topo do diagrama e os demais conforme forem sendo criados devem se posicionar mais abaixo. tais diagramas mostram a seqüência de mensagens enviadas e recebidas pelos objetos que participam de um caso de uso. Tais diagramas são definidos a seguir. as linhas de vida que determinam os tempos de existência dos objetos e são representadas por uma linha vertical pontilhada. os focos de controle que são representados por retângulos posicionados sobre as linhas de vida e servem para indicar quando um objeto está recebendo ou enviando mensagens.1 Diagramas de Seqüência Os principais elementos que compõem um diagrama de seqüência são os atores que participam da realização dos casos de uso que estão sendo representados e apresentam a mesma notação do diagrama de caso de uso. síncrona. tendo sempre como principal objetivo o entendimento dessas interações. ou os dois diagramas dentro de um processo de desenvolvimento depende do foco que se deseja visualizar as interações entre os objetos. e. por fim. A utilização de um. as classes que eventualmente podem aparecer quando da necessidade de se enviar mensagens para elas. A figura abaixo colabora para um melhor entendimento dos principais elementos que estão relacionados ao diagrama de seqüência.

2 Diagramas de Colaboração Os diagramas de colaboração são bem semelhantes aos diagramas de objetos. tendo como principal diferença à utilização de setas e rótulos de mensagens nas ligações entre os objetos. os principais elementos que compõem esse diagrama são os objetos ou classes cujas notações são as mesmas que são utilizadas no diagrama de seqüência.6. os identificadores seqüenciais que.Ator Objeto 1 Objeto 2 Objeto 3 Objeto 4 mensagem 0 mensagem 1 mensagem 2 Linha de vida Foco de controle mensagem 3 Figura 25: Diagrama de Seqüência Fonte: O autor 4. as setas que indicam as direções das mensagens sendo posicionadas próximas aos rótulos das mensagens. Assim como os diagramas de seqüência. indicam a ordem de envio das mensagens. as linhas ou ligações entre os objetos que representam os tipos de relacionamentos (agregações. e. etc. através de seqüências numéricas. esse tipo de diagrama busca representar as trocas de mensagens (interações) entre os objetos que executam os casos de uso. Conforme pode ser observado na figura abaixo. 78 . associações.) entre os objetos. por fim.4.

Demais adornos são definidos pela UML para aplicação nesse diagrama. mostrando todos os possíveis estados que os objetos podem ser assumir durante seus ciclos de vida.Objeto : Janela de Entrada de Pedido 1: prepare() Mensagem : Pedido 2*[para todas as linhas de pedido]:prepare() 3: tem Estoque := verificar() 4: [temEstoque] := remover() linha Macallan:Linha de Pedido Número de Sequência 7:[temEstoque]:new : Item de Entrega 6:[precisaReposição]:new estoque Macallan: Item de Estoque : Item de Reposição Figura 26: Diagrama de Colaboração Fonte: O autor.76) 4. 79 . As transições de estados são representadas por setas podendo ser opcionalmente rotuladas por três partes de acordo com a seguinte notação: Evento [Guarda] / Ação. A primeira parte corresponde ao evento que dispara a transição. Neste diagrama. com exceção dos estados iniciais e finais que são representados respectivamente por um círculo totalmente preenchido e por um círculo parcialmente preenchido. por fim.6. a segunda representa a condição para que a transição ocorra ou não (condição de guarda) e. os estados podem estar aninhados dentro de um superestado com o intuito de facilitar a compreensão do diagrama. p. Além disso. conforme pode ser observado na figura abaixo. adaptada de FOWLER e SCOTT (2000. cada estado é representado por um retângulo com bordas arredondadas.5 Diagramas de Gráficos de Estados O diagrama de gráficos de estados tem como principal objetivo descrever o comportamento de uma determinada classe e conseqüentemente de seus objetos. a última parte se refere à ação realizada resultante da transição.

p. adaptada de FOWLER e SCOTT (2000. representados por barras entre as transações. Tais atividades representam o andamento e execução das operações e as transições caracterizam o término dessas operações. esse diagrama pode apresentar pontos de sincronização.6. além dos elementos já definidos para o diagrama de gráficos de estados. permitindo a modelagem de estados concorrentes.6 Diagramas de Atividades Os diagramas de atividades podem ser considerados tipo de diagrama de gráficos de estados.116) 4.acrescentando alguns detalhes aos estados e transições. Conforme pode ser observado na figura abaixo. onde um mesmo objeto pode apresentar um ou mais estados independentes. 80 . Estado de Início Nome do Superestado Ativado [Nem todos itens verificados] / pegar próximo item [Todos os itens verificados && todos od itens disponíveis] Verificando do / verificar item Expedindo do / iniciar entrega [Todos os itens verificados && alguns itens não estão em estoque] Item recebido [alguns itens não estão em estoque] Item recebido [todos os itens disponíveis] Aguardando Cancelado Cancelado Entregue Estado de Final Figura 27: Diagrama de Gráfico de Estados Fonte: O autor. onde os estados representados referem-se a atividades e não a objetos. esse tipo de diagrama é particularmente útil para modelagem do fluxo de operações onde há a possibilidade de processamento paralelo. e pontos de decisão representados por losangos. ou seja.

mostrando os componentes físicos e suas interdependências. p.122) 4.6. 81 . adaptada de FOWLER e SCOTT (2000.7 Diagramas de Implementação Os diagramas de implementação recebem destaque principalmente na modelagem de sistemas complexos com o objetivo de descrever a arquitetura física do sistema.Estado Inicial Receber o Pedido Separação Atividade Preencher o Pedido Envia a Fatura Guarda [pedido urgente] Desvio [senão] Entrega durante a noite Entrega Regular Recebe o Pagamento Intercalação Junção Fechar o Pedido Estado Final Figura 28: Diagrama de Atividades Fonte: O autor. Dentro da UML. esse tipo de diagrama é representado pelos diagramas de componentes e de implantação que serão descritos a seguir.

Arquivo – quando é um arquivo de dados. adaptada de BEZERRA (2002. Biblioteca – quando se refere a uma biblioteca de objetos ou de funções.4.2 Diagramas de Implantação Os diagramas de implantação têm como principal objetivo mapear os relacionamentos físicos existentes entre os componentes de hardware e software do sistema. Documento – quando o componente é um documento como. pode ser considerado um componente.6.1 Diagramas de Componentes Esse tipo de diagrama mostra as dependências entre os componentes11 de um sistema mostrando suas interfaces e os serviços que realizam.6. por exemplo. Na figura abaixo é possível observar os principais elementos que formam esse tipo de diagrama. por exemplo.7. e as conexões que são representadas por 11 É importante entender que um componente materializa um conjunto de elementos lógicos como. um manual do usuário. Tabela – quando é uma tabela de um banco de dados. Componente Alunos Interface Lançamento de Notas Professores Relação de Dependência Turmas Figura 29: Diagrama de Componentes Fonte: O autor. as classes. Um módulo de sistema (arquivo de código fonte. p. tendo como seus principais elementos os nós que são representados por cubos e significam um recurso computacional físico que normalmente apresenta alguma memória e capacidade de processamento. a saber: Executável – quando um componente pode ser executado.7. etc. por exemplo.250) 4. A UML define alguns estereótipos para componentes. um arquivo executável.). 82 .

a existência de base de dados. Da mesma forma que existem consultorias que avaliam ferramentas de modelagem de processos de negócio. que em seu relatório de avaliação de software de novembro de 2002. os seus componentes residem em nós que por sua vez podem ser de vários tipos como processadores. É importante ressaltar que quando o sistema está sendo executado. etc. o tempo estimado de vida útil dessa ferramenta dentro da organização. a escolha da ferramenta também deve levar em consideração uma série de fatores como o escopo do projeto ou dos projetos em que será utilizada. A figura abaixo ilustra os principais elementos de um diagrama de implantação.2. por exemplo. apresenta a classificação de ferramentas segundo 83 . p.7 Ferramentas de Modelagem de Software com UML Os mesmos critérios de processo de seleção e compra de ferramentas de modelagem de processos de negócio citados no tópico 3.2 podem se aplicar às ferramentas de modelagem de processos de software.252) 4. também existem aquelas avaliam ferramentas de modelagem de software como. Nó físico Servidor de Aplicação <<HTTP>> Cliente: Browser Alunos SGBD Lançamento de Notas Professores Persistência <<ODBC>> Banco de Dados Corporativo Conexão <<LAN>> Turmas Impressora Figura 30: Diagrama de Implantação Fonte: O autor.linhas cheias que significam meios físicos ou protocolos de comunicação que ligam os nós. entre outros fatores. a facilidade de utilização da mesma. a Yphise. Nesse caso. roteadores. sensores. adaptada de BEZERRA (2002. a política do fornecedor com relação à manutenção e atualização da ferramenta.

a saber: Abrangência da Modelagem – Capacidade de modelar com precisão as aplicações e arquiteturas especificadas. Figura 31: Comparação das Ferramentas de Modelagem de Software Fonte: YPHISE (2002) Na classificação acima. implementando todos os conceitos e diagramas da UML com funcionalidade de extensão e adaptação a outros tipos de modelagem. O resultado dessa classificação pode ser observado na figura abaixo. a consultoria avalia as ferramentas com base em cinco critérios. O ambiente de desenvolvimento deve ser fácil de 84 . Fácil Adaptação – A equipe de desenvolvimento necessita de uma ferramenta que é fácil de adaptar e usar.alguns critérios.

85 . O processo inverso é chamado de Engenharia de Produção. verificação e correção de nomes e regras de notação da linguagem (UML) utilizada. deve apresentar capacidade de acesso ao mesmo tempo por muitos usuários. a melhor ferramenta de modelagem de software do mercado é o Rational Rose da empresa Rational Software fundada pelos criadores da UML e do Rational Unified Process (RUP)13. apresentando segurança no processo de modelagem com restrições de acesso e privilégios por tipo de usuário. 12 A Engenharia Reversa é a capacidade que a ferramenta tem de gerar a partir dos códigos existentes modelos de software. A ferramenta também deve possibilitar incorporar facilmente tanto o código existente como os componentes através de engenharia reversa12. Controle da Qualidade dos Modelos – Define a capacidade da ferramenta de controlar a consistência dos modelos através de definição.configurar para adaptar requisitos e métodos específicos da organização. entre outros. a Rational Software pertence a IBM tendo sido adquirida no final de 2002. 13 O RUP é uma metodologia de referência para desenvolvimento de software que utiliza a UML como linguagem de modelagem e suporta a ferramenta Rational Rose. Retenção de informações durante o ciclo de desenvolvimento – A ferramenta deve ser capaz de reter e fornecer informações como. produtividade e sincronização entre os requisitos definidos e o código gerado. Com base nesses critérios utilizados na avaliação da Yphise. por exemplo. ajudando a manter a qualidade. Gestão da Eficiência da Equipe de Desenvolvimento – A ferramenta deve está adequada para suportar projetos que envolvem um grande número de equipes e pessoas. Esse processo será melhor explicado no próximo capítulo. Atualmente. modelos e documentos desenvolvidos durante todo ciclo de desenvolvimento do sistema.

pois.Os critérios citados por CAMEIRA e BASTOS (2000) com relação à existência de base de dados e metodologia de suporte a ferramenta também se aplicam nessa situação. o RUP como metodologia de referência. Com relação a esse critério. mostrando a sua origem e importância dentro da comunidade de desenvolvimento de sistemas de software orientados a objeto. características e ferramentas de modelagem inerentes à UML. através de seus diagramas consegue expor e uniformizar os entendimentos desde o usuário final do sistema até o nível de programação de código. 86 . podendo ser adaptada e utilizada em diferentes metodologias de modelagem de processos e de sistemas. metodologias e diagramas tanto de EPN como da UML. apesar desse critério não ser considerado para avaliação da Yphise. contribui em muito para aumentar a qualidade de um processo de desenvolvimento de software. em sendo uma linguagem padrão de modelagem. O critério referente à existência de base de dados não está explícito nos critérios definidos acima. Dessa forma. a ferramenta Rational Rose apresenta. mas se enquadra no critério de retenção de informações durante o ciclo de desenvolvimento. o próximo capítulo. Foi possível perceber também que a UML é apenas uma linguagem. Assim. 4. pode também ser considerado um critério importante no processo de seleção e compra da ferramenta. tem como principal objetivo apresentar algumas das principais abordagens de extensão da UML para modelagem de negócio. baseado nos conceitos. conforme já citado. fazendo também a comparação entre seus modelos e os modelos tradicionais da EPN. A existência de uma metodologia associada à ferramenta.8 Considerações Finais Neste capítulo foram apresentadas os principais conceitos. foi possível perceber que a UML.

Não serão considerados nessa análise os diagramas de implementação. também pode ser utilizada para modelagem de negócio. Assim. de processos de negócio. mostrando.1 Modelagem de Processos de Negócio com UML: Análise Crítica dos Modelos Conforme a própria definição da OMG citada no capítulo 4. Porém. da versão 1. Esse capítulo tem como principal objetivo analisar e comparar os principais conceitos e modelos que suportam a EPN e a ES. para melhor compreensão do relacionamento entre a EPN e a Engenharia de Software (ES) foram descritas no capítulo 4 as principais características e modelos da UML. enquanto linguagem para modelagem de negócio. Mas. ainda existem limitações com relação à representação de alguns conceitos relacionados à modelagem de processos de negócio.5 de março de 2003. é necessária criar algumas extensões e customizar a linguagem. como será visto nesse tópico. da forma como os modelos estão definidos pela OMG. Nesse tópico. Além disso. um dos principais desdobramentos da Engenharia de Processos de Negócio (EPN) está relacionada á modelagem de processos de negócio orientada para o desenvolvimento de sistemas de informação. considerada pela OMG como linguagem padrão universal para desenvolvimento de sistemas de softwares orientados a objeto. pois. serão mostrados os diagramas da UML sob a ótica de utilização dos mesmos para modelagem de negócio e. será utilizado o EPC como modelo de processos de negócio. 5. a UML além de ser uma linguagem utilizada para modelagem de software. como base de comparação. estes não apresentam nenhum tipo de relação direta com os conceitos de modelagem de negócio.5 EPN E UML: CONTEXTUALIZAÇÃO DA UML NA MODELAGEM DE PROCESSOS DE NEGÓCIO Como foi possível observar no capítulo 3. fazendo-se uma análise crítica dos modelos da UML. para que a UML seja utilizada para modelagem de negócio. portanto. através da comparação entre o EPC e os diagramas da 87 .

Dependendo da situação. Tais cenários representam diversas situações vivenciadas pelos usuários do sistema. por exemplo. surgem os chamados casos de uso de negócio que representam os processos de negócio que definem a interação entre entidades (atores do negócio) que estão fora do negócio como.6. onde se descreve o fluxo normal de eventos que descreve os principais passos do processo. entre outros. O diagrama de casos de uso apresenta alguns conceitos de modelagem de negócio como. a descrição do fluxo de trabalho relacionado a um caso de uso de negócio (processo de negócio) pode ocorrer de duas formas. um caso de uso é um conjunto de cenários que descrevem interações entre usuários e sistemas. fornecedores.1 Modelagem de Negócio e Diagrama de Casos de Uso Conforme apresentado no capítulo 4. incluindo caminhos alternativos para solução de erros e imprevistos que venham a aparecer no meio do processo de interação. o sistema com o qual os usuários interagem. A utilização de uma forma de descrição ou outra fica a critério dos envolvidos com a modelagem dos casos de uso. que podem ser representados por unidades organizacionais. parceiros. os sistemas e as metas de processos que podem estar associadas à execução de um caso de uso ou um conjunto de casos de uso. uma das formas de representar é textualmente com a utilização de um formato básico de descrição. etc. as principais diferenças e semelhanças entre a modelagem de processos de negócio e a modelagem orientada a objeto. por exemplo. Uma outra forma seria através da utilização do diagrama de atividades que descreveria graficamente os passos do caso de uso de negócio. Em considerando a utilização desse diagrama para modelagem de negócio. 5.1. tanto a descrição textual como a gráfica apresentará vantagens e desvantagens. e o próprio negócio. passa a ser o próprio negócio. 88 .1. podendo também usá-las em conjunto para expressar o fluxo de trabalho do processo de negócio. os fluxos alternativos de situações incomuns. clientes. um diagrama de caso de uso de negócio representa visualmente a interação entre os principais serviços (casos de uso de negócio) que o negócio fornece e aqueles (atores do negócio) que utilizam esses serviços (RATIONAL. Dentro de um diagrama de caso de uso de negócio. Logo. a interação entre atores e casos de uso. Conforme foi dito no tópico 4.UML. A partir desse princípio. 2001b).

de mostrar as relações e formas de integração entre os casos de uso e um modelo como o EPC. conforme pode ser observado em LOOS e ALLWEYER (1998) e em LOOS e FETTKE (2001). entre outros aspectos que podem ser mais bem representados de forma gráfica.A figura abaixo mostra de que forma o diagrama de caso de uso pode ser utilizado para modelagem de processos de negócio. Assim. é importante ressaltar que existe a necessidade. Para LOOS e ALLWEYER (1998) essa integração pode se dá em níveis de detalhamento diferente conforme pode ser observado na figura abaixo. característica importante para melhor descrição e compreensão dos processos de negócio. paralelismo. dificulta a identificação e compreensão de. Figura 32: Exemplo de caso de uso de negócio Fonte: Rational (2001b) Porém. pontos de decisão. o modelo de casos de uso não apresenta nenhuma forma de representação gráfica de fluxo de controle. 89 . principalmente com relação ao conceito de caso de uso de negócio. pois. por exemplo.

dentre os diagramas da UML. o EPC. o IDEF 3. Em todos os casos. “formatar o texto” e “salvar o documento”. inicialmente concebido com o intuito de modelar o fluxo de trabalho relacionado ao comportamento de um sistema. 90 . mais especificamente da função “escrever convites” que é executada pela unidade organizacional “secretária” um diagrama de casos de uso onde o ator é a “secretária” que está relacionado com três casos de uso que são necessários para execução desta função: “digitar o texto”. é o que mais se aproxima dos modelos tradicionais de modelagem de processos de negócio como. também pode ser utilizado para modelagem de processos de negócio podendo ser denominado de diagrama de atividades de negócio. Numa outra abordagem. do lado direito da figura.1.2 Modelagem de Negócio e Diagramas de Atividades O diagrama de atividades. é possível utilizar os mesmos papéis (ator representado por um stick man ou unidades organizacionais representadas por elipses) para ambos diagramas. ainda também é possível ter a relação de uma função para um caso de uso. Dessa forma. esse tipo de diagrama. 5. é possível observar o detalhamento do caso de uso “capturar requisição” executado pelo ator representado pelo “assistente de vendas” que está sendo desdobrado em um EPC com duas funções: “criar requisição” e “definir produto e quantidade”. é possível gerar a partir de um EPC. por exemplo. entre outros. Dependendo do nível de detalhamento em que se esteja trabalhando.Necessidade de organizar conferência Comitê de organização Selecionar palestrantes potenciais Palestrantes potenciais selecionados Escrever convites Secretária Digitar texto Ocorrência de requisito Criar requisito Levantar requisito Assis tente de Vendas Requisito criado Secretária Formatar texto Definir produto e quantidade Produto e quantidade definidos Convites escritos Salvar documento Figura 33: Níveis de detalhamento entre casos de uso e EPC Fonte: Traduzida de LOOS e ALLWEYER (1998) Conforme pode ser observado no lado esquerdo da figura.

Demais elementos relacionados à sintaxe e semântica do diagrama como. “executa”. apesar de através das swimlanes estabelecer responsabilidades organizacionais pela execução das atividades. o diagrama de atividades pode suportar a modelagem de processos de negócio. permite relacionar. algumas das entidades de negócio podem se tornar de forma direta uma classe de análise no projeto do sistema. Mas. apesar das diferenças citadas acima. foram explicados no tópico 4. 91 . possuindo apenas barras de sincronização e pontos de decisão representados por losango que no EPC são respectivamente equivalentes ao operador lógico “E” e “OU exclusivo”. Na figura abaixo.Assim como os demais diagramas tradicionais utilizados para modelagem de processos de negócio. “deve ser informado do resultado”. eventos. Porém. por exemplo. papéis e unidades organizacionais responsáveis pela execução das atividades do processo e também pode mostrar. como operadores lógicos. “deve ser aprovado por”. etc. “é responsável por”. esse diagrama permite modelar o fluxo de trabalho considerando situações de sincronismo e de decisão. os comportamentos e relacionamentos entre as entidades de negócio e as atividades em execução. a ausência de uma representação do operador lógico “OU”. por exemplo. Segundo RATIONAL (2001b). se a modelagem do negócio conseguir representar com clareza os requisitos do sistema a ser desenvolvido. Além disso. através de extensões da UML. apesar do diagrama de atividades apresentar um grande potencial de representação de modelagem de processos de negócio. barras de sincronismo.6. insumos e produtos. é possível visualizar a semelhança entre o diagrama de atividades e o EPC. pois. unidades organizacionais. comparando-o com o EPC. o diagrama de atividades não é capaz de representar relacionamentos organizacionais mais detalhados como no EPC em que uma unidade organizacional pode apresentar diversos tipos de relacionamentos com uma determinada função como. através de colunas (swimlanes). reutilizando artefatos de negócio e dando agilidade ao ciclo de vida de desenvolvimento de um sistema de informação. entre outros. por exemplo. também apresenta objetos que podem representar tanto atividades.6. é possível destacar alguns problemas como.

o que faz 92 .1. de forma diferente. os eventos inicias e finais do processo. Porém. Os eventos intermediários não são representados no diagrama de atividades que representa apenas. as funções são convertidas de forma direta para as atividades. pensando em termos de modelagem de negócio. os diagramas de classes e de objetos mostram os relacionamentos entre classes e conseqüentemente objetos que estruturam um sistema. 5. as unidades organizacionais do EPC são representadas nas swimlanes. as entidades de negócio também podem ser representadas como classes e objetos.3 Modelagem de Negócio e Diagrama de Classes Conforme foi possível observar no capítulo 4. É importante destacar que os dois modelos (diagrama de atividades e EPC) podem contemplar de forma satisfatória a modelagem de processos de negócio.Figura 34: Relação entre EPC e Diagrama de Atividades Fonte: LOOS e ALLWEYER (1998) Na figura acima. o operador lógico “OU exclusivo” é convertido de forma direta para um losango e o objeto de negócio “requisição” é mantido de forma idêntica nos dois diagramas. mas o EPC ainda é mais utilizado pelos analistas de negócio na prática de modelagem de processos de negócio pelo fato de ser bastante difundido dentro da comunidade de processos de negócio e de ser um modelo da ferramenta líder do mercado de modelagem de processos.

a modelagem de estruturas organizacionais mostrando os relacionamentos entre as unidades organizacionais num organograma. por exemplo. as mensagens entre os objetos são representadas pelo fluxo de controle apoiado por mecanismos de decisão e de controle como. Na primeira delas. metas. entre outros. Na segunda forma. buscando tirar vantagens das duas abordagens. à modelagem de processos de negócio não são contemplados por esses modelos como os conceitos de fluxo de controle de material e de informação. enquanto processo de negócio. No que diz respeito ao diagrama de classes. o autor sugere a criação do object-oriented event-driven process chain (oEPC) colocando que esse modelo estaria integrado com os conceitos de orientação a objeto e ao mesmo tempo preservaria a lógica de processos do EPC. que o autor chama de abordagem de transformação. pode se relacionar de duas formas com o diagrama de classes.desses diagramas candidatos para aplicação de parte dos conceitos relacionados à modelagem de negócio como. por fim. a principal diferença entre o oEPC e o EPC é que as funções (atividades) são substituídas por objetos de negócio pertencentes a classes de negócio. por exemplo. considerando que um dos principais objetivos da modelagem de processos de negócio é 93 . Outros conceitos relacionados. principalmente. os eventos descrevem os estados de transição dos objetos de negócio de acordo com as operações executadas. os operadores lógicos e. o primeiro autor coloca que o EPC. Além disso. o EPC pode contribuir de forma direta na construção do diagrama de classes. indicadores. denominada de abordagem de integração. Conforme pode ser visto na figura abaixo. objetos esses que apresentam seus atributos e suas operações. de atividades. Essa identificação se daria através do detalhamento de objetos de informação processados e das atividades executadas no processo. a modelagem dos relacionamentos entre unidades organizacionais e demais entidades de negócio utilizadas como recursos para execução dos processos de negócio e a modelagem dos relacionamentos entre os próprios recursos. FELD e ZIMMERMANN (1997) e LOOS e ALLWEYER (1998) fazem uma comparação entre o EPC e os diagramas da UML com o intuito de apresentar uma sinergia entre os conceitos de processos e da orientação a objeto. Alguns autores como NÜTTGENS. de evento.

No nível mais agregado. e que objetos daquele pacote tiveram seus estados alterados pela função. representado nesse caso por uma seta com sentido do pacote para a função. é possível associar aos objetos de negócio tanto unidades organizacionais quanto os recursos utilizados. Nessa abordagem. por exemplo. 94 . as funções agregadas do EPC se relacionariam com pacotes (conjunto de objetos logicamente agrupadas) onde o sentido da seta indica. que informações contidas nos objetos de um pacote servem de entrada para execução de uma determinada função. o diagrama de classes pode ser considerado a parte central da UML sendo base fundamental para o desenvolvimento orientado a objeto. pois.identificar e resolver problemas organizacionais. conforme pode ser vista na figura abaixo. Objeto de Negócio Atributo Inativo Atributo a1 a2 Evento classe 0 triggers Objeto de negócio a1 l triggers AND 1 triggers executores Organização unidade 1 Atributo a3 Operação Evento classe 1 triggers Organização unidade 2 executores Objeto de negócio l 2 Evento classe 2 triggers Objeto de negócio l 3 executores Organização unidade 3 Evento classe 3 Evento classe 4 Figura 35: Estrutura do oEPC Fonte: Traduzida de NÜTTGENS. representado por uma seta com sentido da função para o pacote. os autores sugerem três níveis de detalhamento entre o EPC e os elementos que formam o diagrama de classes. FELD e ZIMMERMANN (1997) Para LOOS e ALLWEYER (1998) a relação do EPC com o diagrama de classes é a mais importante dentre os demais modelos da UML.

Procuração Material Nome Quantidade em Estoque 1. 1 Determinar Receptor() Figura 37: Diagrama de Classes agrupado num pacote Fonte: LOOS e ALLWEYER (1998) 95 ... Pedido Data Status Item do Pedido Estoque Status Determinar Material() Determinar Estoque() 0 Requisitos Empregado 0. mostrando que os pacotes relacionados às funções apresentam em seu detalhamento diagramas de classes e seus respectivos elementos.Pedido do Cliente Pedidos do cliente Pedido de Resolução do problema Vendedor Pedido em produção ^ Requisição feita Procuração Procuração Procuração Providencia do material ^ Produção Produção Produção Produto final Figura 36: EPC de alto nível com pacotes Fonte: LOOS e ALLWEYER (1998) A figura abaixo ajuda na compreensão da abordagem citada acima.

mostrando quais objetos são utilizados e modificados pelas funções. Requisito ocorrido Criar requisito Requisito criado Determinar Determinar qtd() Status Determinar materiais e quantidade Material e quantidade determinados Determinar Determinar receptor Requisito capturado Figura 39: EPC Capturar Requisitos detalhado com atributos e operações Fonte: Traduzida de LOOS e ALLWEYER (1998) 96 . Requisito Material ocorreu Empregado Capturar requisito Assistente de vendas Requisito Requisito Capturado Verificar material em Material XOR Procurador especialista Material em estoque Material em falta Figura 38: EPC de nível intermediário com classe Fonte: Traduzida de LOOS e ALLWEYER (1998) Conforme pode ser observado na figura abaixo. as funções já em um nível bem desagregado se relacionam diretamente com atributos e operações dos objetos das classes. os autores relacionam as funções um pouco mais detalhadas diretamente com os objetos que na abordagem anterior estavam contidos nos pacotes. conforme pode ser observado na figura abaixo.No nível intermediário. no terceiro e último nível.

1. 5. sendo utilizado quando é necessário entender de forma mais clara o comportamento desse objeto.4 Diagrama de Gráficos de Estados O diagrama de gráfico de estados. conforme pode ser observado na figura abaixo. desta forma. Figura 40: Comparação entre EPC e Diagrama de Estados Fonte: LOOS e ALLWEYER (1998) 97 . esse diagrama. conhecido também como apenas diagrama de estados. Apesar desse tipo de diagrama não apresentar qualquer tipo de relação com os conceitos de modelagem de negócio é possível fazer uma comparação com o EPC. sendo relevante em algumas situações no nível de análise e projeto de um sistema.Os autores colocam que nesse nível as funções estão muito próximas das operações. Por ser muito específico e voltado para modelagem de estados de um único objeto. onde cada operação que é relevante para o negócio é executada por uma função. o gap entre funções e operações durante a definição de requisitos. apresenta limitações para modelagem de negócio. está normalmente associado a um único objeto de sistema. reduzindo.

Em muitos casos. conforme já citado no capítulo 4. é importante ressaltar que existe alguma redundância entre os eventos do EPC e os estados do diagrama de estados. é possível acompanhar as transições e mudanças de estados de um determinado objeto dentro de um processo de negócio. Além disso. a função “retirar material do estoque” só pode ser executada quando o objeto de entrada “requisição” estiver no estado de “verificada”. Pensando em termos de conceitos de modelagem de negócio e considerando que esses diagramas normalmente estão relacionados às realizações dos casos de uso eles podem representar interações entre entidades de negócio. 5. o evento “requisição capturada” que é redundante com o objeto de saída “requisição” no estado de “capturada”.LOOS e ALLWEYER (1998) ressaltam a importância de se definir os estados dos possíveis objetos associados às funções.5 Modelagem de Negócio e Diagramas de Interação Os diagramas de interação (diagrama de seqüência e de colaboração). como pode ser visto na figura acima. Nessas situações basta a utilização de uma das notações. por exemplo. Mas.1. pois. nem sempre essa relação é direta como pode ser visto no caso em que o objeto “requisição” se encontra no estado de “verificada” e pode ter dois eventos relacionados “material em estoque” e “material não existe em estoque”. o próprio evento já indica uma mudança de estado de um determinado objeto que está sendo utilizado durante o processo como. 98 . os atores e as metas de processo relacionadas à execução dos casos de uso. têm como principal objetivo modelar as interações que ocorrem entre dois ou mais objetos através do envio e recebimento de mensagens para realizar as execuções das operações requeridas. Dessa forma.

não sendo adequados para modelagem de negócio. por exemplo. 99 . enquanto o EPC. portanto. os diagramas de interação descrevem as trocas de mensagens entre os objetos de forma mais detalhada do ponto de vista da implementação do sistema. a saber: Melhorar o entendimento e os mecanismos de funcionamento do negócio através do uso de modelos. 5. os modelos relacionados ao desenvolvimento de qualquer sistema de informação que dará suporte ao negócio. Serve de base para melhoria contínua tanto da estrutura como da operação do negócio. definindo de forma mais clara os principais requisitos que determinarão as funcionalidades dos sistemas. está focado na modelagem de funções e objetos relevantes sob o ponto de vista do negócio. por exemplo. a modelagem de negócio é base fundamental para modelagem de outros modelos como.2 Extensões da UML para Modelagem de Negócio Para ERIKSSON e PENKER (2000). pois. Possibilita a elaboração de um plano de ação para gerar. tornando o processo de desenvolvimento de sistemas orientado ao negócio. através de mudanças radicais ou incrementais. LOOS e ALLWEYER (1998) também afirmam que esses diagramas estão muito próximos do nível de implementação. Serve de base para a modelagem de sistemas de informação que darão suporte ao negócio. Os autores colocam que apesar de existirem informações redundantes entre os diagramas não é possível transformar um EPC diretamente em um diagrama de interação. eles normalmente são utilizados no nível de implementação. para LOOS e FETTKE (2001). Os autores destacam algumas vantagens de se realizar a modelagem de negócio.Mas. apesar desses diagramas apresentam alguns aspectos do fluxo de processos de negócio. inovação nos processos de negócio. apresentando detalhes técnicos e.

foram utilizados os mecanismos de extensão da UML (estereótipos. segundo os autores.3 dessa dissertação. tais diagramas conseguem representar diversos aspectos de negócio como. descritos e explicados no tópico 4.Realização de benchmarking. os modelos referentes à essas partes que não são chaves para o negócio serviriam de referência para a operacionalização dos terceiros. Em sua abordagem. estereotipado do elemento atividade do diagrama de atividades. os autores criaram um conjunto de extensões da UML para que a linguagem pudesse representar. entre outros. por exemplo. paralelismo de execução entre atividades. valores atribuídos e restrições). os autores criaram um diagrama para representar através de um símbolo de processo. 100 . Diante dessas vantagens. Identificação de oportunidades de terceirização de partes do negócio que não são consideradas chaves para o negócio. para representar. conforme pode ser observado na figura abaixo. regras e objetivos atrelados à execução dos processos de negócio. recursos (pessoas e máquinas). identificação de responsabilidades por atividades. através da criação de novos ícones.4. pois. os autores consideram o diagrama de atividades como o principal modelo de representação de modelagem de negócio. Reconhecendo as diferenças entre os conceitos que envolvem a modelagem de negócio e a de software como. recursos usados. os autores apresentam em sua proposta uma extensão da UML para modelagem de negócio. práticas e modelos de negócio de outras empresas. mostrando como uma mesma linguagem pode ser utilizada para tanto para modelagem de negócio quanto para de software. os principais elementos relacionados à execução e modelagem de negócio. através da comparação de tecnologias. Nesse caso. os principais conceitos envolvidos na modelagem de um negócio. por exemplo. as extensões para modelagem de negócio de acordo com a sintaxe da UML. Assim. consumidos e produzidos por uma atividade. Para criar esses ícones relacionados à modelagem de negócio. relacionamentos e dependências entre atividades.

a arquitetura de um negócio pode ser quebrada em quatro vistas: 5. por exemplo. um modelo de objetivos e problemas. sub-objetivos e os problemas que limitam o alcance dos objetivos. os autores também propõem vistas de negócio como.1 Vista de Visão do Negócio Essa vista se caracteriza por apresentar os objetivos estratégicos do negócio que servirão de guia para a realização das demais vistas.2. que buscam diminuir a complexidade de entendimento do negócio através da divisão em vistas que podem ser expressas por um ou mais modelos. Assim. e que pode ser detalhado em diferentes níveis para mostrar objetivos. representado por um diagrama de objetos da UML.<<objetivo>> Objetivo <<recurso>> Entrada: l <<processo>> Processo A <<recurso>> Saída: l <<recurso>> Recurso A <<recurso>> Recurso B Figura 41: Diagrama de Atividades e estereótipos de processos de negócio Fonte: Traduzida de ERIKSSON e PENKER (1999) Em sua abordagem. e um modelo 101 . Para os autores. as citadas na metodologia ARIS. os principais resultados dessa vista podem ser expressados pelos artefatos: declaração da visão do negócio que pode se caracterizar por um breve documento textual que define a visão do futuro da organização.

entre os recursos utilizados em suas execuções e entre os objetivos estratégicos definidos. pois. apresenta todos os processos de negócio. que define conceitos e relacionamentos dentro do negócio com o intuito de criar um conjunto de terminologias comum a todos envolvidos com o negócio. representado por diagrama de classes da UML. A figura abaixo exemplifica um diagrama de objetivos e problemas que mostra a hierarquia existente entre objetivos e seus respectivos problemas. os relacionamentos entre eles. Como pode ser observado na figura abaixo. Muitos Clientes: Objetivo Quantitativo Valor_Objetivo = 500000 Valor_Atual = 0 Unidade_de_Medida = "Clientes cadastrados" <<problema>> Clientes não estão querendo se registrar (Completo) <<problema>> Clientes não gostam do preço <<problema>> Site não é conhecido (Incompleto) Muitos Visitantes da Internet: Objetivo Quantitativo Muitos Clientes Registrados: Objetivo Qualitativo Muitos Clientes Inscritos: Objetivo Qualitativo (Incompleto) <<problema>> Clientes não conhecem as vantagens Links de Outros Sites: Objetivo Quantitativo Site Avaliado em Outras Mídias: Objetivo Qualitativo Visível nos Sites de Busca: Objetivo Quantitativo Tornar Registro Interessante: Objetivo Qualitativo Comunicar serviços prêmio para membros: Objetivo Qualitativo Preço Atrativo: Objetivo Quantitativo Prover bons serviços prêmio: Objetivo Quantitativo <<problema>> Outros sites não colocam links <<causa>> Não é interesse de proprietários de outros sites atrair visitas para este site <<ação>> Prover incentivos para outros sites (como prêmios para cada visitante encaminhado) <<pré-requisito>> Meios financeiros para prover bonificação Figura 42: Diagrama de Objetivos e Problemas Fonte: Traduzida de ERIKSSON e PENKER (1999) 5.2 Vista de Processos de Negócio Esta vista se caracteriza como a principal vista da modelagem de negócio. o principal modelo utilizado nessa vista é o diagrama de processos que tem como base o diagrama de atividades e apresenta os principais elementos envolvidos com os processos como as unidades organizacionais 102 .2.conceitual.

Na parte inferior encontra-se um conjunto de pacotes horizontais que são denominados de pacotes de linha de montagem. os recursos consumidos ou produzidos pelos processos entre outros. mostrando como a informação é acessada pelo sistema e como é utilizada pelos processos. Esses pacotes são elementos da UML e recebem o estereótipo de <<linha de montagem>>. no topo do diagrama de linha de montagem está o diagrama de processos. Figura 43: Diagrama de Processos Fonte: ERIKSSON e PENKER (1999) Os autores também propõem um modelo denominado de diagrama de linha de montagem que é uma variante do diagrama de processos original. O principal objetivo desse diagrama é mostrar os relacionamentos entre os processos e os objetos de informação. servindo como base de modelagem para os processos que são diretamente implementados por um sistema de informação. onde cada um representa um conjunto de objetos.envolvidas na execução dos processos. os eventos de negócio que iniciam ou finalizam os processos. Conforme pode ser observado na figura abaixo. 103 .

Assim.2. incluindo modelos como. 5. mostra quais 104 Receber Lista de Pacotes Identificar como enviado-cliente Registrar como vendido Identificar Vendedor Identificar pedido . é possível identificar tanto as funcionalidades (casos de uso) que os sistemas devem ter como os atores (executores dos processos) relacionados com essas funcionalidades. Com esse diagrama. A vista de processos tem relação com essa vista.3 Vista de Estrutura do Negócio Conforme pode ser visto na figura abaixo. são representadas por casos de uso. esse diagrama facilita a identificação dos casos de uso que devem ser modelados. pois. dentro da concepção da modelagem orientada a objeto. ajudando a realizar com mais eficiência a conexão entre a modelagem de processos de negócio e os requisitos funcionais dos sistemas que serão desenvolvidos. essa vista mostra a estrutura de recursos.<<processo>> Confirmação de Venda <<processo>> Registro de Transação <<processo>> Envio do Pedido Receber Informações do pedido <<linha de montagem>> Sistema de Contabilidade <<linha de montagem>> Sistema de Vendas saída entrada <<linha de montagem>> Sistema de Inventário Figura 44: Diagrama de Linha de Montagem Fonte: Adaptada de JUNIOR (2003) É importante ressaltar que esse diagrama apresenta as interfaces dos processos de negócio e dos sistemas de informação que. produtos e de informação do negócio. o organograma. por exemplo.

recursos são utilizados para a execução dos processos e. o comportamento em cada estado e possíveis estados de transição a modelagem ocorre nessa vista. o comportamento dos recursos é orientado pela vista de processos de negócio que determina o fluxo de controle do trabalho realizado.2. De uma maneira geral. colaboração e também de processos quando há a necessidade de mostrar interação entre processos. Nessa vista. também é possível determinar as interações entre diferentes processos bem como definir responsabilidades para diferentes atividades e mapear o comportamento de cada recurso envolvido nos processos de negócio. seqüência. Vendas: Unidade Organizacional Desenvolvimento: Unidade Organizacional Departamento: Tipo de organização Unidade Organizacional Equipe OOA: Propósito Unidade Organizacional Equipe Java: Unidade Organizacional Equipe BM: Unidade Organizacional Equipe OOD: Unidade Organizacional Equipe: Tipo de organização Figura 45: Diagrama Organizacional Fonte: Traduzida de ERIKSSON e PENKER (1999) 5. 105 . elas podem ser modeladas em paralelo mantendo consistência entre elas. portanto.4 Vista de Comportamento do Negócio Essa vista mostra os comportamentos individuais dos recursos e processos bem como suas interações.: Unidade Organizacional Corporação: Tipo de organização Tipo de organização Descrição Produção: Unidade Organizacional Dep. Nessa vista são utilizados diagramas de estado. quando se deseja detalhar o comportamento de um determinado objeto mostrando seu estado. Diagrama de Classe Diagrama de Objeto Software Inc. Mas.

por exemplo. foi apresentada uma proposta de extensão da UML por ERIKSSON e PENKER (1999. os modelos da UML não representam de forma satisfatória alguns conceitos relacionados a modelagem de negócio. 106 . vistas essas que foram criadas para suportar conceitos de modelagem de sistemas de software e não de negócio. mesclando as principais etapas de modelagem de processos de negócio com as do RUP. a estrutura de vistas da metodologia ARIS. onde percebese a existência de conceitos relacionados a modelagem de negócio com uma proposta de arquitetura dividida em vistas suportadas por modelos e extensões da UML.3 Considerações Finais Nesse capítulo foi possível observar e comparar alguns dos conceitos e modelos envolvidos com a modelagem de processos de negócio e a modelagem orientada a objeto. Essa abordagem já se aproxima mais da modelagem de processos de negócio. utilizando alguns diagramas da UML. conforme observado na comparação com o EPC. tendo como base as vistas da arquitetura da UML apresentada no capítulo 4.5. para representar conceitos inerentes aos conceitos de processos de negócio.2000). o diagrama de atividades. Uma outra desvantagem dessa abordagem está relacionada ao fato de não possuir nenhum tipo de arquitetura voltada para modelagem de negócio como. Além dessa comparação dos modelos da UML com EPC. o objetivo do próximo capítulo é definir uma proposta de metodologia de modelagem de processos com foco em desenvolvimento em sistemas. mostrando as vantagens e desvantagens da utilização dos modelos da UML para realizar a modelagem de processos de negócio. apesar de apresentar vantagens de entendimento por parte dos analistas de desenvolvedores de sistemas apresenta limitações de entendimento por parte dos analistas de negócio. podendo ser eficiente para modelar sistemas de informação mais simples. As principais limitações dessa abordagem são a falta de capacidade de abstração não considerando níveis de detalhamento diferentes se limitando a um nível macro de modelagem e a limitação para representar sistemas de informação que suportem estruturas de processos de negócio mais complexas. Diante da análise acima. pois. principalmente. Foi possível concluir que uma proposta de modelagem de negócios com os modelos da UML.

esse capítulo tem como principal objetivo definir uma metodologia de modelagem de processos e requisitos de negócio utilizando como base de desenvolvimento alguns dos modelos da metodologia ARIS. não existe uma única metodologia de modelagem de processos de negócio. 2001a) Diante da afirmação acima. a ferramenta ARIS Toolset . 6. 107 . podem ser integradas. além dos modelos tradicionais de processo também suporta os modelos da UML e através de um módulo denominado de TOOLBUS pode importar os modelos da UML para e Rational Rose e vice-versa.1 Principais Etapas para Modelagem de Processos de Negócio A modelagem de processo de negócio.6 MODELAGEM DE PROCESSO DE NEGÓCIO E O RATIONAL UNIFIED PROCESS (RUP) “Um dos maiores problemas com a maior parte dos esforços relacionados à engenharia de negócios é que as comunidades de engenharia de software e a engenharia de negócios não se comunicam de forma adequada. pois. modelos da UML e conceitos do RUP. entre outros. Com isso. apresenta diversas aplicações como o projeto de desenvolvimento de sistemas de informação. a abordagem da modelagem varia de acordo com o objetivo para o qual se está modelando. pois. considerando suas respectivas fases e artefatos. se não totalmente.” (RATIONAL. ARIS Toolset e Rational Rose. gestão de conhecimento. como foi possível observar no capítulo 3. as comunidades de engenharia de negócios e de desenvolvimento de softwares através da utilização de duas metodologias que são suportadas por duas ferramentas. O principal objetivo dessa metodologia é o de integrar. desenvolvimento de processos de negócio e desenvolvimento de software e que conforme pode ser observado em IDS SCHEER (2002). mas pelo menos parcialmente. o produto da engenharia de negócios não é usado de forma correta como insumo para os esforços de engenharia de softwares. e viceversa. Sendo assim. gestão da cadeia de suprimento. análise de indicadores desempenho. consideradas líderes de mercado em seus respectivos segmentos.

Para VERNADAT (1996). se caracterizando como componentes ou modelos pré-fabricados que variam desde componentes de processos de negócio até os componentes de software. por exemplo. Engenharia Ontológica Bibliotecas de Modelos Definição do Domínio do Negócio Engenharia de Processos de Negócio Projeto do Sistema e Validação Implantação e Lançamento do Sistema Processo de Melhoria Contínua Operação do Sistema Figura 46: Processo de Modelagem de Negócio Fonte: Adaptado de VERNADAT (1996) Dentro das etapas propostas pelo autor. existem muitos processos ou metodologias de modelagem de processos de negócio que podem ser definidos de acordo com os objetivos da modelagem. os das UML. Diante dessa afirmação. são verdadeiros padrões de soluções para uma gama de problemas. Essas bibliotecas de modelos são construídas com o tempo através de experiências vivenciadas em diversos projetos e situações que moldam um conjunto de modelos que armazenam conhecimentos que podem servir de referência. 108 . mostrando a preocupação da melhoria contínua envolvendo a etapa de Operação do Sistema e Engenharia de Processo de Negócio. tipo de análise a ser realizada sobre os modelos ou até mesmo em função da experiência dos usuários. o mesmo autor propõe uma estrutura geral de um processo de modelagem de processos de negócio com desdobramento para sistemas de informação que pode ser observada na figura abaixo. podendo ser reutilizados para situações futuras. é importante destacar a existência de bibliotecas de modelos relacionados tanto com os modelos de processos de negócio quanto com os modelos relacionados ao projeto do sistema. Esses modelos que apresentam um grande potencial de reutilização sejam processo de negócios ou modelos de sistemas como. Outro aspecto importante do modelo é a iteração existente dentro do processo de modelagem.

entender. treinamento dos usuários. Definição do Mapa Estratégico Desenvolvimento da Estratégia e Arquitetura Modelagem dos Processos Atuais Análise e Redesenho dos Processos Futuros Implementação dos Processos Futuros Figura 47: Processo de Modelagem de Negócio com Desdobramento para Sistemas Fonte: Adaptada de IDS SCHEER (2002) Nessa abordagem. deve-se. Na etapa seguinte ocorre a modelagem e dos processos de negócio atuais com o levantamento de informações importantes para a realização da análise da atual estrutura de negócio e de TI. Por fim. os principais processos de negócio relacionados aos sistemas de informações são levantados e direcionados de acordo com os objetivos estratégicos definidos pela organização. documentar e difundir a visão estratégica da organização. conforme mostra a figura abaixo. estabelecendo uma relação direta entre os objetivos estratégicos. definir. Assim. funções e processos de negócio que serão suportadas pelos sistemas de informação. testes operacionais com uma versão beta do sistema. dentro da lógica de melhoria contínua. migração de dados entre sistemas quando necessário e a entrega da versão final que entrará em produção. Além disso. 109 . identificando. antes de se desenvolver qualquer tipo de sistema que venha a automatizar qualquer processo de negócio chave. definição de manuais de utilização do sistema. conforme observado nas duas primeiras etapas. ocorrem a implementação dos processos futuros onde são realizadas atividades como desenvolvimento do código fonte. Identificadas as possibilidades de melhorias futuras. cabe definir as ferramentas de modelagem que darão suporte a modelagem de processos e de sistema.Uma outra proposta de modelagem de processo de negócio com desdobramento para sistemas pode ser vista em IDS SCHEER AG (2002). oportunidades de melhorias futuras. na próxima fase ocorre o redesenho ou remodelagem dos processos de negócio onde informações detalhadas servem de base para a definição dos requisitos funcionais e da arquitetura do sistema a ser criado.

sendo suportada. (2000) que 14 Cabe ressaltar que além da metodologia RUP. melhoria no fluxo de informações. e que leva em consideração em suas etapas iniciais do projeto de desenvolvimento de software a modelagem de processos de negócio. incluindo os processos de negócio e a arquitetura dos sistemas de informação. A constatação da visão por processos dentro da comunidade de desenvolvimento de software pode ser comprovada por alguns autores como BOOCH et al. como por exemplo. Como exemplo.7 dessa dissertação. que será detalhada nesse tópico. o RUP. redução dos tempos e custos dos processos. algumas das principais metodologias de desenvolvimento de sistemas estão levando em consideração o levantamento e modelagem de processos de negócio como parte fundamental para identificação de requisitos de sistemas que possam alinhar e orientar o desenvolvimento de componentes de software e suas interfaces de serviços com as necessidades dos usuários e com os objetivos estratégicos definidos por uma organização ou conjunto de organizações (cadeias ou redes de empresas). é importante. 110 . pode-se citar a metodologia de desenvolvimento de software Rational Unified Process (RUP). etc. pois. proporcionando vantagens já citadas anteriormente como a uniformização do entendimento e padronização da forma de trabalho. A metodologia RUP foi escolhida como base de estudo pois é uma das principais metodologias de desenvolvimento de software do mercado.É importante destacar que para a realização da modelagem consistente e de fácil entendimento da estrutura do negócio como um todo.14 É importante destacar que a visão por processos mencionada no capítulo 3 está presente em alguns processos ou metodologias de desenvolvimento de software. quebrar a modelagem em vistas suportadas por modelos que possam representar de forma simplificada e integrada diferentes aspectos da modelagem realizada. de acordo com a classificação apresentada no item 4. conforme observado no tópico anterior.2 Processos Produtivos de Desenvolvimento de Sistemas Atualmente. não serão abordadas demais variações das metodologias de Engenharia de Software. pela melhor ferramenta de modelagem de software do mercado que tem a UML como linguagem padrão de modelagem. está fora do escopo dessa dissertação. 6.

um produto de software capaz de atender as necessidades de seu negócio. é um conjunto de passos parcialmente ordenados com a intenção de atingir a meta de entregar. como e por quem essas atividades serão executadas. ARLOW e NEUSTADT (2002) apud JUNIOR (2003) colocam que um processo de desenvolvimento de software transforma os requisitos dos usuários em software e define quem e o que irá desenvolver. testar e manter um produto de software. Além disso. iterações e artefatos utilizados como. o autor destaca os objetivos de prover pontos de controle e padronização do processo. Já para LARMAN (2000) um processo de desenvolvimento de software é um método para organizar as atividades relacionadas com a criação. Além disso. os modelos da UML. tendo como principais objetivos à definição das atividades que serão executadas. Para BEZERRA (2002).1 Principais Características do RUP São três características principais que servem de base para construção do RUP: processo orientado por casos de uso. dentro da Engenharia de Software.2. Conforme colocado acima o RUP é um processo de desenvolvimento de software e se baseia na UML como linguagem padrão de modelagem. como e quando será desenvolvido o software. centrado na arquitetura e iterativo e incremental.afirmam que um processo. 6. desenvolver. por exemplo. A seguir essas características são detalhadas. quando. um processo de desenvolvimento de software compreende todas as atividades necessárias para definir. de maneira eficiente e previsível. o RUP tem como principal meta permitir a produção de software de alta qualidade que atenda as necessidades do usuário final dentro do prazo e orçamento previsto para o projeto em questão. apresenta as ditas melhores práticas do mercado em desenvolvimento de software dotando de uma flexibilidade para adaptação a diferentes tipos de projeto e empresas e também permite uma gestão disciplinada do processo através atribuições e controle das atividades e responsabilidades dos atores envolvidos no projeto. entrega e manutenção dos sistemas de software. Para um melhor entendimento do RUP serão descritas a seguir as suas principais características incluindo suas fases. Assim. 111 .

pois facilita a gestão e a reutilização ou customização de componentes de software adquiridos no mercado ou desenvolvidos internamente pela organização. implementação.6. o Common Object Request Broker Architecture (CORBA) do Object Management Group (OMG) e Entreprise Java Beans (EJB) da Sun Microsystems que oferecem plataformas com um ambiente adequado para o desenvolvimento. com tecnologias e custos envolvidos no projeto. para que a arquitetura de um sistema seja desenvolvida permitindo a evolução futura do sistema é necessário que os arquitetos trabalhem com base nos principais casos de uso que 112 . Uma das abordagens que contribui para a construção de um arquitetura flexível é o desenvolvimento baseado em componente (Component-Based Development – CBD). 6.1. entre outros aspectos que envolvem um sistema. Ou seja. projeto e implementação são gerados a partir dos modelos de casos de uso que também orientam a construção da arquitetura do sistema. capacidade de recuperação e funcionalidades desses elementos. desempenho. todos os modelos de análise. com a estética das interfaces de usuários. servem de base e orientam os demais fluxos de trabalho envolvidos como análise e projeto.1 Processo Orientado a Casos de Uso Um processo orientado a casos de uso significa que os casos de uso não são artefatos ligados apenas à especificação dos requisitos do sistema. implementação e teste do sistema. testar e avaliar a arquitetura frente aos requisitos definidos. pelo fato de expressarem as necessidades dos usuários do sistema. A cada iteração do processo de desenvolvimento de software é possível medir.2. os casos de uso.2 Processo Centrado na Arquitetura Uma arquitetura de software tem relação direta com a estrutura e o comportamento dos elementos de um sistema. com a flexibilidade de reutilização. Assim. permitindo que a equipe envolvida evite os riscos mais importantes para o projeto.1. Existem alguns modelos e padrões de arquiteturas disponíveis no mercado de software como o Modelo de Objeto Componente (Component Object Model – COM) da Microsoft.2. servindo também de base para os demais fluxos de trabalho do processo de desenvolvimento. gestão e manutenção dos componentes de software. Dessa forma.

implementação e teste. reduz as dependências entre as camadas já que as camadas inferiores não conhecem os detalhes de interfaces das camadas superiores.1. 6. Um dos padrões utilizados para definição de arquiteturas com base em componentes é o padrão de camadas. Cada camada pode ser representada por um conjunto de pacotes de classes que apresentam um mesmo nível de generalização e volatilidade15 em interfaces. com conselhos sobre como utilizá-lo em novas situações.) que implementam um sistema e por conseqüência todos os requisitos de negócio definidos nas fases de concepção e elaboração. pois estão relacionadas a aplicações mais genéricas. conforme pode ser observado na figura abaixo. análise e projeto. levantamento de requisitos. as regras e os processos de negócio envolvidos com o sistema. de documentos com regras de negócio. enquanto que as mais altas tratam de necessidades específicas da aplicação e possuem interfaces menos estáveis. Também é importante ressaltar que um componente ou um conjunto de componentes de software representam um conjunto de artefatos físicos (fichários de código.3 Desenvolvimento Iterativo e Incremental Os processos clássicos de desenvolvimento de software. facilitando a compreensão e organização do desenvolvimento de sistemas complexos.2. etc. pois. ajudando dessa forma na identificação de elementos reutilizáveis. costumam seguir o ciclo em cascata onde existe uma abordagem linear de desenvolvimento iniciando com a modelagem de negócio. 15 As camadas mais baixas conservam por mais tempo suas interfaces. Segundo LARMAN (2000). Também cabe ressaltar a importância da utilização de padrões de projeto na definição de arquiteturas. onde um componente somente pode acessar componentes de sua camada ou na camada imediatamente abaixo. onde são definidos os objetivos estratégicos. que pode ser utilizado em novos contextos.representam os requisitos funcionais chaves do sistema. 113 . um padrão pode ser definido como um par nomeado problema / solução.

possibilitando uma reação mais pontual e eficiente aos riscos a cada iteração. esta abordagem também apresenta outras vantagens como uma melhor monitoração e controle do projeto a cada teste de iteração.Modelagem de Negócio Levantamento de Requisito Análise e Projeto Implementação T este Implantação Figura 48: Modelo Cascata de Desenvolvimento de Software Fonte: Fonte: Adaptada de BEZERRA (2002) A grande desvantagem desse tipo de abordagem está no adiamento dos riscos inerentes ao processo tornando tardia e cara a correção de erros de fases anteriores. etc. esses modelos de projetos são implementados através de componentes de sistemas e. identificação antecipada de inconsistências entre requisitos. tais componentes são testados de acordo com as funcionalidades definidas pelos casos de uso. construções e implementações. Essa abordagem tem como base o modelo espiral onde os riscos que envolvem o projeto são identificados com antecedência no ciclo de vida. surge o processo iterativo e incremental. Como opção a abordagem em cascata. Caso as funcionalidades testadas ao final de uma iteração sejam validadas. o desenvolvimento prossegue com uma nova iteração que contemplará novas funcionalidades e aperfeiçoará outras em 114 . o maior contato com o usuário final que participa e valida os requisitos definidos em vários momentos do ciclo de vida. aprendizado contínuo dos envolvidos com o projeto com uma melhoria contínua do processo. são identificados e especificados os principais casos de uso que serão implementados ao final da iteração. Além da identificação antecipada dos riscos que envolvem o processo. por fim. são criados os modelos de projeto do sistema com base na arquitetura definida. distribuição mais uniforme da carga de trabalho da equipe como um todo. Para cada iteração.

a saber (KRUCHTEN. 2003): 115 . o RUP engloba demais características que também são consideradas como as melhores práticas de software do mercado. Figura 49: Um Processo Iterativo e Incremental Fonte: Adaptada de KRUCHTEN (2003) Modelagem de Negócio Levantamento de Requisito Modelagem de Negócio Levantamento de Requisito Modelagem de Negócio Levantamento de Requisito Análise e Projeto Análise e Projeto Análise e Projeto Implementação Implementação Implementação Teste Teste Teste Implantação Implantação Implantação Figura 50: Abordagem Iterativa e Incremental Fonte: Adaptada de BEZERRA (2002) Além dessas três características principais. tentandose uma nova abordagem. As figuras abaixo ajudam na compreensão da abordagem iterativa e incremental. Caso ao contrário.desenvolvimento. as decisões tomadas devem ser revistas.

sincronizar os modelos e o código-fonte a cada iteração. são definidos num único momento.Gestão de Requisitos de um sistema de software Os requisitos para a construção de sistemas de softwares representam uma condição ou capacidade que um sistema deve possuir para atender aos objetivos estratégicos para o qual foi concebido. sendo necessária uma gestão dinâmica e contínua para identificá-los. identificar arquiteturas não modulares e inflexíveis. Modelagem com a UML A modelagem visual ajuda a entender a complexidade de um sistema. torna-se fundamental uma avaliação contínua da qualidade das funcionalidades através de testes iterativos em pontos críticos que envolvem os principais cenários e códigos desenvolvidos. principalmente quando é suportada por uma linguagem padrão de mercado como a UML. estabelecer níveis de detalhamento adequados. Também é importante avaliar o desempenho e confiabilidade do sistema. aumentar a qualidade da aplicação. cabe ressaltar que nem todos os requisitos sejam funcionais ou não. Em sendo apoiada por uma boa ferramenta de modelagem é possível. mantendo consistência entre os artefatos (modelos da UML) relacionados com os requisitos. avaliá-los e reformulá-los durante o desenvolvimento do sistema. a construção e a implementação. A adequada gestão de requisitos pode evitar riscos e problemas típicos de um processo de desenvolvimento de software através da identificação antecipada de inconsistências. Além disso. dentro da lógica iterativa. etc. os problemas de software são de 100 a 1000 vezes mais custosos de serem solucionados após a entrega do sistema. 116 . etc. Por isso. entre outros aspectos que contribuem para identificação antecipada de inconsistências. Verificação Contínua da Qualidade do Software Segundo KRUCHTEN (2003). do estabelecimento dos critérios de priorização dos requisitos. assim como as necessidades dos usuários envolvidos. facilitando a uniformização de entendimentos a todos envolvidos no desenvolvimento. da avaliação objetiva de funcionalidades e desempenhos do sistema.

em cada fase ocorrem várias iterações. é importante que a cada conclusão de uma iteração exista uma linha base testada que permita rastrear e identificar os elementos de software impactados pelas mudanças. sendo que cada ciclo apresenta como resultado uma versão do sistema pronta para operação e é subdividido em quatro fases.2. portanto. de que forma os aspectos do ciclo de vida do sistema se desdobram e o eixo vertical representa os fluxos de trabalho que agrupam logicamente as atividades por natureza. Além disso. que passa pelos seguintes fluxos de trabalho: modelagem de negócio. Figura 51: Estrutura do RUP Fonte: Adaptada de KRUCHTEN (2003) 117 . Controle de Mudanças do Software É crucial existir uma coordenação adequada das atividades e artefatos gerados pelos diversos membros das equipes envolvidas no projeto para evitar o caos e.2 O Ciclo de Vida de um Sistema no RUP O RUP consiste de vários ciclos durante a vida de um sistema. sendo que cada iteração representa um ciclo de desenvolvimento. a falta de controle do processo de desenvolvimento. Assim. implementação e teste.reduzindo-se de forma radical os custos relacionados aos problemas encontrados. análise e projeto. através das fases. onde o eixo horizontal representa o tempo e mostra. elaboração. requisitos. 6. construção e transição. concepção. essa lógica é estruturada em duas dimensões. Conforme pode ser observado na figura abaixo.

descriminar os casos de uso críticos do sistema que servirão de referência para as demais fases do processo. A proposta de modelagem de negócio no RUP leva em consideração técnicas de engenharia de software para levantar e modelar diversos aspectos estruturais e 118 . entre outros.1 Concepção Segundo BOOCH et. os fatores críticos para o sucesso do projeto. modelo preliminar com a listagem dos casos de uso e atores identificados num primeiro momento.3. modelo de domínio. 6. também conhecida como fase de início ou de origem. são definidos critérios de sucesso do projeto incluindo avaliação dos riscos.3 Fases da Metodologia Para BOOCH et. Outros artefatos podem ser citados como resultado dessa fase como um glossário do projeto. protótipos.al (2000). uma fase pode ser definida como um período de tempo entre dois importantes marcos do processo de desenvolvimento em que um conjunto bem definido de objetivos é alcançado. os principais objetivos dessa fase são: estabelecer o escopo do projeto delimitando o que deve ou não estar no produto. responsável por expor os riscos. artefatos são concluídos e decisões são tomadas em relação a passagem para a fase posterior.2. A seguir são descritas as fases e suas principais características. mostrar pelo menos uma proposta de arquitetura candidata perante os casos de uso críticos. Para KRUCHTEN (2003). estimar o custo global e os riscos do projeto. as funcionalidades do sistema. as regras de negócio. pode-se citar o documento de Visão do Projeto. os principais fluxos de trabalho envolvidos nessa fase são a Modelagem do Negócio e Levantamento de Requisitos. durante a fase de concepção. al (2000).Os próximos tópicos descrevem brevemente as fases do RUP com os principais fluxos de trabalho e artefatos envolvidos. estimativa e alocação de recursos e um planejamento dos principais pontos de controle do projeto. Como um dos principais artefatos gerados nessa fase. os propósitos e objetivos do negócio. Nesta fase se inicia o levantamento e a modelagem dos processos de negócio e dos requisitos de negócio que devem ser convertidos em casos de uso de sistema. Conforme pode ser observado na figura acima.2. 6. etc.

por exemplo. a arquitetura.comportamentais de uma organização com intuito de entender melhor o domínio do negócio através de seus objetivos estratégicos. 16 Esse modelo representa a maneira como os processos de negócio (casos de uso) são implementados internamente. 119 . as entidades de negócio e os relacionamentos entre eles. é importante ressaltar que dentro do fluxo de trabalho de requisitos são levantados requisitos funcionais e não funcionais. descrevendo através de diagramas de atividades. Os funcionais são todos aqueles que refletem as necessidades diretas dos usuários do sistema e que. confiabilidade. existem outros artefatos como documentos que definem a visão. performance. seus recursos. entre outros aspectos que agregam valor na definição de um sistema de informação. suas regras e processos de negócio. Conforme pode ser observado em KRUCHTEN (2003). Com base na modelagem de negócio. No fluxo de trabalho de requisitos são identificados os requisitos mais relevantes para definição do escopo e da arquitetura do sistema. existem atributos necessários da qualidade de um sistema de software que são definidos no modelo FURPS cujo significado é apresentado na tabela a seguir. portanto. classe e de interação. mostrando de que maneira os processos de negócio são realizados. Além disso. os analistas de sistemas podem através dos modelos de casos de uso de negócio e de objetos de negócio identificar os principais casos de uso de sistemas e seus respectivos atores tendo como resultado o primeiro modelo de caso de uso de sistema. Os principais modelos da UML envolvidos nessa fase são o modelo de casos de uso de negócio e o modelo de objetos de negócio16. o glossário do negócio. definem o comportamento e ações que o sistema deve executar. sua estrutura organizacional. Já os requisitos não funcionais estão ligados a demais atributos não relacionados diretamente as funcionalidades do sistema como. Além desses modelos. os trabalhadores do negócio. entre outros. etc. as regras.

a partir dos casos de uso de sistema modelados no fluxo de requisitos. um modelo inicial de análise com a identificação de algumas classes e seus relacionamentos sendo o primeiro passo para obtenção da visão da arquitetura do sistema. segurança e capacidade do sistema. a definição de uma arquitetura sólida. um modelo de projeto inicial com a identificação de algumas poucas classes de projeto. documentação de usuário e materiais de treinamento.Tabela 2: Modelo FURPS de classificação de requisitos Tipo de Requisito Functional (Funcional) Usability (Usabilidade) Definição Funções. Além disso. Supportability (Suporte) Manutenção. Performance (Performance) Tempo de resposta. Reliability (Confiabilidade) Freqüência de falhas. Fatores humanos (estética. 6. capacidade de testes e adaptabilidade.3.2. recuperação. facilidade de uso e aprendizado). Segundo KRUCHTEN (2003) os principais resultados dessa fase são: 120 .al (2000) coloca que as principais metas da fase de elaboração são a análise do domínio do problema. Os fluxos de implementação e teste que não apresentam muita relevância nessa fase. o desenvolvimento do plano do projeto e a eliminação dos principais riscos do projeto. dentro desse mesmo fluxo de trabalho e criado. uso de memória para execução de uma determinada ação do sistema. de uso de recursos como. de recuperação. previsibilidade e precisão. com base no modelo de análise. dado que os objetivos principais da fase de definição do escopo do sistema e descrição inicial de sua arquitetura são alcançados entre os fluxos de modelagem de negócio e projeto. Fonte: O autor Ainda na fase de concepção. existem outros fluxos de trabalho relacionados como análise e projeto em que é criado. por exemplo.2 Elaboração BOOCH et.

além de avaliar o prosseguimento para a próxima fase. é possível visualizar de forma detalhada o escopo e os objetivos do sistema. os requisitos não funcionais. Nessa fase tanto a análise quanto o projeto são realizados num nível arquitetural envolvendo casos de uso. classes. É importante destacar o papel do arquiteto dentro do projeto do sistema. as atividades do fluxo de trabalho de requisitos estão relacionadas à identificação de casos de uso adicionais que não foram identificados na fase de concepção. por 121 . atores e descrições dos casos de uso definidos. com os resultados acima. a arquitetura escolhida e as soluções para os principais riscos do projeto. Um protótipo arquitetônico executável. Uma descrição da arquitetura de software. seus relacionamentos e atributos. As atividades do fluxo de análise e projeto estão voltadas para os casos de uso significantes para a arquitetura do sistema. pacotes e subsistemas importantes para arquitetura. pois ele realiza o projeto da arquitetura em camadas. Um manual de usuário preliminar. Levantamento da maioria dos requisitos que não estejam associados diretamente aos casos de uso como. a fase de construção. Dessa forma. O modelo de casos de uso elaborado nessa fase deve ter em torno de no mínimo 80% dos casos de uso referentes ao sistema com as respectivas descrições dos casos de uso principais para embasar a compreensão dos requisitos funcionais e a criação da arquitetura do sistema. Os principais fluxos de trabalho dessa fase são requisitos e. Nessa fase. onde as camadas mais baixas representam os mecanismos em que o sistema irá operar como.Um modelo de caso de uso com a maior parte (pelo menos 80%) dos casos de uso. é possível estimar com precisão os custos e o cronograma para o projeto. por exemplo. Um plano de desenvolvimento para o projeto global com estabelecimento de critérios de avaliação para cada iteração. análise e projeto. onde os modelos de análise e projeto da fase de concepção são refinados com a definição de classes de análise e de projeto. Ao final dessa fase. principalmente. Uma lista de riscos revisada.

portanto. o treinamento dos usuários. performance do sistema. com base no modelo de projeto revisto e atualizado no fluxo anterior. incluindo requisitos funcionais e não funcionais como. O fluxo de implementação se caracteriza como principal fluxo de trabalho dessa fase. é desenvolvido estando pronto para a operacionalização e transição aos usuários. pois. Segundo KRUCHTEN (2003) os principais resultados dessa fase são o produto de software integrado com as plataformas adequadas e os manuais de usuários com a descrição do sistema. Durante essa fase. ou seja.3. no que se refere ao fluxo de trabalho de requisitos. são detalhados os casos de uso remanescentes e são construídos protótipos de interface com usuário. a migração de 122 . próximas aos usuários do sistema. 6. implementa o sistema em termos de componentes de software.3 Construção É na fase de construção em que o sistema.4 Transição O principal objetivo dessa fase é disponibilizar inicialmente uma versão beta do sistema para a comunidade de usuários para identificação de questões que requerem algum desenvolvimento adicional com objetivo de ajustar o sistema para o lançamento da versão final que entrará em produção. com base no modelo de projeto.2. Com relação ao fluxo de análise e projeto tanto os modelos de análise quanto de projeto devem ser complementados com os casos de uso remanescentes para todos os casos de uso sejam contemplados na arquitetura do sistema. no fluxo de teste onde ocorrem os testes da primeira versão operacional do sistema. arquivos executáveis. enquanto produto completo.3. Por fim. 6. código fonte. Outras questões também são levadas em consideração nessa fase como. os elementos da arquitetura do sistema. Os fluxos de trabalho de implementação e teste na fase de elaboração têm como principais objetivos implementar e testar. por exemplo.2. sistemas de banco de dados e as camadas mais altas próximas às aplicações da arquitetura e. por exemplo. entre outros.exemplo.

entre outras. incluindo fluxos de trabalho como a "Modelagem de Negócio" que utiliza os diagramas de casos de uso para modelar processos de negócio. Foi verificado que o RUP enquanto processo de desenvolvimento de sistemas. foi possível entender de que forma os diagramas da UML são utilizados na criação de um software. Através dessa metodologia. Além disso. por exemplo. a não visualização do fluxo de controle dos processos. Ao final dessa fase. 6. 123 . não utiliza nenhum tipo de modelo para explicitar os objetivos estratégicos que devem suportar os processos e não apresenta nenhuma proposta de uma arquitetura de negócio quebrada em vistas.3 Considerações Finais Neste capítulo foram apresentadas algumas das principais etapas para modelagem de processos de negócio e algumas das principais características dos processos de desenvolvimento de sistemas.dados do legado para o novo sistema. tomando como referência o RUP da empresa Rational Software. determinando a necessidade de se iniciar um outro ciclo de desenvolvimento e as lições aprendidas com o projeto são assimiladas para projetos futuros. apesar de apresentar um fluxo de trabalho denominado de "Modelagem de Negócio" ainda apresenta algumas deficiências com relação à modelagem de processos de negócio. o que dificulta a compreensão e a análise de um negócio. Foram mostradas as fases de desenvolvimento de um sistema de software e seus respectivos artefatos. utiliza como base para modelagem de processos de negócio o modelo de casos de uso que apresenta limitações como. os objetivo do ciclo de vida do projeto são avaliados. pois.

A figura abaixo ajuda a entender melhor o relacionamento entre o processo de modelagem de negócio e o processo de desenvolvimento de sistemas de informação. 7. o que leva ao desenvolvimento de sistemas de informações 124 . mostrando que os processos de negócio devem estar relacionados com os objetivos de uma organização para que possam ser modelados de forma consistente com a estratégia adotada e para que possam gerar requisitos funcionais e não funcionais mais consistentes com o negócio. qualidade. um ator de um caso de uso. ou seja. desempenho. por exemplo. Identificar requisitos funcionais através de um conjunto correto de funções ou casos de uso que o sistema deve fornecer aos processos de negócio. Identificar requisitos não funcionais que não são especificados nos casos de uso como. entre outros.7 PROPOSTA PROCESSOS METODOLÓGICA E REQUISITOS DE DE MODELAGEM NEGÓCIO DE PARA DESENVOLVIMENTO DE SISTEMAS Nesse capítulo será apresentada uma proposta de metodologia de modelagem de processos de requisitos de negócio para desenvolvimento de sistemas. Identificar classes de negócio candidatas a se tornarem classes de sistemas como. componentes de software. tempo de acesso. questões relacionadas a segurança. considerando alguns dos principais modelos tradicionais da EPN e da UML. por exemplo. Identificar componentes de negócio que possam encapsular uma específica funcionalidade de negócio de tal forma que possa ser reutilizada para diferentes propósitos de modelagem de negócio e que possam ser desdobrados em componentes técnicos.1 Modelagem de Negócio para Sistemas – Principais Fases a Artefatos ERIKSSON e PENKER (1999) colocam que a modelagem de negócio é utilizada para os seguintes aspectos da modelagem de software: Identificar informações de sistemas que possibilitem um melhor suporte a operação do negócio.

conforme observado na figura abaixo (Modelagem de Negócio. <<goal>> Eliminação do problema: Objetivo qualitativo <<abstract>> Objetivos e visões do negócio <<abstract>> Problema <<abstract>> Estratégias Desc_Objetivo: “Para melhorar o negócio e seus sistemas eliminando todos os problemas percebidos durante a ánalise. Implementação e Teste) pode125 . Desenvolvimento da Estratégia e Arquitetura. serão utilizados os modelos da metodologia ARIS e os modelos da UML.alinhados tanto aos processos de negócios quanto aos objetivos estratégicos da organização. Para melhor compreensão dessa modelagem de negócio para sistemas. Análise e Redesenho dos Processos Futuros e Implementação dos Processos Futuros). um projeto cuja modelagem de processos de negócio está orientada para desenvolvimento de sistemas pode ser dividida em cinco etapas (Definição do Mapa Estratégico. Modelagem dos Processos Atuais. Análise e Projeto. este tópico tem como principal objetivo comparar as abordagens citadas e estabelecer uma transição mais clara das informações levantadas na modelagem de um negócio para a modelagem de um sistema de informação.” <<process>> <<abstract>> Contexto Modelagem de Processsos de Negócio <<abstract>> Melhorias no negócio <<information>> Requisitos funcionais e não funcionais do sistema <<process>> Desenvolvimento de Sistemas de Informação <<physical>> Sistema Legado <<abstract>> Documentação existente e modelos <<abstract>> Padrões de Projeto <<abstract>> Conhecimento <<physical>> Novos componentes Figura 52: Diagrama de Processos mostrando a relação entre Processos de Negócio e Sistemas Fonte: Adaptada de ERIKSSON e PENKER (1999) Apresentado o RUP e algumas abordagens de metodologia de modelagem de processos de negócio. Conforme foi possível observar na figura abaixo. Levantamento de Requisitos. Comparando essas etapas com os fluxos de trabalho do RUP.

para representar processos de negócio. Na figura abaixo é possível visualizar essa comparação. Desenvolvimento da Estratégia e Arquitetura. esta proposta apresenta limitações quanto a representação e modelagem dos fluxos dos processos de negócio e suas integrações e quanto ao alinhamento dos casos de uso identificados com os objetivos do negócio.se dizer que a etapa de Modelagem de Negócio do RUP deveria contemplar as quatro primeiras etapas: Definição do Mapa Estratégico. Modelagem dos Processos Atuais e Modelagem dos Processos Futuros. Mas. a modelagem de negócio no RUP é realizada com base em técnicas de modelagem de software. Porém. 126 . mais especificamente os casos de uso de negócio. Todas as informações documentadas nessas três etapas servem de requisitos de negócio para o desenvolvimento de sistemas.

“Levantamento de Requisitos” e parte da fase “Análise e Projeto” considerando apenas o diagrama de classes que envolve os principais conceitos do negócio. 127 . “Teste” e “Implantação” bem como seus artefatos.Modelagem de Processos de Negócio Definição do Mapa Estratégico Desenvolver Estratégia e Arquitetura Modelagem dos Processos Atuais Análise e Redesenho dos Processos Futuros Implementação dos Processos Futuros Modelagem de Sistemas de Informação Modelagem de Negócio Levantamento de Requisito Análise e Projeto Implementação Teste Implantação Figura 53: Análise comparada entre etapas de Modelagem de Processos de Negócio e de Desenvolvimento de Sistemas Fonte: O autor. Assim. o foco principal será dado nas fases de Concepção e Elaboração do RUP no que se refere aos fluxos de “Modelagem de Negócio”. adaptada de IDS SCHEER (2002) Cabe ressaltar que essa dissertação não pretende detalhar na metodologia proposta as fases de “Implementação”.

seria a fronteira entre a especificação do negócio realizada pelo Analista de Negócio e a especificação funcional de sistemas realizada pelo Analista de Sistemas. todos os artefatos gerados nessas fases devem ser definidos na fase de Concepção e se necessário refinados na fase de Elaboração. Nos tópicos a seguir. identifica as classes de objetos que representam os principais conceitos do negócio. Em seguida deve ser executada a fase de "Análise e Projeto" onde o Analista de Sistema. 128 . portanto. processos e recursos do negócio. pertencente à metodologia de modelagem de processos de negócio. considerando a lógica de melhoria contínua dentro de um processo de desenvolvimento de sistemas iterativo e incremental. Dessa forma.1 Modelagem e Levantamento de Requisitos de Negócio Nessa fase devem ser levantados os objetivos. a fase de “Modelagem de Negócio” pertencente à metodologia de modelagem de sistemas de informação deve contemplar o levantamento e modelagem das diretrizes estratégicas que devem ser sustentadas e associadas aos processos de negócio modelados. com base nos artefatos gerados na fase "Modelagem e Levantamento de Requisito de Negócio". bem como seus atributos e operações. Logo.Conforme a figura acima mostra. a fase de modelagem de negócio como um todo deve contemplar de forma satisfatória o levantamento dos requisitos de negócio necessários para que o Analista de Sistema possa fazer análise e projeto do sistema de forma consistente com as necessidades do negócio. considerando as oportunidades de melhoria relacionadas aos processos de negócio atuais. 7. essa fase relacionada de forma estreita ou até mesmo sendo parte da fase “Modelagem de Negócio”. para que estes possam ser remodelados numa situação futura e que a partir deles possam ser derivados os casos de uso. a fase de “Análise de Redesenho dos Processos de Negócio”. boa parte dos artefatos levantados na fase de “Levantamento de Requisitos” deve ser de responsabilidade do Analista de Negócio. É importante observar que dentro da lógica iterativa e incremental estabelecida pelo RUP.1. o que faz com que estas fases possam ser definidas em uma única fase denominada de "Modelagem e Levantamento de Requisitos de Negócio". são descritas as fases de “Modelagem e Levantamento de Requisitos de Negócio” e os artefatos relacionados às mesmas. estando. Assim.

4 e foi utilizado para descrever os demais processos listados abaixo. o primeiro passo a ser realizado pelo Analista de Negócio é a definição dos objetivos da organização com um todo. mostrando as relações de dependência desde os objetivos estratégicos até os operacionais. Necessidade de definição do negócio Analista de Negócio Modelar objetivos do negócio Modelo de Objetivos Analista de Negócio Modelar processos de negócio atuais Modelos de processos atuais Analista de Negócio Identif icar necessidade de melhorias Lista de Problemas e Soluções Analista de Negócio Modelar processos de negócio futuros Modelos de processos futuros Analista de Negócio Derivar casos de uso dos processos Modelos de Casos de Uso Analista de Sistema Modelar diagrama de classes conceitual Modelo de Classes Requisitos de negócio levantados Fase de Análise e Projeto Figura 54: Fluxo de Modelagem e Levantamento de Requisitos de Negócio Fonte: O autor. esses objetivos em sub-objetivos. Conforme pode ser observado no fluxo acima. Para a representação desse processo. desdobrando. 129 . de forma hierárquica.3. Após a 17 O modelo EPC e suas notações foram explicados no tópico 3.Na figura abaixo é possível visualizar de que forma deve ser executada essa fase. foi utilizado o modelo EPC da ferramenta ARIS Toolset17. mostrando as principais atividades que devem ser executadas pelo Analista de Negócio para que se elabore uma especificação de negócio adequada ao desenvolvimento de sistemas de informação.

identificação dos objetivos deve-se associá-los aos processos de negócio que irão suportá-los. É importante destacar que as relações entre objetivos e processos pode ser tanto de um para um como de um para muitos, ou seja, um processo pode estar associado a um ou mais objetivos e um objetivo pode estar associado a um ou mais processos. Como resultado dessa atividade deve-se ter um modelo de objetivos. Em seguida, o Analista de Negócio deve identificar e modelar os processos de negócio atuais descrevendo numa lógica temporal as seqüências de atividades que devem ser executadas em cada processo para se alcançar os objetivos definidos anteriormente. Além disso, o Analista de Negócio também deve identificar e modelar os recursos ( sistemas, informações de entrada e saída, unidades organizacionais responsáveis, etc) que serão necessários para execução dos processos de negócio como, por exemplo, o modelo de organograma que define a hierarquia entre as unidades organizacionais e serve de base para definição de papéis e responsabilidades na execução dos processos de negócio, o diagrama de gráfico de estados que serve de base para definir os comportamentos de determinados recursos ao longo dos processos de negócio como, por exemplo, uma ordem de serviço que pode assumir diversos estados ao longo de sua "vida" útil como, por exemplo, ordem de serviço solicitada, em produção, cancelada, finalizada, alterada, etc. Como resultado dessa atividade têm-se os processos de negócio associados aos recursos identificados, permitindo realizar análises para identificar oportunidades de melhorias nos processos. Na próxima atividade o Analista de Negócio deve identificar as necessidades de melhorias nos processos de negócio, devendo identificar os principais problemas, priorizá-los e solucioná-los. Como exemplo de melhoria, pode-se identificar a necessidade de se automatizar carências de suporte automatizado de informações nos processos de negócio o que leva a definição de novos sistemas de informação, etc. Como resultado dessa atividade pode-se citar, por exemplo, uma listagem de problemas e soluções (novos requisitos de negócio) que devem ser implantadas. Identificado os principais problemas e soluções a serem adotadas, o Analista de Negócio deve modelar os novos processos e, caso necessário, os novos recursos que estarão sendo implantados para execução do negócio. Com os processos futuros identificados e com os demais requisitos de negócio identificados o Analista de Negócio deve identificar os casos de uso associados aos processos de negócio. É importante ressaltar que a derivação dos casos de uso dos 130

processos de negócio muitas vezes não é uma relação direta um para um, podendo ser um para muitos, ou seja, um processo ou uma atividade de um processo, dependendo do nível de detalhamento em que estejam modelados, podem gerar apenas um ou vários casos de uso. Além disso, os casos de uso podem ser derivados de diferentes níveis de detalhamento. Conforme pode ser visto na figura abaixo, um caso de uso foi derivado do macroprocesso representado pelo modelo VAC e outros dois foram derivados das atividades do EPC que apresenta um nível de detalhamento maior que o VAC.

Figura 55: Derivação de casos de uso a partir de processos de negócio Fonte: O autor.

Cabe ao Analista de Negócio identificar o nível de detalhamento adequado para identificação e descrição dos casos de uso. As descrições dos casos de uso devem considerar os objetivos dos mesmos, os fluxos de eventos normais e alternativos, as pré e pós-condições para execução do mesmo, entre outros fatores que auxiliam na definição dos requisitos de negócio. Essas descrições normalmente são feitas de forma textual. Uma discussão interessante, vivenciada pelo autor em alguns projetos de desenvolvimento de sistemas, está relacionada a papéis e responsabilidades de modelagem que envolve tanto o Analista de Sistema como o Analista de Negócio. Essa discussão gira em torno da responsabilidade de modelagem dos diagramas de casos de 131

uso que são os diagramas da UML que fazem a principal ponte entre as necessidades do negócio e, portanto, dos usuários e a análise e projeto de um sistema. Na experiência vivenciada pelo autor, os Analistas de Negócio envolvidos nos projetos inicialmente não conseguiram utilizar os diagramas de caso de uso, pois, não apresentavam domínio da técnica de modelagem do mesmo e apresentavam resistência em seu aprendizado pelo fato de ser uma técnica originalmente relacionada a desenvolvimento de sistemas. Com a falta de domínio e resistência ao aprendizado, a modelagem de casos de uso era realizada por Analistas de Sistema que acompanhavam o desenvolvimento e modelagem dos processos de negócio e interagiam de forma estreita com os Analistas de Negócio. Com o tempo, os Analistas de Negócio passaram a realizar a modelagem dos casos de uso porque perceberam que a elaboração dos diagramas de casos de uso facilitava consideravelmente o trabalho do Analista de Sistema e que as informações contempladas nos casos de uso só poderiam ser fornecidas pelos próprios Analistas de Negócio, pois, envolviam conceitos e regras de negócio que não eram do domínio do Analista de Sistema. Logo, os Analistas de Negócio passaram a elaborar uma especificação de negócio orientada para o desenvolvimento de um sistema de informação com a utilização dos diagramas de casos de uso o que reduziu o tempo de desenvolvimento dos sistemas, pois, reduziram os conflitos e as dúvidas entre os Analistas de Negócio e de Sistema. Após a modelagem dos diagramas de casos de uso, o Analista de Sistema deve levantar um artefato que geralmente não é de domínio do Analista de Negócio que é o diagrama de classes conceitual. O Analista de Sistema deve analisar os requisitos de negócio levantados para modelar o diagrama de classes conceitual e em paralelo deve também analisar os requisitos não funcionais levantados pelo Analista de Negócio, complementá-los se necessário e levantar outros requisitos não funcionais. Feito isso, a próxima fase seria a de "Análise e Projeto" onde serão desenvolvidos outros diagramas voltados para implementação do sistema como, por exemplo, os diagramas de classes de sistemas. Para melhor compreensão da metodologia proposta, a tabela abaixo mostra as principais fases e artefatos que devem ser gerados pelo Analista de Negócio para a criação de uma especificação de negócio bem como as fases e artefatos que devem ser gerados pelo Analista de Sistemas para elaboração de uma especificação funcional.

132

Já os artefatos gerados pelo Analista de Sistema estão representados pela cor amarela É importante colocar que algumas vezes o artefato “Requisitos Não Funcionais” pode ser feito em parte pelo Analista de Negócio. a responsabilidade de levantamento desse artefato é do Analista de Sistema. pois são definidos requisitos como.Na fase de “Modelagem e Levantamento de Requisitos de Negócio”. por exemplo. Porém. estão representados na tabela abaixo pela cor vermelha. tempo de acesso às informações e segurança do sistema que são definidos e validados de acordo com as necessidades do negócio e também de acordo com as tecnologias envolvidas na solução. 133 . os artefatos que devem ser gerados pelo Analista de Negócio.

por exemplo.Tabela 3: Fases e Artefatos da Metodologia Proposta Modelo objetivos do negócio – nessa etapa são levantados todos objetivos e sub-objetivos estratégicos que justificam e existência do negócio e servem de base Maximizar participação no mercado Reduzir Custos para a modelagem dos processos e dos sistemas de Aumentar índices de crescimento Melhorar qualidade Cumprir prazos de entrega Lotes de produção negócio. Ex. tamanho. produtos. regras de negócio e objetivos associados aos processos. Esse levantamento pode ser realizado Penetrar mercado asiático Controle de Produção T amanho dos estoques textualmente ou graficamente como. EPC. origem.. é importante levantar o dicionário de dados18 que envolve o sistema em desenvolvimento. devem ser levados com relação ao levantamento de dados. Esse levantamento deve seguir os princípios de modelagem definidos. deve ser sustentado por uma boa ferramenta de modelagem de processos. por exemplo. numérico. sua descrição. insumos. FAD entre outros apresentados no capítulo 3. Modelo de processos e de requisitos de negócio – nessa etapa são modelados os processos de negócio que são criados a partir dos objetivos estratégicos definidos Ex.. 18 O dicionário de dados ajuda na definição dos campos de um sistema. Estão diretamente atrelados as regras de negócio. 134 . entre outros.). podendo ser realizado por diagramas como. Processos EPC Macro-processo VAC e são ressaltados os recursos. Além disso. pelo diagrama de objetivos. também são identificados alguns requisitos não funcionais identificados tanto pelo Analista de Negócio quanto pelo Analista de Sistemas e podem ser descritos textualmente.São levantados também os requisitos funcionais que definem o que o sistema deve fazer e ajudam a estabelecer o escopo do sistema a ser desenvolvido. Costumam ser explicitados textualmente. se é editável ou não. o VAC. Nesse momento. considerando aspectos como tipo do campo (alfa.

bem como descrições das regras e requisitos de negócio associados ao desenvolvimento do sistema e aos modelos de casos de uso e diagrama de classes conceitual pertencente a UML. Esses casos de uso podem ser derivados diretamente das funções dos processos de negócio conforme pode ser observado no item 5.6. foi criada a tabela abaixo que exemplifica e demonstra os principais elementos de cada modelo e suas relações. Cabe ressaltar que esse diagrama de classe é do tipo conceitual. Empresa nome telefone endereço Atributos Realizar Pagamento Cliente <<inclui>> Realizar Pedido Cliente <<estende>> Requisitar Catálogo do Pedido <<generaliza>> Realizar Pagamento em Dinheiro Pedido Cliente códigoDoCliente limiteDeCrédito incluirPedido( ) Operações atenderPedido( ) 1 Agregação Associação Multiplicidade * Pedido.Modelos de Casos de Uso – após a modelagem dos processos de negócio e identificação dos sistemas de informação que irão suportar esses processos. caso de uso e diagrama de classes. item quantidade Produto incluirItemPedido( ) calcularTotalPedido( ) Generalização Superclasse Chocolate Subclasse Papel contratante Nome da Associação Contrata Papel contratado Pessoa razãoSocial endereço Emprego salário dataContratação Classe Associativa Na proposta metodológica citada acima foram utilizados como exemplo de artefatos para a realização da fase “Modelagem e Levantamento de Requisitos de Negócio” alguns dos modelos tradicionais da EPN como os Diagramas de Objetivo.2. nessa perspectiva são levantados os principais conceitos que estão envolvidos no domínio que está sendo estudado e tais conceitos serão relacionados à classes que irão representá-los no diagrama. Conforme observado no tópico 4. Modelos de Classes – a partir dos diagramas de casos de uso e de seqüência é possível identificar as classes do sistema.1. Para melhor entender dentro da metodologia proposta a transição dos elementos entre os modelos EPC. 135 . são Cliente Sistema de Caixa Eletrônico Realizar Saque <<inclui>> Fornecer Identif icação Obter Extrato identificados e descritos os casos de uso que irão representar as funcionalidades e as interfaces entre os diversos atores do processo com o sistema de informação. Fonte: O autor. VAC e EPC pertencentes à metodologia ARIS e suportados pela ferramenta ARIS Toolset. suas operações e atributos.1.

o elemento Executor do EPC torna-se Ator do Caso de Uso. Foi proposta a junção das fases "Modelagem de Negócio" e "Levantamento de Requisitos" em uma fase denominada de "Modelagem e Levantamento de Requisitos de Negócio" cuja responsabilidade de execução foi delegada em parte ao Analista de Negócio e em parte ao Analista de Sistema.2 Considerações Finais Nesse capítulo foi proposta uma metodologia de modelagem de processos de negócio orientada para desenvolvimento de sistemas onde foi possível utilizar como artefatos tanto modelos de negócio tradicionais como os modelos da UML. pode-se extrair Descrição de Casos de Uso e dessas descrições pode-se extrair classes conceituais para o Diagrama de Classes Conceitual. O elemento Atividade do EPC torna-se o próprio Caso de Uso e é através desse Caso de Uso que se extrai algumas classes conceituais para o Diagrama de Classes Conceitual. Como apresentado acima. No próximo tópico serão descritos dois exemplos baseados em experiências práticas que demonstram a metodologia proposta acima e a transição dos modelos 136 .Tabela 4: Comparação entre o EPC x Casos de Uso x Diagrama de Classe. 7. EPC (Elementos) Casos de Uso (Descrição e Di agrama) Diagrama de Classes Conceitual Executor Ator Extraem-se algumas classes conceituais Classes Atividade Caso de Uso Fonte: O autor É possível verificar que através dos elementos do EPC.

tradicionais de negócio para os modelos de caso de uso que servem de ponte e linguagem comum entre o Analista de Negócio e o Analista de Sistema. 137 .

em sua maioria. mostrando a transição dos requisitos de negócio para os de sistemas. por questões de sigilo. Além disso. Além disso. Seus clientes diretos são. não considerando demais modelos relacionados à modelagem dos processos de negócio. 8. Cabe ressaltar que os exemplos foram inseridos nessa dissertação com o intuito de melhor explicitar a metodologia proposta e não pretende demonstrar todos os artefatos gerados durante o projeto. et al. 2003) que teve como base um estudo em uma empresa do setor farmacêutico. cabe ressaltar que o projeto apenas considerou a utilização dos modelos da UML. É importante ressaltar que o projeto realizado na empresa de TI utilizou tanto o EPC enquanto modelo de EPN e o caso de uso enquanto modelo da UML. No segundo exemplo. Projeto e Gerência de Sistemas (ROCHA. a mesma busca alcançar uma posição competitiva de liderança em custos e prazos de ativação de seus produtos frente a seus competidores. grandes e médios clientes.1 Descrição do Caso da Empresa de TI A Empresa WTelcom é uma organização do setor de telecomunicações focada no aprovisionamento de produtos de dados e voz para o mercado de massa e corporativo. é importante colocar que todos os projetos foram 138 .8 CASOS DE APLICAÇÃO DA METODOLOGIA PROPOSTA Este capítulo tem como objetivo aplicar a metodologia proposta através da descrição de dois casos baseados num projeto em uma empresa de TI e um outro baseado num trabalho de projeto final apresentado à Pontifícia Universidade Católica do Rio de Janeiro (PUC-RJ) no curso de Pós-Graduação em Análise. mostrando apenas aqueles mais relevantes. Neste contexto. partindo-se da atividade de modelagem dos processos futuros da fase "Modelagem e Levantamento dos Requisitos de Negócio". Além disso. É importante ressaltar que esse caso é resultado de algumas experiências práticas vivenciadas em alguns projetos que foram realizados ao longo de quatro anos de trabalho na WTelcom. os nomes das empresas e alguns dados foram alterados. através da análise do relatório final do projeto e de entrevistas com seus autores complementou o projeto com os demais modelos de negócio da metodologia proposta. o exemplo considera que todos os problemas e oportunidades de melhorias já foram identificadas e levantadas. O autor da dissertação.

serviu de base para a realização do estudo de caso e. Entretanto. até diferentes ações de aprovisionamento19 de um mesmo produto. Um desses projetos foi utilizado como estudo de caso para a elaboração da metodologia proposta. Neste sentido. Alteração. Desativação. outro projeto realizado ao longo desse período de quatro anos.1.1 Componentização e Padronização de Processos de Negócio Dentro da Gerência de Processos Operacionais da WTelcom. denominado de Componentização e Padronização de Processos de Negócio. Porém. 19 Ações de processos – pode ser entendido como os tipos de processos comumente envolvidos no setor de telecomunicações: Ativação. se limitando aos processos de negócio relacionados a essa área. etc. No entanto. será descrito brevemente a seguir. sendo que. foi identificado que os diferentes produtos construídos apresentavam processos de aprovisionamento com bastantes semelhanças.realizados no âmbito da Gerência de Processos Operacionais da empresa. foi iniciado um projeto na empresa cuja a primeira fase consistiu na modelagem e análise de processos com base na idéia de componentização de processos . 139 . portanto. não apresentava muita agilidade para colocar o produto em tempo hábil no mercado. pois reiniciava-se a cada lançamento de um novo produto. por vezes. Este documento é passado para a área de TI para servir de suporte à construção do sistema de aprovisionamento do produto em questão. denominados de sistemas de aprovisionamento. todo o processo de elaboração da especificação operacional. por vezes. que consiste em um relatório contendo todas os requisitos e processos do produto. para que um produto e seu respectivo sistema de informação seja desenvolvido é necessário elaborar uma especificação operacional. 8. buscando uma melhor execução e gestão das atribuições e objetivos da gerência responsável pelos mesmos. sem aproveitar praticamente nada do que já existia disponível. Com a necessidade de reduzir o tempo de desenvolvimento dos novos produtos. Bloqueio. foram demandadas técnicas que pudessem agilizar a modelagem e levantamento dos seus processos e requisitos de negócio. subsidiando a tomada de decisão. apresentavam processos muito parecidos. em nível da alta gerência.

Terminada a primeira fase. que estivessem diretamente relacionadas às plataformas de rede e suas funcionalidades. O levantamento e modelagem dos dados das demais fases do Processo Padrão de Ativação e das fases referentes às demais ações de aprovisionamento (Desativação. buscou-se realizar a componentização dos processos de aprovisionamento dos diferentes produtos. por exemplo. Com relação ao escopo dessa fase. etc. pelos analistas de processos de todas as famílias de produtos/serviços da empresa. documentos de marketing com premissas de desenvolvimento de 140 . ficou definido que diante do prazo estabelecido. resultado da primeira fase. sistemicamente. da área de TI e. Cancelamento. como a elaboração das suas especificações técnicas e conseqüentemente o desenvolvimento dos sistemas corporativos necessários para o seu aprovisionamento. foi dado início uma outra fase onde foram levantados os principais dados/informações referentes aos componentes de processos definidos na fase anterior. com resultados claros nos indicadores da Gerência envolvida no projeto. Neste contexto. de forma que a modelagem dos processos operacionais tornasse mais rápida tanto a divulgação dos processos internamente. documentos técnicos relacionados aos equipamentos e plataformas de rede envolvidas no aprovisionamento. espera-se atingir vários benefícios no âmbito da Gerência.) ficou para uma próxima fase do projeto. que deverão ser seguidos. optou-se pelo levantamento e modelagem dos dados de algumas das fases do macroprocesso. Alteração. desde a sua contratação até operacionalização e cancelamento. Durante este trabalho de componentização de processos e com vistas à componentização de sistemas realizado na empresa WTelcom. seria dada prioridade ao levantamento dos dados das fases de aprovisionamento do Macroprocesso Padrão de Ativação. Estas fases foram definidas e padronizadas anteriormente no Projeto de Padronização de Processos Operacionais. foi possível obter modelos padrões para as diversas etapas dos processos que compõem o serviço/ produto. doravante. Como base de desenvolvimento para o projeto foram utilizados documentos já existentes como. ou ainda das diferentes ações de aprovisionamento de um mesmo produto.Desta maneira. Com esta padronização. o relatório resultante da primeira fase do projeto.

por exemplo. foi iniciada a modelagem destes dados na ferramenta ARIS Toolset. detalhando esses dados em frames e campos. O objetivo final a que o projeto se propõe alcançar. Estes documentos e mais as reuniões que foram realizadas com analistas de negócio de outras áreas (como. deram subsídios para os analistas de negócio da Gerência de Processos Operacionais iniciarem o levantamento das informações técnicas de aprovisionamento. é mais ambicioso. suas funcionalidades. de forma a acelerar sobremaneira o desenvolvimento de novos serviços/produtos na empresa WTelcom. as telas de sistemas de aprovisionamento já implantados ajudaram no levantamento das informações. campos e frames (conjunto de campos) e em seguida essas informações foram modeladas na ferramenta ARIS Toolset. Os principais benefícios gerados com esse projeto estão listados abaixo: 141 . no entanto. envolvendo a obtenção de componentes de processos genéricos que possam ser utilizados diretamente para a modelagem de processos e também serem desdobrados em componentes de sistemas. Além disso. Para cada família de produtos foram identificadas e levantadas as principais plataformas. entre outros. Após a identificação dos dados para configuração de funcionalidades nas plataformas. a Área de Engenharia). Assim. O projeto teve como seu principal resultado o levantamento dos dados das principais plataformas de configuração levantadas para cada família de produto. os especialistas de cada família de produto ficaram com a responsabilidade de realizar o levantamento das funcionalidades e respectivos dados das plataformas de rede envolvidas com a solução do cliente e associá-los aos processos definidos na primeira fase do projeto.produtos. com esse levantamento é possível identificar as potencialidades dessas plataformas que podem ser utilizadas para darem suporte às soluções customizadas. O mapeamento desses dados permite à Gerência de Processos Operacionais identificar de forma mais rápida as funcionalidades existentes nas plataformas podendo gerar especificações de novos produtos num menor tempo de desenvolvimento. Além disso. de acordo com a metodologia adotada no escopo do projeto. realizada pelos analistas de processos da Gerência de Processos Operacionais. ou nos elementos de rede de uma plataforma.

demais conceitos e tecnologias relacionadas à automação dos processos de negócio e definição de arquiteturas de sistemas de informação como. avaliandose a utilização dos diagramas de casos de uso da UML como linguagem comum entre as áreas de negócio e de TI. as tecnologias de workflow e integração entre aplicativos (Enterprise Aplication Integration – EAI). devem ser considerados para viabilizar o desenvolvimento de sistemas com arquiteturas mais flexíveis e centradas em processos de negócios e não somente em tecnologia de desenvolvimento. Redução do tempo total de desenvolvimento e operacionalização de produtos.• • • • Formalização e padronização da modelagem de processos dentro da Área de Processos Operacionais. 142 . No âmbito desta atividade está incluída a integração das atividades de concepção de processos. entre outros. desenvolvimento. • • • Aumento da flexibilidade frente às variações da demanda e para atender de forma rápida soluções customizadas. Melhora das interfaces processuais com respectivos fluxos de informação entre as áreas de operações. seus dados e os caso de uso. Maior facilidade para o gerenciamento dos processos. foi sugerido uma maior interação com a área de TI para definição da camada de apresentação. Apoio à melhoria dos processos e desenvolvimento de sistemas de suporte à operação. Na figura abaixo é possível visualizar a relação entre os processos de negócios. Como uma das sugestões para dar continuidade ao projeto. por exemplo. os Business Process Management Systems (BPMS). operacionalização e manutenção de sistemas. implementação. Além disso. faturamento e vendas. Aceleração do desenvolvimento e adequação dos sistemas que suportam os produtos através da identificação e modelagem de dados por tecnologia utilizada. por exemplo.

Essas chamadas. 8. A seguir será visto um caso onde foi realizado a especificação de negócio um produto da WTelcom. permitindo a realização de chamadas locais. Fonte: O autor. Em virtude desse entroncamento. aumentando a taxa de ligações completadas e oferecendo descontos por volume.Config RI NEC.doc Sistema da Plataforma RI NEC Figura 56: Elaboração de uma Especificação de Processos e Requisitos de Negócio. chamadas podem ser originadas de telefones fixos ou públicos pertencentes à rede Pública de Telefonia. PO . este novo serviço é capaz de prover um elevado grau de qualidade no escoamento do tráfego. bem como 143 .2 O Caso do Produto TelVip O caso é construído com base em um dos novos produtos que foi desenvolvido e que necessitava de um sistema de suporte para sua operacionalização. Além disso.REPOSITÓRIO DE COMPONENTES DE PROCESSOS E REQUISITOS DE NEGÓCIO Opção com menor grau de granularidade Macro-processo Macro processo Opção com menor grau de granularidade Diagrama de Casos de Uso S istema de Caixa Eletrô nico Processos (EPC) Realizar <<inclui>> Saque Fornece r Identificação Cliente Obter Extrato <<inclui>> Diagrama de Funções (FAD) CCR RI SP Realizar Pagamento Cliente <<gene raliza>> Realizar Pagamento em Dinheiro Cliente <<estend e>> Requisitar Realizar Catálogo do P edido Pedido Dados de Entrada Configuração RI NEC Configurar RI NEC Dados de Saída Configuração RI NEC Especificação de Processos e Requisitos de Negócio Ex . Portanto. Consiste no entroncamento direto da Central da WTelcom ao cliente.1. este produto deverá oferecer facilidade de acesso remoto para realização de chamadas telefônicas. É um produto de voz destinado prioritariamente ao mercado empresarial e denominado de TelVip que deve ser suportado pelo sistema denominado de Sistema de Aprovisionamento (SA). através do uso de códigos de autorização.

Antes de realizar a modelagem do processo de Ativação.1 Modelagem dos Objetivos do Negócio Nesse caso. foram levantados de forma textual os principais conceitos e regras de negócio envolvidas no produto como.1. por fim. 8.1. 144 . o Analista de Negócio deve levantar os principais objetivos do negócio que envolve o desenvolvimento do novo sistema que suportará o novo produto. não foi utilizado nenhum modelo gráfico para representar os objetivos do negócio. mais precisamente os objetivos do novo produto que foi desenvolvido. 8. Foram realizadas entrevistas com os especialistas do produto para o levantamento. Alteração.2.1. dos processos detalhados e dos casos de uso. os principais objetivos para o desenvolvimento do novo produto são: prover um elevado grau de qualidade no escoamento do tráfego. Correção. interurbanas e internacionais deverão ser agregadas numa única fatura. oferecer descontos por volume de tráfego e consolidar as chamadas locais.2. principais modelos utilizados na elaboração da especificação de negócio.1 Modelagem e Levantamento de Requisitos de Negócio Nessa fase. os casos de uso. Dentre os principais processos de negócio que normalmente envolvem um produto de telecomunicações (Ativação. Conforme pode ser observado na descrição do caso.1. aumento da taxa de ligações completadas. Bloqueio. o Analista de Negócio teve que levantar os principais processos de negócio que suportam o produto. A seguir serão mostardas as principais etapas da metodologia proposta para esse caso.1.2 Modelagem dos Processos de Negócio Definidos os objetivos do TelVip. interurbanas e internacionais em uma única fatura. deve levantar os processos e regras de negócio que suportarão o novo sistema.as chamadas locais.2. Cancelamento. etc) foi dado foco no processo de Ativação para simplificar e facilitar a compreensão da metodologia proposta exemplificado no caso. 8. os requisitos funcionais e. Desativação.

O estorno de uma Order Entry significa que as informações técnicas e operacionais deverão ser revistas. Foram definidas. os dados de Order Entry passarão por uma análise para verificar se as informações técnicas e operacionais são suficientes e/ou estão consistentes para execução das atividades operacionais. algumas regras de negócio com relação ao produto como: Não deverá ser gerada Order Entry de aprovisionamento nos casos de alterações contratuais e comerciais que não necessitem de intervenção da área de operações. Levantados os principais conceitos e regras de negócio que estavam envolvidos no negócio. configuração e ativação a serem executadas na área de operações. mostrando apenas a parte do processo de 145 . O processo foi modelado utilizando o modelo EPC do ARIS e procurou as principais atividades para realizar a ativação do produto TelVip. apenas as diferenças inerentes ao produto em questão. também de forma textual. Além desse conceito. Toda a vez que for feita uma solicitação de aprovisionamento. Caso as informações da Order Entry não estejam consistentes. fato que agilizou o desenvolvimento da especificação operacional e conseqüentemente a de sistemas de informação também. interfaces de processos e a lógica de controle do processo. executores. este exemplo vai focar no detalhamento da atividade “Analisar Order Entry”. o conceito de Order Entry (OE) que é uma ordem de serviço gerada quando o serviço contratado pelo cliente necessitar de atividades de construção. foi levantado através de entrevistas com os especialistas do produto o processo de Ativação do TelVip. corrigidas ou completadas. em termos de processo de negócio. levantando as principais atividades. Para simplificar a compreensão do caso. a Order Entry será estornada para a Área de Mercado. Cabe ressaltar que através da utilização dos modelos pré-definidos pelo projeto de componentização de processos foi possível modelar. Ao ser recebida na interface do usuário do Sistema de Suporte. O serviço pode até mesmo ser cancelado caso comprovada a inviabilidade. a Order Entry deverá ser identificada com um número único.por exemplo. é importante destacar o conceito de Ativação que pode ser definido como uma ação de processo que definirá as atividades operacionais para construção e configuração de um novo serviço para o cliente.

2. O processo pode ser parcialmente visualizado na figura abaixo.1. No caso da atividade “Analisar Order Entry” foram levantados os dados que deveriam ser analisados e validados pelo gerente de implantação como. por exemplo.1. dados técnicos do produto. Elaboração da Order Entry (Área de Mercado) Order Entry (OE) elaborada Gerente de Implantação Analisar Order Entry SA OU Order Entry validada Order Entry não validada Gerente de Implantação Construir Acesso SA Gerente de Implantação Estornar Order Entry SA Configurador Configurar Rede do Serviço SA Order Entry estornada Continuação do processo Elaboração da Order Entry (Área de Mercado) Figura 57: Parte do Processo de Ativação do TelVip Fonte: O autor. os dados cadastrais do cliente. para cada atividade os principais dados necessários para suas execução e as regras de negócio relacionadas. Com a modelagem do processo de Ativação do produto foram levantados. 8.Ativação do produto que está relacionada a essa atividade.2.1. de forma textual. dados do contrato.1.3 Levantamento de Requisitos Funcionais e Não Funcionais É importante ressaltar que nesse caso não foram levantados requisitos não funcionais e que os requisitos funcionais do sistema a ser desenvolvido foram levantados a partir da identificação a modelagem dos casos de uso do sistema conforme pode ser visto no tópico a seguir. entre outros.4 Identificação e Modelagem de Casos de Uso 146 . 8.

pode ser visualizado na figura abaixo apenas a parte do diagrama de casos de uso referente às funções do Gerente de Implantação que aparecem no processo modelado acima. a atividade “Analisar Order Entry” se tornou de forma direta um caso de uso. Em seguida pode ser visualizada a descrição do caso de uso “Analisar Order Entry”. Considerando a escolha da atividade “Analisar Order Entry” como exemplo de aplicação da metodologia neste caso. modelar e descrever os principais casos de uso envolvidos na elaboração do sistema de suporte ao produto. O SA exibe os dados referentes ao item escolhido. foi necessário para o Analista de Negócio identificar. 147 . O SA exibe a tela de Análise de Order Entry (OE) com todos os itens que estão sob sua responsabilidade. É importante ressaltar que o nível de detalhamento de modelagem do Processo de Ativação.Após o levantamento do processo de negócio e dos dados necessários para sua execução. Fluxo Normal de Eventos: O ator seleciona no Sistema de Aprovisionamento (SA) a opção de produto de voz e o nome do seu posto de trabalho. Logo. O ator seleciona o item da OE que vai ser analisado. Analisar Order Entry Gerente de Implantação Construir Acesso Figura 58: Parte do diagrama de casos de uso do produto TelVip Fonte: O autor Descrição do Caso de Uso Analisar Order Entry Caso de Uso: Analisar Order Entry Ator: Gerente de Implantação Pré-condição: A Order Entry deve estar no grid da fase Análise de Order Entry Pós-condição: A Order Entry é aceita ou recusada. permitiu fazer a relação de uma atividade para um caso de uso.

É importante ressaltar que a modelagem do diagrama de classes conceitual não foi realizada. Se o item foi recusado. 148 . Logo. o sistema encaminha todos os itens da OE para a próxima fase do processo. a seqüência de passos abaixo é realizada: Se todas as informações do item estiverem OK. o sistema abre o Lotus Notes e envia um e-mail para Área de Mercado contendo o(s) motivo(s) da recusa da OE. o ator aceita o item clicando no campo “Data de Aceite”. O conteúdo do e-mail será composto de uma concatenação dos motivos de cada item recusado. data e hora. Fim do caso de uso. Se houver inconsistência ou falta de dados o ator recusa o item clicando no campo “Data de Recusa”. O sistema de suporte deverá registrar o login. pois o desenvolvimento do SA foi realizado de forma estruturada e não orientada a objeto. nesse caso. não importando se mais de um item foi recusado. Se for o último item da OE o sistema analisa: Se houver pelo menos um item que tenha sido recusado. O e-mail será único. o SA exibe uma tela onde a causa de recusa deve ser informada. Se todos os itens analisados foram aceitos. O SA fecha a tela daquele item e abre a tela do próximo item daquela OE pendente de análise. No próximo tópico será visto um outro caso de aplicação da metodologia proposta.Para cada item aberto. não houve participação direta de um Analista de Sistema na fase de “Modelagem de Levantamento de Requisitos de Negócio”. O ator preenche o 'Ramal' em seguida clica no botão 'Arquivar'. nome.

programada e emergencial nos equipamentos de produção. solicita a compra de material ao Setor de Compras. aumento na velocidade de execução das tarefas. Tal sistema não atendia por completo as necessidades de seus usuários. O caso analisado foi focado no Setor de Manutenção da empresa. 149 .2 Descrição do Caso da Empresa do Setor Farmacêutico O Laboratório Zaffiman é uma empresa internacional que se dedica à saúde do homem. estabelecendo e conquistando novos conhecimentos sobre áreas fundamentais da saúde. evitar falha de funcionamento dos equipamentos. foi fundada em 1910 na Holanda. atendendo aos diversos setores desta filial. Seus objetivos são evitar interrupção na produção de medicamentos. é o setor responsável pela manutenção e conservação da fábrica. O Setor de Manutenção utilizava um sistema informatizado para o seu controle. pois o sistema de manutenção em operação apresentava algumas deficiências.8. conservação e reparos em mobiliário. Para cumprir com esses objetivos o setor conta com mão-de-obra especializada como mecânicos. serralheiros. tecnologia ultrapassada. processo. Possui um almoxarifado técnico que. marceneiros. melhorando assim alguns aspectos como: segurança no armazenamento de dados. Localizado em Nova Iguaçu no Rio de Janeiro. instrumentistas. falta de manutenção e diversos erros internos de implementação. No setor são realizados serviços de manutenção preventiva. Decorrente de diversas dificuldades como interação. aumento na precisão das informações fornecidas pelo sistema. eletricistas. instalações e equipamentos. quando necessita. acabou perdendo a credibilidade gerando a necessidade do desenvolvimento de um novo sistema. Diante dos problemas apresentados acima foi necessário construir um sistema mais confiável que permitisse planejar e controlar os serviços e custos de manutenção através de Ordens de Trabalho (OT). eliminação dos congelamentos do sistema e redução do tráfego na rede. pintores e bombeiros hidráulicos. evitar o risco de acidentes. encanadores. que tem como objetivo principal realizar a conservação da fábrica. baseou-se na ética e dedicou-se essencialmente na pesquisa de novas e mais seguras drogas. nos equipamentos de apoio e nas instalações prediais. pedreiros.

evitar o risco de acidentes.2.1 Modelagem dos Objetivos do Negócio Conforme mencionado no caso. conservação e reparos em mobiliário. os requisitos funcionais e parte dos requisitos não funcionais e. os processos e regras de negócio que suportarão o novo sistema.3. 8. os casos de uso.1 Modelagem e Levantamento de Requisitos de Negócio Esta fase deve ser executada pelo Analista de Negócio que deve levantar os principais objetivos do negócio a serem aplicados no projeto do novo sistema.1.20 Processo de Manutenção Conservação da fábrica Evitar o risco de acidentes Evitar falha de funcionamento dos equipamentos Conservar e reparar mobiliário. instalações e equipamentos. o principal objetivo do Setor de Manutenção e. bem como a associação desses objetivos ao processo de manutenção. 150 .2. por fim. mostrando a hierarquia entre os objetivos do Setor de Manutenção. O modelo escolhido para realizar a modelagem foi o Diagrama de Objetivos da ferramenta ARIS Toolset.1 dessa dissertação. do processo de manutenção é a conservação da fábrica. evitar falha de funcionamento dos equipamentos. portanto. instalações e equipamentos Figura 59: Diagrama de objetivos do Processo de Manutenção Fonte: O autor 20 Os significados dos objetos utilizados podem ser vistos no tópico 3. Com base nessas informações foi modelado o Diagrama de Objetivos mostrado na figura abaixo.8. Os sub-objetivos associados a esse objetivo principal seriam os de evitar interrupção na produção de medicamentos.

Logo. o autor tomou como base as informações e os pseudo-códigos descritos no projeto. Para realizar a modelagem do processo. pois. vários cargos dentro da organização podem solicitar um serviço de manutenção e também executá-los.A associação dos objetivos do negócio. os processos de negócio passam a ser executados em função da visão e dos objetivos da organização.2 Modelagem dos Processos de Negócio De acordo com a metodologia proposta. 8.1. foram levantados apenas os dados de entrada e de saída da atividade “Alocar mão-de-obra”. com a modelagem do processo de manutenção.2. foi possível identificar as principais atividades. Ou seja. o próximo passo a ser executado pelo Analista de Negócio é a modelagem do processo de manutenção. Com o intuito de simplificar o exemplo. Além disso. foram identificadas e diferenciadas as atividades manuais das suportadas pelo sistema. Os significados dos objetos apresentados no modelo podem ser vistos no tópico 3. somente as atividades com interfaces previstas com o sistema poderiam ser consideradas como candidatas a se tornarem casos de uso. pois. insumos. 151 . desde um nível mais estratégico até um nível operacional. facilita a transição da estratégia desejada para a realizada. Com relação ao levantamento dos dados é importante ressaltar que esses dados devem estar presentes no dicionário de dados Com relação aos executores é importante destacar que tanto o “Solicitante” quanto o “Executor” estão representados por uma elipse que apresenta o significado do conceito de grupo e não de cargo.4 dessa dissertação. Conforme pode ser observado nas figuras abaixo. produtos e recursos envolvidos no processo como seus executores e o sistema de informação utilizado denominado de Sistema de Controle e Manutenção (SISCOM). foram utilizados os modelos EPC e FAD da ferramenta ARIS Toolset para representação do processo e de seus insumos e produtos.3.

Necessiadade de manutenção identificada Solicitar serviço de manutenção Cadastrar solicitação de serviço Encaminhar serviço para setor responsável Solicitante Atendente da CAP SISCOM Atendente da CAP SISCOM Supervisor de Manutenção Gerar OT SISCOM Supervisor de Alocar Manutenção mão-de-obra SISCOM Executor Checar OT a ser executada Verificar necessidade de material para execução da OT OU SISCOM Executor Material necessário Material não necessário Executor Solicitar material ao Almoxarife Almoxarife Verificar disponibilidade em estoque OU Material não disponível Avisar ao Supervisor necessidade de compra de material Solicitar compra de material Compra de material solicitada Material disponível OU Executor OU Supervisor de Manutenção SISCOM Executor Executar OT Executor Entregar OT executada ao Supervisor Atualizar status da OT para concluída Processo de Compras Supervisor de Manutenção SISCOM Material comprado Atendente da CAP Dar baixa do serviço Serviço de manutenção concluído SISCOM Almoxarife Receber material SISCOM Material disponível Figura 60: Processo de Manutenção Fonte: O autor. 152 .

Requisitos Funcionais Possibilitar a desativação de um determinado cliente no sistema.3 Levantamento de Requisitos Funcionais e Não Funcionais Nesta etapa o Analista de Negócio deve levantar todos os requisitos funcionais para o novo sistema a ser projetado. Além disso. "Alocar mãode-obra". Abaixo pode ser vista a listagem dos principais requisitos levantados para o desenvolvimento do SISCOM. Emitir Log Book (documento com a relação de todos os serviços executados em cada equipamento com a validação de uma assinatura eletrônica) por equipamento.1. ele deve levantar em conjunto com o Analista de Sistema os requisitos não funcionais como. 8.2. tempo de resposta do sistema. por exemplo. por exemplo. segurança do mesmo e etc. as atividades "Gerar OT".Quantidade de executores Tipos de executores Alocar mão-de-obra Quantidade de horas para tarefa Número da OT Nome do executor Figura 61: FAD Alocar mão-de-obra Fonte: o autor Com o levantamento do processo de manutenção foi possível identificar alguns casos de uso em potencial como. Cadastrar equipamentos e setores separadamente. 153 . "Encaminhar serviço para setor responsável" e todas as demais que apresentavam interface com o sistema. Possibilitar verificação do prazo de garantia de um equipamento. Emitir listagem de clientes em ordem alfabética.

Emitir listagem de clientes por setor. Emitir listagem de serviços programados por executor. Emitir listagem de funcionários da manutenção. Emitir listagem de materiais de estoque por grupo de material. Emitir listagem de grupos de equipamento. Emitir listagem de clientes que apresentaram um número muito alto de manutenções emergenciais ou programadas. Emitir listagem de OTs por tipo de executor. Emitir listagem de custo de serviços por equipamentos. Emitir listagem de OTs por situação. Emitir listagem de serviços programados por solicitante. Emitir listagem de situações. 154 . Emitir listagem de OTs por cada setor da manutenção. Emitir listagem de serviços programados por período. Emitir listagem de clientes por TAG. Emitir listagem de executores. Emitir listagem de custo de serviços por centro de custo. Emitir listagem de clientes por centro de custo. Emitir listagem de materiais de estoque por localização. Emitir listagem de tipos de serviço.Emitir listagem de clientes por grupo de equipamento. Emitir automaticamente OTs para serviços programados. Emitir listagem de materiais de estoque por ordem alfabética. Emitir listagem de OTs por tipo de OT. Emitir listagem de setores. Emitir listagem de OTs por funcionário executor. Emitir listagem de OTs por período. Emitir listagem de OTs por solicitante. Emitir listagem de serviços programados por cada setor da empresa. Emitir listagem de materiais de estoque por tipo de material. Emitir listagem de serviços programados por cada setor da manutenção. Emitir listagem de serviços que não viraram OTs.

Tais atividades. Definir níveis de acesso permitindo a utilização de fluxos ordenados da informação. que podem ser observadas na tabela abaixo. Emitir listagem de materiais em compras. através de correio eletrônico. 155 .4 Identificação e Modelagem de Casos de Uso Com a modelagem do processo de manutenção foi possível identificar as atividades candidatas a se tornarem casos de uso e os executores candidatos a se tornarem atores. Automatizar a confirmação de OTs concluídas ou OTs canceladas para os seus respectivos solicitantes. Automatizar a transferência das entradas de materiais (recebimento de material) executadas no sistema utilizado pelo setor de compras para o sistema do setor de manutenção. 8. Automatizar a emissão de OTs programadas e preventivas.2. Reduzir o tempo de resposta em consultas para no máximo 10 segundos.Emitir listagem de movimento de entrada e saída por material. Emitir listagem de materiais de estoque com quantidade abaixo ou igual ao mínimo estabelecido. Requisitos não funcionais Migrar dados atuais do Sistema Administrativo para o banco de dados do SISCOM. Automatizar a transferência das solicitações de compras criadas no sistema do Setor de Manutenção para o sistema utilizado pelo Setor de Compras. Publicar relatórios na WEB. Definir design de telas intuitivo.1. são aquelas que apresentam interfaces com o sistema.

Supervisor de Manutenção Supervisor de Manutenção Executor Supervisor de Manutenção Supervisor de Manutenção Atendente da CAP Almoxarife Analisando as atividades citadas acima percebe-se que apesar de todas serem candidatas a se tornarem casos de uso. Isso vai depender do nível de detalhamento da modelagem dos processos de negócio. Nesse caso. Esse exemplo foi citado para mostrar que nem sempre a relação entre atividades e casos de uso é um para um. Nesse caso. como é o caso da atividade "Alocar mão-de-obra" que envolve uma quantidade relativa de interações com o sistema e pode se tornar um caso de uso. pelo próprio nome das atividades já é possível intuir que a primeira atividade provavelmente possui mais passos a serem executados no sistema do que a segunda. a atividade "Encaminhar serviço para setor responsável" pode passar a ser o último passo da atividade "Cadastrar solicitação de serviço" que irá se transformar num caso de uso cujo ator é o executor da atividade. Num outro exemplo. "Supervisor de Manutenção". se transforma no ator do caso de uso. Como exemplo. pode-se citar as duas primeiras atividades "Cadastrar solicitação de serviço" e "Encaminhar serviço para setor responsável". a relação pode não ser direta de uma atividade para um caso de uso. podemos encontrar uma relação um para um entre atividades e casos de uso. o executor da atividade. 156 .Tabela 5: Lista de atividades e executores candidatos a casos de uso e atores Atividades Cadastrar solicitação de serviço Executores Atendente da CAP Encaminhar serviço para setor responsável Atendente da CAP Gerar OT Alocar mão-de-obra Checar OT a ser executada Solicitar compra de material Atualizar status da OT para concluída Dar baixa do serviço Receber material Fonte: O autor. ou seja. Logo. o Atendente da CAP.

et al (2003) É possível perceber no diagrama acima a presença de demais casos de uso que não podem ser diretamente derivados do processo de manutenção como. mostrando que nem todos os casos de uso podem ser derivados do processo de manutenção. Sistema de Controle de Manutenção Executor Gerar OT Atualizar OT <<estende>> Cadastrar Serviço <<inclui>> Atendente da CAP Executor Interno Alocar Mão-de-Obra Executor Terceirizado Programar Tarefa Devolver Material Requisitar Material Supervisor Almoxarife Solicitar Compra de Material Sistema de Compras Sistema Administrativo Importar Dados do Sistema Administrativo Receber Material Figura 62: Diagrama de casos de uso para elaboração do SISCOM. todos os passos descritos no caso de uso "Alocar mão-de-obra" sempre fazem 157 . Fonte: ROCHA. Esse caso de uso foi modelado a partir da lista de requisitos não funcionais. No exemplo citado.Com a identificação dos casos de uso e seus respectivos atores foi possível construir o diagrama de casos de uso da figura abaixo. o caso de uso "Importar Dados do Sistema Administrativo" que se caracteriza como um requisito não funcional necessário para manter o SISCOM sempre atualizado com os dados do Sistema Administrativo. por exemplo. A relação de inclusão tem como principal objetivo quebrar um caso de uso complexo em um ou mais casos de uso para facilitar o entendimento do comportamento do sistema. Também é possível perceber no diagrama as relações entre os caso de uso "Gerar OT" que tem uma relação de inclusão com o caso de uso "Alocar mão-de-obra" e apresenta uma relação de extensão com o caso de uso "Programar Tarefa".

Já a relação de extensão tem o objetivo de representar um comportamento que eventualmente ocorre como o caso de uso "Programar Tarefa”. 158 . Sistema solicita quantidade de horas estipuladas da tarefa. Fim do caso de uso. Supervisor solicita cancelamento do caso de uso “Alocar mão-de-obra” Fim do caso de uso. foi escolhido o caso de uso "Alocar mão-de-obra" que será descrito no próximo tópico. Descrição: Esse Caso de Uso se inicia quando o supervisor informa os dados dos executores responsáveis para execução das tarefas. Supervisor informa tipo de executores. Sistema solicita confirmação dos dados. Sistema obtém e exibe matrícula do executor. Sistema solicita nome do executor. Supervisor informa nome do executor. Fluxo Normal de Eventos: Sistema solicita quantidade de executores.parte dos passos do caso de uso "Gerar OT". Sistema exibe total de horas disponíveis no dia por executor. Supervisor informa quantidade de executores. Caso necessário será contratada mão-de-obra externa. Para exemplificar como seria uma descrição de um caso de uso. Pré-condição: O supervisor deve estar autenticado no sistema. Sistema solicita tipo de executores. Ator: Supervisor. Supervisor confirma os dados. Fluxo Alternativo – Passo 12 do Curso Típico: Supervisor não confirma os dados. Supervisor informa quantidade de horas estipuladas da tarefa. Sistema aloca mão-de-obra para tarefa. Descrição de Caso de Uso Alocar mão-de-obra Caso de Uso: Alocar mão-de-obra.

... recomenda-se à utilização da tabela de relacionamentos entre os modelos EPC.. Conforme pode ser visto na tabela abaixo.Finalizada as descrições dos casos de uso a próxima etapa seria a elaboração do diagrama de classes. 159 . Caso de Uso e Diagrama de Classes. para facilitar a identificação das classes.... Tabela 6: Processo de Manutenção (EPC x Casos de Uso x Diagrama de Classes) Processo de Manutenção EPC (Elementos) Casos de Uso (Descrição e Di agrama) Diagrama de Classes Conceitual X X Solicitante Solicitar serviço de manutenção Atendente da CAP Cadastrar solicitação de serviço Solicitante X Atendente da CAP Cadastrar Serviço X Serviço Setor Funcionário Atendente da CAP Encaminhar serviço para setor responsável Supervisor de Manutenção Gerar OT Supervisor de Manutenção Alocar mão-de-obra Atendente da CAP X Supervisor de Manutenção Gerar OT Supervisor de Manutenção Alocar mão-de-obra X X X OT X Tarefa Mão-de-obra . Fonte: O autor .

conforme pode ser observado no tópico 4.2. a figura abaixo mostra a relação entre a atividade "Alocar mão-de-obra" e as classes "Tarefa" e "Funcionário". que a implementam. as classes Tarefa e Mão-de-obra que estão relacionadas à atividade e ao caso de uso Alocar mão-de-obra. torna possível a redução do tempo de implantação de novos requisitos de negócio. portanto.5 Modelagem do Diagrama de Classes O diagrama de classes do projeto buscou demonstrar os principais conceitos do sistema. as principais classes do SISCOM que interagem com a atividade “Alocar mão-de-obra”. é possível identificar.3. que deve ser realizado pelo Analista de Sistema. Na figura abaixo é possível visualizar apenas parte do diagrama de classes que está relacionada com o caso de uso descrito acima "Alocar mão-de-obra". o que proporciona uma maior agilidade na implantação de qualquer melhoria de processos de negócio que tenham que ser refletidas nos sistemas de informação. através do diagrama de seqüências. 160 .1. na perspectiva conceitual sendo. conforme proposta por LOOS e ALLWEYER (1998) no tópico 5. por exemplo. a associação entre as atividades e classes. independente da linguagem de implantação.2. 8. Logo.Através dessa tabela já podem ser identificadas algumas classes que irão compor o diagrama de classes como.1.6. estando classificado. Tarefa Supervisor de Manutenção Alocar mão-de-obra Funcionário SISCOM Figura 63: Atividade “Alocar mão-de-obra” e classes associadas” Fonte: O autor Com esse mapeamento. Para exemplificar essa situação no caso do exemplo apresentado.

* 0.* Necessita 0..Solicitante Trabal ha 1.* Setor de M anutenção Supervisor ObterSupervisor() 1 0.* Serviço Numero Descricao DataSolicitacao PerdaProducao DataPrevistaInicio Situacao Cri ar() SalvarSituacao() Cri arTarefa() GerarNumero() SalvarDataSolicitacao() ObterEquipamento() Encaminhar() 1 0..* Roteiro 0.....* 0. et al (2003) 161 ...* Tarefa Externa AlocarMaodeObraExterna() 1 1 T arefa Descricao DuracaoPrevista DataPrevi staInicio Criar() AlocarMaoDeObra() GerarOT () ObterDados() Programar() 0..* Encaminha 1....* 1 Tipo Executor Codigo Nome 0..1 Prioridade de Servi ço Codigo Nome 1.* Empresa Codigo Nome Aloca Sobressalente 1 0..* Ramal Criar() ObterDados() 1 Funcionario Matricula Nome Cargo ObterDados() 1 Setor de Manute 1 Cadastra Solicita Necessita 1..* T arefa Programada NumeroDias QuantidadeExecutores Gera O Figura 64: Diagrama de classes para elaboração do SISCOM Fonte: ROCHA.* nto 0.* Seto Obte Obte Material 0.

A definição das classes que representam os principais conceitos do sistema e a representação e descrição dos casos de uso facilitam a modelagem dos diagramas de seqüência que são importantes para a visualização da realização dos casos de uso e para. se caso necessário. 162 .3 Considerações Finais Este capítulo mostrou aplicações da metodologia proposta para modelagem de processos orientada para desenvolvimento de sistemas e buscou mostrar de forma consistente de que maneira são gerados os principais artefatos e as relações entre eles. o que permite uma maior agilidade na implementação de novos requisitos de negócio. a reavaliação do diagrama de classes. 8. foi possível mostrar que é possível derivar casos de uso de processos de negócio de forma que o Analista de Negócio possa passar informações mais consistentes para o Analista de Sistema. Além disso. possibilitando a associação das classes do sistema com as atividades executadas pelos processos de negócio.

etc. através delas.9 CONCLUSÕES E PERSPECTIVAS DE DESENVOLVIMENTO 9.1 Conclusões Nessa dissertação foi possível mostrar os principais conceitos. se tem a possibilidade de entender melhor a organização e a maneira como ela opera. Foi possível perceber que a análise dos processos de negócio de uma organização é de fundamental importância para a sua efetiva reestruturação. Os processos descrevem a seqüência de atividades realizadas pela empresa e. Portanto. uma mudança de paradigma. informações. Deste modo. aplicações e ganhos da Engenharia de Processos de Negócio. Com relação ao estudo da EPN realizado foi possível chegar aos seguintes resultados: 163 . isto é.). Dentre os principais conceitos apresentados pode-se destacar o entendimento e a importância da utilização da visão por processos e da tecnologia da informação para a modelagem de um negócio. Já as organizações orientadas por processos expõem as ligações entre as funções e possibilitam a quem exerce uma função ter a noção mais geral de funcionamento da organização. os produtos gerados (insumos. facilita uma reestruturação organizacional e a concepção e implantação de uma arquitetura integrada de sistemas. mostram os recursos utilizados. uma organização que conhece os seus processos tem maior potencial de resultados na integração entre suas áreas. que provocava uma grande especialização dos colaboradores e uma visão compartimentada do funcionamento de toda organização. Assim. tempo e custo e quem as realizam. O surgimento de organizações focadas nos seus processos talvez seja um marco na administração de empresas. resultando em retornos significativos sobre os investimentos realizados. Antes disso. Ao descrever seus processos. todo processo tem início e fim e os seus relacionamentos (inputs / outputs) são passíveis de ser claramente identificados. o foco central passa a ser o cliente. entendendo quais e como são as atividades antes e depois da realizada por ele. ferramentas. Nessas organizações. metodologias. procura-se agregar maior valor nas atividades no que diz respeito a aumentar a satisfação do cliente. o foco era na estruturação funcional. uma empresa ao levantar e modelar seus processos evidencia os seus problemas.

foi possível perceber a importância e as vantagens da visão por processos e o papel da TI enquanto ferramenta habilitadora da construção e implantação dessa visão nas organizações. foram apresentados os principais conceitos e modelos associados a Unified Modeling Language (UML). ressaltando a importância da integração e do alinhamento entre a estratégia concebida para um negócio. Com relação ao estudo da UML e dos modelos que a suportam e levando-se em consideração seu relacionamento com os conceitos e modelos tradicionais da EPN foi possível obter os seguintes resultados: A UML enquanto linguagem padrão para desenvolvimento de software. Para entender melhor a relação entre a EPN e sistemas de informação. A UML pelo fato de ter sido desenvolvida para desenvolver softwares não possui nenhum tipo de arquitetura voltada para modelagem de negócio como. considerada pela Object Management Group (OMG) como linguagem padrão de desenvolvimento de sistemas de software. tendo como base as vistas da arquitetura da UML apresentada no capítulo 4. sendo difícil imaginar a não aplicação da TI.Frente aos problemas acarretados por uma visão estritamente funcional. foi dado destaque ao desdobramento para desenvolvimento de sistemas de informação. a estrutura de vistas da metodologia ARIS. Dentre as aplicações da EPN. Foi possível perceber a importância da existência de um aparato metodológico com a definição de princípios de modelagem e seleção de ferramentas de software para realizar a implantação da visão por processos. não está amarrada a nenhum processo específico de desenvolvimento de software e contribui em muito para aumentar a qualidade de um processo de desenvolvimento de software. através de seus diagramas consegue expor e uniformizar os entendimentos na comunidade de desenvolvimento de software. A percepção da abrangência dos principais desenvolvimentos possíveis da EPN. pois. por exemplo. no desenvolvimento de sistemas de informação que implementam os processos de negócio. principalmente. seus processos e os sistemas que o suportam. vistas essas que foram 164 .

foi possível entender de que forma os diagramas da UML são utilizados para a modelagem de negócio num processo de desenvolvimento de um sistema de negócio. Essa abordagem já se aproxima mais da modelagem de processos de negócio. Ao analisar o RUP. Foi possível concluir que uma proposta de modelagem de negócios com os modelos da UML. sob o ponto de vista de modelagem de negócio. apesar de apresentar vantagens de entendimento por parte dos analistas e desenvolvedores de sistemas apresenta limitações de entendimento por parte dos analistas de negócio. mesclando as principais etapas de modelagem de processos de negócio com as algumas das etapas de modelagem de sistemas de informação. tomando como base de referência o Rational Unified Processo (RUP) como metodologia de desenvolvimento de sistemas de informação. os modelos da UML ainda -não representam de forma satisfatória alguns conceitos relacionados à modelagem de negócio. para representar conceitos inerentes aos conceitos de processos de negócio. foi possível chegar as seguintes conclusões: 165 . Para elaborar a proposta foi necessário realizar um estudo sobre os processos de desenvolvimento de software. As principais limitações dessa abordagem são a falta de capacidade de abstração não considerando níveis de detalhamento diferentes se limitando a um nível macro de modelagem e a limitação para representar sistemas de informação que suportem estruturas de processos de negócio mais complexas. pois.criadas para suportar conceitos de modelagem de sistemas de software e não de negócio. Foi apresentada uma proposta de extensão da UML criada por ERIKSSON e PENKER (1999. sendo necessária utilização dos mecanismos de extensão da linguagem para se criar perfis voltados para a modelagem de negócio.2000). o diagrama de atividades. principalmente. onde já é possível visualizar uma proposta arquitetura dividida em vistas suportadas por modelos e extensões da UML. conforme observado na comparação com o EPC. podendo ser eficiente para modelar sistemas de informação mais simples. utilizando alguns diagramas da UML. Através da análise do RUP. Diante dos resultados acima foi identificada a necessidade de se definir uma proposta de metodologia de modelagem de processos com foco no desenvolvimento em sistemas.

A modelagem de processos de negócio identifica a maneira como o negócio deve ser executado. Quando se inicia o desenvolvimento de software diretamente a partir do mapeamento do sistema. é importante ressaltar que mapeamento dos processos de negócio pode ser bastante útil para o desenvolvimento de software e devemos entender requisito como uma condição ou habilidade. dentro de uma lógica de melhoria contínua. Mas. utiliza técnicas de modelagem de software. para representar processos de negócio.O RUP trabalha na lógica de desenvolvimento iterativo e incremental o que minimiza os riscos de um projeto de desenvolvimento. a partir destes. Diante das deficiência do RUP com relação a modelagem de negócio. é mesma da UML onde as vistas propostas foram criadas para suportar conceitos de modelagem de sistemas de software e não de negócio. da qual o usuário precisa para que seja solucionado um problema ou alcançado um objetivo. a implementação de requisitos de negócio em sistemas de informação. mais especificamente os casos de uso de negócio. A partir desta identificação.2000). mas que muitas vezes são baseadas em artifícios puramente relativos a tecnologia que podem não atender ao negócio de forma plena. esta proposta apresenta limitações quanto a representação e modelagem dos fluxos dos processos de negócio e suas integrações e quanto ao alinhamento dos casos de uso identificados com os objetivos do negócio. o que facilita. Como base. a única arquitetura que o RUP utiliza. Apesar do RUP já contemplar e reconhecer em seu processo de desenvolvimento a modelagem do negócio como sendo fundamental para o desenvolvimento de sistemas. 166 . podem ser mapeados quais são os requisitos do usuário e. A modelagem de negócio do RUP também não contempla nenhum tipo de arquitetura de negócio quebrada em vistas como as vistas da metodologia ARIS e da proposta de ERIKSSON e PENKER (1999. ou ainda atender de forma incorreta. os analistas conseguem encontrar soluções técnicas. dificultando a compreensão do negócio como um todo. o software propriamente dito. possibilitando uma maior integração entre a área de negócios e de sistemas.

Foi possível visualizar. bem como as fases de Concepção e Elaboração do RUP e alguns de seus artefatos. o usuário passa a ter domínio sobre as tarefas que executa no dia-a-dia (inclusive custos) e com isso percebe com maior clareza quais são seus anseios. Dessa forma.Boa parte dos problemas tidos como clássicos no desenvolvimento de software são originados pela não realização deste estudo. ou ainda porque a forma como são executados não está otimizada. pois. Os principais benefícios da metodologia proposta foram: Diante das deficiências do RUP para modelagem de negócio foi proposta a criação de um fluxo de “Modelagem de Negócio” dentro da lógica do RUP. foram utilizados alguns dos modelos tradicionais da EPN e da UML. Para elaborar a metodologia proposta. os analistas e desenvolvedores trabalham com maior segurança e estabilidade até a entrega de seu produto final e a alteração de requisitos só é justificada a partir de mudanças no negócio. o contínuo aumento do escopo dos sistemas. Realizando a transição através da metodologia proposta foi possível mapear e relacionar as classes de um sistema com as atividades envolvidas num processo 167 . conseqüentemente. destacando-se a instabilidade de requisitos e. Esta instabilidade ocorre normalmente porque os requisitos de usuário não têm justificativa sólida nos processos executados pelo negócio. Todos são beneficiados quando há realização de modelagem de processos de negócio para subsídio do desenvolvimento do software. mas com base em técnicas de EPN e não em técnicas de modelagem de software. a transição entre os modelos tradicionais da EPN e os modelos da UML. através da descrição dos casos de uso. a metodologia proposta teve o intuito integrar de forma mais consistente os conceitos de modelagem de processos de negócio com os conceitos de modelagem de sistemas. mostrando que é importante e possível construir sistemas alinhados com os objetivos estratégicos definidos. permitindo identificação mais segura de que o software vai atender às suas necessidades. buscando reduzir o tempo de transição dos processos de negócio para o desenvolvimento de sistemas de informação e procurando uniformizar o entendimento entre analistas de negócio e de sistemas.

A responsabilidade atribuída ao Analista de Negócio de modelar os diagramas de caso de uso pode ser uma limitação para aplicação da metodologia. pois. cabe ao Analista de Negócio saber o nível de modelagem suficiente para derivar casos de uso. o que. pois muitos Analistas de Negócio não possuem base conceitual e experiência prática para realizar a modelagem de casos de uso. sendo importante a experiência e conhecimento do Analista de Sistema para a criação do diagrama de classes conceitual. Foram analisados os papéis do Analista de Sistema e de Negócio e com base na bibliografia levantada e na experiência prática do autor. Nem todas as classes de negócio são identificadas e derivadas de forma direta a partir dos processos e requisitos de negócio. eficiente e fundamental para fazer a ponte entre a modelagem de negócio e de sistemas. foi proposto que o levantamento dos casos de uso bem como suas descrições e demais artefatos relacionados à fase de “Levantamento de Requisito” do RUP fossem levantados pelo Analista de Negócio. Foi proposta a junção das fases "Modelagem de Negócio" e "Levantamento de Requisitos" em uma fase denominada de "Modelagem e Levantamento de Requisitos de Negócio" cuja responsabilidade de execução foi delegada ao Analista de Negócio e em parte delegada ao Analista de Sistema. por vezes gera resistências no 168 . pois. variando com o nível de detalhamento do processo modelado. ao mudar uma determinada parte do processo é possível identificar com mais facilidade a parte do sistema que deve ser alterado. A definição correta do nível de detalhamento adequado para derivação dos casos de uso varia de acordo com a experiência do Analista de Negócio e de acordo com a situação vivenciada. o autor acredita que a técnica de modelagem de casos de uso é de fácil assimilação. o que reduz o tempo de implementação de melhorias propostas com base nos processos de negócio.de negócio. ou seja. As principais limitações da metodologia proposta foram: A derivação de processos de negócio para casos de uso nem sempre é direta.

Verificar até que ponto as novas tecnologias que estão surgindo dentro do quadro conceitual de BPM.aprendizado dessa técnica de levantamento de requisitos funcionais de negócio para o desenvolvimento de sistemas de informação. portanto. reduzindo o tempo de desenvolvimento dos sistemas de negócio. Associar a metodologia proposta os conceitos de componentização de processos e de sistemas. a modelagem de processos de negócio é uma prática fundamental para modelagem de sistemas podem ser sugeridas as seguintes perspectivas de desenvolvimento: Realizar uma análise aprofundada de interfaces entre ferramentas de modelagem de processos e ferramentas de modelagem de sistemas. inviabilizam ou complementam o desenvolvimento tradicional de software. Estudar de que forma o conceito de Engenharia Simultânea pode ajudar na relação entre os especialistas de negócio e de sistemas. 169 . Aplicação da proposta de extensão da UML de ERIKSSON e PENKER (2000) na metodologia definida. 9. verificando a possibilidade de viabilizar uma maior integração entre a área de negócios e de sistemas de informação. Complementar a metodologia proposta com as demais fases de desenvolvimento não contempladas nessa dissertação. entendendo melhor de que forma isso pode agilizar o desenvolvimento tanto de processos de negócio quanto de sistemas de negócio.2 Perspectivas de Desenvolvimento Considerando que a modelagem de negócio e.

20. Dissertação (Mestrado em Engenharia de Produção) – Universidade Federal de Santa Catarina. BEZERRA. R. Dissertação (Mestrado em Engenharia de Produção) – COPPE. 1 CD.. A organização por processos.. Anais Eletrônicos. Extensões da UML para descrever processos de negócio.. UML and the Unified Process: Pratical ObjectOriented Analysis & Design. 2003. 472p. Falhas e Resultados.. Florianópolis. Aplicações e Casos com a Finalidade de Síntese sobre sua Estrutura... Análise e Projeto Orientados a Objeto. São Paulo. 2000. Volume 2: Seu Guia para Desenvolver Sistemas Robustos com Tecnologia de Objetos. 286p. H. 1ª ed. Hiper-Integração: Engenharia de Processos. et al. Engenharia de Processos: Análise do Referencial Teórico Conceitual. J.... Rio de Janeiro: Infobook.0 Setembro 2001.. R. 2002. 1ª ed. CAMEIRA. São Paulo. Apud SANTOS. Apud JUNIOR. Great Britain: Addison-Wesley. Ferramentas de apoio à engenharia de processos de negócios: critérios de classificação e método de análise de adequação a um projeto.10 REFERÊNCIAS BIBLIOGRÁFICAS AALST. Princípios de Análise e Projeto de Sistemas com UML.. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. 2000. M.. 95 p. Rio de Janeiro: ABEPRO. CAULLIRAUX. Techniques and Empirical studies. Conhecimentos. A.. Rio de Janeiro.. S.. E. Rio de Janeiro: Campus. 1998. NEVES. Berlin: Springer-Verlag. I. In: SAP UNIVERSE. Universidade Federal do Rio de Janeiro. NEUSTADT. R. Versão 6. 317 p... R. Arquitetura Integrada de Sistemas Componentizados com Agentes e Modelos de Negócios 170 . ANTUNES J. Instrumentos. Business Process Management: Models. 1998. AMBLER. 2003. ARLOW. W. CAMEIRA. BASTOS. 2002. 2002.W. ARIS Methods. IDS SCHEER AG.

19. 1999a.E... Mission Critical: realizing the promise of enterprise systems. PROENÇA. PR. Curitiba.. 1999. DAVENPORT.. 171 . H. M. São Paulo: FGV. 8. 334 p. 1 CD. 2000. LOGÍSTICA E OPERAÇÕES INTERNACIONAIS. CAMEIRA. Engenharia de processos de negócios: considerações metodológicas com vistas à análise e integração de processos. H.. R.. Rio de Janeiro.. Business Modeling with UML. CAULLIRAUX. Componentized integrated systems architecture and business process engeneering: methodological aspects. R.. Sistemas Integrados de Gestão: Perspectivas de Evolução e Questões Associadas. H. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. ERIKSSON. Rio de Janeiro. Rio de Janeiro: ABEPRO. 2002.therationaledge. Rio de Janeiro. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. Rio de Janeiro: ABEPRO. CAULLIRAUX. 2003. A.Tecnologicamente Habilitados.. R. CAMEIRA. SANTOS.... 408 p.. CAMEIRA. In: SIMPÓSIO DE ADMINISTRAÇÃO DA PRODUÇÃO. CAULLIRAUX. H. Aplicações das Redes de Comunicação: Estratégia e Organização.. M. Anais Eletrônicos. 432 p. São Paulo. Anais Eletrônicos. 1CD. __________________. Acesso em: 23. H.. A Consolidação da Visão por Processos na Engenharia de Produção e Possíveis Desdobramentos. 1CD. In: INTERNATIONAL CONFERENCE ON INDUSTRIAL ENGINEERING AND OPERATIONS MANAGEMENT. Reengenharia de Processos. PENKER... 2000. CAMEIRA. Anais… Porto Alegre: ABEPRO. R. São Paulo: ABEPRO. Anais Eletrônicos... 1CD.set. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. 1994.. Rio de Janeiro: Campus. Disponível em: http://www. São Paulo.com. R.. Universidade Federal do Rio de Janeiro. T. 1999b. Boston. 19. 2000. 3. __________.. Anais Eletrônicos. MA: Harvard Business School Press. Tese (Doutorado em Engenharia de Produção) – COPPE.

IDS SCHEER AG. Rio de Janeiro.. Campos. PENKER. K... M. Process Think: Winning Perspectives For Business Change in the Information Age... falhas e resultados. Porto Alegre: Bookman. IDS SCHEER AG. M. Disponível em: http://www. 1994. KETTINGER. Acesso em: 04 jun. 1999. HAMMER.. 1ª ed. FURLAN. Heidelberg: SpringerVerlag Berlin. Acesso em: 12 mar. 2002. Apud SANTOS. SCOTT.ids-scheer. instrumentos. 172 .gartner. 169p. The BPA Market Catches Another Major Updraft. Universidade Federal do Rio de Janeiro. & W. 1ª ed.com . ARIS 5 E-Business Suite Version.. TQC – Controle da qualidade total (no estilo Japonês). E CHAMPY. 2000. C. GARTNER GROUP. 2002. M. Heidelberg: Springer-Verlag Berlin. Como elaborar projetos de pesquisa. D. 2000. February. 317 p. 329p. ISBN: 1-878-28968-3.com . Idea Group Inc. Disponível em: http://www. aplicações e casos com a finalidade de síntese sobre sua estrutura. H. Rio de Janeiro: Campus. São Paulo: Makron Books.. Belo Horizonte: Ed. 2003. FOWLER. . 2002. Dissertação (Mestrado em Engenharia de Produção) – COPPE. Business Modeling with UML: BusinessPatterns at Work. São Paulo: Atlas. 2003. da concorrência e das grandes mudanças da gerência. Acesso em: 1 nov. GIL. FALCONI. 2001. New York: OMG Press. UML Essencial: Um breve guia para a linguagempadrão de modelagem de objetos.. White paper.E.com .ERIKSSON. 1998. conhecimentos. Modelagem de Objetos Através da UML – The Unified Modeling Language. Disponível em: http://www.R. V. February. J. GROVER.. 2000. Engenharia de Processos: análise do referencial teórico conceitual.ids-scheer. 2000. 8a ed. Reengenharia: repensando a empresa em função dos clientes. R. White paper. J. System Design with ARIS HOBE and Rational Unified Process. 1991. 2ª ed. V. A..

Dissertação (Mestrado em Engenharia de Produção) – Universidade Federal de Santa Catarina. Germany. Apud SANTOS. In:The Proceeding of the Fifth International Symposium on Economic Informatics Bucharest. LOOS. JUNIOR.. 2001. “Towards an Integration of Business Process Modeling and Object-Oriented Software Development”.com . Introdução ao RUP Rational Unified Process. MAYER. TEUFEL. P. 317 p. KULAK. SAP R/3 Process-oriented Implementation. KELLER. 2003.. 2003. Universidade Federal do Rio de Janeiro. T.. Use Cases: Requirements in Context. ALLWEYER.. 492p. England: Addison Weley Longman. D. 2003. Rio de Janeiro. R. C. Engenharia de Processos: análise do referencial teórico conceitual. Rio de Janeiro: Ciência Moderna Ltda. Information Integration for Concurrent Engineering Compendium of Methods Report. Business Modeling with UML: A Business Process Centrede Architecture. R. Acesso em: 22 out. 1998.JACKOWSKI. conhecimentos. GUINEY. Ohio: Armstrong Laboratory Logistics Research/ Division Wright-Patterson Air Force Base. Florianópolis. Porto Alegre: Bookman.. 2003. LARMAN. LOOS.. et al. New York: ACM Press. 255p. P. Jun... aplicações e casos com a finalidade de síntese sobre sua estrutura. 173 . G... “Process Orientation and Object-Orientation – An Approach for Integrating UML and Event-Driven Process Chains (EPC)”. FETTKE. T. Extensões da UML para descrever processos de negócio... P. March. falhas e resultados. Saarbrücken. Harlow.. 1995. E. 2000. instrumentos. In: Publication of the Institut für Wirtschaftsinformatic University of Saarland. Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a Objeto. 95 p. Disponível em: http://www. Dissertação (Mestrado em Engenharia de Produção) – COPPE... Z. R. Bucharest. 329 p. 844 p. P. KRUCHTEN.agillealliance. 2000. 2002. 1998.

T. Acesso em: 14 mai.. B.com . 174 . 472 p. Korthaus. 316 p. Disponível em: http://www.. 1. White paper. 1st. Disponível em: http://www. D. JACOBSON.NEVES. A.. 2002. OMG Unified Modeling Language Specification. Nice. M. The Unified Modeling Language Reference Manual.. Acesso em: 03 abril. Business Modeling with UML and Rational Suite AnalystStudio. FELD. 550 p. 1998.. Massachusetts. (Hrsg): The Unified Modeling Language – Technical Aspectes and Apllications.2.rational. I..omg. Best Practices for Software Development Teams White paper. J. A Organização por Processos para a Gestão da Cadeia de Suprimentos. Heidelberg.. Modelagem Empresarial: ferramentas para tomada de decisão. 1999.. ROCHA. Doing Research in Business and Management. PIDD. Grupo de Produção Integrada/ COPPE-EE/ UFRJ. Acesso em: 19 abr.rational. England: Sage Publications.. RUMBAUGH. 1996. In: Schader. 1999. M.. V. Projeto de Sistema (Pós-Graduação em Análise. RATIONAL SOFTWARE. Disponível em: http://www. et al. Prentice Hall. G. Rio de Janeiro: Campus. São Paulo: Bookman. Concurrent Engineering Fundamentals: integrated product and process development. Rio de Janeiro. PRASAD. 2000. In: SAPPHIRE. 2001a.Version 1. Pontifícia Universidade Católica do Rio de Janeiro..com . RUMBAUGH. Projeto e Gerência de Sistema) – CCE. 2003. “Business Process Modeling with EPC and UML – Transformation or Integration?”. G. I. Inc... 399 p. A. L. J. v. BOOCH. RATIONAL SOFTWARE. March. et al. 309p.. 1998. BOOCH.. SILVA. Projeto Final 2003. 2001b. M. ARRUDA. ZIMMERMANN.. UML: Guia do Usuário. 321p. NÜTTGENS. 2002. 2003.. E.5. New Jersey. Proceedings... M. 2003. Wiltshire. JACOBSON. REMENYI. 1997. EUA: Addison Wesley Longman.org . Ed.

aplicações e casos com a finalidade de síntese sobre sua estrutura. Berlin. Engenharia de processos de negócios: aplicações e metodologias.. 2002.. Porto Alegre: Bookman. SCHNEIDER.. A. P.. 1999. A. 1 CD. Dissertação (Mestrado em Engenharia de Produção) – COPPE. Heidelberg: Springer Verlag. 1ª Ed. grupos e gestão democrática via espaços de comunicação-negociação. ARIS – Business Process Modeling. ______________. SALERNO. 175 . São Paulo: Atlas. 2st Ed.. Melhores Desempenhos das Empresas. Porto Alegre: Bookman. 2st Ed. Universidade Federal do Rio de Janeiro. SANTOS.. ARIS – Business Process Frameworks.. Projeto de Organizações Integradas e Flexíveis: processos. instrumentos. Berlin. 2002. 1999. Sistemas de Produção com Estoque Zero. Sistema de Troca Rápida de Ferramenta.. Engenharia de Processos: análise do referencial teórico conceitual. Anais Eletrônicos. Rio de Janeiro. M. 1996a. 2002. S. G. 1998. A. 1ª Ed. R.. J. R.. SHINGO. 1998. 188p. CLEMENTA. Massachusetts: Addison-Wesley Longman.. 1ª Ed. BRACHE. 317 p. Porto Alegre: ABEPRO. 1996b. G.-W..RUMMLER. Applying use cases: A Pratical Guide. CLEMENTE. CAMEIRA. O Sistema Toyota de Produção. R. A. Curitiba. Heidelberg: Springer Verlag. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. falhas e resultados. conhecimentos. Porto Alegre: Bookman. 22. S. ______________.. WINTERS. 2000. R. ______________.. 1994. P.. 1 ed.. São Paulo: Makron Books. SANTOS. SCHEER.

1996. Tampa. 176 . STEIN. New York: Marcel Dekker. E.. VERNADAT. K. H. Enterprise Modeling and Integration: Principles and Applications. Rio de Janeiro. 2003.. 1 ed. 2 ed. da Modelagem de processos para implementação de workflow: uma avaliação crítica. 2001. 1 ed... SMITH.SILVA. 1 ed. A.com . 211 p. Disponível em: http://www. Porto Alegre: Bookman. YIN. Dissertação (Graduação em Engenharia de Produção) – COPPE. Acesso em: 09 mai. YPHIS. Estudo de Caso: Planejamento e Métodos. Software Evaluation Report : UML Modeling Tools. e FINGAR. R. London: Chapman & Hall.rational. 2001. Universidade Federal do Rio de Janeiro.. Florida: Megahn-Kiffer Press. Business Process Management – The Third Wave. B.. V. 2002. 2000. P. 1996. Re-Engineering the Manufacturing System . R. F.Applying the Theory of Constraints.

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->