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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

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

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

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

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

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

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

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

Introdução à Bonita BPM

Introdução à Bonita BPM WHITE PAPER Introdução à Bonita BPM Como começar a usar o Bonita BPM para capturar um processo conceitual e transformá-lo em um diagrama de processo Charlotte Adams, Alexandre Bricout e Maria Picard, Bonitasoft

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

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

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

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

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

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

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

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

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Ponta Grossa 2012 ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Trabalho elaborado pelo

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

www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00

www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00 www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00 Controle de Revisões Micropagamento F2b Web Services/Web 18/04/2006 Revisão Data Descrição 00 17/04/2006 Emissão inicial. www.f2b.com.br

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

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

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

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

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Thiago Bianchi 1 Elisa Yumi Nakagawa 2 1 IBM - International Business Machines 04753-080, São Paulo, SP, Brazil tbianchi@br.ibm.com

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

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

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

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

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

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

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

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

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS Ana Carolina Freitas Teixeira¹ RESUMO O gerenciamento de projetos continua crescendo e cada

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

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

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

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

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

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

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

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

MANUAL DE PROCEDIMENTOS MPR/ASCOM-002-R00 ATIVIDADES DE ASSESSORAMENTO, COMUNICAÇÃO INTEGRADA E APOIO À GESTÃO DA ASCOM

MANUAL DE PROCEDIMENTOS MPR/ASCOM-002-R00 ATIVIDADES DE ASSESSORAMENTO, COMUNICAÇÃO INTEGRADA E APOIO À GESTÃO DA ASCOM MANUAL DE PROCEDIMENTOS MPR/ASCOM-002-R00 ATIVIDADES DE ASSESSORAMENTO, COMUNICAÇÃO INTEGRADA E APOIO À GESTÃO DA ASCOM 09/2015 PÁGINA INTENCIONALMENTE EM BRANCO 2 30 de setembro de 2015. Aprovado, Gabriela

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

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

! 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

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

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

Especialização em Arquitetura e Engenharia de Software

Especialização em Arquitetura e Engenharia de Software Especialização em Arquitetura e Engenharia de Software O curso vai propiciar que você seja um especialista para atua atuar na área de Arquitetura de Software em diferentes organizações, estando apto a:

Leia mais

Simular de Financiamento

Simular de Financiamento Simular de Financiamento Versão: PI001 1. Objetivo deste documento Este documento tem como objetivo autorizar formalmente o início de um projeto e contém informações necessárias para o entendimento do

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

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

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

Leia mais

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira 3º semestre CONCEITOS CONCEITOS Atividade Ação executada que tem por finalidade dar suporte aos objetivos da organização. Correspondem

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

AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS

AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS Manual de Instalação Tempro Software StavTISS Sumário 1. INTRODUÇÃO... 2 2. REQUISITOS DO SISTEMA... 3 3. INSTALAÇÃO... 4 4.

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

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