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

) 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).Resumo da Tese apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc. 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 .

Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.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). 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. v .

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

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

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

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

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

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

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

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

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 .Unifed Modeling Language VAC .Sistemas Integrados de Gestão SISCOM .Tecnologia da Informação UML .

através do aumento da taxa de inovação com a conseqüente redução no tempo de desenvolvimento de novos produtos. buscando alcançar seus objetivos estratégicos através da redução de custos e do tempo de atendimento ao cliente. tendo que se adaptarem. a aceleração do processo de inovação e criação de novos produtos. PROENÇA (1999) faz uma abordagem dinâmica no que se refere às estratégias organizacionais frente às mudanças ambientais. às mudanças do ambiente no qual estão inseridas. através dos telejornais.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. como pode ser observado por SANTOS (2002). 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. por fim. o surgimento de modelos de negócio com rápida percepção e resposta às necessidades do cliente. Tais mudanças podem ser observadas no dia a dia através dos jornais impressos ou online.1 INTRODUÇÃO 1. Segundo DAVENPORT (2000). tais fatores e tendências incluem a globalização. 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. A constatação desse ambiente pode ser observado em diversas obras de diversos autores. flexibilidade e inovação para se manterem competitivas. através de parcerias com outras organizações. integração. 1 . entre outras ações que podem contribuir para a sustentação da competitividade no longo prazo. quase que em tempo real. a necessidade do realinhamento horizontal corporativo para suportar com maior eficiência os processos de transações internos e externos à empresa. as organizações estão demandando a todo o momento mais dinâmica. 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. Diante desse contexto.

o resultado de um movimento não apenas quantitativo.. VERNADAT (1996). 2003. Este mesmo autor também ressalta. centros de desenvolvimento e fornecedores e. modificando o ambiente de forma não apenas incremental. de capacidade armazenamento e processamento de informações. a integração dos componentes de hardware e software de diversos fornecedores. a flexibilidade a rápida reconfiguração do fluxo 2 . a integração da função manufatura com projeto. O autor define hiper-integração como: “. relacionando a integração ao desenvolvimento de sistemas. p. de automação e de comunicação. Este mesmo autor destaca a relação do conceito de hiper-integração com a DIFI. em função das tendências do mercado e das customizações para clientes.GALBRAITH (apud SANTOS.1). 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. 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. por exemplo. incremental. com do sua uso acumulativo.” (CAMEIRA. por fim. a dinâmica ao menor tempo de resposta as mudanças do ambiente. este movimento provoca mudanças do contexto no qual a TI é aplicada. Em certos níveis de acúmulo. conseqüência da TI. 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. Tecnologia da Informação (TI) e Modelos de Negócio Tecnologicamente Habilitados. de integração. 2002) considera que diante da complexidade do ambiente de negócios. a dinâmica das organizações é um elemento fundamental para justificar projetos organizacionais mais aderentes. diante de soluções cada vez mais modernas e baseadas na Tecnologia da Informação (TI). mas também qualitativo..

financeira. 2000) e HAMMER e CHAMPY (1994) que atribuem a TI um papel fundamental para se realizar a reengenharia de processos. voz e imagem e surgem sistemas de informação que buscam a não replicação de dados e a integração organizacional. o fator tecnológico como habilitador das transformações na maneira de se fazer negócios. por exemplo. por exemplo. cultural. DAVENPORT (1994. entre outros.2 Justificativa do Trabalho Diante do cenário abordado acima. considerando. a integração funcional de uma organização suportada pelos seus processos de negócio. são suportadas por diversos fatores de ordem política. novos meios e tecnologias de transmissão em telecomunicações que. Essa sinergia entre sistemas de informação e 3 . entre outros fatores que fazem da TI um pré-requisito fundamental para a subsistência das organizações. Esta tese não se propõe a analisar todos esses fatores. possibilitam. pode-se citar a Tecnologia da Informação que tem sido referenciada em diversas obras de diversos autores como. Nesse contexto. econômica. 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. por fim. precisamente. Como conseqüência da evolução da TI. principalmente. 1. dentre os citados acima. da capacidade de dinamicidade de resposta ao ambiente e da flexibilidade de redesenho. através do fluxo de informações horizontal. Dentro dos fatores tecnológicos que motivam tais transformações. tecnológica. 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. do desenvolvimento de sistemas de informação que possibilitem. uma maior vazão de dados. a inovação como conseqüência da hiper-integração dos processos. 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. 2003). 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.de informações suportado pelos processos hiper-integrados e por uma Arquitetura Integrada de Sistemas (AIS) baseada em componentes e em agentes inteligentes e. social. destaca-se a relevância da TI e mais.

por exemplo. 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. o desenvolvimento de sistemas de informação. 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. integração. flexibilidade e inovação. adiante em sistemas de informaçã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. a maneira como a pesquisa foi conduzida. metodologias e ferramentas de modelagem de processo. algumas tecnologias.3 Estrutura do Trabalho Esse tópico tem como principal objetivo descrever a estrutura do trabalho mostrando. os conteúdos dos capítulos envolvidos nessa dissertação. 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. 1. Assim. No capítulo 3. alguns de seus ganhos e algumas de suas aplicações como. analisados e implantados pela UML. No capítulo 2 será mostrado o método de trabalho utilizado.processos de negócio deve existir com um dos principais objetivos para realizar de forma eficiente a estratégia de uma organização. conceitos e técnicas de modelagem de processos e de sistemas que possam contemplar essa necessidade. bem como a Unifed Modeling Language (UML) enquanto uma linguagem padrão para elaboração de estrutura de projetos de software (JACOBSON et al. quais são as delimitações a que se restringe o trabalho e quais são os objetivos principais e específicos do mesmo. de forma breve. O capítulo 4 busca apresentar as principais características e objetivos da UML. Dessa forma. ou seja. 4 . a dissertação apresenta um breve quadro conceitual sobre Engenharia de Processos de Negócio (EPN) ressaltando alguns princípios. as empresas estão buscando novas tecnologias. 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. 2000).. Essa compreensão do papel de cada modelo ajuda a entender como os requisitos e os processos de negócio podem ser levantados. Porém.

Por fim. através dos modelos de processos e dos modelos da UML. 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. 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). mostra também uma proposta de extensão da UML para modelagem de processos de negócio. o capítulo 10 apresenta as referências bibliográficas utilizadas na elaboração do trabalho. Além disso. 5 . a transição de requisitos de negócio para a análise e desenvolvimento de sistemas. O capítulo 9 apresenta as conclusões finais do trabalho mostrando seus principais resultados e perspectivas para desdobramentos de trabalhos futuros. buscando comparar os modelos de processos com os modelos da UML. mostrando as principais vantagens e desvantagens de se utilizar a UML para modelagem de processos de negócio. O capítulo 7 tem como objetivo elaborar uma metodologia de modelagem de processos orientada para desenvolvimento de sistemas que mostra.O capítulo 5 tem como objetivo relacionar os dois capítulos anteriores.

2. 6 .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. • Analisar e relacionar os modelos tradicionais da EPN com os modelos da UML. 2. abordando suas principais aplicações. Portanto.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. mostrando de que maneira a UML pode contribuir para a formulação de uma metodologia de modelagem de processos voltada para sistemas. mostrando o papel deles dentro da metodologia de modelagem de processos. • Apresentar um quadro conceitual referente à UML e seus modelos. 2. metodologias e arquiteturas de referência para modelagem de processos. suas delimitações e. por fim.2 OBJETIVOS DELIMITAÇÕES E MÉTODO DE TRABALHO Este capítulo tem como principal finalidade definir os principais objetivos da tese. a saber: • Apresentar um breve quadro conceitual referente à Engenharia de Processos de Negócio. o método de trabalho adotado durante a pesquisa.2 Objetivos Específicos Esse trabalho apresenta alguns objetivos específicos que darão suporte para a realização do objetivo geral colocado acima. além dos processos de desenvolvimento de software. é importante colocar as delimitações inerentes a cada área com o intuito de focar a tese para a realização de seus objetivos.

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

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

Levantamento de dados ou evidências. 9 .conhecimento contido no estado-da-arte para o estudo de caso contemplado na tese. mostrando suas principais características e seus desdobramentos como. as contribuições realizadas e propostas de pesquisas futuras. por exemplo. 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. Redação e elaboração da documentação final. Fazer a análise dos dados coletados buscando uma melhor compreensão dos problemas contidos dentro do tema proposto. os resultados obtidos. as conclusões oriundas dos conhecimentos adquiridos com o estado-da-arte e daqueles adquiridos com os casos. o desenvolvimento de sistemas de informação. através de estudo de casos em organizações. 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. 3. 2. 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). 4. por intermédio da documentação da organização e de entrevistas com seus profissionais. Além disso. o estudo bibliográfico ajudará a guiar e se necessário ajustar o tema proposto. apresentando o problema tratado.

como a informação flui através desses processos. etc. até. etc. uma organização ou. 1996)... diversos são os quadros conceituais abordados por muitos autores que estão relacionados com a EPN como.. apesar de ter sido mal aplicada em muitas empresas. a Engenharia de Processos de Negócio (EPN) pode ser definida como “. HAMMER. SHINGO. 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. um conjunto de organizações (uma cadeia de suprimento. permitindo entender as cadeias de valor existentes. 1996b..”.3 ENGENHARIA DE PROCESSOS DE NEGÓCIO Segundo SANTOS (2002. a grande responsável pela difusão da visão orientada a processos. Teoria das Restrições (STEIN. p. Dentro da Engenharia de Produção. por exemplo) opera. suas interfaces. 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: “.a EPN é uma técnica muito utilizada quando se deseja entender ou mapear como uma parte de uma organização. análise e melhoria dos processos dentro e entre organizações. quais os recursos são utilizados. CHAMPY. 10 .. a Reengenharia (DAVENPORT. como são realizados os processos. 1994. 1996a.1). uma arquitetura (framework) para entendimento. foi.”. 1994) que para muitos. quem realiza as diversas atividades.. Sistema Toyota de Produção (SHINGO. 1996). Independente do quadro conceitual abordado. no início da década de 90.. 2000). por exemplo.

A um processo correspondem: Um desempenho (performance).” (ZARIFIAN apud SALERNO.104). orientado para o cliente final que lhes é comum.105) Segundo SALERNO (1999. p. que formaliza o seu objetivo global (um nível de qualidade. um prazo de entrega etc. as características de um processo seriam: Uma organização estruturada. durante sua duração. (DAVENPORT. Uma organização que materializa e estrutura transversalmente a interdependência das atividades do processo. Para entender melhor esses conceitos. 1994) “Um processo é uma ordem específica de atividades de trabalho que são realizadas através do tempo com um lugar definido. Uma responsabilidade local de cada grupo de atores ao nível de sua própria atividade. 1999. com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes”. a saber: “Um processo é um grupo de atividades realizadas numa seqüência lógica. (HAMMER e CHAMPY.). Um processo é repetido de maneira recorrente dentro da empresa. com relação ao desempenho global. 1993) “Uma cooperação de atividades distintas para a realização de um objetivo global. p. é importante citar algumas das definições de processo de negócio encontradas na literatura.Existem diversos conceitos atrelados à definição de processo de negócio. modelada em termos e trocas entre as 11 . com início e fim. e com inputs e outputs claramente identificados”. Uma co- responsabilidade dos atores nesta 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.: chegada de um pedido) e outro o fecha (entrega). etc. Um desenrolar temporal. mas outros não. dado que um evento detona o processo (ex.). Esses indicadores seriam a única referência de avaliação sobre o resultado do processo. É possível que alguns recursos fiquem dedicados a um processo. necessários e úteis ao processo. pedidos. etc. mas a utilização racional dos recursos que são.) ou intangíveis (decisão de lançar novo produto. o único critério de coresponsabilidade entre os atores. faturas. Um desempenho global. Entradas tangíveis (produtos. É um ponto de partida para a construção da organização. Os processos estão intrinsecamente 12 . Saídas: o resultado do processo. medido por alguns (poucos) indicadores. Custo dos recursos globais. O processo se desenrola segundo uma temporalidade organizável e mensurável.atividades constitutivas. demanda de investimentos. deve ser explicitado em desempenhos locais para cada atividade. podendo ter um uso variado. 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. Pontos críticos podem ser atividade ou coordenações. ao mesmo tempo. dão o custo de um processo. Recursos: não é o somatório de recursos locais. valorizados. Esta organização se constitui pela ligação ao cliente final.

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

suportada ferramentas e modelos que permitem a visualização do trabalho executado pelas unidades organizacionais. é importante definir uma ferramenta de modelagem. pois.é importante se definir padrões na forma como as pessoas estão modelando os processos. 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. 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. os sistemas de workflow que apóiam a automatização dos processos e do fluxo de informação. como estes objetos estarão dispostos no modelo. por exemplo.Realização de simulações. Padronização dos processos . os modelos que serão utilizados. é possível melhorar a gestão 14 . 2002): Uniformização de entendimentos sobre a forma de trabalho – através da difusão da visão por processos. é 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. Gestão da organização. isso facilita sobremaneira a legibilidade e a homogeneidade dos modelos trabalhados. 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. os objetos dos modelos que serão utilizados. apoiando tomada de decisões. SANTOS (2002) citou os principais resultados da aplicação da EPN nas organizações podem ser citados os seguintes (SANTOS. Nesse sentido. facilitando a uniformização do entendimento sobre a forma de trabalho. Melhoria da gestão organizacional – relacionando-se os processos modelados aos indicadores de desempenho de uma organização.

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

a articulação de diversos objetos que compõem os processos (dados. preferencialmente. uma classificação consistente metodologicamente dos objetos e uma hierarquia entre os modelos e. o foco dado em clientes iniciais e finais (clientes. Neves (1998) Tabela 1 . externos as organizações). etc. por fim.. p. Jr.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. 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. 27) CAMEIRA e CAULLIRAUX (2000) colocam como principais características da visão por processos.). a possibilidade de navegação pelos processos em qualquer direção seja das atividades aos 16 . unidades organizacionais. recursos. apud SANTOS (2002.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. Caulliraux. TEUFEL (1998).

macro-processos (abordagem botton up) ou dos macro-processos para as atividades (abordagem top down). por natureza. pode não representar ganho de eficiência. 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. influencia de maneira drástica o comportamento da sociedade como um todo. Dessa forma. facilitando as quebras das barreiras funcionais. grandes investimentos em tecnologia na automação de processos que geram pouco ou nenhum valor para o cliente da empresa e. desta forma. 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. portanto. aumentando apenas a velocidade com os quais os processos são realizados. Independente do porte. evitando. A Tecnologia da Informação. vale ressaltar que a TI se aplicada em processos problemáticos. a TI tem um papel importantíssimo dentro dos processos empresariais. ao seu negócio. 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. Além disso. Além disso. é importante que uma organização considere em seus planejamentos o uso eficaz e eficiente da TI. tanto na área de computação quanto na área de telecomunicações. alterando a vida das pessoas e das diversas organizações das quais elas fazem parte. Na realização do trabalho. É 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. influenciando de maneira significativa na execução e gestão do trabalho. É 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. do mercado e da sua cultura organizacional. o surgimento de novas 17 . a TI proporciona desde mudanças na forma individual de trabalhar até a forma pela qual as organizações se relacionam em processos interorganizacionais. A evolução da Tecnologia da Informação (TI).

Como visto anteriormente. utilizando os seus recursos 18 . Produtos Acabados. processos e responsabilidades com 1 Negócios realizados através da Internet. Deve reduzir custos através de parcerias com outras empresas. Produtos Intermediários. 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. 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. Knowledge Management (KM). => Capacidades. de um ambiente de negócio colaborativo. Esses processos que formam toda a cadeia podem ser chamados de processos colaborativos. é 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. a visão por processos busca derrubar os “muros” funcionais e proporcionar uma melhor integração entre as áreas de uma empresa. terceirizando atividades e processos que não são chaves e não estão ligados às suas competências centrais. => Créditos.tecnologias e conceitos como Supply Chain Management (SCM). Conforme pode ser visto na figura abaixo. uma empresa também deve se preocupar com a sua cadeia de suprimentos e procurar se posicionar da melhor maneira possível dentro dela. 6) Nesse contexto. etc. Sendo assim. Tempos de Entrega. p. Assim. etc. conhecimentos. Faturas Figura 2: Integração da Cadeia de Suprimentos Fonte: NEVES (1999. as empresas dentro. Termos de Pagamentos. Fornecedor de MP Indústria Distribuição Varejo => Matéria-prima.

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). Na figura abaixo é possível visualizar essa evolução de conceitos e tecnologias relacionados à integração organizacional. em uma integração interorganizacional. buscando adquirir vantagens competitivas para a cadeia como um todo e não somente para uma empresa.seus parceiros. 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. 19 . passando por conceitos e tecnologias abordadas pela Manufatura Integrada por Computador (ou Computer Integrated Manufacturing – CIM). 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. 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.

2 Princípios. é importante entender alguns princípios de modelagem e as principais metodologias de modelagem de processos que suportam a visão por processos. por fim. p. 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. 20 . 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.3) Como citado anteriormente.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. serão mostradas algumas das principais arquiteturas de modelagem de processos de negócio utilizadas no mercado. Sendo assim.

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

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

Conforme pode ser observado na figura abaixo. entre outros fatores que devem ser levados em conta. realizam análises de ferramentas de modelagens de processos segundo alguns critérios. o Gartner Group. 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. algumas consultorias como. 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 . a política do fornecedor com relação à manutenção e atualização da ferramenta. a facilidade de utilização da mesma. a existência de base de dados. o tempo estimado de vida útil dessa ferramenta dentro da organização. por exemplo.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.

p. CAMEIRA (2000. variando de ferramentas de uso específico a uso mais geral e a capacidade de suporte ao mercado. a possibilidade de criação de filtros. classificação e seleção de ferramentas de modelagem. a análise de adequação da ferramenta ao escopo do projeto2 e a escolha da ferramenta. além de proporcionar outras funcionalidades como a geração e análise de diversos tipos de relatórios de modelos e objetos armazenados.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. Em complemento a figura acima.O Gartner Group utiliza dois critérios para a classificação das ferramentas. Além desse método. os autores propõem outros critérios para análise. Com uma base de dados associada é possível armazenar e integrar modelos e objetos de forma consistente. que são a abrangência da visão relacionada aos possíveis desdobramentos e aplicações em que a ferramenta pode ser utilizada. conforme pode ser observado na figura abaixo: Verificação de possibilidades. 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. etc. mecanismos de busca. 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. 24 . 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. a verificação de ferramentas disponíveis no mercado para o cumprimento dos objetivos.

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

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. Pode ser aplicada tanto no ambiente de engenharia empresarial. diversas metodologias de modelagem empresarial relacionadas diretamente a EPN. integrada e consistente com os objetivos aos quais pretende realizar. servirem como ponto de referência para o desenvolvimento de uma metodologia própria e customizada. descritos em termos de sua função. conforme observado em VERNADAT (1996). informação. padronizando módulos. Neste tópico será apresentada uma visão geral de algumas das principais metodologias desenvolvidas e utilizadas na busca de padrões de modelagem. qualidade e tempo de entrega competitivos. 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. CIMOSA introduziu a idéia de arquitetura de sistemas abertos para CIM. 3. 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. A partir dessas metodologias de referência é possível criar uma linguagem padrão intra ou. tornando a modelagem empresarial mais uniforme.3. controlar ou monitorar o dia-a-dia de operações através do ciclo de vida dos produtos. a infraestrutura de integração e ciclo de vida do sistema CIM. no caso de uma cadeia de organizações. inter organizacional que facilita a uniformização de entendimentos por parte das pessoas envolvidas no projeto em questão. através de melhoria contínua ou reengenharia. recurso e aspectos organizacionais. no qual. 26 .2.1 CIMOSA (Computer Integrated Manufacturing Open System Architecture) Elaborada e documentada por um consórcio de empresas denominado AMICE.de todos os tipos. dependendo do objetivo a ser alcançado por um projeto ou aplicação específica. 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.

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

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

englobando. 2002. ZARIFIAN apud SALERNO. SALERNO. os conceitos relacionados a processos de negócio já citados em algumas das definições de alguns autores no início do capítulo. portanto. 2000).2. 1993.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.3. Além disso. será utilizada nesse tópico a metodologia ARIS3 e alguns dos seus modelos.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. DAVENPORT. 1994. 3 A metodologia ARIS foi apresentada no tópico 3. 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. ERIKSSON E PENKER. SANTOS. 1999.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.3 31 . pois este está diretamente ligado à visão de negócio que não muda com mesma velocidade da TI.com o nível de Definição de Requisitos.3.3. para exemplificar os modelos utilizados pela EPN para modelagem de negócio. 3. 1999. 3.

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

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

(ARIS Methods. 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. é muito importante. 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. Assim. arquivos de banco de dados. torna-se possível saber quais são as funcionalidades que devem ser executadas para o alcance dos objetivos desejados. No exemplo. 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. 1996). não estão no escopo dessa dissertação.3.2 A Vista de Dados A quantidade de dados processados e armazenados todos os dias dentro de uma organização é enorme. a função processos de negócio se subdivide. Através da identificação das funções associadas aos objetivos e de suas hierarquias. 2001). (VERNADAT. expressando de forma clara a especificação para aplicações que suportam as funções. processos e objetivos estratégicos da organização. as elipses associadas aos objetivos representam os fatores críticos de sucesso atrelados ao cumprimento dos objetivos. etc. conforme pode ser observado em ARIS Methods (2001). 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. que se realize uma modelagem semântica dos dados. 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.2.disso. em processo de produção que por sua vez é subdividido em processos de planejamento e controle da produção. O Diagrama de Árvore de Função tem como principal objetivo permitir uma análise funcional orientada pelos objetivos associados às funções. 3. Para VERNADAT (1996). por exemplo. O principal modelo para realizar esse levantamento é o modelo de entidades e relacionamentos (MER) que tem como principal objetivo apresentar a estrutura de 36 . documentos técnicos. pois.

representadas por retângulos da cor azul. Conforme pode ser observado na figura abaixo. poder-se-ia. com base em SCHEER (1999) Podemos perceber que. 37 .dados de uma determinada aplicação através da descrição das entidades de dados e seus relacionamentos. 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. agregando conjunto de dados relacionados em objetos de dados complexos determinados como clusters. 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. (CHEN apud SILVA. utilizar o MER para detalhamento de cada cluster. após o mapeamento de uma visão geral dos clusters necessários a uma aplicação. enquanto que o MER relacionado ao cluster Pedido do Cliente está representado pelas entidades Cliente e Pedido. os clusters ou objetos complexos de dados são representados pelos retângulos avermelhados. que por sua vez estão relacionados por um losango amarelo que mostra o relacionamento que existe entre as duas entidades. então.

Com a modelagem do organograma. VERNADAT. A modelagem e a análise da estrutura organizacional de uma empresa podem contribuir bastante na análise dos processos de negócio. A figura abaixo mostra um exemplo de organograma que pode ser modelado no ARIS Toolset. 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. é possível atribuir responsabilidades e determinar quem executará as funções e respectivamente os objetivos definidos na vista de funções. determina a forma como se dá a divisão do trabalho. por exemplo. como uma estrutura hierárquica que define as áreas funcionais ou unidades organizacionais de competência identificadas em uma empresa. essas unidades funcionais são providas de tecnologias para executar um determinado trabalho (ARIS Methods.3.2. a hierarquia de responsabilidades e coordenação. segundo VERNADAT (1996). pois. 1996). 2001. constituída de unidades funcionais e que deve possuir regras e padrões para lidar com sua complexidade. O principal modelo relacionado ao nível de Definição de Requisitos é o organograma que pode ser definido.3. Para 38 . indicando quem é responsável pela área funcional e a quem se reporta na estrutura. relacionamentos de hierarquia entre os objetos de um organograma. Além disso.3 A Vista de Organização Uma organização pode ser considerada uma estrutura social complexa. entre outras informações que agregam valor na análise de um negócio.

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

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

Dependendo do escopo do projeto. 3. por exemplo.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. ter 41 .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. é o nível de agregação dos modelos que deve estar adequado o suficiente para a realização dos objetivos definidos no projeto.

42 . 2003 e CAMEIRA. existem alguns pontos balizadores que ajudam a identificar o nível de detalhamento adequado (CAMEIRA. por exemplo. quanto modelos de dados como. 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. No caso em que o objetivo da modelagem é o rápido entendimento dos macroprocessos de uma organização para definição. o nível de detalhamento dos modelos deve ser suficiente para a compreensão dos requisitos de negócio. 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. é importante saber identificar se o que está sendo descrito não é um procedimento como. no caso de um desenvolvimento orientado a objeto. o nível de detalhamento é uma variável fuzzy não existindo uma regra exata em sua definição. Este mesmo autor coloca que apesar de ser uma variável fuzzy. Esse processo de desenvolvimento de um sistema de informação engloba tanto modelos de processos de negócio. CAULLIRAUX. Quando o objetivo da modelagem é. um baixo nível de detalhamento pode ser suficiente. por exemplo. pois. por exemplo. por exemplo. por exemplo. Para CAMEIRA (2003). Se o objetivo da modelagem for. funcionais e técnicos que serão necessários para o desenvolvimento e implantação do sistema. mesmo dentro de um escopo definido podem existir níveis de detalhamento diferentes. de objetivos estratégicos. as classes. o entendimento do fluxo de informação que atravessa os processos operacionais de uma organização. 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 alto nível de detalhamento num projeto de desenvolvimento de sistemas de informações e um nível mais baixo no caso. os modelos da UML que definem. 2000). macros e detalhados. 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. No caso em que um processo apresenta um alto grau de detalhamento sem necessidade. os objetos e seus relacionamentos. Porém.

p.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. o Process Performance Management (PPM). Identificados e implementados.3. Idef 3 .5. Benchmarking Modelos de negócios eletrônicos Análises organizacionais . por exemplo. A partir dessa análise dos processos de negócio.5. por exemplo. 3) 3. tais indicadores servem de base para atividade de monitoração da organização como um todo. a transição de estrutura funcional e muito hierarquizada para uma matricial e até mesmo para uma totalmente orientada por processos. apoiando as tomadas de decisão. Análise e Melhorias de processos Redesenho de Processos MÉTODOS: Aris. (2002. algumas ferramentas estão sendo desenvolvidas como. 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. Cimosa. modelagem.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.5 Aplicações da EPN A EPN tem como atividade central o levantamento. desenvolvido pela 43 . 3. validação e redesenho de processos de negócio. Nesse sentido. 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. 2000 e SANTOS et al.

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. a competição se dá entre cadeias e não mais entre organizações.4 Gerência Eletrônica de Documentos (GED) e Workflow Conforme pode ser observado em SILVA (2001). 3.5. 2000) 3. 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. que tem o intuito de realizar o acompanhamento automático dos indicadores dos processos durante a operação de Sistemas Integrados de Gestão. 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.5.5 Gestão da Cadeia de Suprimento Como já citado anteriormente. produção e distribuição de produtos ao mercado. 44 . 3.IDS Scheer AG. Além disso. passado e reutilizado por qualquer pessoa.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. (DAVENPORT. Nesse cenário. os modelos originados pela modelagem dos processos representam de forma explícita parte do conhecimento de uma organização que pode ser armazenado. podendo identificar gaps de conhecimento que podem ser preenchidos através de programas de treinamento e capacitações. 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.

3. por exemplo.5. o que possibilita visão homogênea e integrada do negócio. 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.7 Benchmarking Com seus modelos de processos mapeados. 3.5. 3. baseados nas melhores práticas do mercado. passando pela definição da 45 . Através de modelos de processos com diferentes níveis de detalhamento.5.5.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). 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. 3. caso tenha acesso.8 Modelos de Negócios Eletrônicos Com possibilidade de troca de informações via Internet. entre outros. entre empresas e clientes (Business to Customer – B2C). uma certificação segundo as normas ISO. No que tange a essa aplicação. procedimentos e manuais. ou até mesmo compará-los. diversos modelos de negócios virtuais surgem com o intuito de estabelecer vários tipos de relacionamentos entre empresas (Business to Business – B2B). uma organização pode compará-los com modelos de referências.5.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.3.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. pode-se ter uma integração consistente entre documentos organizacionais para atender.

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. e. 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. Figura 16: Arquitetura de Processos de Negócio com Desdobramento para Sistemas de Informação. sendo. portanto.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.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.3. 3. portanto. aos sistemas de software. necessário o treinamento dos usuários finais do sistema baseado nos processos modelados.3. custos e adaptações do sistema a organização e vice-versa. A figura abaixo mostra essa estrutura e a seguir são descritos esses níveis.5. a fase de pós-implantação quando o SIG está em operação.2. por fim. Fonte: SCHEER (1998) 46 .

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

a Unified Modeling Language (UML)5. 1996) Conforme pode ser observado em CAMEIRA et. facilita o processo de desenvolvimento. entre outros). Um outro fator importante em que a EPN pode contribuir com o desenvolvimento de sistemas de informações. maior eficiência no fluxo de informações que atravessa a organização ou a cadeia na qual está inserida. 48 . 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. 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. mas para definir um produto que atenda todas as necessidades dos clientes" (HARTLEY. mas também as informações e dados necessários para o desenvolvimento do sistema. Além disso. reduzindo o tempo de desenvolvimento de produto e de sistemas de informação. etc. De acordo com a definição abaixo.al (2002). qualidade. por exemplo. Nesse tipo de aplicação é importante que sejam modelados não somente os processos. a utilização de uma ferramenta Computer Aided Software Enginneering (CASE) que suporte uma linguagem padrão como. pode reduzir o redução do lead time 5 O detalhamento da UML e de seus modelos pode ser visto no capítulo 4. 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.integrada e consistente. Esses requisitos não servem somente para se atingir as funcionalidades básicas do produto. é possível compreender o conceito de Engenharia Simultânea. 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. "Engenharia Simultânea é uma metodologia de desenvolvimento de produtos. serviço. 1992 apud PRASAD.

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

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

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 .pi oto) ni l Dad d OE os a s ão s ufi ie s c nte p/ alocar fac . 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. em sua arquitetura. Modify c...... 00001001 11001000 10101010 . Analyze c. Dado que processos são suportados por sistemas e a construção destes foi historicamente orientada funcionalmente. 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 . podendo reaproveitar os componentes de software criados anteriormente. inquiry pos. 11010100 00001001 11001000 10101010 . limitando qualquer implantação de inovação em termos de processos de negócio.N Sol ç ão d u e Pend ênc a is Tes te fim f m -a. request po s. reque st Analyze c. 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 . request pos. Article Article n° 00001001 11001000 10101010 . Read c. modelos da UML e componentes de software. 11010100 00001001 11001000 10101010 . 11010100 00001001 11001000 10101010 . 11010100 00001001 11001000 10101010 .. inquiry pos. uma visão por processos. eles não permitem que estes mesmos processos sejam alterados e gerenciados com facilidade.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.-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) Implantação de CPE (Telefonia) Use Case Actor Organiza tional unit Org.Segundo CAMEIRA (2003) a componentização de processo pode reduzir os tempos de desenvolvimento dos sistemas de informação. 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. possibilitando que a organização se oriente para processos. request po s. 11010100 00001001 11001000 10101010 .. Dessa forma. 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. request po s. request pos.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 .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. 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 . n° Acesso obtido Rede E1 configurada M. request pos. 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.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. reque st Delete c.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 . Como exemplo..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.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 . o desenvolvimento do segundo passa a ser focado apenas nas diferenças. mostrando a relação entre processos de negócio. Bernardy T.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.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 . 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. 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 .. realizad a Customer inquiry [texts determ ined] Customer inquiry positions Article Date One customer inquiry position 00001001 11001000 10101010 . 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 .. inquiry pos. texts Read c.. a questão é como fazer para que os sistemas retratem. 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 . inquieries Customer inquiry positions Create c. 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. Stark Configuração de Rede de Serviço (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. 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 . 51 . implementação e gerenciamento dos processos nas empresas ocorra de forma mais flexível. Becker V.. 11010100 Export control V. Modify c. da ta Customer inquiry Date Create c.. texts Delete c.. o autor coloca que após a implantação do primeiro sistema componentizado baseado em processos com grande número de atividades iguais. Analyze c. muitas vezes as organizações acabam ficando "engessadas" tendo que se adaptar aos sistemas de informação. inquiry pos. 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 .. Na figura abaixo é possível visualizar a situação descrita acima.N Estornar O rder E ntry par c or e ã a r ç o Centr de o C o urar nfig C onf g. reque st Read c. Read c. Solu ão de ç Pend c ia ên s Delete c. Delete c....

pode proporcionar para uma organização. idealmente realizada com uma mesma ferramenta e notação. conforme citado nos tópicos a seguir (SANTOS.1 Uniformização de Entendimentos sobre a Forma de Trabalho A modelagem de processos. principalmente. das informações trocadas nas interfaces organizacionais.6 Ganhos Gerais Esperados com a EPN A EPN em suas diversas aplicações pode gerar alguns ganhos importantes para as organizações.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.6.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. 52 .6. Os autores afirmam que os novos sistemas criados a partir dessa nova onda. através da visão por processos. 2003). 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. fica clara a importância da visão por processos possibilitada e suportada pela TI na automatização desse fluxo e no melhor entendimento. Analisado os principais desdobramentos da EPN o próximo tópico vai mostrar os principais ganhos gerados pela utilização da EPN. 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. 6 As duas primeiras ondas foram respectivamente a Administração Científica e a Reengenharia de Processos. 3. 3. 3. 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.

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.3. ferramentas. 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. metodologias.6 Aumento da Conceituação Organizacional sobre Processos Este ganho está relacionado diretamente a todos os demais ganhos. atividades que não agregam valor ao produto final. ressaltando a importância da integração e 53 . 3.6.6.7 Considerações Finais Este capítulo procurou mostrar os principais conceitos.6.6. foi dado destaque ao desdobramento para desenvolvimento de sistemas de informação.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. pois. é 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.3 Padronização dos Processos Este ganho está diretamente relacionado à uniformização do entendimento da forma de trabalho. 3. entre outros que estão diretamente relacionados à redução de tempo e custos operacionais. 3. aplicações e ganhos da Engenharia de Processos de Negócio. controle e coordenação do trabalho. fica mais fácil definir um padrão de modelagem e representação dos processos de negócio. Dentre as aplicações da EPN. alocação de recursos. diante de um referencial de conformidade com uma mesma linguagem de modelagem (modelos com uma mesma notação) compreendida por todos. entre outras. 3. pois.

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

construir. apresenta vocabulário e regras 55 .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). e documentar artefatos (documentos) de sistemas de softwares. Para LARMAN (2000) a UML é uma notação para modelagem de sistemas. Independente da definição é possível observar que a UML é antes de tudo uma linguagem de modelagem. a saber: A UML é definida como uma linguagem padrão para a visualização. usando conceitos orientados a objeto. existem outras definições de outros autores. mostrando seus principais modelos e os papéis destes dentro de um processo de modelagem orientado para o desenvolvimento de sistemas de software. Porém. bem como para modelagem de negócio e outros sistemas que não são softwares. 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.1 Definição e Histórico da UML A UML é uma linguagem para especificar. 4. Em sendo uma linguagem. visualizar. especificação. 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. 2003). A definição acima talvez seja a definição mais completa sobre a UML.. 2000). 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.

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. os especialistas Grady Booch e Jim Rumbaugh. resolveram em outubro de 1994 juntar seus métodos. entre outros. através de uma única semântica e notação. Esse período que durou de 1889 a 1994 ficou conhecido como “Guerra dos Métodos”. surgem na primeira metade da década de 90 diversas propostas de técnicas de modelagem de sistemas orientados a objeto como. a “Guerra dos Métodos” parecia ter chegado ao fim. já citados acima. 56 . Além disso. ambos funcionários da empresa Rational Software. e criaram o Método Unificado apresentado à comunidade de software em Outubro de 1995 na conferência de OOPSLA 95. 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. não indicando quais modelos devem ser criados e nem quando criá-los dentro de um projeto de desenvolvimento de software. anunciaram a compra da empresa Objectory pela Rational Software e que Ivar Jacobson iria se juntar à equipe. Logo. com a junção dos três principais métodos num esforço de estabelecer um único. pois. 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. o Object-Oriented Software Enginneering (OOSE) de Ivar Jacobson. 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. por exemplo. percebendo essa dificuldade. o Método Booch de Grady Booch. quem irá produzi-los e de que maneira esses artefatos irão medir e controlar o projeto como um todo. pelo fato de não ser um método. suportar arquiteturas de diversos níveis de complexidade dentro de diversos domínios de desenvolvimento de sistemas. que eram até então considerados e reconhecidos como os principais métodos orientados a objeto. 2000). porém. A partir desse momento. indicando quais artefatos serão produzidos. durante a conferência. Object Modeling Technique (OMT) com a participação de James Rumbaugh.próprias que orientam a criação e a leitura de modelos bem formatados. a UML por si só não associa e não relaciona seus modelos com uma metodologia / processo de desenvolvimento de software.

diversas organizações submeteram a OMG propostas para um padrão de metodologias e dentre essas propostas estava a versão 1.0 da UML da Rational.org). mas logo em seguida a UML já então na versão 1. as principais características da orientação a objeto. trabalharam seu método sob o novo nome de Unified Modeling Language (UML). a UML tem como principal base para seu desenvolvimento à orientação a objeto e.2 Principais Conceitos Básicos da Orientação a Objeto – Visão Geral Como foi possível observar acima.omg. diversas modificações propostas por diversos colaboradores de diversas empresas foram feitas na UML com o intuito de torná-la mais clara e útil. Assim. em janeiro de 1997. 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.org). 4.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.1 foi escolhida pela OMG como linguagem padrão qualquer tipo de desenvolvimento de sistema orientado a objeto. Atualmente. antes de falar sobre a linguagem UML cabe ressaltar. Houve ainda um pequeno período de discussão sobre os métodos analisados. conhecidos também como os três amigos. gerando com isso a elaboração de novas versões. Desde então. por exemplo. a Smalltalk uma das linguagens pioneiras no mundo dos objetos. A idéia de se criar um sistema com a tecnologia de objeto teve alguns pensadores dentre os quais pode-se citar Alan Kay.Em 1996 os três especialistas. a UML já se encontra na versão 1. de forma breve.5 lançada em março de 2003 e sua especificação pode ser obtida gratuitamente no site da OMG (www. por isso. 4.2. 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.omg. Porém. 57 .

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

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

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

2. onde uma classe pode assumir o papel de classe pai ou superclasse e dar origem a uma classe filho ou subclasse. uma classe pode ser definida como uma abstração de um conjunto de objetos que apresentam características e comportamentos comuns. O conceito de herança apresenta a mesma lógica de abstração. Ao ser criada.6 Herança Como citado anteriormente. através de uma única interface que é o conector comum. é importante que sejam desenvolvidas classes com baixo acoplamento e alta coesão. 61 . 4. para desenvolver um sistema com um baixo custo e com uma manutenção simples. pois. 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).2. O conceito de acoplamento está diretamente relacionado ao quanto às classes estão interconectadas referindo-se ao quanto uma classe conhece da outra. esses dois conceitos talvez sejam os conceitos mais importantes dentro da orientação a objeto. evitando-se dessa forma maiores esforços com manutenção do código de programação. Ou seja. Tal conceito está diretamente relacionado com o conceito de encapsulamento que delimita esse nível de conhecimento entre classes e objetos. 4. O principal objetivo é maximizar a coesão para assegurar um agrupamento consistente de operações na classe. estabelecendo-se uma hierarquia de classes. porém aplicada entre classes. 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 coesão mede o quanto uma classe e suas operações fazem sentido. a subclasse herda todas as propriedades e comportamentos da superclasse evitando-se replicar trechos do código de programação.7 Acoplamento e Coesão Para AMBLER (1998).

a UML dispõe de mecanismos de extensão que possam suportar exceções.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. portanto. podem criar novos conceitos e notações para atender situações não contempladas pelos conceitos principais e devem poder especializar conceitos. Dessa forma. 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. 62 . porém sempre com a preocupação de não redefinir os principais conceitos para cada situação nova que aparece. Tais conceitos são necessários em muitos projetos de diversas áreas de desenvolvimento e aplicação de sistemas sendo. notações e restrições para um domínio de aplicação particular. 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. sem ter que mudar os conceitos principais. mantendo a UML dentro de um mesmo padrão. 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.

permitindo a troca desses modelos entre usuários sem a perda de informações. 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. Logo. 2000). isso também leva a uma padronização e uma maior interoperabilidade entre as diversas ferramentas do mercado. os fornecedores de softwares de modelagem passam a ter que desenvolver ferramentas que suportem os modelos da UML. 8 Metamodelo pode ser definido como um diagrama que define a notação de uma linguagem.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. 63 . Esse metamodelo serve como referência de modelagem e ponto de partida para que os usuários da UML compreendam suas notações. 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. ajudando ao usuário na definição e criação de um modelo bem formado e sintaticamente correto. (Fowler e Scoot.

que são abstrações identificadas como cidadãos de primeira classe de um modelo. colaborações. englobando uma grande variedade de vistas baseadas em diferentes níveis de agregaçã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. que reúnem os itens e. classes ativas. arquiteturas.Suportar conceitos de desenvolvimento de alto nível como componentes.4 Conceitos Básicos da UML Definidos os principais objetivos da UML. interfaces. é 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. por fim. resumidamente.4. ainda existe uma subdivisão sendo estes classificados em itens estruturais (classes. 4. os diagramas que agrupam coleções de itens. alguns mecanismos comuns aplicados na UML. domínios de aplicação. os relacionamentos. a leitura da notação e a criação dos modelos que formam a linguagem tornam-se mais fáceis.1 Blocos de Construção Existem três tipos de blocos de construção que são os itens. as regras que determinam como tais blocos podem ser combinados e. colaborações. tecnologias de implementação. 4. 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. modelos. códigos e arquiteturas comuns de projeto. casos de uso. Dentro dos itens. explicados abaixo. entre outros fatores que fazem da UML uma linguagem que passa a ser vista como uma integração das melhores práticas. esses três elementos serão. por fim. Com a compreensão desses elementos. Para uma melhor compreensão da linguagem. os itens comportamentais (interações 64 . componentes e nós) que são as partes mais estáticas do modelo.

esclarecer e fazer observações sobre qualquer elemento do modelo. 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. 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).. 2000). de colaborações. Como no caso dos itens. os itens anotacionais (nota) que são partes explicativas dos modelos caracterizando-se por comentários para descrever. 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. também existe uma subdivisão dos tipos de relacionamentos que podem existir entre os itens. de objetos. de componentes e de implantação. de atividades. vista de projeto. C. Por fim. de gráfico de estados. Normalmente são expressos por mudanças de estado definidas por pré-condições e pós-condições (LARMAN. De acordo com essas visões. vista de processo.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. de casos de uso. a agregação que é um tipo de relacionamento entre o todo e suas partes. nos quais a alteração do item independente pode alterar o item dependente. definindo o que deve ser feito pela operação e não o como. a UML inclui nove diagramas: diagrama de classes. por fim. a saber: vista de caso de uso. O segundo tipo é a associação que é um relacionamento estrutural que descreve um conjunto de conexões entre objetos como. vista de implementação e vista de implantação. por exemplo. O primeiro deles é a dependência que se caracteriza com um relacionamento semântico entre dois itens. podendo ser encontrado entre interfaces e classes ou componentes que as realizam ou entre casos de uso e as colaborações que as realizam. de seqüências. 65 . 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. 9 Um contrato pode ser definido como um documento que descreve o que uma operação se compromete a atingir.

a UML dispõe de regras semânticas para nomes (quais nomes podem ser atribuídos a coisas). integridade (como os itens se relacionam de forma integrada e consistente) e execução (o que significa executar ou simular um modelo dinâmico). escopo (o contexto que determina um significado específico para um nome). muitos detalhes da respectiva notação.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. Divisões comuns – Dentro da modelagem orientada a objeto existem 66 . a arquitetura também citada acima será mais detalhada mostrando o relacionamento das vistas com os diagramas. operações e comportamentos da classe. 4. 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. 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. 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. Adornos – Um adorno pode ser considerado um tipo de especificação que ajuda a representar.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. Além disso. visibilidade (como os nomes podem ser vistos e utilizados pelos outros).4. Como exemplo. Como exemplo. Para tal. através de textos ou gráficos.

. os autores da UML sugeriram a subdivisão de uma arquitetura de um sistema em cinco vistas (BOOCH et al. valores atribuídos e restrições. Com o segundo. Com o primeiro. ao desempenho. a construção e a documentação de sistemas complexos de softwares. a especificação. gestão e controle do projeto. analistas.5 Arquitetura da UML Conforme definido anteriormente. à flexibilidade. por fim. Para executar essas tarefas. considerando aspectos relacionados à estrutura. 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. 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. programadores. Existem três tipos de mecanismos: estereótipos. 4. cada vista tem um foco em determinado aspecto do sistema.) envolvida no projeto de desenvolvimento deve visualizar o sistema sob diversas perspectivas para melhor entendimento. gerentes de projetos. a UML tem como principais objetivos a visualização. a equipe (usuários do sistema. 2000). Diante da necessidade de se visualizar um sistema sob várias perspectivas. o vocabulário da UML pode ser ampliado com a criação de novos blocos de construção derivados dos já existentes. podem ser criadas novas informações na especificação de um bloco de construção e. etc. com o terceiro mecanismo é possível ampliar as semânticas dos blocos de construção.basicamente duas formas de divisão. Conforme pode ser observado na figura abaixo e no texto abaixo. ao comportamento. à reutilização. mas todas elas estão interligadas de alguma forma: 67 . à funcionalidade. 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. permitindo a inclusão de novas regras ou modificar as já existentes. entre outros.

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

Assim. Este relacionamento é representado no diagrama por uma seta pontilhada entre os casos de uso com o estereótipo “estende”. A herda todas as características de B. 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. tendo-se que se definir apenas as características de especialização de A. por fim.indica que um ator está relacionado a um determinado caso de uso. 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. Logo. WINTERS. 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. GUINEY. Este relacionamento é representado por 71 .uso e. 1998. quando existe um relacionamento de extensão de um caso de uso A para um caso de uso B. KULAK. 2000). uma instância de B pode incluir o comportamento especificado por A. Extensão – ocorre quando um comportamento opcional de um caso de uso tem que ser descrito. Este relacionamento é representado no diagrama por uma seta pontilhada entre os casos de uso com o estereótipo “inclui”. para evitar repetição esse tipo de relacionamento pode ser utilizado. Este relacionamento é representado no diagrama por uma linha reta que liga o ator ao caso de uso. 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. entre atores e entre casos de uso e atores que podem ser de: Comunicação . significando que esse ator interage com o sistema. Este diagrama apresenta basicamente quatro objetos que o constroem. O primeiro objeto seria o caso de uso que é representado por uma elipse contendo o seu nome no interior ou abaixo da elipse. ou seja.

regras e os vários tipos de relacionamentos estáticos existentes entre eles. 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. Não existe um 72 .uma seta cheia que liga os casos de uso ou atores envolvidos. operações. que pode ser opcional. bem como seus atributos.6.2 Diagramas de Classes Os diagramas de classes descrevem os tipos de objetos que existem dentro de um sistema. No que se refere ao desenvolvimento dos diagramas de classes. Por fim. o último objeto. 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.

pode-se classificá-los em dois grupos: 73 . É 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. 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. Especificação – Nessa perspectiva o software passa a ser considerado sendo identificadas as interfaces de cada tipo de dados previsto. os atributos e as operações da classe. a notação definida pela UML para representar uma classe é um retângulo que pode. Conforme pode ser visto na figura abaixo. SCOTT. mas podem ser muito valiosas nos processos de modelagem e revisão dos modelos (FOWLER. Implementação – Essa é a perspectiva mais utilizada e está relacionada diretamente com a codificação das classes projetadas. 2000). não considerando a implementação. dependo da perspectiva adotada. apresentar até três divisões delimitadas para o nome.comprometimento com a implementação podendo ser considerado independente do software e da linguagem de programação que serão utilizados. É importante ressaltar que tais perspectivas não são definidas formalmente na UML.

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

Classes Associativas – esse relacionamento permite atributos e operações as associações. 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 . Na figura abaixo se pode encontrar um exemplo de um diagrama de classes com alguns desses elementos citados acima.Dependência – é um relacionamento em que uma classe ou objeto é independente e a outra classe ou objeto é dependente. mas devem ser utilizados com cautela para não comprometer o entendimento dos principais conceitos envolvidos no diagrama de classes. Todos esses relacionamentos ajudam na compreensão do domínio que está sendo estudado. uma mudança no elemento independente afeta o elemento dependente. ocorrendo quando existem atributos e operações que não podem ser atribuídas a nenhuma das classes pertencentes à associação. Pedido Cliente códigoDoCliente limiteDeCrédito incluirPedido( ) Operações atenderPedido( ) 1 Agregação Associação Multiplicidade * Pedido. ou seja.

6. um objeto é representado.6.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.4. tendo utilidade para representar e facilitar o entendimento de algum tipo de relacionamento complexo de um diagrama de classes. 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. conforme pode ser observado na figura abaixo. É 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.4 Diagramas de Interação Diagramas de interação são modelados para representar os aspectos dinâmicos 76 .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. Com relação à notação. além de apresentar a mesma notação utilizada nos diagramas de interação que serão visto a seguir.35 desconto = 10 Figura 24: Diagrama de Objetos Fonte: BEZERRA (2002.129) 4.20 desconto = 2 item3: ItemPedido quantidade = 1 produto07 : Produto nome = "Esquadro" descrição = "Esquadro de acrílico 20cm" preçoUnitário = 2. Esse tipo de diagrama é utilizado com pouca freqüência. produto20 : Produto nome = "Caderno M" descrição = "Caderno em espiral tamanho médio" preçoUnitário = 4. P.

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. 77 . outro. A utilização de um.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. as mensagens que são trocadas entre os objetos do diagrama sendo representadas por setas. 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. ou seja. por fim.4. A figura abaixo colabora para um melhor entendimento dos principais elementos que estão relacionados ao diagrama de seqüência. Tais diagramas são definidos a seguir. a criação de objetos que está relacionada à posição vertical dos objetos no diagrama. e. mostrando como os sistemas agem internamente para que um determinado ator alcance seu objeto através da realização de um caso de uso. as linhas de vida que determinam os tempos de existência dos objetos e são representadas por uma linha vertical pontilhada. um stick man.dos sistemas. Para isso. síncrona. podendo ser de quatro tipo (simples. ou os dois diagramas dentro de um processo de desenvolvimento depende do foco que se deseja visualizar as interações entre os objetos. assíncrona e de retorno). tendo sempre como principal objetivo o entendimento dessas interações.6. as classes que eventualmente podem aparecer quando da necessidade de se enviar mensagens para elas. 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. 4. 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. 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.

tendo como principal diferença à utilização de setas e rótulos de mensagens nas ligações entre os objetos. através de seqüências numéricas.2 Diagramas de Colaboração Os diagramas de colaboração são bem semelhantes aos diagramas de objetos. Assim como os diagramas de seqüência. Conforme pode ser observado na figura abaixo. e. indicam a ordem de envio das mensagens.6. as linhas ou ligações entre os objetos que representam os tipos de relacionamentos (agregações.4. os identificadores seqüenciais que. associações. por fim. etc.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. 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.) entre os objetos. 78 . as setas que indicam as direções das mensagens sendo posicionadas próximas aos rótulos das mensagens. esse tipo de diagrama busca representar as trocas de mensagens (interações) entre os objetos que executam os casos de uso.

76) 4.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 segunda representa a condição para que a transição ocorra ou não (condição de guarda) e. a última parte se refere à ação realizada resultante da transição. adaptada de FOWLER e SCOTT (2000. 79 . por fim. 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. p. conforme pode ser observado na figura abaixo. os estados podem estar aninhados dentro de um superestado com o intuito de facilitar a compreensão do diagrama. A primeira parte corresponde ao evento que dispara a transição. 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. cada estado é representado por um retângulo com bordas arredondadas. Além disso.6. mostrando todos os possíveis estados que os objetos podem ser assumir durante seus ciclos de vida. Neste diagrama.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. Demais adornos são definidos pela UML para aplicação nesse diagrama.

adaptada de FOWLER e SCOTT (2000. onde os estados representados referem-se a atividades e não a objetos. Conforme pode ser observado na figura abaixo. além dos elementos já definidos para o diagrama de gráficos de estados.6 Diagramas de Atividades Os diagramas de atividades podem ser considerados tipo de diagrama de gráficos de estados. esse tipo de diagrama é particularmente útil para modelagem do fluxo de operações onde há a possibilidade de processamento paralelo. onde um mesmo objeto pode apresentar um ou mais estados independentes.acrescentando alguns detalhes aos estados e transições. permitindo a modelagem de estados concorrentes. 80 . p. ou seja. Tais atividades representam o andamento e execução das operações e as transições caracterizam o término dessas operações.6. esse diagrama pode apresentar pontos de sincronização.116) 4. e pontos de decisão representados por losangos. 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. representados por barras entre as transações.

Dentro da UML.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.122) 4.6. adaptada de FOWLER e SCOTT (2000. p. 81 .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. esse tipo de diagrama é representado pelos diagramas de componentes e de implantação que serão descritos a seguir. mostrando os componentes físicos e suas interdependências.

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. adaptada de BEZERRA (2002. Biblioteca – quando se refere a uma biblioteca de objetos ou de funções. Documento – quando o componente é um documento como. por exemplo. A UML define alguns estereótipos para componentes.6. Arquivo – quando é um arquivo de dados. 82 . um manual do usuário.7. Na figura abaixo é possível observar os principais elementos que formam esse tipo de diagrama. as classes. Um módulo de sistema (arquivo de código fonte.250) 4. por exemplo. Componente Alunos Interface Lançamento de Notas Professores Relação de Dependência Turmas Figura 29: Diagrama de Componentes Fonte: O autor. um arquivo executável. e as conexões que são representadas por 11 É importante entender que um componente materializa um conjunto de elementos lógicos como. 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. Tabela – quando é uma tabela de um banco de dados.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.7. pode ser considerado um componente.).4. por exemplo. etc. p. a saber: Executável – quando um componente pode ser executado.6.

apresenta a classificação de ferramentas segundo 83 . 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.2.linhas cheias que significam meios físicos ou protocolos de comunicação que ligam os nós. roteadores.252) 4. os seus componentes residem em nós que por sua vez podem ser de vários tipos como processadores. a existência de base de dados. p. também existem aquelas avaliam ferramentas de modelagem de software como. entre outros fatores. A figura abaixo ilustra os principais elementos de um diagrama de implantação. adaptada de BEZERRA (2002. Nesse caso. etc. sensores.2 podem se aplicar às ferramentas de modelagem de processos de software. a Yphise. o tempo estimado de vida útil dessa ferramenta dentro da organização. 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. Da mesma forma que existem consultorias que avaliam ferramentas de modelagem de processos de negócio. a facilidade de utilização da mesma. que em seu relatório de avaliação de software de novembro de 2002. por exemplo.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. a política do fornecedor com relação à manutenção e atualização da ferramenta. É importante ressaltar que quando o sistema está sendo executado.

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. Figura 31: Comparação das Ferramentas de Modelagem de Software Fonte: YPHISE (2002) Na classificação acima. Fácil Adaptação – A equipe de desenvolvimento necessita de uma ferramenta que é fácil de adaptar e usar.alguns critérios. a saber: Abrangência da Modelagem – Capacidade de modelar com precisão as aplicações e arquiteturas especificadas. a consultoria avalia as ferramentas com base em cinco critérios. O ambiente de desenvolvimento deve ser fácil de 84 .

verificação e correção de nomes e regras de notação da linguagem (UML) utilizada. 85 . ajudando a manter a qualidade. Retenção de informações durante o ciclo de desenvolvimento – A ferramenta deve ser capaz de reter e fornecer informações como. Com base nesses critérios utilizados na avaliação da Yphise. modelos e documentos desenvolvidos durante todo ciclo de desenvolvimento do sistema. apresentando segurança no processo de modelagem com restrições de acesso e privilégios por tipo de usuário. entre outros. deve apresentar capacidade de acesso ao mesmo tempo por muitos usuários. a Rational Software pertence a IBM tendo sido adquirida no final de 2002. 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. Controle da Qualidade dos Modelos – Define a capacidade da ferramenta de controlar a consistência dos modelos através de definição. 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. O processo inverso é chamado de Engenharia de Produção. 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. 12 A Engenharia Reversa é a capacidade que a ferramenta tem de gerar a partir dos códigos existentes modelos de software. produtividade e sincronização entre os requisitos definidos e o código gerado. Atualmente. Esse processo será melhor explicado no próximo capítulo. A ferramenta também deve possibilitar incorporar facilmente tanto o código existente como os componentes através de engenharia reversa12.configurar para adaptar requisitos e métodos específicos da organização. por exemplo.

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

fazendo-se uma análise crítica dos modelos da UML. Além disso. através da comparação entre o EPC e os diagramas da 87 . também pode ser utilizada para modelagem de negócio. Porém. ainda existem limitações com relação à representação de alguns conceitos relacionados à modelagem de processos de negócio. serão mostrados os diagramas da UML sob a ótica de utilização dos mesmos para modelagem de negócio e. Não serão considerados nessa análise os diagramas de implementação. pois. Mas. Assim. como base de comparação. como será visto nesse tópico. portanto. para que a UML seja utilizada para modelagem de negócio. mostrando. da versão 1. 5. enquanto linguagem para modelagem de negócio. será utilizado o EPC como modelo de processos de negócio. a UML além de ser uma linguagem utilizada para modelagem de software. 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.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. Nesse tópico. Esse capítulo tem como principal objetivo analisar e comparar os principais conceitos e modelos que suportam a EPN e a ES. da forma como os modelos estão definidos pela OMG.5 EPN E UML: CONTEXTUALIZAÇÃO DA UML NA MODELAGEM DE PROCESSOS DE NEGÓCIO Como foi possível observar no capítulo 3. estes não apresentam nenhum tipo de relação direta com os conceitos de modelagem de negócio.5 de março de 2003. 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. é necessária criar algumas extensões e customizar a linguagem. considerada pela OMG como linguagem padrão universal para desenvolvimento de sistemas de softwares orientados a objeto. de processos de negócio.

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. 5. entre outros. 88 . clientes. 2001b). Dentro de um diagrama de caso de uso de negócio. e o próprio negócio.1. 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.UML. Conforme foi dito no tópico 4. O diagrama de casos de uso apresenta alguns conceitos de modelagem de negócio como. etc. as principais diferenças e semelhanças entre a modelagem de processos de negócio e a modelagem orientada a objeto. a interação entre atores e casos de uso.6.1 Modelagem de Negócio e Diagrama de Casos de Uso Conforme apresentado no capítulo 4. um caso de uso é um conjunto de cenários que descrevem interações entre usuários e sistemas. passa a ser o próprio negócio. Logo.1. 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. 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. que podem ser representados por unidades organizacionais. A partir desse princípio. Tais cenários representam diversas situações vivenciadas pelos usuários do sistema. onde se descreve o fluxo normal de eventos que descreve os principais passos do processo. podendo também usá-las em conjunto para expressar o fluxo de trabalho do processo de negócio. Em considerando a utilização desse diagrama para modelagem de negócio. 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. por exemplo. fornecedores. A utilização de uma forma de descrição ou outra fica a critério dos envolvidos com a modelagem dos casos de uso. 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. uma das formas de representar é textualmente com a utilização de um formato básico de descrição. os fluxos alternativos de situações incomuns. Dependendo da situação. tanto a descrição textual como a gráfica apresentará vantagens e desvantagens.

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

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. 90 . Em todos os casos. entre outros. é o que mais se aproxima dos modelos tradicionais de modelagem de processos de negócio como. é possível utilizar os mesmos papéis (ator representado por um stick man ou unidades organizacionais representadas por elipses) para ambos diagramas. também pode ser utilizado para modelagem de processos de negócio podendo ser denominado de diagrama de atividades de negócio. Dependendo do nível de detalhamento em que se esteja trabalhando.2 Modelagem de Negócio e Diagramas de Atividades O diagrama de atividades. 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”. Dessa forma. “formatar o texto” e “salvar o documento”. do lado direito da figura. é possível gerar a partir de um EPC. o IDEF 3. 5. dentre os diagramas da UML. Numa outra abordagem. ainda também é possível ter a relação de uma função para um caso de uso. esse tipo de diagrama. inicialmente concebido com o intuito de modelar o fluxo de trabalho relacionado ao comportamento de um sistema.1. por exemplo. o EPC. é 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”.

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

1. as entidades de negócio também podem ser representadas como classes e objetos. as funções são convertidas de forma direta para as atividades. 5. 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. o que faz 92 . É importante destacar que os dois modelos (diagrama de atividades e EPC) podem contemplar de forma satisfatória a modelagem de processos de negócio.3 Modelagem de Negócio e Diagrama de Classes Conforme foi possível observar no capítulo 4. de forma diferente. pensando em termos de modelagem de negócio. os eventos inicias e finais do processo. os diagramas de classes e de objetos mostram os relacionamentos entre classes e conseqüentemente objetos que estruturam um sistema. 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. as unidades organizacionais do EPC são representadas nas swimlanes. Os eventos intermediários não são representados no diagrama de atividades que representa apenas.Figura 34: Relação entre EPC e Diagrama de Atividades Fonte: LOOS e ALLWEYER (1998) Na figura acima. Porém.

de atividades. as mensagens entre os objetos são representadas pelo fluxo de controle apoiado por mecanismos de decisão e de controle como. buscando tirar vantagens das duas abordagens. denominada de abordagem de integração. 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. entre outros. o EPC pode contribuir de forma direta na construção do diagrama de classes. o primeiro autor coloca que o EPC. No que diz respeito ao diagrama de classes. Essa identificação se daria através do detalhamento de objetos de informação processados e das atividades executadas no processo. Outros conceitos relacionados. por exemplo. 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. que o autor chama de abordagem de transformação. 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. Na primeira delas. Conforme pode ser visto na figura abaixo. os operadores lógicos e. principalmente. à 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. por exemplo. 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. objetos esses que apresentam seus atributos e suas operações. a modelagem de estruturas organizacionais mostrando os relacionamentos entre as unidades organizacionais num organograma. considerando que um dos principais objetivos da modelagem de processos de negócio é 93 . Alguns autores como NÜTTGENS. Na segunda forma. de evento. Além disso.desses diagramas candidatos para aplicação de parte dos conceitos relacionados à modelagem de negócio como. metas. indicadores. os eventos descrevem os estados de transição dos objetos de negócio de acordo com as operações executadas. por fim. pode se relacionar de duas formas com o diagrama de classes.

os autores sugerem três níveis de detalhamento entre o EPC e os elementos que formam o diagrama de classes. conforme pode ser vista na figura abaixo. representado por uma seta com sentido da função para o pacote. e que objetos daquele pacote tiveram seus estados alterados pela função. 94 . por exemplo. pois. No nível mais agregado. 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. Nessa abordagem. as funções agregadas do EPC se relacionariam com pacotes (conjunto de objetos logicamente agrupadas) onde o sentido da seta indica. o diagrama de classes pode ser considerado a parte central da UML sendo base fundamental para o desenvolvimento orientado a objeto.identificar e resolver problemas organizacionais. 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. que informações contidas nos objetos de um pacote servem de entrada para execução de uma determinada função. 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.

1 Determinar Receptor() Figura 37: Diagrama de Classes agrupado num pacote Fonte: LOOS e ALLWEYER (1998) 95 .. 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. Pedido Data Status Item do Pedido Estoque Status Determinar Material() Determinar Estoque() 0 Requisitos Empregado 0.. Procuração Material Nome Quantidade em Estoque 1.

mostrando quais objetos são utilizados e modificados pelas funções. 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. 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. no terceiro e último nível. as funções já em um nível bem desagregado se relacionam diretamente com atributos e operações dos objetos das classes.No nível intermediário.

onde cada operação que é relevante para o negócio é executada por uma função. apresenta limitações para modelagem de negócio. está normalmente associado a um único objeto de sistema. Por ser muito específico e voltado para modelagem de estados de um único objeto. sendo relevante em algumas situações no nível de análise e projeto de um sistema. conhecido também como apenas diagrama 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 . o gap entre funções e operações durante a definição de requisitos.Os autores colocam que nesse nível as funções estão muito próximas das operações. 5.4 Diagrama de Gráficos de Estados O diagrama de gráfico de estados. esse diagrama. sendo utilizado quando é necessário entender de forma mais clara o comportamento desse objeto. reduzindo.1. 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.

pois. Nessas situações basta a utilização de uma das notações. os atores e as metas de processo relacionadas à execução dos casos de uso. Dessa forma. o próprio evento já indica uma mudança de estado de um determinado objeto que está sendo utilizado durante o processo como. por exemplo. 5. 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.1.LOOS e ALLWEYER (1998) ressaltam a importância de se definir os estados dos possíveis objetos associados às funções. Além disso.5 Modelagem de Negócio e Diagramas de Interação Os diagramas de interação (diagrama de seqüência e de colaboração). é possível acompanhar as transições e mudanças de estados de um determinado objeto dentro de um processo de negócio. conforme já citado no capítulo 4. 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”. 98 . o evento “requisição capturada” que é redundante com o objeto de saída “requisição” no estado de “capturada”. como pode ser visto na figura acima. a função “retirar material do estoque” só pode ser executada quando o objeto de entrada “requisição” estiver no estado de “verificada”. Mas. Em muitos casos. é importante ressaltar que existe alguma redundância entre os eventos do EPC e os estados do diagrama de estados. 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.

portanto. enquanto o EPC. os modelos relacionados ao desenvolvimento de qualquer sistema de informação que dará suporte ao negócio. LOOS e ALLWEYER (1998) também afirmam que esses diagramas estão muito próximos do nível de implementação. inovação nos processos de negócio. Possibilita a elaboração de um plano de ação para gerar. apesar desses diagramas apresentam alguns aspectos do fluxo de processos de negócio. para LOOS e FETTKE (2001). 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. não sendo adequados para modelagem de negócio. eles normalmente são utilizados no nível de implementação. através de mudanças radicais ou incrementais. 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. 99 . a saber: Melhorar o entendimento e os mecanismos de funcionamento do negócio através do uso de modelos. 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.Mas. a modelagem de negócio é base fundamental para modelagem de outros modelos como. 5. Serve de base para a modelagem de sistemas de informação que darão suporte ao negócio. apresentando detalhes técnicos e.2 Extensões da UML para Modelagem de Negócio Para ERIKSSON e PENKER (2000). por exemplo. tornando o processo de desenvolvimento de sistemas orientado ao negócio. por exemplo. pois. Serve de base para melhoria contínua tanto da estrutura como da operação do negócio. Os autores destacam algumas vantagens de se realizar a modelagem de negócio.

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

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. representado por um diagrama de objetos da UML. Para os autores.2. 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. por exemplo. a arquitetura de um negócio pode ser quebrada em quatro vistas: 5. um modelo de objetivos e problemas. os autores também propõem vistas de negócio como.<<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. 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. sub-objetivos e os problemas que limitam o alcance dos objetivos. e um modelo 101 . e que pode ser detalhado em diferentes níveis para mostrar objetivos.

pois.2 Vista de Processos de Negócio Esta vista se caracteriza como a principal vista da modelagem de negócio. Como pode ser observado na figura abaixo. 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.conceitual. A figura abaixo exemplifica um diagrama de objetivos e problemas que mostra a hierarquia existente entre objetivos e seus respectivos problemas. entre os recursos utilizados em suas execuções e entre os objetivos estratégicos definidos. apresenta todos os processos 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 . 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. representado por diagrama de classes da UML.2. os relacionamentos entre eles.

os recursos consumidos ou produzidos pelos processos entre outros. 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. onde cada um representa um conjunto de objetos. 103 . no topo do diagrama de linha de montagem está o diagrama de processos. servindo como base de modelagem para os processos que são diretamente implementados por um sistema de informação. Esses pacotes são elementos da UML e recebem o estereótipo de <<linha de montagem>>. Na parte inferior encontra-se um conjunto de pacotes horizontais que são denominados de pacotes de linha de montagem. Conforme pode ser observado na figura abaixo. mostrando como a informação é acessada pelo sistema e como é utilizada pelos processos. O principal objetivo desse diagrama é mostrar os relacionamentos entre os processos e os objetos de informação. os eventos de negócio que iniciam ou finalizam os processos.envolvidas na execução dos processos.

A vista de processos tem relação com essa vista. Com esse diagrama. produtos e de informação do negócio. mostra quais 104 Receber Lista de Pacotes Identificar como enviado-cliente Registrar como vendido Identificar Vendedor Identificar pedido . são representadas por casos de uso. essa vista mostra a estrutura de recursos. dentro da concepção da modelagem orientada a objeto. o organograma. 5.2. é possível identificar tanto as funcionalidades (casos de uso) que os sistemas devem ter como os atores (executores dos processos) relacionados com essas funcionalidades. esse diagrama facilita a identificação dos casos de uso que devem ser modelados.3 Vista de Estrutura do Negócio Conforme pode ser visto na figura abaixo. Assim. pois. por exemplo. 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.<<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. incluindo modelos como.

seqüência. Diagrama de Classe Diagrama de Objeto Software Inc. o comportamento dos recursos é orientado pela vista de processos de negócio que determina o fluxo de controle do trabalho realizado.4 Vista de Comportamento do Negócio Essa vista mostra os comportamentos individuais dos recursos e processos bem como suas interações. Mas. 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. quando se deseja detalhar o comportamento de um determinado objeto mostrando seu estado. elas podem ser modeladas em paralelo mantendo consistência entre elas. 105 . o comportamento em cada estado e possíveis estados de transição a modelagem ocorre nessa vista. colaboração e também de processos quando há a necessidade de mostrar interação entre processos. Nessa vista são utilizados diagramas de estado. Nessa vista. De uma maneira geral.recursos são utilizados para a execução dos processos e. 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. portanto.2.: Unidade Organizacional Corporação: Tipo de organização Tipo de organização Descrição Produção: Unidade Organizacional Dep.

Uma outra desvantagem dessa abordagem está relacionada ao fato de não possuir nenhum tipo de arquitetura voltada para modelagem de negócio como.2000). pois. 106 . 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. para representar conceitos inerentes aos conceitos de processos de negócio. o objetivo do próximo capítulo é definir uma proposta de metodologia de modelagem de processos com foco em desenvolvimento em sistemas. podendo ser eficiente para modelar sistemas de informação mais simples. foi apresentada uma proposta de extensão da UML por ERIKSSON e PENKER (1999. 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. Foi possível concluir que uma proposta de modelagem de negócios com os modelos da UML. principalmente. Além dessa comparação dos modelos da UML com EPC. tendo como base as vistas da arquitetura da UML apresentada no capítulo 4. mostrando as vantagens e desvantagens da utilização dos modelos da UML para realizar a modelagem de processos de negócio. utilizando alguns diagramas da UML. 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. por exemplo. os modelos da UML não representam de forma satisfatória alguns conceitos relacionados a modelagem de negócio. 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. Essa abordagem já se aproxima mais da modelagem de processos de negócio. o diagrama de atividades. Diante da análise acima.5. conforme observado na comparação com o EPC. a estrutura de vistas da metodologia ARIS.

2001a) Diante da afirmação acima. Com isso. Sendo assim. análise de indicadores desempenho. desenvolvimento de processos de negócio e desenvolvimento de software e que conforme pode ser observado em IDS SCHEER (2002). gestão da cadeia de suprimento. consideradas líderes de mercado em seus respectivos segmentos.” (RATIONAL. o produto da engenharia de negócios não é usado de forma correta como insumo para os esforços de engenharia de softwares.1 Principais Etapas para Modelagem de Processos de Negócio A modelagem de processo de negócio. modelos da UML e conceitos do RUP. e viceversa. a abordagem da modelagem varia de acordo com o objetivo para o qual se está modelando. mas pelo menos parcialmente. O principal objetivo dessa metodologia é o de integrar. apresenta diversas aplicações como o projeto de desenvolvimento de sistemas de informação. a ferramenta ARIS Toolset .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. 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. considerando suas respectivas fases e artefatos. 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. como foi possível observar no capítulo 3. 107 . não existe uma única metodologia de modelagem de processos de negócio. 6. pois. se não totalmente. ARIS Toolset e Rational Rose. gestão de conhecimento. entre outros. 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. podem ser integradas. pois.

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. os das UML. se caracterizando como componentes ou modelos pré-fabricados que variam desde componentes de processos de negócio até os componentes de software. por exemplo. é 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. 108 . Outro aspecto importante do modelo é a iteração existente dentro do processo de modelagem. 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. Diante dessa afirmação. Esses modelos que apresentam um grande potencial de reutilização sejam processo de negócios ou modelos de sistemas como. tipo de análise a ser realizada sobre os modelos ou até mesmo em função da experiência dos usuários. são verdadeiros padrões de soluções para uma gama de problemas. 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. existem muitos processos ou metodologias de modelagem de processos de negócio que podem ser definidos de acordo com os objetivos da modelagem.Para VERNADAT (1996). podendo ser reutilizados para situações futuras. mostrando a preocupação da melhoria contínua envolvendo a etapa de Operação do Sistema e Engenharia de Processo de Negócio.

testes operacionais com uma versão beta do sistema. cabe definir as ferramentas de modelagem que darão suporte a modelagem de processos e de sistema. 109 . dentro da lógica de melhoria contínua. 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. Além disso. 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. definição de manuais de utilização do sistema. entender. conforme observado nas duas primeiras etapas. migração de dados entre sistemas quando necessário e a entrega da versão final que entrará em produção. documentar e difundir a visão estratégica da organização. conforme mostra a figura abaixo. ocorrem a implementação dos processos futuros onde são realizadas atividades como desenvolvimento do código fonte. definir. funções e processos de negócio que serão suportadas pelos sistemas de informação. treinamento dos usuários. 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. Identificadas as possibilidades de melhorias futuras. antes de se desenvolver qualquer tipo de sistema que venha a automatizar qualquer processo de negócio chave. identificando. Assim. oportunidades de melhorias futuras. 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. estabelecendo uma relação direta entre os objetivos estratégicos.Uma outra proposta de modelagem de processo de negócio com desdobramento para sistemas pode ser vista em IDS SCHEER AG (2002). Por fim.

pois. 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). redução dos tempos e custos dos processos. 6. não serão abordadas demais variações das metodologias de Engenharia de Software. melhoria no fluxo de informações. quebrar a modelagem em vistas suportadas por modelos que possam representar de forma simplificada e integrada diferentes aspectos da modelagem realizada. é importante. etc. (2000) que 14 Cabe ressaltar que além da metodologia RUP.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.2 Processos Produtivos de Desenvolvimento de Sistemas Atualmente. proporcionando vantagens já citadas anteriormente como a uniformização do entendimento e padronização da forma de trabalho. 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. A metodologia RUP foi escolhida como base de estudo pois é uma das principais metodologias de desenvolvimento de software do mercado. incluindo os processos de negócio e a arquitetura dos sistemas de informação. pode-se citar a metodologia de desenvolvimento de software Rational Unified Process (RUP). de acordo com a classificação apresentada no item 4.É importante destacar que para a realização da modelagem consistente e de fácil entendimento da estrutura do negócio como um todo. que será detalhada nesse tópico. está fora do escopo dessa dissertação. pela melhor ferramenta de modelagem de software do mercado que tem a UML como linguagem padrão de modelagem. como por exemplo. sendo suportada. Como exemplo. conforme observado no tópico anterior. e que leva em consideração em suas etapas iniciais do projeto de desenvolvimento de software a modelagem de processos de negócio. o RUP. 110 .7 dessa dissertação.

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. desenvolver. como e quando será desenvolvido o software.2. dentro da Engenharia de Software. centrado na arquitetura e iterativo e incremental. Conforme colocado acima o RUP é um processo de desenvolvimento de software e se baseia na UML como linguagem padrão de modelagem. Além disso. 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.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. os modelos da UML. de maneira eficiente e previsível. um processo de desenvolvimento de software compreende todas as atividades necessárias para definir. testar e manter um produto de software. Para um melhor entendimento do RUP serão descritas a seguir as suas principais características incluindo suas fases. 6. Já para LARMAN (2000) um processo de desenvolvimento de software é um método para organizar as atividades relacionadas com a criação. quando. o autor destaca os objetivos de prover pontos de controle e padronização do processo. A seguir essas características são detalhadas. tendo como principais objetivos à definição das atividades que serão executadas. como e por quem essas atividades serão executadas. 111 .afirmam que um processo. entrega e manutenção dos sistemas de software. por exemplo. um produto de software capaz de atender as necessidades de seu negócio. Assim. Além disso. é um conjunto de passos parcialmente ordenados com a intenção de atingir a meta de entregar. iterações e artefatos utilizados como. Para BEZERRA (2002). 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.

com a estética das interfaces de usuários. 6. Dessa forma. pelo fato de expressarem as necessidades dos usuários do sistema. 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.2.1. A cada iteração do processo de desenvolvimento de software é possível medir.2. capacidade de recuperação e funcionalidades desses elementos. gestão e manutenção dos componentes de software. entre outros aspectos que envolvem um sistema.6. com tecnologias e custos envolvidos no projeto. Ou seja. servem de base e orientam os demais fluxos de trabalho envolvidos como análise e projeto. com a flexibilidade de reutilização. implementação e teste do sistema. testar e avaliar a arquitetura frente aos requisitos definidos. todos os modelos de análise.2 Processo Centrado na Arquitetura Uma arquitetura de software tem relação direta com a estrutura e o comportamento dos elementos de um sistema. permitindo que a equipe envolvida evite os riscos mais importantes para o projeto.1. 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. Assim. 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.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. servindo também de base para os demais fluxos de trabalho do processo de desenvolvimento. desempenho. Uma das abordagens que contribui para a construção de um arquitetura flexível é o desenvolvimento baseado em componente (Component-Based Development – CBD). 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 . os casos de uso. 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.

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

são identificados e especificados os principais casos de uso que serão implementados ao final da 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. são criados os modelos de projeto do sistema com base na arquitetura definida. surge o processo iterativo e incremental. tais componentes são testados de acordo com as funcionalidades definidas pelos casos de uso. o maior contato com o usuário final que participa e valida os requisitos definidos em vários momentos do ciclo de vida. distribuição mais uniforme da carga de trabalho da equipe como um todo. esses modelos de projetos são implementados através de componentes de sistemas e. esta abordagem também apresenta outras vantagens como uma melhor monitoração e controle do projeto a cada teste de iteração. Além da identificação antecipada dos riscos que envolvem o processo. etc. o desenvolvimento prossegue com uma nova iteração que contemplará novas funcionalidades e aperfeiçoará outras em 114 . aprendizado contínuo dos envolvidos com o projeto com uma melhoria contínua do processo. Para cada iteração. possibilitando uma reação mais pontual e eficiente aos riscos a cada iteração. Caso as funcionalidades testadas ao final de uma iteração sejam validadas. identificação antecipada de inconsistências entre requisitos. 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. construções e implementações. por fim. Como opção a abordagem em cascata.

desenvolvimento. As figuras abaixo ajudam na compreensão da abordagem iterativa e incremental. 2003): 115 . as decisões tomadas devem ser revistas. 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. o RUP engloba demais características que também são consideradas como as melhores práticas de software do mercado. Caso ao contrário. tentandose uma nova abordagem. a saber (KRUCHTEN.

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. assim como as necessidades dos usuários envolvidos. Também é importante avaliar o desempenho e confiabilidade do sistema. a construção e a implementação. do estabelecimento dos critérios de priorização dos requisitos. facilitando a uniformização de entendimentos a todos envolvidos no desenvolvimento. os problemas de software são de 100 a 1000 vezes mais custosos de serem solucionados após a entrega do sistema. identificar arquiteturas não modulares e inflexíveis. Em sendo apoiada por uma boa ferramenta de modelagem é possível. sincronizar os modelos e o código-fonte a cada iteração. avaliá-los e reformulá-los durante o desenvolvimento do sistema. Por isso. etc.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. aumentar a qualidade da aplicação. sendo necessária uma gestão dinâmica e contínua para identificá-los. mantendo consistência entre os artefatos (modelos da UML) relacionados com os requisitos. estabelecer níveis de detalhamento adequados. Verificação Contínua da Qualidade do Software Segundo KRUCHTEN (2003). 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. Modelagem com a UML A modelagem visual ajuda a entender a complexidade de um sistema. etc. 116 . da avaliação objetiva de funcionalidades e desempenhos do sistema. principalmente quando é suportada por uma linguagem padrão de mercado como a UML. dentro da lógica iterativa. entre outros aspectos que contribuem para identificação antecipada de inconsistências. Além disso. são definidos num único momento. cabe ressaltar que nem todos os requisitos sejam funcionais ou não.

reduzindo-se de forma radical os custos relacionados aos problemas encontrados.2. 6. requisitos. a falta de controle do processo de desenvolvimento. portanto. 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. Assim. implementação e teste. onde o eixo horizontal representa o tempo e mostra. Além disso. elaboração. Conforme pode ser observado na figura abaixo. construção e transição. essa lógica é estruturada em duas dimensões. sendo que cada iteração representa um ciclo de desenvolvimento. análise e projeto. 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. é 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.2 O Ciclo de Vida de um Sistema no RUP O RUP consiste de vários ciclos durante a vida de um sistema. que passa pelos seguintes fluxos de trabalho: modelagem de negócio. Figura 51: Estrutura do RUP Fonte: Adaptada de KRUCHTEN (2003) 117 . concepção. através das fases. em cada fase ocorrem várias iterações. sendo que cada ciclo apresenta como resultado uma versão do sistema pronta para operação e é subdividido em quatro fases.

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. durante a fase de concepção. Para KRUCHTEN (2003). as funcionalidades do sistema. os propósitos e objetivos do negócio.al (2000). os fatores críticos para o sucesso do projeto. são definidos critérios de sucesso do projeto incluindo avaliação dos riscos. etc.Os próximos tópicos descrevem brevemente as fases do RUP com os principais fluxos de trabalho e artefatos envolvidos. Como um dos principais artefatos gerados nessa fase. 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 . 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. estimar o custo global e os riscos do projeto.3.2. protótipos. Conforme pode ser observado na figura acima. entre outros.3 Fases da Metodologia Para BOOCH et. os principais fluxos de trabalho envolvidos nessa fase são a Modelagem do Negócio e Levantamento de Requisitos. responsável por expor os riscos. modelo de domínio. modelo preliminar com a listagem dos casos de uso e atores identificados num primeiro momento. os principais objetivos dessa fase são: estabelecer o escopo do projeto delimitando o que deve ou não estar no produto. Outros artefatos podem ser citados como resultado dessa fase como um glossário do projeto.2. as regras de negócio. mostrar pelo menos uma proposta de arquitetura candidata perante os casos de uso críticos.1 Concepção Segundo BOOCH et. 6. A seguir são descritas as fases e suas principais características. al (2000). 6. artefatos são concluídos e decisões são tomadas em relação a passagem para a fase posterior. pode-se citar o documento de Visão do Projeto. estimativa e alocação de recursos e um planejamento dos principais pontos de controle do projeto. também conhecida como fase de início ou de origem.

entre outros aspectos que agregam valor na definição de um sistema de informação. por exemplo. Além disso. existem outros artefatos como documentos que definem a visão. o glossário do negócio. 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 funcionais são todos aqueles que refletem as necessidades diretas dos usuários do sistema e que. Já os requisitos não funcionais estão ligados a demais atributos não relacionados diretamente as funcionalidades do sistema como. 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. Conforme pode ser observado em KRUCHTEN (2003). Com base na modelagem de negócio. definem o comportamento e ações que o sistema deve executar. No fluxo de trabalho de requisitos são identificados os requisitos mais relevantes para definição do escopo e da arquitetura do sistema. suas regras e processos de negócio. Além desses modelos.comportamentais de uma organização com intuito de entender melhor o domínio do negócio através de seus objetivos estratégicos. as regras. sua estrutura organizacional. 16 Esse modelo representa a maneira como os processos de negócio (casos de uso) são implementados internamente. 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. confiabilidade. mostrando de que maneira os processos de negócio são realizados. portanto. entre outros. performance. seus recursos. a arquitetura. descrevendo através de diagramas de atividades. é importante ressaltar que dentro do fluxo de trabalho de requisitos são levantados requisitos funcionais e não funcionais. os trabalhadores do negócio. as entidades de negócio e os relacionamentos entre eles. 119 . etc. classe e de interação.

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

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

com base no modelo de projeto revisto e atualizado no fluxo anterior.exemplo. sistemas de banco de dados e as camadas mais altas próximas às aplicações da arquitetura e. por exemplo. ou seja. O fluxo de implementação se caracteriza como principal fluxo de trabalho dessa fase. a migração de 122 .3. enquanto produto completo.3. 6. 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. portanto. são detalhados os casos de uso remanescentes e são construídos protótipos de interface com usuário. Os fluxos de trabalho de implementação e teste na fase de elaboração têm como principais objetivos implementar e testar. 6. próximas aos usuários do sistema. o treinamento dos usuários. entre outros. no fluxo de teste onde ocorrem os testes da primeira versão operacional do sistema.2.3 Construção É na fase de construção em que o sistema. Por fim. incluindo requisitos funcionais e não funcionais como. Durante essa fase. performance do sistema. por exemplo.2. os elementos da arquitetura do sistema. 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. pois. no que se refere ao fluxo de trabalho de requisitos. arquivos executáveis.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. é desenvolvido estando pronto para a operacionalização e transição aos usuários. com base no modelo de projeto. código fonte. Outras questões também são levadas em consideração nessa fase como. implementa o sistema em termos de componentes de software.

Além disso.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. por exemplo. tomando como referência o RUP da empresa Rational Software.dados do legado para o novo sistema. incluindo fluxos de trabalho como a "Modelagem de Negócio" que utiliza os diagramas de casos de uso para modelar processos de negócio. 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. Foi verificado que o RUP enquanto processo de desenvolvimento de sistemas. 123 . Ao final dessa fase. 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. Através dessa metodologia. foi possível entender de que forma os diagramas da UML são utilizados na criação de um software. 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. 6. os objetivo do ciclo de vida do projeto são avaliados. a não visualização do fluxo de controle dos processos. 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. pois. entre outras.

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. considerando alguns dos principais modelos tradicionais da EPN e da UML. 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. entre outros. tempo de acesso.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. qualidade. 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. componentes de software. 7. 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. desempenho. o que leva ao desenvolvimento de sistemas de informações 124 . por exemplo. 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. um ator de um caso de uso. ou seja. Identificar classes de negócio candidatas a se tornarem classes de sistemas como. por exemplo. Identificar requisitos não funcionais que não são especificados nos casos de uso como. questões relacionadas a segurança.

Comparando essas etapas com os fluxos de trabalho do RUP. 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. Levantamento de Requisitos.alinhados tanto aos processos de negócios quanto aos objetivos estratégicos da organizaçã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. Implementação e Teste) pode125 . serão utilizados os modelos da metodologia ARIS e os modelos da UML. Desenvolvimento da Estratégia e Arquitetura. <<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. 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. Conforme foi possível observar na figura abaixo. Análise e Redesenho dos Processos Futuros e Implementação dos Processos Futuros). Modelagem dos Processos Atuais. conforme observado na figura abaixo (Modelagem de Negócio. Para melhor compreensão dessa modelagem de negócio para sistemas. Análise e Projeto.

Porém. 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. Todas as informações documentadas nessas três etapas servem de requisitos de negócio para o desenvolvimento de sistemas. 126 . Desenvolvimento da Estratégia e Arquitetura. para representar processos de negócio. Mas. Na figura abaixo é possível visualizar essa comparação.se dizer que a etapa de Modelagem de Negócio do RUP deveria contemplar as quatro primeiras etapas: Definição do Mapa Estratégico. mais especificamente os casos de uso de negócio. Modelagem dos Processos Atuais e Modelagem dos Processos Futuros. a modelagem de negócio no RUP é realizada com base em técnicas de modelagem de software.

“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. 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”. Assim. 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. adaptada de IDS SCHEER (2002) Cabe ressaltar que essa dissertação não pretende detalhar na metodologia proposta as fases de “Implementação”.

Assim. para que estes possam ser remodelados numa situação futura e que a partir deles possam ser derivados os casos de uso. 128 . 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. portanto. 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. são descritas as fases de “Modelagem e Levantamento de Requisitos de Negócio” e os artefatos relacionados às mesmas. 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. identifica as classes de objetos que representam os principais conceitos do negócio.1 Modelagem e Levantamento de Requisitos de Negócio Nessa fase devem ser levantados os objetivos. estando. 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. boa parte dos artefatos levantados na fase de “Levantamento de Requisitos” deve ser de responsabilidade do Analista de Negócio.1. Logo. a fase de “Análise de Redesenho dos Processos de Negócio”. com base nos artefatos gerados na fase "Modelagem e Levantamento de Requisito de Negócio". considerando as oportunidades de melhoria relacionadas aos processos de negócio atuais. essa fase relacionada de forma estreita ou até mesmo sendo parte da fase “Modelagem de Negócio”.Conforme a figura acima mostra. processos e recursos do negócio. 7. bem como seus atributos e operações. Em seguida deve ser executada a fase de "Análise e Projeto" onde o Analista de Sistema. Dessa forma. considerando a lógica de melhoria contínua dentro de um processo de desenvolvimento de sistemas iterativo e incremental. É importante observar que dentro da lógica iterativa e incremental estabelecida pelo RUP. o que faz com que estas fases possam ser definidas em uma única fase denominada de "Modelagem e Levantamento de Requisitos de Negócio". pertencente à metodologia de modelagem de processos de negócio.

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.4 e foi utilizado para descrever os demais processos listados abaixo. Conforme pode ser observado no fluxo acima. 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.3. o primeiro passo a ser realizado pelo Analista de Negócio é a definição dos objetivos da organização com um todo. esses objetivos em sub-objetivos. Para a representação desse processo. foi utilizado o modelo EPC da ferramenta ARIS Toolset17. 129 . 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. desdobrando. de forma hierárquica. mostrando as relações de dependência desde os objetivos estratégicos até os operacionais.

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

a responsabilidade de levantamento desse artefato é do Analista de Sistema. os artefatos que devem ser gerados pelo Analista de Negócio. por exemplo. pois são definidos requisitos como.Na fase de “Modelagem e Levantamento de Requisitos de Negócio”. 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. estão representados na tabela abaixo pela cor vermelha. 133 . 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. Porém.

é importante levantar o dicionário de dados18 que envolve o sistema em desenvolvimento. podendo ser realizado por diagramas como. pelo diagrama de objetivos. tamanho. produtos. FAD entre outros apresentados no capítulo 3. Processos EPC Macro-processo VAC e são ressaltados os recursos. 18 O dicionário de dados ajuda na definição dos campos de um sistema. entre outros. 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. 134 .. devem ser levados com relação ao levantamento de dados. Ex.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. considerando aspectos como tipo do campo (alfa. por exemplo. insumos. regras de negócio e objetivos associados aos processos. origem. Além disso. sua descrição. se é editável ou não. o VAC. Esse levantamento pode ser realizado Penetrar mercado asiático Controle de Produção T amanho dos estoques textualmente ou graficamente como. 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. numérico. Costumam ser explicitados textualmente. por exemplo. Esse levantamento deve seguir os princípios de modelagem definidos. deve ser sustentado por uma boa ferramenta de modelagem de processos. Estão diretamente atrelados as regras de negócio.).. Nesse momento.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. EPC.

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. 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. foi criada a tabela abaixo que exemplifica e demonstra os principais elementos de cada modelo e suas relações. caso de uso e diagrama de classes.1. 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. Cabe ressaltar que esse diagrama de classe é do tipo conceitual. Modelos de Classes – a partir dos diagramas de casos de uso e de seqüência é possível identificar as classes do sistema. Para melhor entender dentro da metodologia proposta a transição dos elementos entre os modelos EPC.6.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. 135 . Conforme observado no tópico 4. 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.2. 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. suas operações e atributos. Esses casos de uso podem ser derivados diretamente das funções dos processos de negócio conforme pode ser observado no item 5.1. VAC e EPC pertencentes à metodologia ARIS e suportados pela ferramenta ARIS Toolset.

o elemento Executor do EPC torna-se Ator do Caso de Uso. 7.Tabela 4: Comparação entre o EPC x Casos de Uso x Diagrama de Classe. pode-se extrair Descrição de Casos de Uso e dessas descrições pode-se extrair classes conceituais para o Diagrama de Classes Conceitual.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. 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. 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 . 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. Como apresentado acima. 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.

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 .

grandes e médios clientes. mostrando apenas aqueles mais relevantes. Projeto e Gerência de Sistemas (ROCHA. Além disso. Seus clientes diretos são. Neste contexto. É 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. não considerando demais modelos relacionados à modelagem dos processos de negócio. 2003) que teve como base um estudo em uma empresa do setor farmacêutico. mostrando a transição dos requisitos de negócio para os de sistemas. 8. os nomes das empresas e alguns dados foram alterados. O autor da dissertação. 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. por questões de sigilo. No segundo exemplo. 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. é importante colocar que todos os projetos foram 138 .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 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. et al.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. partindo-se da atividade de modelagem dos processos futuros da fase "Modelagem e Levantamento dos Requisitos de Negócio". em sua maioria. o exemplo considera que todos os problemas e oportunidades de melhorias já foram identificadas e levantadas. Além disso. 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. Além disso. cabe ressaltar que o projeto apenas considerou a utilização dos modelos da UML.

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

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

a Área de Engenharia). 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. foi iniciada a modelagem destes dados na ferramenta ARIS Toolset. 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. Para cada família de produtos foram identificadas e levantadas as principais plataformas. 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. Assim. de forma a acelerar sobremaneira o desenvolvimento de novos serviços/produtos na empresa WTelcom. Após a identificação dos dados para configuração de funcionalidades nas plataformas. 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. 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. detalhando esses dados em frames e campos. é mais ambicioso. campos e frames (conjunto de campos) e em seguida essas informações foram modeladas na ferramenta ARIS Toolset. realizada pelos analistas de processos da Gerência de Processos Operacionais. por exemplo. Além disso.produtos. de acordo com a metodologia adotada no escopo do projeto. no entanto. ou nos elementos de rede de uma plataforma. entre outros. Além disso. Os principais benefícios gerados com esse projeto estão listados abaixo: 141 . as telas de sistemas de aprovisionamento já implantados ajudaram no levantamento das informações. suas funcionalidades. O projeto teve como seu principal resultado o levantamento dos dados das principais plataformas de configuração levantadas para cada família de produto.

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). demais conceitos e tecnologias relacionadas à automação dos processos de negócio e definição de arquiteturas de sistemas de informação como. Redução do tempo total de desenvolvimento e operacionalização de produtos. faturamento e vendas. • • • Aumento da flexibilidade frente às variações da demanda e para atender de forma rápida soluções customizadas. por exemplo. desenvolvimento. seus dados e os caso de uso. Apoio à melhoria dos processos e desenvolvimento de sistemas de suporte à operação. os Business Process Management Systems (BPMS). implementação. entre outros. foi sugerido uma maior interação com a área de TI para definição da camada de apresentação. Na figura abaixo é possível visualizar a relação entre os processos de negócios. por exemplo. 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. Como uma das sugestões para dar continuidade ao projeto. 142 . 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. No âmbito desta atividade está incluída a integração das atividades de concepção de processos. operacionalização e manutenção de sistemas. Além disso.• • • • Formalização e padronização da modelagem de processos dentro da Área de Processos Operacionais. Maior facilidade para o gerenciamento dos processos. Melhora das interfaces processuais com respectivos fluxos de informação entre as áreas de operações.

8. bem como 143 . Fonte: O autor. Em virtude desse entroncamento. A seguir será visto um caso onde foi realizado a especificação de negócio um produto da WTelcom. chamadas podem ser originadas de telefones fixos ou públicos pertencentes à rede Pública de Telefonia. É 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).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 . este novo serviço é capaz de prover um elevado grau de qualidade no escoamento do tráfego. Essas chamadas. aumentando a taxa de ligações completadas e oferecendo descontos por volume.1. permitindo a realização de chamadas locais.doc Sistema da Plataforma RI NEC Figura 56: Elaboração de uma Especificação de Processos e Requisitos de Negócio. Portanto. PO . através do uso de códigos de autorização. Consiste no entroncamento direto da Central da WTelcom ao cliente.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.Config RI NEC. este produto deverá oferecer facilidade de acesso remoto para realização de chamadas telefônicas. Além disso.

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

O processo foi modelado utilizando o modelo EPC do ARIS e procurou as principais atividades para realizar a ativação do produto TelVip. Toda a vez que for feita uma solicitação de aprovisionamento. 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. configuração e ativação a serem executadas na área de operações. Foram definidas. a Order Entry será estornada para a Área de Mercado. mostrando apenas a parte do processo de 145 . este exemplo vai focar no detalhamento da atividade “Analisar Order Entry”. Além desse conceito. Cabe ressaltar que através da utilização dos modelos pré-definidos pelo projeto de componentização de processos foi possível modelar. Levantados os principais conceitos e regras de negócio que estavam envolvidos no negócio. O serviço pode até mesmo ser cancelado caso comprovada a inviabilidade. Caso as informações da Order Entry não estejam consistentes. foi levantado através de entrevistas com os especialistas do produto o processo de Ativação do TelVip. também de forma textual. fato que agilizou o desenvolvimento da especificação operacional e conseqüentemente a de sistemas de informação também. 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. Ao ser recebida na interface do usuário do Sistema de Suporte. Para simplificar a compreensão do caso. 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.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. interfaces de processos e a lógica de controle do processo. executores. a Order Entry deverá ser identificada com um número único. apenas as diferenças inerentes ao produto em questão. em termos de processo de negócio. levantando as principais atividades. corrigidas ou completadas. O estorno de uma Order Entry significa que as informações técnicas e operacionais deverão ser revistas.

2. para cada atividade os principais dados necessários para suas execução e as regras de negócio relacionadas. O processo pode ser parcialmente visualizado na figura abaixo. de forma textual. No caso da atividade “Analisar Order Entry” foram levantados os dados que deveriam ser analisados e validados pelo gerente de implantação como. Com a modelagem do processo de Ativação do produto foram levantados. 8. por exemplo. 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. dados do contrato.Ativação do produto que está relacionada a essa atividade. os dados cadastrais do cliente.1.1.1.1. dados técnicos do produto. entre outros.2.4 Identificação e Modelagem de Casos de Uso 146 .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. 8.

Logo. 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. 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”. É importante ressaltar que o nível de detalhamento de modelagem do Processo de Ativação. 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. 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. O SA exibe os dados referentes ao item escolhido. O ator seleciona o item da OE que vai ser analisado. permitiu fazer a relação de uma atividade para um caso de uso. 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. 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.Após o levantamento do processo de negócio e dos dados necessários para sua execução.

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

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

mostrando a hierarquia entre os objetivos do Setor de Manutenção. os processos e regras de negócio que suportarão o novo sistema.2. os requisitos funcionais e parte dos requisitos não funcionais e.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. 150 . conservação e reparos em mobiliário. Com base nessas informações foi modelado o Diagrama de Objetivos mostrado na figura abaixo. bem como a associação desses objetivos ao processo de manutenção. evitar falha de funcionamento dos equipamentos. por fim. O modelo escolhido para realizar a modelagem foi o Diagrama de Objetivos da ferramenta ARIS Toolset.1 dessa dissertação.2.8.3. o principal objetivo do Setor de Manutenção e. os casos de uso. instalações e equipamentos. Os sub-objetivos associados a esse objetivo principal seriam os de evitar interrupção na produção de medicamentos. portanto.1.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. 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. do processo de manutenção é a conservação da fábrica.1 Modelagem dos Objetivos do Negócio Conforme mencionado no caso. evitar o risco de acidentes. 8.

desde um nível mais estratégico até um nível operacional. com a modelagem do processo de manutenção. pois. somente as atividades com interfaces previstas com o sistema poderiam ser consideradas como candidatas a se tornarem casos de uso. vários cargos dentro da organização podem solicitar um serviço de manutenção e também executá-los. Logo. foi possível identificar as principais atividades. Conforme pode ser observado nas figuras abaixo. insumos. foram identificadas e diferenciadas as atividades manuais das suportadas pelo sistema. Ou seja.2.1.A associação dos objetivos do negócio. foram levantados apenas os dados de entrada e de saída da atividade “Alocar mão-de-obra”.3. o autor tomou como base as informações e os pseudo-códigos descritos no projeto. os processos de negócio passam a ser executados em função da visão e dos objetivos da organização. 8. 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. 151 . Além disso. Para realizar a modelagem do processo. facilita a transição da estratégia desejada para a realizada. Os significados dos objetos apresentados no modelo podem ser vistos no tópico 3. Com o intuito de simplificar o exemplo. pois.2 Modelagem dos Processos de Negócio De acordo com a metodologia proposta. 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.4 dessa dissertação. o próximo passo a ser executado pelo Analista de Negócio é a modelagem do processo de manutenção.

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

"Encaminhar serviço para setor responsável" e todas as demais que apresentavam interface com o sistema. "Alocar mãode-obra". 153 . 8. Possibilitar verificação do prazo de garantia de um equipamento.2. Abaixo pode ser vista a listagem dos principais requisitos levantados para o desenvolvimento do SISCOM.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. Além disso. segurança do mesmo e etc. Requisitos Funcionais Possibilitar a desativação de um determinado cliente no sistema. por exemplo. tempo de resposta do sistema. ele deve levantar em conjunto com o Analista de Sistema os requisitos não funcionais como. 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. Cadastrar equipamentos e setores separadamente. por exemplo.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. Emitir listagem de clientes em ordem alfabética.1. as atividades "Gerar OT".

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

2. Automatizar a confirmação de OTs concluídas ou OTs canceladas para os seus respectivos solicitantes. Emitir listagem de materiais em compras. Requisitos não funcionais Migrar dados atuais do Sistema Administrativo para o banco de dados do SISCOM. Tais atividades. Publicar relatórios na WEB. 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. 155 . Definir níveis de acesso permitindo a utilização de fluxos ordenados da informação. Emitir listagem de materiais de estoque com quantidade abaixo ou igual ao mínimo estabelecido. Definir design de telas intuitivo. Reduzir o tempo de resposta em consultas para no máximo 10 segundos.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 transferência das solicitações de compras criadas no sistema do Setor de Manutenção para o sistema utilizado pelo Setor de Compras. através de correio eletrônico. Automatizar a emissão de OTs programadas e preventivas. que podem ser observadas na tabela abaixo.1.Emitir listagem de movimento de entrada e saída por material. 8. são aquelas que apresentam interfaces com o sistema.

Logo.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. Nesse caso. 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. se transforma no ator do caso de uso. pode-se citar as duas primeiras atividades "Cadastrar solicitação de serviço" e "Encaminhar serviço para setor responsável". podemos encontrar uma relação um para um entre atividades e casos de uso. o Atendente da CAP. Isso vai depender do nível de detalhamento da modelagem dos processos de negócio. 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. Como exemplo. a relação pode não ser direta de uma atividade para um caso de uso. 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. Num outro exemplo. 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. "Supervisor de Manutenção". ou seja. Nesse caso. 156 . Esse exemplo foi citado para mostrar que nem sempre a relação entre atividades e casos de uso é um para um. o executor da atividade.

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. Fonte: ROCHA. 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. Esse caso de uso foi modelado a partir da lista de requisitos não funcionais. todos os passos descritos no caso de uso "Alocar mão-de-obra" sempre fazem 157 . 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. 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. No exemplo citado. por exemplo. 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". mostrando que nem todos os casos de uso podem ser derivados do processo de manutenção.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.

Descrição: Esse Caso de Uso se inicia quando o supervisor informa os dados dos executores responsáveis para execução das tarefas. foi escolhido o caso de uso "Alocar mão-de-obra" que será descrito no próximo tópico. Sistema aloca mão-de-obra para tarefa. Fluxo Alternativo – Passo 12 do Curso Típico: Supervisor não confirma os dados. Sistema solicita confirmação dos dados. Supervisor informa nome do executor. Supervisor solicita cancelamento do caso de uso “Alocar mão-de-obra” Fim do caso de uso. Pré-condição: O supervisor deve estar autenticado no sistema. Fluxo Normal de Eventos: Sistema solicita quantidade de executores. Ator: Supervisor. Já a relação de extensão tem o objetivo de representar um comportamento que eventualmente ocorre como o caso de uso "Programar Tarefa”. Caso necessário será contratada mão-de-obra externa. 158 . Sistema solicita quantidade de horas estipuladas da tarefa. Sistema solicita nome do executor. Fim do caso de uso. Para exemplificar como seria uma descrição de um caso de uso. Supervisor informa quantidade de executores. Supervisor confirma os dados.parte dos passos do caso de uso "Gerar OT". Sistema obtém e exibe matrícula do executor. Sistema exibe total de horas disponíveis no dia por executor. Supervisor informa tipo de executores. Supervisor informa quantidade de horas estipuladas da tarefa. Sistema solicita tipo de executores. 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.Finalizada as descrições dos casos de uso a próxima etapa seria a elaboração do diagrama de classes. Caso de Uso e Diagrama de Classes. Conforme pode ser visto na tabela abaixo.. 159 ... 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 . para facilitar a identificação das classes.. Fonte: O autor .

conforme pode ser observado no tópico 4.Através dessa tabela já podem ser identificadas algumas classes que irão compor o diagrama de classes como.2. torna possível a redução do tempo de implantação de novos requisitos de negócio. as principais classes do SISCOM que interagem com a atividade “Alocar mão-de-obra”.1. através do diagrama de seqüências. 8. que deve ser realizado pelo Analista de Sistema. Para exemplificar essa situação no caso do exemplo apresentado. conforme proposta por LOOS e ALLWEYER (1998) no tópico 5. 160 . independente da linguagem de implantação. é possível identificar. 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".5 Modelagem do Diagrama de Classes O diagrama de classes do projeto buscou demonstrar os principais conceitos do sistema. 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.3. Logo. portanto. 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. a figura abaixo mostra a relação entre a atividade "Alocar mão-de-obra" e as classes "Tarefa" e "Funcionário". as classes Tarefa e Mão-de-obra que estão relacionadas à atividade e ao caso de uso Alocar mão-de-obra. que a implementam. na perspectiva conceitual sendo. por exemplo.6. estando classificado.1. a associação entre as atividades e classes.2.

.* 1 Tipo Executor Codigo Nome 0.* Necessita 0..* T arefa Programada NumeroDias QuantidadeExecutores Gera O Figura 64: Diagrama de classes para elaboração do SISCOM Fonte: ROCHA...* Seto Obte Obte Material 0.. et al (2003) 161 .....1 Prioridade de Servi ço Codigo Nome 1.* 0.* Setor de M anutenção Supervisor ObterSupervisor() 1 0...* nto 0.* Ramal Criar() ObterDados() 1 Funcionario Matricula Nome Cargo ObterDados() 1 Setor de Manute 1 Cadastra Solicita Necessita 1..* Encaminha 1..* 0.* Tarefa Externa AlocarMaodeObraExterna() 1 1 T arefa Descricao DuracaoPrevista DataPrevi staInicio Criar() AlocarMaoDeObra() GerarOT () ObterDados() Programar() 0.* Roteiro 0.* Serviço Numero Descricao DataSolicitacao PerdaProducao DataPrevistaInicio Situacao Cri ar() SalvarSituacao() Cri arTarefa() GerarNumero() SalvarDataSolicitacao() ObterEquipamento() Encaminhar() 1 0.Solicitante Trabal ha 1...* Empresa Codigo Nome Aloca Sobressalente 1 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. 8. 162 . o que permite uma maior agilidade na implementação de novos requisitos de negócio. Além disso.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. a reavaliação do diagrama de classes. 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. possibilitando a associação das classes do sistema com as atividades executadas pelos processos de negócio. se caso necessário.

uma organização que conhece os seus processos tem maior potencial de resultados na integração entre suas áreas. 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. Antes disso. procura-se agregar maior valor nas atividades no que diz respeito a aumentar a satisfação do cliente. ferramentas. o foco era na estruturação funcional. resultando em retornos significativos sobre os investimentos realizados. tempo e custo e quem as realizam. Com relação ao estudo da EPN realizado foi possível chegar aos seguintes resultados: 163 . se tem a possibilidade de entender melhor a organização e a maneira como ela opera. uma mudança de paradigma. Nessas organizações. mostram os recursos utilizados. através delas. Assim. facilita uma reestruturação organizacional e a concepção e implantação de uma arquitetura integrada de sistemas. 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.1 Conclusões Nessa dissertação foi possível mostrar os principais conceitos. os produtos gerados (insumos. 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. isto é.9 CONCLUSÕES E PERSPECTIVAS DE DESENVOLVIMENTO 9. metodologias. aplicações e ganhos da Engenharia de Processos de Negócio.). O surgimento de organizações focadas nos seus processos talvez seja um marco na administração de empresas. uma empresa ao levantar e modelar seus processos evidencia os seus problemas. Os processos descrevem a seqüência de atividades realizadas pela empresa e. que provocava uma grande especialização dos colaboradores e uma visão compartimentada do funcionamento de toda organização. Deste modo. informações. etc. Portanto. entendendo quais e como são as atividades antes e depois da realizada por ele. 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. Ao descrever seus processos.

a estrutura de vistas da metodologia ARIS. ressaltando a importância da integração e do alinhamento entre a estratégia concebida para um negócio. seus processos e os sistemas que o suportam. foi dado destaque ao desdobramento para desenvolvimento de sistemas de informação. pois.Frente aos problemas acarretados por uma visão estritamente funcional. no desenvolvimento de sistemas de informação que implementam os processos de negócio. considerada pela Object Management Group (OMG) como linguagem padrão de desenvolvimento de sistemas de software. Dentre as aplicações da EPN. sendo difícil imaginar a não aplicação da TI. principalmente. 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. tendo como base as vistas da arquitetura da UML apresentada no capítulo 4. 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. 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. vistas essas que foram 164 . através de seus diagramas consegue expor e uniformizar os entendimentos na comunidade de desenvolvimento de software. Para entender melhor a relação entre a EPN e sistemas de informação. A percepção da abrangência dos principais desenvolvimentos possíveis da EPN. 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. foram apresentados os principais conceitos e modelos associados a Unified Modeling Language (UML). por exemplo. 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.

conforme observado na comparação com o EPC. utilizando alguns diagramas da UML.2000). 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. 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. Foi apresentada uma proposta de extensão da UML criada por ERIKSSON e PENKER (1999. Ao analisar o RUP. sendo necessária utilização dos mecanismos de extensão da linguagem para se criar perfis voltados para a modelagem de negócio. foi possível chegar as seguintes conclusões: 165 . Através da análise do RUP. para representar conceitos inerentes aos conceitos de processos de negócio.criadas para suportar conceitos de modelagem de sistemas de software e não de negócio. os modelos da UML ainda -não representam de forma satisfatória alguns conceitos relacionados à modelagem de negócio. Foi possível concluir que uma proposta de modelagem de negócios com os modelos da UML. Essa abordagem já se aproxima mais da modelagem de processos 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. 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. 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. Para elaborar a proposta foi necessário realizar um estudo sobre os processos de desenvolvimento de software. onde já é possível visualizar uma proposta arquitetura dividida em vistas suportadas por modelos e extensões da UML. pois. sob o ponto de vista de modelagem de negócio. principalmente. tomando como base de referência o Rational Unified Processo (RUP) como metodologia de desenvolvimento de sistemas de informação. o diagrama de atividades. podendo ser eficiente para modelar sistemas de informação mais simples.

A partir desta identificação. o que facilita. Mas. para representar processos de negócio. dentro de uma lógica de melhoria contínua. é mesma da UML onde as vistas propostas foram criadas para suportar conceitos de modelagem de sistemas de software e não de negócio.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. dificultando a compreensão do negócio como um todo. ou ainda atender de forma incorreta. 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. utiliza técnicas de modelagem de software. Como base. possibilitando uma maior integração entre a área de negócios e de sistemas. a partir destes. 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.O RUP trabalha na lógica de desenvolvimento iterativo e incremental o que minimiza os riscos de um projeto de desenvolvimento. os analistas conseguem encontrar soluções técnicas. o software propriamente dito. 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. podem ser mapeados quais são os requisitos do usuário e. A modelagem de processos de negócio identifica a maneira como o negócio deve ser executado. mais especificamente os casos de uso de negócio. a implementação de requisitos de negócio em sistemas de informação. 166 . é 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. a única arquitetura que o RUP utiliza. da qual o usuário precisa para que seja solucionado um problema ou alcançado um objetivo. Quando se inicia o desenvolvimento de software diretamente a partir do mapeamento do sistema. Diante das deficiência do RUP com relação a modelagem de negócio.

foram utilizados alguns dos modelos tradicionais da EPN e da UML. 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 . bem como as fases de Concepção e Elaboração do RUP e alguns de seus artefatos.Boa parte dos problemas tidos como clássicos no desenvolvimento de software são originados pela não realização deste estudo. Para elaborar a metodologia proposta. a transição entre os modelos tradicionais da EPN e os modelos da UML. 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. 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. Dessa forma. ou ainda porque a forma como são executados não está otimizada. Todos são beneficiados quando há realização de modelagem de processos de negócio para subsídio do desenvolvimento do software. 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. conseqüentemente. mostrando que é importante e possível construir sistemas alinhados com os objetivos estratégicos definidos. mas com base em técnicas de EPN e não em técnicas de modelagem de software. Foi possível visualizar. pois. o contínuo aumento do escopo dos sistemas. 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. permitindo identificação mais segura de que o software vai atender às suas necessidades. 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. através da descrição dos casos de uso. 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.

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. pois. ou seja. 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 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. 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. pois muitos Analistas de Negócio não possuem base conceitual e experiência prática para realizar a modelagem de casos de uso.de negócio. ao mudar uma determinada parte do processo é possível identificar com mais facilidade a parte do sistema que deve ser alterado. o autor acredita que a técnica de modelagem de casos de uso é de fácil assimilação. por vezes gera resistências no 168 . pois. 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. 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. sendo importante a experiência e conhecimento do Analista de Sistema para a criação do diagrama de classes conceitual. cabe ao Analista de Negócio saber o nível de modelagem suficiente para derivar casos de uso. As principais limitações da metodologia proposta foram: A derivação de processos de negócio para casos de uso nem sempre é direta. variando com o nível de detalhamento do processo modelado. o que. o que reduz o tempo de implementação de melhorias propostas com base nos processos de negócio.

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful