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

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

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

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

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

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

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

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

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

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

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

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

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

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

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

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

Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software

Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software Walter Itamar Mourão Arcadian Tecnologia S/A. Av. do Contorno 3505, sala 802 Belo Horizonte MG CEP: 30110-090

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

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Renan Sales Barros 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais (ICEN)

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

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

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

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

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

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

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

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

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

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

Sumário. Uma visão mais clara da UML

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

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

Gerenciamento de Rede Baseado em Políticas

Gerenciamento de Rede Baseado em Políticas Gerenciamento de Rede Baseado em Políticas (Policy-Based Networking) Ademir José de Carvalho Junior Recife, Fevereiro de 2007 Resumo: A complexidade das redes baseadas em IP atualmente segue crescendo

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

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

E-Commerce Master. Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM

E-Commerce Master. Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM E-Commerce Master Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM Histórico de revisões Versão Data Autor Descrição Localização 1.0 05/06/2013 Thyago Ferreira 1.0 05/06/2013 Vilmar de Sousa

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

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

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow

Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow Resumo. A fim de flexibilizar o fluxo de controle e o fluxo de dados em Sistemas Gerenciadores de Workflow (SGWf),

Leia mais

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br Desenvolvimento Web Saymon Yury C. Silva Analista de Sistemas http://www.saymonyury.com.br Vantagens Informação em qualquer hora e lugar; Rápidos resultados; Portabilidade absoluta; Manutenção facilitada

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Como Evitar os 10 Maiores Erros em Modelagem de Processos Alexandre Magno Vazquez Mello

Como Evitar os 10 Maiores Erros em Modelagem de Processos Alexandre Magno Vazquez Mello Motivação para a Modelagem/Documentação de Processo Processo, definido de forma bem direta, é como fazemos o que fazemos, isto é, o conhecimento sobre como as coisas são feitas. Esse conhecimento geralmente

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

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

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

AUTOMATIZAÇÃO DE PROCESSOS EM APLICAÇÕES DE GESTÃO DE INCIDENTES UTILIZANDO BPMN

AUTOMATIZAÇÃO DE PROCESSOS EM APLICAÇÕES DE GESTÃO DE INCIDENTES UTILIZANDO BPMN UNIVERSIDADE REGIONAL DE BLUMENAU CURSO DE SISTEMAS DE INFORMAÇÃO AUTOMATIZAÇÃO DE PROCESSOS EM APLICAÇÕES DE GESTÃO DE INCIDENTES UTILIZANDO BPMN Eduardo Leopoldino de Souza Prof. Cláudio Ratke, Orientador

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

Tópicos Especiais em Sistemas de Telecomunicações IV

Tópicos Especiais em Sistemas de Telecomunicações IV Sumário Tópicos Especiais em Sistemas de Telecomunicações IV Modelagem de Sistemas de Software Departamento de Engenharia de Telecomunicações Escola de Engenharia Universidade Federal Fluminense Setembro

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

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

Documento de Visão do Projeto

Documento de Visão do Projeto Documento de Visão do Projeto 1. Objetivo O propósito deste documento é coletar, analisar e definir as necessidades de alto-nível e características do projeto de software do Módulo Editor de Estruturas

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global Sistema de Aproveitamento de Disciplinas da Faculdade de Informática da PUCRS: uma sistemática de gerência

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

Modelagem de Casos de Uso (Parte 1)

Modelagem de Casos de Uso (Parte 1) Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS Este anexo apresenta uma visão geral das seguintes plataformas: 1. Plataforma Microsoft.NET - VB.NET e C#; 2. Plataforma JAVA; 3. Plataforma Android, ios e Windows

Leia mais

Correção de cartões de respostas utilizando análise e processamento de imagens digitais

Correção de cartões de respostas utilizando análise e processamento de imagens digitais Correção de cartões de respostas utilizando análise e processamento de imagens digitais Vantuil José de OLIVEIRA NETO¹, Caroline Julliê de Freitas RIBEIRO¹, Samuel Pereira DIAS² ¹ Tecnólogos em Análise

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

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

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

Tracker Um Framework para Rastreamento de Produtos no Processo de Produção

Tracker Um Framework para Rastreamento de Produtos no Processo de Produção Tracker Um Framework para Rastreamento de Produtos no Processo de Produção Ramiro de Souza Fernandes, Rodrigo Prestes Machado Curso de Análise e Desenvolvimento de Sistemas Faculdade de Tecnologia Senac

Leia mais

Demoiselle Framework. Palestrante: Flávio Gomes da Silva Lisboa JUN/2009

Demoiselle Framework. Palestrante: Flávio Gomes da Silva Lisboa JUN/2009 Demoiselle Framework Palestrante: Flávio Gomes da Silva Lisboa JUN/2009 Sumário Introdução Desenvolvimento de TI para Governo Elementos de Decisão Estratégia para a área de tecnologia Diretivas da Arquitetura

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

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

Definição de Processos de Workflow

Definição de Processos de Workflow Definição de Processos de Tiago Telecken Universidade Federal do Rio Grande do Sul telecken@inf.ufrgs.br Resumo Este artigo apresenta uma introdução a tecnologia de workflow informando noções básicas sobre

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

Alfresco Content Management

Alfresco Content Management Alfresco Content Management Alfresco é um sistema ECM (Enterprise Content Management) também conhecido como GED (Gestão Eletrônica de Documentos) em nosso mercado de porte corporativo para atender a empresas

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

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

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

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

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

2 Geração Dinâmica de Conteúdo e Templates de Composição

2 Geração Dinâmica de Conteúdo e Templates de Composição 2 Geração Dinâmica de Conteúdo e Templates de Composição Alguns dos aspectos mais importantes na arquitetura proposta nesta dissertação são: a geração dinâmica de conteúdo e a utilização de templates de

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Análise e Projeto Orientado a Objetos. Modelagem de Domínio

Análise e Projeto Orientado a Objetos. Modelagem de Domínio + Análise e Projeto Orientado a Objetos Modelagem de Domínio Introdução 2 n A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

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

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Treinamento BPM e BPMN Apresentação Executiva

Treinamento BPM e BPMN Apresentação Executiva Apresentação Executiva 1 O treinamento de BPM e BPMN tem como premissa capacitar o aluno a captar as atividades relativas a determinado processo da empresa, organizá-las, gerando um fluxograma de atividades/processos,

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

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

Gerenciamento de Escopo na Gestão de Projetos

Gerenciamento de Escopo na Gestão de Projetos Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior aebjr@terra.com.br MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro

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

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

Estudo de Viabilidade

Estudo de Viabilidade Universidade Federal de Pernambuco Centro de Informática Estudo de Viabilidade SorveTech (Sistema de Gerenciamento) Professora: Carla Silva Disciplina: Especificação de Requisitos e Validação de Sistemas

Leia mais

MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES

MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES BANCO INTERAMERICANO DE DESENVOLVIMENTO REPRESENTAÇÃO NO BRASIL SOLICITAÇÃO DE MANIFESTAÇÃO DE

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

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

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais