Tema: Engenharia de Software (processo de desenvolvimento de sistemas)

Tamanho: px
Começar a partir da página:

Download "Tema: Engenharia de Software (processo de desenvolvimento de sistemas)"

Transcrição

1 Título do Trabalho: Ei, Seu Sistema é um Workflow! Autor(a): Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Total de páginas: 29

2

3 Título: Ei, Seu Sistema é um Workflow! Autor: Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Resumo: O objetivo deste trabalho baseia-se na apresentação dos principais benefícios factíveis de serem alcançados por uma empresa, a partir do momento em que há a disseminação e um entendimento sólido sobre a tecnologia de Workflows. Com a posse deste entendimento, as equipes munem-se de práticas e técnicas que garantem um produto mais confiável e construído em prazos mais curtos. Embora apresente-se como uma tecnologia com amplos estudos e diversas soluções de software livre existentes no mercado, ainda há pouco direcionamento para o seu uso no Serpro. A pouca compreensão que existe internamente na empresa sobre o tema apresenta-se como o maior dificultador para identificar, documentar e implementar sistemas deste tipo. Considerando a grande extensão deste assunto, que abrange conceitos como Services Oriented Architecture (SOA), Business Process Management (BPM) e Enterprise Service Bus (ESB), que possuem como foco uma visão mais ampla, tocando mais incisivamente nas questões que envolvem o negócio macro de uma empresa, o contexto no qual o Serpro atua urge não desprezar as dificuldades encontradas por suas equipes de desenvolvimento para construírem aplicações desta natureza para seus clientes. Observou-se que o pouco conhecimento em Workflows direciona para a perda de qualidade e produtividade das equipes, uma vez que grande parte de código dos sistemas que são inerentes a esta tecnologia pode ser descartada apenas adotando um mecanismo de Workflow. Contudo, este benefício estende-se também às áreas de requisitos, análise e projeto, que tendem a se tornar mais simples, uma vez que sistemas de Workflow são propensos a se comportarem de forma similar. Este trabalho ainda apresenta um estudo de caso, dentro do próprio Serpro, exemplificando como este trabalho extra foi evitado adotando um mecanismo de código livre no desenvolvimento de um projeto para a Receita Federal do Brasil. Com este rápido estudo de caso, é possível observar os benefícios alcançados pela equipe, reduzindo a quantidade de código, aumentando a qualidade do produto e diminuindo o prazo para entrega. Concluindo, apresenta-se como o Demoiselle pode agregar funcionalidades de Workflow, permitindo que as equipes de desenvolvimento do Serpro usufruam das vantagens que esta tecnologia proporciona. Palavras-chave: Workflow. SOA. BPM. ESB. Demoiselle. Engenharia. Total de páginas: 29

4 Currículo Funcionário do Serpro desde 2006, atua na área de desenvolvimento de software desde Atuou no Serpro no projeto Sispei, sistema da Receita Federal do Brasil totalmente direcionado para Workflows. Possui a certificação Java 1.4 e está concluíndo a pósgraduação de Sistemas Distribuídos pela Universidade Federal da Bahia. Apoiador e mantenedor de diversos projetos de software livre.

5 Sumário O Incrível Mundo dos Workflows...7 Ei, Seu Sistema é um Workflow!...9 Então, qual o problema?...10 Qual o Caminho?...12 O Mapa para a Mina...12 Sistema AmoWorkflows S/A...13 Ajudando o Analista de Requisitos...15 Generalizando os Casos de Uso...15 Casos de Uso Modulares...17 Regras de Negócio por Entidade/Ação...17 Análise, Projeto e Codificação...18 Componentes...18 Utilização de Engines...19 Exemplos são Melhores que Mil Palavras...20 Demoiselle e Workflows...23 O Amanhã...24 O Fim...24 Bibliografia...26

6

7 O INCRÍVEL MUNDO DOS WORKFLOWS Embora seja considerado um tema de discussão antiga, podem ser encontradas, ainda hoje, diversas correntes divergentes quanto ao que é e quais as atribuições de um Workflow. O objetivo desta seção é esclarecer o que são Fluxos de Trabalho, quais as suas atribuições e como podem ser aplicados, tentando desmistificar este incrível, e fascinante, mundo dos Workflows. Muitos dos conceitos desta área são encontrados em nosso cotidiano. A sequência de tarefas realizadas ao levantar-se da cama até o momento de chegada ao trabalho destaca uma série de atividades executadas todos os dias por muitas pessoas: levantar, escovar os dentes, tomar banho, tomar o café da manhã, dirigir-se ao trabalho, etc. Deste exemplo, observa-se um conjunto de estados que se modificam a partir de ações. Tem-se, então, o estado dormindo, que necessita da ação acordar para que se passe para o estado escovando os dentes. Para chegar ao estado tomando café da manhã será necessário executar algumas atividades, como escovar os dentes e tomar banho. Embora possa ser considerado um exemplo simplório, é importante para clarear as ideias básicas de um Workflow. Em uma visão macro, abordando questões de negócio de uma empresa, tem-se relatórios que estão aguardando validação e que, para chegarem até o chefe do setor, devem ser analisados e, logo após, aprovados. Para aqueles formados na área de engenharia de sistemas, alguns conceitos anteriormente aprendidos em outras áreas podem surgir, como o de Máquinas de Estado. De fato, um fluxo de trabalho contém esta ideia, mas a amplia consideravelmente. Conforme a evolução das tecnologias que circundam os Workflows foram avançando, diversas características foram agregadas, muitas vezes criando termos novos que possivelmente criaram mais dificuldades para entender este tema. Para Eder e Liebhart (1996), fluxos de trabalho são Processos de Negócio que consistem de múltiplas atividades que devem ser executadas em uma sequência válida. Atividades representam qualquer unidade de trabalho, que pode ser, por exemplo, uma simples chamada de telefone. Para o objetivo deste trabalho será considerada a definição construída pela Workflow Management Coalition (WfMC), órgão criado e gerido por um grupo de empresas e outras partes interessadas neste assunto. A WfMC descreve: Workflows preocupam-se com a automação de procedimentos nos quais documentos, informações 7

8 ou tarefas são trocados entre participantes, conforme um conjunto definido de regras, com o objetivo de alcançar, ou contribuir, para uma meta global de negócios (WFMC, 2010). Considerando a definição proposta pela WfMC, pode-se esclarecer um fluxo de trabalho através de um rápido exemplo real, como um fluxo de pedidos de compra. Nele pode-se perceber a participação de entes que devem executar tarefas como, por exemplo, o técnico que deve verificar o estoque dos produtos que compõem o pedido e a aprovação financeira, realizada pelo analista financeiro. A Ilustração 1 exemplifica esta ideia. Nesta ilustração percebe-se seis estados, ou passos, que um pedido pode passar. Em cada passo deste pode existir uma ou mais tarefas associadas aos usuários do sistema. Uma vez executada uma atividade, ou tarefa, o fluxo migra de estado, utilizando para isto as transições, representadas através das setas direcionadas que interligam os passos. Ilustração 1: Exemplo de Fluxo de Trabalho. Outro termo comum nesta área, e que merece um esclarecimento, é o termo Workflow Engine ou, traduzido para nosso idioma, Mecanismo de Fluxo de Trabalho. Uma vez definido um fluxo de trabalho, cabe operacionalizá-lo e um mecanismo de workflow é o responsável por esta ação. Cabe a ele tratar uma entrada, o fluxo de trabalho descrito em uma linguagem, e gerenciar as transições entre os estados e as tarefas que cada participante possui, além da execução destas pelos seus responsáveis. As linguagens de definição de processos são estruturas formalmente organizadas que permitem aos responsáveis pela idealização de um fluxo descreverem os passos e as 8

9 tarefas que cada participante terá. Neste contexto, podemos destacar as linguagens extensible Process Definition Language (XPDL, 2010) e a Business Process Management Notation 2 (BPMN2, 2010). A primeira é mantida pela WfMC, enquanto a segunda é mantida pelo grupo BPM.org. A linguagem BPMN2 diferencia-se da XPDL não apenas na sintaxe, mas também na forma de apresentação, uma vez que ela também pode ser usada de maneira visual, permitindo a construção de fluxos de trabalho adotando elementos gráficos pré-estabelecidos. Ambas linguagens não encerram o assunto, pois diversas outras já foram sugeridas, embora muitas não tenham alcançado o êxito pretendido. Atualmente, a linguagem BPMN2 possui maior evidência, sendo adotada como linguagem padrão dos Mecanismos de Workflow mais utilizados do mercado. Finalizando, é importante diferenciar os conceitos de Workflows e BPM, pois percebe-se, nos analistas de sistemas e negócio, confusão quanto aos limites de cada um. Pretendendo não se estender neste assunto, será adotada a ideia de BPM defendida por (COOK, 2007): Worflows são a base para o BPM. Deste ponto de vista, um BPM é um Workflow com alguns enfeites. Do ponto de vista de um analista de negócios, contudo, estes adornos são tão importantes para as pessoas que desejam que seus processos de negócio sejam rodados de forma eficiente, que cabe criar um termo específico para designar isto. EI, SEU SISTEMA É UM WORKFLOW! Com base nos conceitos de Workflows já discutidos, esta seção apresenta como muitos analistas de sistemas não percebem que várias aplicações a serem desenvolvidas são Workflows e acabam perdendo a oportunidade de adotar práticas que agilizariam o desenvolvimento e ajudariam a ter um produto mais confiável. Espera-se que ao final deste seção qualquer analista de sistemas possa imediatamente afirmar, ao ouvir os requisitos ditados por seu cliente, a frase: Ei, seu sistema é um Workflow!. De fato, muitos sistemas possuem características inerentes de Workflow, porém uma quantidade bem razoável de analistas de sistemas não consegue captar este detalhe de fundamental importância. Quando o fazem, infelizmente, não adotam práticas que permitam um maior ganho de produtividade. 9

10 Então, qual o problema? Desenvolver um sistema não é uma tarefa trivial. Contudo, pode ser ainda mais conturbada quando os responsáveis por sua criação não possuem conhecimentos além daqueles referentes à sua área de atuação. Sistemas de Workflow são um exemplo prático disto. A partir das descrições do negócio de uma empresa, é simples observar que determinada aplicação pode ser modelada facilmente como um fluxo de trabalho, mas não é tão fácil para aqueles que nunca estudaram o assunto. Conscientes ou não, os analistas terminam abdicando de adotar práticas ou reusar soluções existentes que poderiam agilizar e embutir maior qualidade ao produto. Este esforço supérfluo é comum no desenvolvimento de sistemas, principalmente pela falta de cultura nesta tecnologia. Visando a exemplificar, pode-se considerar esta simples descrição inicial de um sistema, dada por um cliente fictício: Gostaria de um sistema para facilitar a publicação de notícias em meu sítio na Internet. Os repórteres enviam as notícias de suas casas e o redator revisa. Depois, eu devo publicá-las, uma a uma, evitando notícias que ferem interesses de patrocinadores. Para um analista de sistemas com bons conhecimentos em Workflows é bastante fácil identificar um fluxo de trabalho no qual notícias passam por, no mínimo, três passos antes de serem acessíveis ao usuário externo, conforme apresenta a Ilustração 2. Contudo, para o analista sem conhecimentos sólidos, este fato passa despercebido, dificultando sobremaneira o reuso e manutenção futura do sistema. Ilustração 2: Exemplo de Workflow para Publicação de Notícias. Cabe destacar, também, que sistemas como o já descrito nos parágrafos anteriores são comuns. Considerando uma empresa com as dimensões do Serpro, no qual centenas de sistemas são mantidos e desenvolvidos anualmente, pode-se compreender o esforço desnecessário aplicado na criação de sistemas de Workflow. Em um rápido levantamento, consultando as equipes de desenvolvimento de uma das regionais, constatou-se a 10

11 existência de, no mínimo, cinco sistemas que poderiam ser criados com práticas específicas. Sistema (Linguagem) Requisitos Projeto Engine A (Java) Sim Sim OSWorkflow B (ASP) Não Não Não Utilizou C (PHP) Não Não Galáxia D (Java) Não Não Não Utilizou E(ASP) Não Não Não Utilizou Tabela 1: Lista de Sistemas Regional Salvador que poderiam usar práticas de Workflow. A Tabela 1 apresenta estes sistemas, usando nomes ficíticos. Este levantamento foi feito em agosto de 2010 e demonstra como apenas um sistema adotou práticas na área de engenharia de requisitos, análise e projeto, além de uma engine. Três foram totalmente desenvolvidos sem qualquer tipo de prática que visasse alavancar a produtividade da equipe. Um deles adotou apenas um engine. Um fato comum é a construção quase completa de uma engine própria, contendo código específico da aplicação entrelaçado com o gerenciamento do fluxo de trabalho. Adotando os termos comuns na área de desenvolvimento de aplicações, pode-se dizer que o código encontra-se com centenas de comandos if e switch totalmente desnecessários, que visam a apenas controlar em qual direção o fluxo deve prosseguir. Obviamente, uma simples engine eliminaria todo este esforço. A Listagem 1 exemplifica um cenário como este. public class SistemaSemEngineDeWorkflow { public void aprovardocumento(documento documento) throws Exception { if (! documento.getsituacao().equals("situacao_aaprovar") ) { throw new Exception("Situação Incorreta!"); } else { // Checar se o usuário pode executar tal tarefa... if ( usuario.getnome().equals("usuario1") ) { documento.setsitucao("situacao_aprovado"); } else { throw new Exception("Usuário Não Pode executar tal ação!"); } } } } Listagem 1: Código Fictício de um Fluxo de Trablaho sem utilizar Engines. 11

12 Este código Java (JAVA, 2010) fictício demonstra a utilização dispensável de instruções de controle de fluxo. Todo ele pode, e deve, ser executado por um mecanismo de fluxo de trabalho, que abstraia todas estas informações, permitindo ao programador focar-se apenas nas regras que são específicas para a aplicação em construção. Embora já haja forte ganho adotando apenas uma engine, benefícios ainda maiores podem ser obtidos usando práticas também em algumas disciplinas da engenharia de software. Comumente sistemas de Workflow são complexos e a engenharia tende a ocupar um tempo considerável no desenvolvimento do sistema. Os ganhos são perceptíveis não apenas na questão do tempo economizado, mas também na robustez do produto. As engines disponíveis no mercado já foram validadas por dezenas de outros projetos. Práticas e padrões na área de engenharia também garantem um produto mais confiável, pois estas podem ser constantemente evoluídas e validadas por diversas equipes. As etapas de elicitação de requisitos, análise e projeto são aquelas que mais ganham com a utilização destas práticas. Qual o Caminho? A garantia de um bom produto ao término do desenvolvimento de um sistema de Workflow depende fortemente dos meios adotados para desenvolvê-lo. Esta seção descreve poucas e simples práticas que, em tese, se aplicadas no desenvolvimento de sistemas deste tipo, tendem a dar maiores ganhos para as equipes. Destaca-se que nenhum estudo aprofundado foi realizado. Todo conhecimento aqui descrito foi adquirido através da criação de um sistema real e de estudos teóricos nesta área. Estas práticas ainda devem ser melhoradas e avaliadas no desenvolvimento de sistemas deste tipo, visando a validá-las e estendê-las. Também é importante destacar que se tratam apenas de práticas e não um roteiro completo e fechado de passos a serem seguidos por qualquer equipe. O Mapa para a Mina Cada tipo de sistema possui características específicas que podem ser usadas para facilitar sua classificação. Em Workflows o cenário não é diferente. Dada uma descrição de um cliente, o analista pode verificar a existência de alguns termos que definem facilmente sua classificação como um sistema de fluxo de trabalho. Provavelmente, o cliente do produto não dirá imediatamente estes termos, mas o analista pode induzi-lo a isto. Entretanto, caso o cliente relate diretamente os termos ação, atividade, tarefa, passo, 12

13 situação e estado, há fortes indícios que o sistema a ser desenvolvido é um Workflow. Também deve-se ter atenção especial a uma possível sequência de ações que o usuário possa relatar, como fulano deve escrever o relatório e enviar para o seu chefe olhar. Há uma possibilidade, neste caso, de que se esteja falando em uma entidade relatório que possui dois estados. Sistemas de Workflow sempre possuem esta característica: pessoas ou sistemas devem executar algo em alguma entidade, normalmente um documento. Para entender como um sistema pode interagir com um fluxo, basta imaginar uma administradora de cartão de crédito fornecendo um retorno para o fluxo, indicando que o cartão do cliente tem crédito. Neste caso, um pedido pode passar do estado Aguardando Pagamento para Pago, sem interferência humana direta. Finalizando, a indicação é estar atento não apenas a termos específicos, mas também a entidades que dependem de pessoas para executar alguma ação, como enviar para o chefe analisar. Sistema AmoWorkflows S/A Para ilustrar estas práticas, consideraremos uma descrição de um sistema fictício. Tratase de uma aplicação que contém apenas dois documentos: um Relatório Diário e um Relatório Especial. O primeiro é um documento que é gerado diariamente por analistas da empresa AmoWorkflows S/A. O segundo é um relatório gerado ao final do mês pelos chefes de setor. O cliente deste sistema descreve-o da seguinte forma para o analista de sistemas: Preciso de um sistema que gerencie dois documentos de minha empresa. Um documento chamado Relatório Diário, que é criado pelos analistas todos os dias e que depois são enviados para revisão da sua chefia imediata. Após revisar, o Relatório Diário deve ser enviado para a Aprovação da chefia do setor. Já o segundo documento é um Relatório Especial, criado pelas chefias imediatas mensalmente e enviado para o Parecer do chefe do setor. Logo após isto, o chefe do setor envia para a aprovação do gerente da empresa. Esta etapa de aprovação é idêntica à aprovação do Relatório Diário. Nenhum relatório pode ser aprovado caso o usuário não tenha informado seu detalhamento. Todo relatório também deve ter preenchida automaticamente a data de aprovação. Finalmente, todos os relatórios são classificados como público ou restrito e ainda há o envio de s para as pessoas responsáveis em executar cada tarefa. Desta descrição, pode-se encontrar facilmente alguns casos de uso, sendo eles: 13

14 Relatório Diário Manter Relatório Diário; Enviar Relatório Diário para Revisão; Revisar Relatório Diário; Rejeitar Relatório Diário; Enviar Relatório Diário para Aprovação; Aprovar Relatório Diário; Reprovar Relatório Diário. Relatório Especial Manter Relatório Especial; Enviar Relatório Especial para Parecer; Dar Parecer no Relatório Especial; Enviar Relatório Especial para Aprovação; Aprovar Relatório Especial; Reprovar Relatório Especial. Modelando este sistema com os conceitos de Workflow, teremos estados, tarefas e transições entre estes estados. A Ilustração 3 apresenta a forma gráfica que representa o fluxo de trabalho para o documento Relatório Diário. Ilustração 3: Representação Gráfica do Fluxo do Relatório Diário. 14

15 A Ilustração 4 apresenta, utilizando a mesma notação gráfica do Relatório Diário, a representação do fluxo de trabalho do Relatório Especial. Ilustração 4: Representação Gráfica do Fluxo do Relatório Especial. Ajudando o Analista de Requisitos Deve-se considerar a área de requisitos inicialmente, pois trata-se da primeira etapa da construção de todo sistema. Aqui são apresentadas práticas que visam a construir casos de uso mais genéricos e o principal ganho é na produtividade. Aqui, nenhuma técnica de elicitação nova foi criada, ao contrário, algumas foram apenas mais evidenciadas, pois trazem ganhos para os sistemas de Workflow. Serão apresentadas apenas três práticas consideradas mais importantes. Generalizando os Casos de Uso Generalização é um conceito bastante comum na engenharia de software, principalmente na fase de construção de código. Atribui-se a ela muitos ganhos, pois partes comuns são agrupadas em uma única entidade, evitando a repetição. Em requisitos, no entanto, vê-se pouco o seu uso. Tende-se a construir diversos casos de uso, um para cada situação descrita pelo cliente, sem analisar friamente se existem casos de uso que podem ser generalizados. Isto é importante principalmente em sistemas de Workflows, pois é comum ocorrer a repetição de atividades em diversas instâncias de fluxos diferentes. Conforme o exemplo apresentado nesta seção, pode-se perceber que os dois documentos transitam entre 15

16 estados diferentes, mas possuem tarefas parecidas, ou até mesmo iguais. Ambos relatórios necessitam de aprovação e geraram dois ECUs chamados, respectivamente, Aprovar Relatório Especial e Aprovar Relatório Diário. Neste contexto, a melhor prática para esta situação consiste em tentar generalizar em um único ECU o comportamento geral da atividade Aprovar. Nome do Caso de Uso Aprovar Relatório Diário e Relatório Especial Objetivo Aprovar os documentos Relatório Diário e Relatório Especial. Atores Analista, Chefe de Setor, Chefia Imediata Pré-condições O documento a ser aprovado deve se encontrar na situação A Aprovar. Fluxo Principal P1. Solicitar Aprovação Na tela de edição do documento, o Ator opta por Aprovar o documento. P2. Solicitar Confirmação O sistema exibe mensagem solicitando confirmação da aprovação. P3. Confirmar Aprovação O Ator confirma a aprovação. P4. Gravar Dados P4.1. Inclusão do Caso de Uso Validar Campos de Formulário P4.2. O sistema grava os dados e altera a situação do documento para Aprovado. P4.3. O sistema numera o documento. P4.4. O sistema grava o histórico conforme LEL. P5. Enviar Fluxos Alternativos A1. Aprovar Relatório Diário Se no passo P4, o documento for do tipo Relatório Diário: A1.1. O sistema envia para a Chefia Imediata. A1.2. O fluxo retorna ao passo P4.2. A2. Aprovar Relatório Especial Se no passo P4, o documento for do tipo Relatório Especial: A2.1. O sistema envia para todos funcionários do setor. A2.2. O fluxo retorna ao passo P4.2. Tabela 2: Definição do ECU de Aprovação. A Tabela 2 demonstra, de forma bastante resumida, como o ECU de aprovação pode ser 16

17 idealizado com esta ideia. Observa-se que as questões específicas para cada documento podem ser referenciadas na seção de fluxos alternativos, evitando a criação de dois ECUs, uma vez que seus fluxos principais são iguais, mudando apenas questões simples de regra de negócio. Embora possa parecer uma prática bastante simples e seus ganhos contestáveis, considerando sistemas com mais de dez documentos e que possuem semelhanças em suas atividades, esta prática tende a diminuir consideravelmente o número de casos de uso. De fato, para sistemas pequenos, talvez não haja ganhos visíveis. Mas, neste caso, cabe também avaliar se a tecnologia de Workflows é realmente necessária para criá-lo. Casos de Uso Modulares Embora a ideia de modularizar alguns tipos de casos de uso possa parecer idêntica à ideia de generalização, existem diferenças e tratam-se de práticas complementares. Existem outros padrões também comuns em sistema de fluxo de trabalho, como o envio de correios eletrônico ou a atribuição de papeis de forma dinâmica. Neste caso, pode-se criar ECUs específicos para estes padrões comportamentais, apenas referenciado-os quando necessário nos casos de uso mais específicos. Por exemplo, o ECU Aprovar Relatório Especial pode referenciar diretamente estes dois ECUs citados. Regras de Negócio por Entidade/Ação O documento de regras de negócio não possui um padrão para ser criado, contendo os tópicos necessários e o formato do texto. Cabe ao analista definir a melhor forma junto ao seu cliente. Em um sistema de Workflow, entretanto, algumas características levam a considerar a possibilidade de se adotar um padrão comum. Todo fluxo de trabalho possui ações a serem executadas, sejam por humanos ou por uma máquina. Também possuem entidades que sofrem estas ações. Por exemplo, o documento Relatório Diário sofre a ação Aprovar. Em um sistema de notícias, uma Notícia sofre a ação de Revisão, uma passagem sofre a ação de Aprovação em um sistema de reserva de passagens. 17

18 1. Relatório Diário 1. Enviar para Aprovação Descrever as regras de negócio desta ação. 2. Aprovar Descrevar as regras de negócio desta ação. Tabela 3: Documento de Regras de Negócio. Assim, é indicado que as regras de negócio do sistema venham a ter dois níveis de divisão. A primeira, por entidade que sofre a ação, como o Relatório Diário. A segunda, por ação. A Tabela 3 ilustra simplificadamente esta ideia. Esta ação reforça a qualidade do artefato gerado. Análise, Projeto e Codificação As etapas de análise e projeto beneficiam-se de práticas bastante difundidas na área. A principal delas diz respeito à componentização. Já a etapa de codificação beneficia-se basicamente na utilização de uma engine, além das práticas comuns e bastante difundidas de programação. Os ganhos de uma área beneficiam diretamente a outra, portanto, esta seção discutirá as técnicas independente de área da engenharia. Aqui, observa-se um forte ganho na robustez do produto, adotando soluções consolidadas de mercado e práticas reconhecidas. Componentes A ideia de criar sistemas componentizados é antiga, embora pouco praticada. Os teóricos na área afirmam a necessidade de se modularizar, visando dividir o problema em partes mais compreensíveis e de fácil manutenção. Na área de Workflows a componentização assume papel de fundamental importância tanto na programação, como na definição da arquitetura. No sistema sugerido nesta seção, pode-se verificar alguns requisitos pedidos pelo cliente, como o envio de correios eletrônicos, documentos que são classificados entre público e restrito, validados, complementados com informações extras e, finalmente, tem seus dados persistidos em um banco de dados. Analistas experientes materializam estes requisitos em alguns componentes, como: Componente de Validação, Componente de Complementação, Componente de Classificação, Componente de Persistência e 18

19 Componente de Envio de Correio Eletrônico. Todos podem agir de forma independente e podem ter seu comportamento definido de diversas formas, como em arquivos no formato extensible Markup Language (XML, 2010) ou em através de código na linguagem no qual o sistema foi concebido. A prática de componentizar comportamentos gerais facilita sobremaneira a realização de casos de uso que adotam diagramas de sequência. Ilustração 5: Diagrama de Sequência Simplificado. A Ilustração 5 apresenta um diagrama de sequência bastante simplificado de uma possível realização de caso de uso, como a aprovação dos Relatórios. Observa-se que todos os documentos poderão ter diagramas de sequência parecidos com este, mudando apenas a ordem de chamada dos componentes. Assim, é possível agrupar diagramas de sequência em comum. Por exemplo, basta apenas a criação de um diagrama de sequencia para todos os documentos que possuem a necessidade de Aprovação, pois a sequência de componentes e a forma como são chamados apresenta-se sempre a mesma. Para a criação dos componentes, é indicado ao analista verificar comportamentos em comum a muitas entidades. Como exemplo, caso dois ou três documentos tenham necessidade de classificação, cabe criar um componente específico para isto. Utilização de Engines Quanto à programação do sistema é fortemente indicado que uma engine de Workflow seja adotada. Isto evitará o problema já destacado, no qual código de negócio apresentase entrelaçado com código para o controle do fluxo de trabalho. Uma engine abstrai todos 19

20 estes aspectos, controlando o fluxo e a atribuição de tarefas para os usuários. Um estudo deve ser realizado visando a detectar aquela que melhor se encaixa ao projeto em criação. Deve-se considerar as características da engine, as facilidades que ela provê, se segue padrões abertos e amplamente difundidos e, preferencialmente, se é código aberto. Há uma gama enorme de mecanismos deste tipo disponibilizados pelos comunidades de código aberto e este fato deve ser aproveitado. No momento de escolha da engine, a equipe pode usar como guia os seguintes aspectos: 1. Licença Livre; 2. Ampla documentação, contendo JavaDoc; 3. Adota como linguagem de definição de processos a BPMN2; 4. Possuir ferramenta gráfica para criação de processos; 5. Comunidade ativa; 6. Facilitar a criação de componentes para acoplamento à engine; 7. Integração com diretórios de usuário, como LDAP. Esta lista não esgota o assunto e, portanto, a depender do projeto, novos aspectos devem ser levantados e agregados. Usar uma engine de mercado reforça o reuso de soluções abertas e já consolidadas no mercado, agregando maior confiabilidade ao produto final, além de um grande ganho de produtividade. EXEMPLOS SÃO MELHORES QUE MIL PALAVRAS Esta seção tem como objetivo apresentar um estudo de caso interno ao Serpro, no qual a equipe de desenvolvimento responsável pelo sistema adotou as práticas citadas na seção anterior para a modelagem e programação de um aplicativo com características de Workflow. Trata-se de um sistema criado para a Receita Federal do Brasil. Devido ao caráter altamente sigiloso do sistema, o cliente não permitiu que documentos reais do sistema fossem utilizados neste trabalho. Portanto, serão realizadas substituições gráficas e documentais, embora os exemplos apresentados ainda estejam refletindo o sistema real. O objetivo deste sistema, de forma bastante resumida, baseia-se no gerenciamento dos 20

21 documentos que permeiam o processo de investigação da Receita Federal do Brasil. O sistema foi idealizado para ser executado em um ambiente Java e acessado através de navegadores web. O cerne deste sistema baseia-se nos trâmites de mais de vinte (20) documentos, cada qual com suas ações específicas. Cada documento possui, em média, cinco ações que podem ser executadas por pessoas. Neste cenário, tem-se aproximadamente cerca de cem (100) ações diferentes em todo o sistema. Considerando a própria complexidade do sistema, mas também a necessidade em concluir a sua confecção dentro do prazo, a equipe realizou um estudo inicial, no qual o objetivo foi identificar um Motor de Workflow que fosse capaz de dar suporte à aplicação. A engine escolhida foi a OSWorkflow (OSWORKFLOW, 2010) da empresa OpenSymphony. Uma vez definido o software, necessitou-se identificar a melhor forma possível para elicitar os requisitos, assim como para a realização de casos de uso, conforme determinado pela versão vigente do Processo de Desenvolvimento de Software do Serpro (PSDS, 2010), chegando às práticas já descritas na seção anterior. Esta etapa demonstrou-se de extrema importância, uma vez que o sistema apresentava cerca de cento e noventa (190) casos de uso, além de um documento de Regras de Negócio que alcançava cerca de duzentas (200) páginas. Neste contexto, havia uma necessidade urgente de adotar um padrão, ou prática, que visasse agilizar a etapa de elicitação de requisitos, sem comprometer a qualidade dos documentos gerados por esta área da engenharia de software. Notou-se que era possível generalizar muitas ações realizadas nos documentos e, portanto, foram criados ECUs genéricos e modulares. A Ilustração 6 apresenta a quantidade total de ECUs necessários caso esta prática não fosse adotada, em contrapartida com a adoção desta prática. 21

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantação

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta

Leia mais

IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR

IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR Jeferson J. S. Boesing 1 ; Manassés Ribeiro 2 1.Aluno do Curso

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

SOA 2.0 ou Event-Driven SOA

SOA 2.0 ou Event-Driven SOA SOA SOA 2.0 ou Event-Driven SOA 1 Introdução Recentemente, a Oracle anuciou o termo SOA 2.0. E já deu para imaginar a repercussão que isto teve. Estamos em um momento onde SOA (Service-Oriented Architecture),

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da 6 Conclusões No âmbito do framework teórico da Engenharia Semiótica, este trabalho faz parte de um esforço conjunto para desenvolver ferramentas epistêmicas que apóiem a reflexão do designer durante o

Leia mais

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 1 INTRODUÇÃO A Business Process Modeling Notation (BPMN), ou Notação de Modelagem de Processos de Negócio, é um conjunto de

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (Business Process. George Valença gavs@cin.ufpe.br BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de

Leia mais

Casos de Uso. Prof. Clayton Vieira Fraga Filho site: www.claytonfraga.pro.br e-mail: claytonfraga@gmail.com ENG10015 Engenharia de Software

Casos de Uso. Prof. Clayton Vieira Fraga Filho site: www.claytonfraga.pro.br e-mail: claytonfraga@gmail.com ENG10015 Engenharia de Software Prof. Clayton Vieira Fraga Filho site: www.claytonfraga.pro.br e-mail: claytonfraga@gmail.com ENG10015 Engenharia de Software Um caso de uso descreve o que seu sistema faz para atingir determinado objetivo

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge. Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009

Leia mais

BPM Definições e Contexto Prática Aula 1

BPM Definições e Contexto Prática Aula 1 BPM Definições e Contexto Prática Aula 1 BP Business Process Algumas definições sobre o que é Processos de Negócio (BP) Um processo é um fluxo coordenado e padronizado de atividades executadas por pessoas

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

5 Exemplo de aplicação

5 Exemplo de aplicação 111 5 Exemplo de aplicação Este capítulo apresenta um exemplo de uso da linguagem proposta como forma de validação. Através da implementação da linguagem utilizando o potencial de extensão da ferramenta

Leia mais

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

SAPENS - Sistema Automático de Páginas de Ensino

SAPENS - Sistema Automático de Páginas de Ensino SAPENS - Sistema Automático de Páginas de Ensino Eduardo Kokubo kokubo@inf.univali.br Fabiane Barreto Vavassori, MSc fabiane@inf.univali.br Universidade do Vale do Itajaí - UNIVALI Centro de Ensino Superior

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação O Valor da TI Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação 2010 Bridge Consulting

Leia mais

Software de Compras. Manual de treinamento para usuários do OutBuyCenter

Software de Compras. Manual de treinamento para usuários do OutBuyCenter Software de Compras Manual de treinamento para usuários do OutBuyCenter OutBuyCenter Software para o gerenciamento de compras integradas (eprocurement e supply chain), objetiva a rápida tramitação de compras

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas Instituto de Educação Tecnológica Pós-graduação Gestão de Projetos Aperfeiçoamento/GPPP1301 T132 09 de outubro de 2013 Um passo inicial para aplicação do gerenciamento de s em pequenas empresas Heinrich

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

Curso de Licenciatura em Informática

Curso de Licenciatura em Informática Curso de Licenciatura em Informática Disciplina: Análise e Projeto de Sistemas Professor: Rafael Vargas Mesquita EXERCÍCIOS SOBRE MODELAGEM DE CASOS DE USO Exercício 1: construa um Diagrama de Casos de

Leia mais

Sumário. Apresentação O que é o Centro de Gerenciamento de Serviços (CGS) NTI? Terminologia Status do seu chamado Utilização do Portal Web

Sumário. Apresentação O que é o Centro de Gerenciamento de Serviços (CGS) NTI? Terminologia Status do seu chamado Utilização do Portal Web Sumário Apresentação O que é o Centro de Gerenciamento de Serviços (CGS) NTI? Terminologia Status do seu chamado Utilização do Portal Web Fazendo Login no Sistema Tela inicial do Portal WEB Criando um

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Adm. Vinicius Braga admviniciusbraga@gmail.com Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Objetivos Contextualização Conceitos Boas práticas de modelagem Elementos do BPMN Tipos

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma: 1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que

Leia mais

Manual do Usuário. Sistema/Ferramenta: Spider-ACQ. Versão do Sistema/Ferramenta: 1.0. www.spider.ufpa.br

Manual do Usuário. Sistema/Ferramenta: Spider-ACQ. Versão do Sistema/Ferramenta: 1.0. www.spider.ufpa.br Manual do Usuário Sistema/Ferramenta: Spider-ACQ Versão do Sistema/Ferramenta: 1.0 www.spider.ufpa.br Histórico de Revisões Data Versão Descrição Autor 27/05/2011 1.0 Criação da seção de instalação/configuração

Leia mais

Sistemas de Produtividade

Sistemas de Produtividade Sistemas de Produtividade Os Sistemas de Produtividade que apresentaremos em seguida são soluções completas e podem funcionar interligadas ou não no. Elas recebem dados dos aplicativos de produtividade,

Leia mais

Guia de Especificação de Caso de Uso Metodologia CELEPAR

Guia de Especificação de Caso de Uso Metodologia CELEPAR Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007

Leia mais

Cláudia Araújo Coordenadora Diego Macêdo Programador Marcelo Rodrigues Suporte

Cláudia Araújo Coordenadora Diego Macêdo Programador Marcelo Rodrigues Suporte BCON Sistema de Controle de Vendas e Estoque Declaração de escopo Versão 1.0 Histórico de Revisão Elaborado por: Filipe de Almeida do Amaral Versão 1.0 Aprovado por: Marcelo Persegona 22/03/2011 Time da

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Gerenciamento de Requisitos Gerenciamento de Requisitos

Gerenciamento de Requisitos Gerenciamento de Requisitos Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso

Leia mais

Unidade 4: Contextualização de Objetos de Aprendizagem

Unidade 4: Contextualização de Objetos de Aprendizagem Coordenação: Juliana Cristina Braga Autoria: Rita Ponchio Você aprendeu na unidade anterior a importância da adoção de uma metodologia para a construção de OA., e também uma descrição geral da metodologia

Leia mais

Manual do usuário - Service Desk SDM - COPASA. Service Desk

Manual do usuário - Service Desk SDM - COPASA. Service Desk Manual do usuário - Service Desk SDM - COPASA Service Desk Sumário Apresentação O que é o Service Desk? Terminologia Status do seu chamado Utilização do Portal Web Fazendo Login no Sistema Tela inicial

Leia mais

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2 Modelo de domínio Introdução! 1 Modelos de Domínio! 1 Identificação de classes conceituais! 2 Estratégia para identificar classes conceituais! 2 Passos para a elaboração do modelo de domínio! 2 Passo 1

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES

FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES LEADWORK TECNOLOGIA E TREINAMENTO FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES Flexibilidade Acesso via Client Notes, Web e Mobile. Com o framework de desenvolvimento as soluções podem ser oferecidas com acesso

Leia mais

Manual SAGe Versão 1.2 (a partir da versão 12.08.01)

Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

UNIVERSIDADE PAULISTA

UNIVERSIDADE PAULISTA UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA Projeto Integrado Multidisciplinar III e IV Marketing Manual de orientações - PIM Curso Superior de Tecnologia em Marketing. 1. Introdução Os Projetos

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

3 Arquitetura do Sistema

3 Arquitetura do Sistema 3 Arquitetura do Sistema Este capítulo irá descrever a arquitetura geral do sistema, justificando as decisões de implementação tomadas. Na primeira seção iremos considerar um conjunto de nós interagindo

Leia mais

CIGAM SOFTWARE CORPORATIVA LTDA.

CIGAM SOFTWARE CORPORATIVA LTDA. CIGAM SOFTWARE CORPORATIVA LTDA. Raquel Engeroff Neusa Cristina Schnorenberger Novo Hamburgo RS Vídeo Institucional Estratégia Visão Missão Ser uma das 5 maiores empresas de software de gestão empresarial

Leia mais

Histórico da Revisão. Data Versão Descrição Autor

Histórico da Revisão. Data Versão Descrição Autor Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não

Leia mais

ERP: Pacote Pronto versus Solução in house

ERP: Pacote Pronto versus Solução in house ERP: Pacote Pronto versus Solução in house Introdução Com a disseminação da utilidade e dos ganhos em se informatizar e integrar os diversos departamentos de uma empresa com o uso de um ERP, algumas empresas

Leia mais

Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática

Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática Rene Baltazar Introdução Serão abordados, neste trabalho, significados e características de Professor Pesquisador e as conseqüências,

Leia mais

FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES

FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES LEADWORK TECNOLOGIA E TREINAMENTO FRAMEWORK DE DESENVOLVIMENTO LOTUS NOTES Flexibilidade Acesso via Client Notes, via Web e via Mobile. Nossas soluções podem ser oferecidas com acesso via Client Notes,

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

Título: Controle de Estoque (componente de especificação)

Título: Controle de Estoque (componente de especificação) Título: Controle de Estoque (componente de especificação) Palavras-chave: estoque, inventário, controle Autoria e data: Marcelo Pessôa 02 de junho de 2014 Versão: 1.0 Tecnologia: Independe de tecnologia

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

15 Computador, projeto e manufatura

15 Computador, projeto e manufatura A U A UL LA Computador, projeto e manufatura Um problema Depois de pronto o desenho de uma peça ou objeto, de que maneira ele é utilizado na fabricação? Parte da resposta está na Aula 2, que aborda as

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas Criação de uma Serviço de Geração de Relatórios Goiânia 12/2011 Versionamento 12/12/2011 Hugo Marciano... 1.0

Leia mais

UNIVERSIDADE PAULISTA

UNIVERSIDADE PAULISTA UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA Projeto Integrado Multidisciplinar III e IV Recursos Humanos Manual de orientações - PIM Curso Superior de Tecnologia em Gestão de Recursos Humanos 1.

Leia mais

Histórico de Revisão Data Versão Descrição Autor

Histórico de Revisão Data Versão Descrição Autor H6Projetos Documento de Requisitos Versão 1.3 Histórico de Revisão Data Versão Descrição Autor 05/09/2013 1.0 Preenchimento do Capítulo 2 Requisitos Funcionais Evilson Montenegro 26/09/2013 1.1 Preenchimento

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

Engenharia de Requisitos- como Previnir e Reduzir Riscos Engenharia de Requisitos- como Previnir e Reduzir Riscos Natasha de Souza Arruda natasha.arruda@ig.com.br FGS Resumo:Engenharia de Requisitos é um dos processos fundamentais para o desenvolvimento de software.

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais