UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE DOCUMENTOS ELETRÔNICOS DANIEL MARQUES DE REZENDE ROGERIO RIBEIRO DE SOUZA FILHO Novembro 2008 2 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE DOCUMENTOS ELETRÔNICOS Trabalho de Trabalho de Conclusão de Curso apresentado por Daniel Marques de Rezende e Rogério Ribeiro de Souza Filho à Universidade Católica de Goiás, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação, aprovado em 26/11/2008, pela Banca Examinadora: Professor Joriver, UCG – Orientador Novembro 2008 SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE DOCUMENTOS ELETRÔNICOS DANIEL MARQUES DE REZENDE ROGERIO RIBEIRO DE SOUZA FILHO Trabalho de Conclusão de Curso apresentado por Daniel Marques de Rezende e Rogério Ribeiro de Souza Filho à Universidade Católica de Goiás, como parte dos requisitos para obtenção do título de Bacharel em Engenharia de Computação. _________________________ Professor Joriver Canedo, MSc. Orientador _________________________________ Professor Jeová Martins Ribeiro. Coordenador de Trabalho de Conclusão de Curso à Deus pela minha vida e oportunidades. Aos nossos familiarese amigos. “O senhor ... Mire e veja que o mais importante e bonito do mundo é isto, que as pessoas não estão sempre iguais, não foram terminadas, mas que elas vão sempre mudando. Afinam ou desafinam – verdade maior. É o que a vida me ensinou. Isto me alegra, montão.” Guimarães Rosa RESUMO Apresenta-se os conceitos básicos da gerência eletrônica de documentos (GED) e conceituação acerca dos processos, mais conhecidos, utilizados na engenharia de software. Com base nos conhecimentos adquiridos acerca do processo de desenvolvimento espiral, foram apresentadas as diversas fases necessárias para o desenvolvimento de um sistema básico de gerenciamento eletrônico de documentos e um modelo de banco de dados para armazenar tais documentos. Apresenta-se também uma solução para possibilitar ao usuário a criação de modelos de documentos, conforme as necessidades da empresa que venha adquirir o sistema. Foi utilizada a linguagem de programação Visual Basic .NET[5] para a implementação do sistema, por ser uma linguagem orientada a objetos bastante difundida no meio comercial, e a ferramenta case Jude Community como apoio à especificação dos diagramas de casos de uso, de seqüência e de classes. Palavras-Chave: Gerenciamento Eletrônico de Documentos, Desenvolvimento Espiral, Desenvolvimento orientado a objeto. ABSTRACT It presents the basic concepts of management of electronic documents (GED) and conceptualization about the processes, better known, used in software engineering. Based on the knowledge gained about the process of development spiral, was presented the various stages needed for the development of a basic system for managing electronic documents and a sample database to store such documents. It also presents a solution to enable the user to create models of documents, according to the needs of the company which will acquire the system. We used the programming language Visual Basic. NET [5] for the implementation of the system, because it is an object oriented language to be widespread in the commercial, and the tool case Jude Community to support the specification diagrams of use cases of sequence and classes. Key Words: Management of Electronic Documents, Spiral Development, object oriented Development. SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE DOCUMENTOS ELETRÔNICOS SUMÁRIO LISTA DE FIGURAS ...................................................................................................... x LISTA DE ABREVIATURAS xii ...................................................................................... 1. INTRODUÇÃO 2. ESTUDOS BIBLIOGRÁFICOS 2.1. Processos de software 2.1.1. 2.1.2. 2.1.3. 2.2. ..................................................................................................... ............................................................................. 3 ................................................................................ 3 Modelos de processos de software ............................................... 3 .................................................. 4 2.1.1.1. O modelo em cascata 2.1.1.2. Desenvolvimento evolucionário 2.1.1.3. Engenharia de software baseada em componentes ................................ 5 ..... 6 .................................................................... 7 2.1.2.1. Entrega incremental ..................................................... 8 2.1.2.2. Desenvolvimento em espiral 9 Interação de processo Atividades de processo de software ...................................... ............................................ 11 ......................................... 11 ................................... 11 2.1.3.1. Especificação de software 2.1.3.2. Desenvolvimento de software 2.1.3.3. Validação de software ............................................... 13 2.1.3.4. Evolução do software .................................................. 14 ........................................................... 15 ................................................................. 16 Processo de engenharia de requisitos 2.2.1. 1 Requisitos de software 2.2.1.1. Requisitos funcionais e não funcionais ....................... 17 2.2.1.1.1. Requisitos funcionais ............................. 17 2.2.1.1.2. Requisitos não funcionais ....................... 17 2.2.1.2. Requisitos de usuários ............................................... 18 2.2.1.3. Requisitos de sistemas ............................................... 19 2.2.1.4. Especificação de Interface ......................................... 19 Elicitação e analise de requisitos 2.2.3. Validação de requisitos .................................................. 19 ................................................................. 21 2.2.3.1. Planejamento e gerenciamento de requisitos .............. 22 2.2.3.2. Gerenciamento de mudança de requisitos ................. 24 ............................................................................................... 25 2.3. Casos de uso 2.4. Diagrama de classe 2.5. Diagrama de seqüência 2.6. 2.7. 3. 2.2.2. ...................................................................................... 26 ................................................................................ 26 Banco de dados ......................................................................................... 27 2.6.1. My Sql ......................................................................................... 27 2.6.2. Postgre Sql 2.6.3. Oracle ................................................................................... 27 ......................................................................................... 28 Programação orientada a objeto SISTEMA PROPOSTO ................................................................. 28 ......................................................................................... 30 3.1. Benefícios do produto ................................................................................ 30 3.2. Diagrama de contexto ................................................................................ 31 3.3. Usuários ........................................................................................................ 31 3.4. Interface de hardware ................................................................................... 32 3.5. Interface de software ................................................................................... 32 3.6. Restrições ..................................................................................................... 32 3.7. Requisitos específicos 3.7.1. Requisitos funcionais 3.7.1.1. 3.7.2. ................................................................................ .................................................................... Diagrama de caso de uso ............................................ 3.7.1.1.1. Diagramas dos casos de uso ................. 3.7.1.1.2. Descrição dos casos de uso completo 37 37 34 34 .. 37 Requisitos não funcionais .............................................................. 41 3.8. Diagrama de classes ................................................................................... 3.9. Diagrama de entidades e relacionamentos do banco de dados 3.10. Diagramas de seqüência 3.11. Interfaces de usuário 61 .................... 62 ............................................................................. 63 ................................................................................... 83 4. CONCLUSÃO ........................................................................................................ 5. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 103 104 6. GLOSSÁRIO ........................................................................................................... 106 x LISTA DE FIGURAS Figura 2.1 – Ciclo de vida de software em cascata ............................................................. 4 Figura 2.2 – Desenvolvimento evolucionário ..................................................................... 6 Figura 2.3 – Engenharia de software baseada em componentes ......................................... 7 Figura 2.4 – Entrega incremental ........................................................................................ 8 Figura 2.5 – Modelo em espiral do processo de software ................................................... 9 Figura 2.6 – Modelo geral de processo de projeto .............................................................. 12 Figura 2.7 – Processo de teste ............................................................................................. 13 Figura 2.8 – Evolução de sistema........................................................................................ 14 Figura 2.9 – Processo de engenharia de requisitos.............................................................. 15 Figura 2.10 – Modelo em espiral dos processos de engenharia de requisitos ..................... 16 Figura 2.11 – Tipos de requisitos não funcionais ............................................................... 18 Figura 2.12 – Processo de elicitação e análise de requisitos ............................................... 20 Figura 2.13 – Gerenciamento de mudanças de requisitos ................................................... 24 Figura 3.1 – Diagrama de contexto ..................................................................................... 31 Figura 3.2 – Diagrama de caso de uso acesso ao sistema.................................................... 34 Figura 3.3 – Diagrama de caso de uso gerenciamento de usuários ..................................... 34 Figura 3.4 – Diagrama de caso de uso modelagem do documento ..................................... 35 Figura 3.5 – Diagrama de caso de uso gerenciamento do documento ................................ 35 Figura 3.6 – Diagrama de caso de uso consultar documento .............................................. 36 Figura 3.7 – Diagrama de caso de uso arquivo morto ......................................................... 36 Figura 3.8 – Diagrama de classes ........................................................................................ 61 Figura 3.9 – Diagrama de relacionamentos do banco de dados .......................................... 62 Figura 3.10 – DSS01 Diagrama de seqüência acessar sistema ........................................... 63 Figura 3.11 – DSS02 Diagrama de seqüência bloquear sistema ......................................... 64 Figura 3.12 – DSS03 Diagrama de seqüência cadastrar usuário......................................... 65 Figura 3.13 – DSS04 Diagrama de seqüência alterar usuário ............................................. 66 Figura 3.14 – DSS05 Diagrama de seqüência remover usuário .......................................... 67 xi Figura 3.15 – DSS06 Diagrama de seqüência consultar usuário......................................... 68 Figura 3.16 – DSS08 Diagrama de seqüência consultar modelo ........................................ 68 Figura 3.17 – DSS07 Diagrama de seqüência criar modelo................................................ 69 Figura 3.18 – DSS09 Diagrama de seqüência alterar modelo............................................. 70 Figura 3.19 – DSS10 Diagrama de seqüência remover modelo.......................................... 71 Figura 3.20 – DSS11 Diagrama de seqüência liberar modelo............................................. 72 Figura 3.21 – DSS12 Diagrama de seqüência criar documento .......................................... 73 Figura 3.22 – DSS13 Diagrama de seqüência consultar documento................................... 74 Figura 3.23 – DSS14 Diagrama de seqüência alterar documento ....................................... 75 Figura 3.24 – DSS15 Diagrama de seqüência remover documento .................................... 76 Figura 3.25 – DSS16 Diagrama de seqüência liberar documento....................................... 77 Figura 3.26 – DSS17 Diagrama de seqüência divulgar documento .................................... 78 Figura 3.27 – DSS18 Diagrama de seqüência imprimir documento ................................... 79 Figura 3.28 – DSS19 Diagrama de seqüência mover documento para o arquivo morto .... 80 Figura 3.29 – DSS20 Diagrama de seqüência recuperar documento do arquivo morto ..... 81 Figura 3.30 – DSS21 Diagrama de seqüência remover documento do arquivo morto ....... 82 Figura 3.31 – DSS23 Diagrama de seqüência consultar documento no arquivo morto...... 82 Figura 3.32 – Tela 01 – Tela principal do sistema .............................................................. 83 Figura 3.33 – Tela 02 – Tela principal do sistema .............................................................. 84 Figura 3.34 – Tela 03 – Tela principal do sistema .............................................................. 85 Figura 3.35 – Tela 04 – Tela principal do sistema .............................................................. 86 Figura 3.36 – Tela 05 – Tela principal do sistema .............................................................. 87 Figura 3.37 – Tela 06 – Acessar sistema ............................................................................. 88 Figura 3.38 – Tela 07 – Configurar sistema ........................................................................ 89 Figura 3.39 – Tela 08 – Configurar sistema ........................................................................ 90 Figura 3.40 – Tela 09 – Teste de conexão do banco de dados ............................................ 91 Figura 3.41 – Tela 10 – Gerenciamento de usuário............................................................. 92 Figura 3.42 – Tela 11 – Gerenciamento de modelos........................................................... 93 Figura 3.43 – Tela 12 – Gerenciamento de modelos........................................................... 94 Figura 3.44 – Tela 13 – Gerenciamento de modelos........................................................... 95 Figura 3.45 – Tela 14 – Visualizar modelo ......................................................................... 96 xii Figura 3.46 – Tela 15 – Liberar modelo.............................................................................. 97 Figura 3.47 – Tela 16 – Gerenciamento de documentos ..................................................... 98 Figura 3.48 – Tela 17 – Liberar documento ........................................................................ 99 Figura 3.49 – Tela 18 – Consultar documento .................................................................... 100 Figura 3.50 – Tela 19 – Divulgar documento...................................................................... 101 Figura 3.51 – Tela 20 – Arquivo morto............................................................................... 102 xiii LISTA DE ABREVIATURAS E SIGLAS GED Gerenciamento Eletrônico de Documentos. OCR Reconhecimento Óptico de Caracteres. UML Linguagem de Modelagem Unificada. RE Engenharia de Requisitos. CASE Engenharia de Software auxiliada por Computador. PC Computador Pessoal – Microcomputador. COTS Sistemas comerciais independentes. HD Disco rígido. SGBD Sistema Gerenciador de Banco de Dados. SQL Linguagem de Consulta Estruturada ODBC Conectividade de Base de Dados Aberto. 1 SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE DOCUMENTOS ELETRÔNICOS CAPÍTULO I 1. INTRODUÇÃO Cada vez mais as empresas e organizações estão gerando documentos em forma de papel. A rapidez na localização das informações contidas nos documentos é hoje uma questão prioritária. A morosidade na localização e a falta de cuidado no arquivamento dos documentos de registros funcionais e financeiros, bem como as obrigações fiscais, não passam de falta de organização e métodos no armazenamento e recuperação de documentos. Organizá-los em pastas e arquivos físicos dificulta a agilidade de recuperação, trazendo conseqüências para os processos. Além disso, a informação contida em documentos, em forma de papel, tem uma menor flexibilidade e tende a gerar maiores gastos, que são destinados a manutenção de locais cada vez maiores para o armazenamento da documentação física, diferente de quando é feito na forma eletrônica. Utilizava-se da tecnologia de processamento de documentos que se restringia a melhorar recursos para gerar, imprimir e transportar os mesmos. Atualmente é utilizada a tecnologia GED, que implementou algumas soluções importantes na maneira de criar, armazenar e distribuir um documento, baseado em tecnologias de extração do meio físico (papel) para o meio digital (imagem digitalizada), reduzindo assim, a necessidade crescente de espaço físico. A tecnologia GED oferece também uma solução para aumentar a agilidade do processo de gerenciamento manual de documentos para o usuário, com segurança e confiabilidade. O que é GED? O gerenciamento eletrônico de documentos ou “Document Imaging” é o processo de conversão dos documentos em suporte de papel ou microfilme em bitmaps eletrônico, que representam a figura de uma pagina e o seu gerenciamento através de um software, o qual 2 permite que os mesmos sejam indexados, armazenados, pesquisados, recuperados e visualizados. A escanerização ou digitalização é um processo de conversão dos documentos em papel ou microfilme, o qual é similar ao usado por uma fotocopiadora ou FAC-SÍMILE. Os documentos são convertidos através de um equipamento chamado scanner. Uma vez convertido em imagem eletrônica, cada documento é nomeado e indexado através de informações obtidas dele mesmo, como títulos, nomes, datas ou outras identificações e, então, arquivado eletronicamente. Mais tarde, os documentos podem ser recuperados pesquisando-se através dos índices digitados (titulo ou o código de identificação). Se desejado, o computador pode “ler” o texto de cada página (imagem) através de um processo chamado Reconhecimento Óptico de Caracteres – OCR que cria um arquivo de texto, o qual pode ser usado para indexar o documento. O processo de utilização do texto de um documento para pesquisa e recuperação é reconhecido como “full-text indexing and retrieving”, uma ferramenta poderosa que permite uma pessoa achar qualquer página através de certas palavras ou frases. Além do gerenciamento eletrônico, este projeto tem como objetivo facilitar a criação de documentos a serem moldados de acordo com o padrão adotado pela organização, tornando assim um documento padrão automatizado para ser utilizado entre os usuários da mesma. Neste projeto fizemos uma breve introdução bibliográfica sobre os processos de software (item 2.1), citando alguns modelos de processos, interação de processo, atividades de processo e também processos de engenharia de requisitos (item 2.2), casos de uso (item 2.3), diagramas de classe (item 2.4), diagramas de seqüência (item 2.5), banco de dados (2.6), orientação a objetos (item 2.7). Para o desenvolvimento do sistema em questão foi utilizado o sistema de desenvolvimento em espiral apoiado pela ferramenta case Jude Community como apoio à especificação dos diagramas de casos de uso, de seqüência e de classes, modelado o banco de dados com suporte da ferramenta Power Designer e implementado na linguagem orientada a objetos Visual Basic .NET[5]. 3 CAPÍTULO II 2. ESTUDOS BIBLIOGRÁFICOS Nos estudos bibliográficos serão abordados os processos de software mais conhecidos, seus modelos, interação e atividades, também serão abordados os processos de engenharia de requisitos, requisitos de software, estudo de viabilidade, elicitação e validação de requisitos. 2.1. PROCESSOS DE SOFTWARE Processo de software é um conjunto de atividades que envolvem o desenvolvimento de software. Apesar de existir muitos processos de softwares diferentes tais como, sistemas críticos e sistemas de negócios, algumas atividades são comuns a todos eles como as atividades abaixo retiradas do Sommerville [2]: • Especificação de software – “a funcionalidade do software e as restrições sobre sua operação devem ser definidas”; • Projeto e implementação de software – “o software que atenda à especificação deve ser produzido”; • Validação de software – “o software deve ser validado para garantir que ele faça o que o cliente deseja”; • Evolução de software – “o software deve evoluir para atender às necessidades mutáveis do cliente”. 2.1.1. MODELOS DE PROCESSO DE SOFTWARE Um modelo de processo de software é uma representação abstrata de um processo de software, onde cada modelo representa um processo sob determinada perspectiva. Os modelos de processos conhecidos retirados do Sommerville [2]: 4 • Modelo em cascata – “considera as atividades fundamentais do processo, compreendendo especificação, desenvolvimento, validação e evolução, e as representam como fases de processos separadas, tais como especificação de requisitos, projeto de software, implementação, teste e assim por diante”; • Desenvolvimento evolucionário – “esta abordagem intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é desenvolvido rapidamente baseado em especificações abstratas. Este sistema é, então, refinado com as entradas do cliente para produzir um sistema que satisfaça as necessidades do cliente”; • Engenharia de software baseada em componentes – “esta abordagem baseia-se na existência de um número significativo de componentes reusáveis. O processo de desenvolvimento do sistema enfoca a integração desses componentes, em vez de desenvolvê-los a partir do zero”. 2.1.1.1. O MODELO EM CASCATA Este modelo é denominado cascata, devido ao encadeamento de uma fase com a outra, como podemos observar na Figura 2.1, retirado do Sommerville [2]. A fase seguinte só deve começar quando a fase atual for encerrada, e cada uma das fases desse modelo deverá gerar um documento de aprovação. Figura 2.1 – Ciclo de vida de software em cascata. 5 Estágios do modelo cascata baseado no Sommerville [2]: • Análise e definição de requisitos – “os serviços, restrições e objetivos do sistema são definidos por meio de consulta aos usuários do sistema. Eles são, portanto, definidos detalhadamente e servem como uma especificação de sistema”. • Projeto de sistema e software – “o processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele estabelece uma arquitetura geral do sistema. O projeto de software envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações”. • Implementação e teste de sistema – “durante esse estágio, o projeto de software é realizado como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação”. • Integração e teste de sistema – “as unidades individuais de programa ou os programas são integrados e testados como um sistema completo para garantir que os requisitos de software foram atendidos. Após os testes, o sistema de software é liberado para o cliente”. • Operação e manutenção – “geralmente esta é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em operação. A manutenção envolve a correção de erros não detectados nos estágios anteriores do ciclo de vida, no aprimoramento da implementação das unidades de sistema e na ampliação dos serviços de sistema à medida que novos requisitos são identificados”. Pelo fato do modelo cascata não ser um modelo flexível, é recomendado que este modelo seja usado apenas quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento do sistema. 2.1.1.2. DESENVOLVIMENTO EVOLUCIONÁRIO O desenvolvimento evolucionário se baseia na exposição de resultados aos comentários dos usuários, refinando esse(s) resultado(s) com várias versões até que se obtenha o sistema adequado, como é mostrado na Figura 2.2, retirada do Sommerville [2]. 6 Figura 2.2 – Desenvolvimento evolucionário. Existem dois tipos fundamentais de desenvolvimento evolucionário especificados em Sommerville [2]: • Desenvolvimento exploratório – “no qual o objetivo do processo é trabalhar com o cliente para explorar os requisitos e entregar um sistema final. O desenvolvimento começa com as partes do sistema compreendidas. O sistema evolui por meio da adição de novas características propostas pelo cliente”. • Prototipação – “na qual o objetivo do processo de desenvolvimento evolucionário é compreender os requisitos do cliente e, a partir disso, desenvolver melhor definição de requisitos para o sistema. O protótipo se concentra na experimentação dos requisitos mal compreendidos do cliente”. 2.1.1.3. ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES Quando as pessoas que trabalham no projeto conhecem os projetos ou os códigos similares, é provável que haja algum reuso de software. De acordo com Sommerville [2], demonstrado na Figura 2.3, à abordagem orientada a reuso depende de uma grande base de componentes de software reusáveis e algum framework de integração desses componentes. 7 Figura 2.3 – Engenharia de software baseada em componentes. • Análise de componentes – “dada uma especificação de requisitos, é feita uma busca pelos componentes para implementar essa especificação. Geralmente, não existe uma correspondência exata e os componentes que podem ser usados fornecem apenas parte da funcionalidade necessária”. • Modificação de requisitos – “durante esse estágio, os requisitos são analisados usando informações sobre os componentes encontrados. Eles são modificados para refletir os componentes disponíveis. Quando as modificações são impossíveis, a atividade de analise de componentes pode ser novamente realizada para procurar soluções alternativas”. • Projeto de sistema com reuso – “durante este estágio, o framework do sistema é projetado ou um framework existente e reusado. Os projetistas levam em consideração os componentes reusados, organizando o framework para eles. Pode ser necessário projetar algum software novo caso os componentes reusáveis não estejam disponíveis”. • Desenvolvimento e integração – “o software que não pode ser adquirido externamente é desenvolvido e os componentes e os sistemas COTS são integrados para criar um novo sistema. A integração de sistema, neste modelo, pode ser parte do processo de desenvolvimento, em vez de ser uma atividade separada”. 2.1.2. ITERAÇÃO DE PROCESSO Como alterações em projetos de grande porte são inevitáveis, devido a mudanças de requisitos, tecnologias disponíveis atualmente e a pressões externas do mercado, devido à 8 competitividade entre as empresas. As atividades de processo são repetidas regularmente à medida que o sistema é retrabalhado, em resposta às solicitações de mudanças. Os modelos utilizados para apoiar a iteração de processos são: • Entrega incremental – “a especificação, o projeto e a implementação de software são divididos em uma série de incrementos desenvolvidos um de cada vez”. • Desenvolvimento espiral – “o desenvolvimento do sistema evolui em espiral para fora a partir de um esboço inicial até o sistema final”. 2.1.2.1. ENTREGA INCREMENTAL A entrega incremental é uma abordagem intermediaria que combina as vantagens do modelo de desenvolvimento em cascata e o modelo de abordagem evolucionaria, como podemos observar na Figura 2.4 encontrada no Sommerville [2]. Figura 2.4 – Entrega incremental. Vantagens: • “Os clientes não precisam esperar até a entrega do sistema inteiro para se beneficiarem dele. O primeiro incremento satisfaz os requisitos mais críticos e, dessa forma, é possível usar o software imediatamente”; • “Os clientes podem usar os incrementos iniciais como protótipos e ganhar experiência, obtendo informações sobre os requisitos dos incrementos posteriores do sistema”; 9 • “Existe um risco menor de falha geral do projeto. Embora possa ser encontrados problemas em alguns incrementos, é provável que alguns sejam entregues com sucesso aos clientes”; • “Como os serviços de prioridade mais alta são entregues primeiro, e os incrementos posteriores são integrados a eles, é inevitável que os serviços mais importantes de sistema recebam mais testes. Isso significa que os clientes têm menor probabilidade de encontrar falhas de software nas partes mais importantes do sistema”. No entanto, “os incrementos devem ser relativamente pequenos com até 20 mil linhas de código, e cada um deve entregar alguma funcionalidade de sistema”. 2.1.2.2. DESENVOLVIMENTO EM ESPIRAL Ao invés de se representar as atividades do processo de software de forma seqüencial com algum retorno entre uma atividade e outra, é representada como uma espiral de acordo com a Figura 2.5. Cada fase do processo pode ser representada como uma volta da espiral, sendo que as fases do desenvolvimento evoluem da volta mais interna para a mais externa. Figura 2.5 – Modelo em espiral do processo de software. 10 De acordo com Sommerville [2], cada volta na espiral está dividida em quatro setores: • Definição de objetivos – “os objetivos específicos dessa fase são definidos. As restrições sobre o processo e o produto são identificadas em um plano detalhado de gerenciamento é elaborado. Os riscos de projeto são identificados. Dependendo disso, estratégias alternativas podem ser planejadas”. • Avaliação e redução de riscos – “para cada risco de projeto identificado, uma analise detalhada realizada. Providencias são tomadas para reduzir o risco. Por exemplo, se houver risco de que os requisitos não sejam apropriados, um protótipo do sistema poderá ser desenvolvido”. • Desenvolvimento e validação – “após a avaliação de risco, um modelo de desenvolvimento para o sistema é selecionado. Por exemplo, se os riscos da interface com o usuário forem dominantes, o modelo de desenvolvimento apropriado pode ser a prototipação evolucionaria. Se os riscos de segurança constituírem a principal consideração, o desenvolvimento baseado em transformações formais pode ser mais apropriados e assim por diante”. • Planejamento – “o projeto é revisado e uma decisão é tomada para prosseguimento a próxima volta da espiral. Se a decisão for pelo prosseguimento, serão elaborados planos para a próxima fase do projeto”. Comparando com outros modelos, a principal diferença entre o modelo espiral e eles, é o reconhecimento explicito do risco. A elaboração de objetivos como desempenho e funcionalidade, podem fazer parte de um ciclo da espiral. Os caminhos alternativos para alcançar esses objetivos e as restrições impostas sobre cada um deles são, então, enumerados. Cada alternativa é avaliada em relação a cada objetivo e as fontes de riscos de projetos são identificadas. O próximo passo é resolver esses riscos por meios de atividades de coletas de informações, tais como analise mais detalhada, prototipação e simulação. Após a avaliação dos riscos, é realizada uma parte do desenvolvimento, seguida pela atividade de planejamento para próxima fase do processo. 11 2.1.3. ATIVIDADES DE PROCESSO DE SOFTWARE Especificação, desenvolvimento, validação e evolução, são as quatro atividades básicas do processo, e há duas formas de organizá-las. No modelo em cascata as atividades são organizadas em seqüencia, e no modelo evolucionário são intercaladas. 2.1.3.1. ESPECIFICAÇÃO DE SOFTWARE A especificação de software é o processo utilizado para definir quais serviços são necessários e identificar as restrições de operação e de desenvolvimento do sistema, esse processo também é conhecido como engenharia de requisitos. Os requisitos são apresentados de duas formas diferentes: uma das formas é para usuários finais e clientes com uma declaração de requisitos de alto nível, e a outra forma é para projetistas de sistemas com uma declaração mais detalhada. 2.1.3.2. DESENVOLVIMENTO DE SOFTWARE O desenvolvimento de software é o processo de conversão de uma especificação de sistema em um sistema executável. “Um projeto de software é a descrição da estrutura de software a ser implementada, dos dados que são partes do sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.” Sommerville [2]. Para aprimoramento de modelos anteriores utiliza-se o processo feed-back, o ato de decompor um projeto para descobrir erros e omissões em estágios anteriores de projeto. A Figura 2.6 é um modelo desse processo que sugere que os estágios do processo de projeto sejam seqüenciais. 12 Figura 2.6 – Modelo geral de processo de projeto. As atividades específicas do processo de projeto listadas abaixo, podem ser uma especificação abstrata e formal que serve para esclarecer os requisitos, ou pode ser uma especificação de como uma parte do software será realizada. De acordo com Sommerville [2]: • Projeto de arquitetura – “os subsistemas constituintes do sistema e os seus relacionamentos são identificados e documentados”. • Especificação abstrata – “para cada subsistema, é produzida uma especificação abstrata dos serviços e as restrições sob as quais ele deve operar”. • Projeto de interface – “para cada subsistema, é projetada e documentada a interface com outros subsistemas. A especificação de interface não deve ser ambígua, pois ela permite que o subsistema seja usado sem que se tenha conhecimento da sua operação”. • Projeto de componente – “os serviços são alocados aos componentes e as interfaces desses componentes são projetadas”. • Projeto de estruturas de dados – “as estruturas de dados usadas na implementação do sistema são projetadas detalhadamente e especificadas”. • Projeto de algoritmo – “os algoritmos usados para fornecer os serviços são projetados detalhadamente e especificados”. 13 2.1.3.3. VALIDAÇÃO DE SOFTWARE “A validação do software, destina-se a mostrar que um sistema está em conformidade com sua especificação e que atende às expectativas do cliente que está adquirindo o sistema.” Sommerville [2]. Ou seja, cada etapa do processo de software, desde a definição de requisitos de usuários até o desenvolvimento do programa, irá passar pelo processo de verificação tais como inspeções e revisões. A Figura 2.7 mostra um processo de teste em três estágios, onde primeiramente os componentes do sistema são testados, depois é testado o sistema integrado e, finalmente, o sistema é testado com os dados do cliente. Figura 2.7 – Processo de teste. Estágios do processo de teste retirados do Sommerville [2]: • Teste de componentes (ou unidade) – “os componentes individuais são testados para garantir que operem corretamente. Cada componente é testado independentemente, sem os outros componentes de sistema. Os componentes podem ser entidades simples, tais como funções ou classes de objetos, ou podem ser grupos coerentes dessas entidades”. • Teste de sistema – “os componentes são integrados para compor o sistema. Esse processo está relacionado com a busca de erros que resultam das interações não previstas entre os componentes e problemas de interface de componentes. Está também relacionado à validação de que o sistema atende aos requisitos funcionais e não funcionais e ao teste no qual os componentes são integrados para formar 14 subsistemas testados individualmente antes que sejam integrados para formar o sistema final”. • Teste de aceitação – “este é o final do processo de teste, antes que o sistema seja aceito para o uso operacional. O sistema é testado com os dados fornecidos pelo cliente do sistema, em vez de dados simulados de teste. O teste de aceitação pode revelar erros e omissões na definição de requisitos de sistema, em vez de dados simulados de teste. O teste de aceitação pode revelar erros e omissões na definição de requisitos de sistema, pois os dados reais exercitam o sistema de formas diferentes dos dados de teste. O teste de aceitação pode também revelar problemas de requisitos, em que os recursos do sistema não atendem realmente às necessidades do usuário ou o desempenho do sistema é inaceitável”. 2.1.3.4. EVOLUÇÃO DE SOFTWARE De acordo com Sommerville [2] a flexibilidade dos sistemas de software é uma das principais razões pelas quais cada vez mais o software está sendo incorporado a sistemas complexos de grande porte. Após a decisão de aquisição de hardware, é muito oneroso fazer mudanças no projeto de hardware. No entanto, mudanças podem ser feitas no software a qualquer instante durante ou após o desenvolvimento do sistema. Mesmo mudanças extensas são mais baratas do que as mudanças correspondentes no hardware do sistema. “É mais realista pensar na engenharia de software como um processo evolutivo, Figura 2.8, no qual o software é continuamente alterado ao longo de sua vida, em resposta às mudanças de requisitos e as necessidades do cliente”, Sommerville [2]. Figura 2.8 – Evolução de sistema. 15 2.2. PROCESSOS DE ENGENHARIA DE REQUISITOS De acordo com Sommerville [2], “o objetivo do processo de engenharia de requisitos é criar e manter um documento de requisitos do sistema”. O processo geral inclui quatro subprocessos Figura 2.9 de alto nível de engenharia de requisitos que são especificados nos subtópicos 2.10 (requisitos de software), 2.11 (estudo de viabilidade), 1.12 (elicitação e análise de requisitos) e 2.13 (validação de requisitos). Figura 2.9 – Processo de engenharia de requisitos. Como podemos observar em Sommerville [2], os processos de engenharia de requisitos no formato espiral conforme ilustrado na Figura 2.10, mostra os processos como uma atividade de três estágios, na qual as atividades estão organizadas como um processo iterativo em espiral. Porém o modelo espiral acomoda abordagens de desenvolvimento em que os requisitos são desenvolvidos para diferentes níveis de detalhes. O número de iterações na espiral pode variar no decorrer do levantamento dos requisitos, de modo que pode-se sair da espiral depois de alguns ou todos os requisitos de usuário tiverem sidos elicitados diferindo do exemplo inicial demonstrado na Figura 2.9. 16 Figura 2.10 – Modelo em espiral dos processos de engenharia de requisitos. 2.2.1. REQUISITOS DE SOFTWARE Segundo Sommerville, os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. O termo requisito não é usado pela indústria de software de maneira consistente. Em alguns casos, um requisito é simplesmente uma declaração abstrata de alto nível de um serviço que o sistema deve fornecer ou uma função do sistema. Davis (Davis 1993) explica por que essas diferenças existem: “Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um grande projeto de software, ela precisa definir suas necessidades de maneira suficientemente abstrata, para que uma solução não seja predefinida. Os requisitos devem ser redigidos de modo que os diversos fornecedores possam apresentar propostas, talvez, diferentes maneiras de atender ás necessidades organizacionais do cliente. Após a aprovação do contrato, o fornecedor deve redigir uma definição mais detalhada do sistema para o cliente, de modo que o cliente possa compreender e validar o que o software fará. Esses dois documentos podem ser chamados de documentos de requisitos do sistema.” 17 2.2.1.1. REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS Os requisitos de sistema de software são, freqüentemente, classificados em requisitos funcionais e requisitos não funcionais: 2.2.1.1.1. REQUISITOS FUNCIONAIS Os requisitos funcionais de um sistema descrevem o que o sistema deve fazer. Esses requisitos dependem do tipo do software que está sendo desenvolvido, dos usuários a que o software se destina e da abordagem geral considerada pela organização ao redigir os requisitos. Os requisitos funcionais descrevem a função do sistema detalhadamente, suas entradas e saídas, exceções etc. Em principio, a especificação de requisitos funcionais de um sistema deve ser completa e consistente. Completeza significa que todos os serviços exigidos pelo usuário devem ser definidos. Consistência significa que os requisitos não devem ter definições contraditórias. Na prática, em sistemas grandes e complexos, é praticamente impossível atingir a consistência e a completeza de requisitos. 2.2.1.1.2. REQUISITOS NÃO FUNCIONAIS Sommerville [2], afirma que requisitos não funcionais “são aqueles não diretamente relacionados as funções especificas fornecidas pelo sistema. Eles podem estar relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento”. Tipos de requisitos não funcionais, que podem ser observados na Figura 3.3 abaixo: • Requisitos de produto – estes requisitos especificam o comportamento do produto; • Requisitos organizacionais – estes requisitos são derivados de políticas e procedimentos da organização do cliente e do desenvolvedor; • Requisitos externos – abrange todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. 18 Figura 2.11 – Tipos de requisitos não funcionais. 2.2.1.2. REQUISITOS DE USUÁRIOS Requisitos de usuários devem especifica apenas o comportamento externo do sistema e evitar, sempre que possível, características de projeto do sistema, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado. Diretrizes sugeridas por Sommerville [2], para minimizar o mal-entendimento ao redigir requisitos de usuários: • “Invente um formato padrão e assegure-se que todas as definições de requisitos aderiram a esse formato”; • “Use a linguagem de forma consistente”; • “Use destaque no texto (negrito, itálico ou cor) para ressaltar as partes principais dos requisitos”; • “Evitar, sempre que possível, o uso de jargões de informática”. 19 2.2.1.3. REQUISITOS DE SISTEMA É a especificação completa e consistente de todo o sistema. Devem simplesmente descrever o comportamento externo do sistema e suas restrições operacionais, e eles não devem estar relacionados a como o sistema pode ser projetado ou implementado. 2.2.1.4. ESPECIFICAÇÃO DE INTERFACE Sommerville [2] define especificação de interface em três tipos: • Interfaces de procedimentos – “nas quais programas ou subsistemas existentes oferecem uma serie de serviços acessados pela chamada de procedimentos de interface”; • Estruturas de dados – “que são passadas de um subsistema para outro”; • Representações de dados – “estabelecidas para um sistema preexistentes”. 2.2.2. ELICITAÇÃO E ANÁLISE DE REQUISITOS Nesse estágio os engenheiros de software trabalham diretamente com os clientes e usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o sistema deve fornecer, o desempenho esperado do sistema, restrições de hardware etc. Um modelo de processo bastante genérico de elicitação e análise de requisitos é apresentado na Figura 2.12. Esse modelo poderá variar de organização para organização, dependendo de fatores locais, como o nível de conhecimento da equipe, o tipo do sistema que está sendo desenvolvido e os padrões usados. Optamos por demonstrar o processo de elicitação e análise de requisitos em formato de espiral como adotado por Sommerville [2], de modo que as atividades se intercalem à medida que o processo progrida da parte interna da espiral para a parte externa. 20 Figura 2.12 – Processo de elicitação e análise de requisitos. As atividades deste processo são retiradas de Sommerville [2]: • Obtenção de requisitos – “É o processo de interação com os stakehoders no sistema para coletar seus requisitos. Os requisitos de domínio são também descobertos durante essa atividade, provenientes dos stakeholders e da documentação”. • Classificação e organização de requisitos – “Esta atividade envolve a coleção de requisitos não estruturados, agrupa os requisitos relacionados e os organiza em conjuntos coerentes”. • Priorização e negociação de requisitos – “Inevitavelmente, quando vários stakeholders participam do processo, os requisitos serão conflitantes. Esta atividade está relacionada à priorização de requisitos, à procura e à resolução de conflitos por meio de negociação”. 21 • Documentação de requisitos – “Os requisitos são documentados e colocados na próxima volta da espiral, Figura 2.12. Podem ser produzidos documentos formais ou informais”. 2.2.3. VALIDAÇÃO DE REQUISITOS A validação de requisitos dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja. A validação de requisitos se sobrepõe à análise; está relacionada à descoberta de problemas com os requisitos. A validação de requisitos é importante porque os erros em um documento de requisitos podem levar a custos excessivos de retrabalho quando são descobertos durante o desenvolvimento ou depois que o sistema está em operação. O custo de correção de um problema de requisitos, fazendo uma mudança de sistema, é muito maior do que a correção de erros de projeto e de codificação. A razão disso é que uma mudança de requisitos significa geralmente que o projeto e a implementação do sistema devem também ser mudados e o sistema deve ser novamente testado. Durante o processo de validação de requisitos, devem ser realizadas verificações nos requisitos do documento de requisitos. De acordo com Sommerville [2], essas verificações incluem: • Verificações de validade. “Um usuário pode pensar que um sistema é necessário para desempenhar determinadas funções. Contudo, mais estudos e analises podem identificar que funções adicionais e diferentes são necessárias”. • Verificações de consistência. “Os requisitos em um documento não devem ser conflitantes. Isso significa que não devem existir restrições ou descrições contraditórias para a mesma função do sistema”. • Verificações de completeza. “O documento de requisitos deve incluir requisitos que definam todas as funções e as restrições desejadas pelo usuário do sistema”. • Verificações de realismo. “Usando o conhecimento da tecnologia existente, os requisitos devem ser verificados quanto a se realmente podem ser implementados. Essas verificações também devem levar em consideração o orçamento e o prazo para desenvolvimento do sistema”. 22 • Facilidade de verificação. “Para reduzir o potencial de divergências entre cliente e fornecedor, os requisitos do sistema devem sempre ser escritos de modo que sejam verificáveis. Isto significa que deve-se escrever um conjunto de testes que possa demonstrar que o sistema entregue atende a cada requisito especificado”. Uma série de técnicas de validação de requisitos pode ser usada em conjunto ou individualmente: • Revisões de requisitos. “Os requisitos são analisados sistematicamente por uma equipe de revisores”. • Prototipação. “Nesta abordagem de validação, um modelo executável do sistema é apresentado para usuários finais e clientes. Eles podem experimentar o modelo para verificar se atende às suas necessidades reais”. • Geração de casos de teste. “Os requisitos devem ser testáveis. Se os testes dos requisitos forem criados como parte do processo de validação, eles freqüentemente revelarão problemas de requisitos. Se um teste for difícil ou impossível de ser projetado, isso significa geralmente que os requisitos serão difíceis de ser implementados e devem ser reconsiderados”. 2.2.3.1. PLANEJAMENTO DE GERENCIAMENTO DE REQUISITOS Para cada projeto, o estágio de planejamento estabelece o nível de detalhamento necessário para o gerenciamento de requisitos. Durante o estágio de gerenciamento de requisitos deve-se decidir sobre[2]: • Identificação de requisitos. “Cada requisito deve ser identificado unicamente de modo que possa ser feita a referência cruzada entre este e outros requisitos para que ele possa ser usado nas avaliações de rastreabilidade”. • Processo de gerenciamento de mudanças. “É o conjunto de atividades que avaliam o impacto e custo das mudanças”. • Políticas de rastreabilidade. “Essas políticas definem os relacionamentos entre os requisitos e o projeto do sistema, que devem ser registrados, e como esses registros devem ser mantidos”. 23 • Apoio de ferramentas CASE. “O gerenciamento de requisitos envolve grandes quantidades de informações sobre os requisitos. As ferramentas que podem ser usadas variam desde sistemas especializados de gerenciamento de requisitos a planilhas e sistemas simples de banco de dados”. “Existem vários relacionamentos entre os requisitos e entre os requisitos de projeto do sistema. Existem também ligações entre requisitos e os motivos básicos de por esses requisitos foram propostos. Quando aas mudanças são propostas, deve-se rastrear seu impacto em outros requisitos e no projeto do sistema. A rastreabilidade é a propriedade de uma especificação que reflete a facilidade de encontrar os requisitos relacionados”. Existem três tipos de informações de rastreabilidade que podem ser mantidos[2]: • “Informações de rastreabilidade da origem ligam os requisitos aos stakeholders que propuseram os requisitos e aos motivos desses requisitos. Quando uma mudança é proposta, utiliza-se essas informações para encontrar e consultar os stakeholders sobre a mudança”. • “Informações de rastreabilidade de requisitos ligam os requisitos dependentes dentro do documento de requisitos. Utiliza-se essas informações para avaliar quantos requisitos provavelmente serão afetados pela mudança proposta e a extensão das mudanças de requisitos conseqüentes que podem ser necessários”. • “Informações de rastreabilidade de projeto ligam os requisitos aos módulos de projeto, nos quais esses requisitos são implementados. Usa-se essas informações para avaliar o impacto das mudanças de requisitos propostos no projeto e na implementação do sistema”. “As informações de rastreablilidade são freqüentemente representadas por meio de matrizes de rastreabilidade que relacionam os requisitos aos stakeholders, aos outros requisitos ou aos módulos de projeto. Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em uma linha e uma coluna da matriz. As dependências entre diferentes requisitos são registradas na célula correspondente à intersecção de linha/coluna”. “As matrizes de rastreabilidade podem ser usadas quando um pequeno número de requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos, tornam-se muito difíceis de serem gerenciadas e sua manutenção é dispendiosa. Para esses sistemas, deve-se captar as informações de rastreabilidade em um banco de dados de requisitos, 24 no qual cada registro é explicitamente ligado a requisitos relacionados. Pode-se então avaliar o impacto das mudanças usando os recursos de acesso ao banco de dados. As matrizes de rastreabilidade podem ser geradas automaticamente baseadas no banco de dados”. O gerenciamento de requisitos precisa de apoio automatizado; as ferramentas CASE para essa finalidade devem ser selecionadas durante a fase de planejamento. Segundo Sommerville [2] o apoio de ferramentas é necessário para: • Armazenamento de requisitos. “Os requisitos devem ser mantidos em um repositório de dados seguro e gerenciado acessível a todos os envolvidos no processo de engenharia de requisitos”. • Gerenciamento de mudanças. “O processo de gerenciamento de mudanças (figura 2.13) é simplificado se um apoio ativo de ferramentas estiver disponível”. • Gerenciamento de rastreabilidade. “Conforme explicado anteriormente, o apoio de ferramentas para rastreabilidade permite que requisitos relacionados sejam obtidos. Algumas ferramentas usam técnicas de processamento de linguagem natural para auxiliar na descoberta de possíveis relacionamentos entre os requisitos”. Figura 2.13 – Gerenciamento de mudanças de requisitos. Para sistemas de pequeno porte, o uso de ferramentas especializadas de gerenciamento de requisitos pode não ser necessário. O processo de gerenciamento de requisitos pode ter apoio de recursos disponíveis em processadores de texto, planilhas e bancos de dados de PC. Contudo para sistemas de grande porte, é necessária uma ferramenta de apoio mais especializada[2]. 2.2.3.2. GERENCIAMENTO DE MUDANÇAS DE REQUISITOS O gerenciamento de mudanças de requisitos Figura 2.13, deve ser aplicado a todas as mudanças propostas aos requisitos. A vantagem de usar um processo formal para gerenciamento de mudanças é que todas as propostas de mudanças são tratadas consistentemente, e que as 25 mudanças no documento de requisitos são feitas de maneira controlada. Existem três principais estágios para um processo de gerenciamento de mudanças[2]: • Análise do problema e especificação da mudança – “o processo se inicia com um problema de requisitos identificado ou, às vezes, com uma proposta de mudança específica. Durante este estágio, o problema ou a proposta de mudança de requisitos é analisada para verificar se é válida. Os resultados da análise são realimentados para o solicitante da mudança e, algumas vezes, é feita uma proposta de mudança de requisitos mais específica”. • Análise da mudança estimativa de custo – “efeito da mudança proposta é avaliado usando as informações de rastreabilidade e o conhecimento geral sobre os requisitos do sistema. Uma vez completada esta análise, é tomada uma decisão sobre prosseguir ou não com a mudança de requisitos”. • Implementação da mudança – “o documento de requisitos e, quando necessário, o projeto e implementação de sistema são modificados. Deve-se organizar o documento de requisitos de modo que se possa realizar as mudanças sem reescrita ou reorganização extensivas”. 2.3. CASOS DE USO Na Engenharia de Software, um caso de uso é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Pode ser representado por uma elipse contendo, internamente, o nome do caso de uso. Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante. Cada Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento. Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho. 26 2.4. DIAGRAMA DE CLASSE Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. É uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, seqüência e estados. 2.5. DIAGRAMA DE SEQÜÊNCIA Diagrama de seqüência, ou diagrama de seqüência de mensagens é um diagrama usado em UML, representando a seqüência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a seqüência global do comportamento. O diagrama de seqüência representa essa informação de uma forma simples e lógica. Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso. Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos. Este diagrama é construído a partir do diagrama de casos de usos. Primeiro, se define qual o papel do sistema (casos de uso), depois, é definido como o software realizará seu papel (Sequência de operações). O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações. 27 2.6. BANCO DE DADOS Bancos de dados são conjuntos de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação. Um banco de dados normalmente agrupa registros utilizáveis para um mesmo fim. Um banco de dados é usualmente mantido e acessado por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de dados é usado como sinônimo de SGDB. O modelo de dados mais adotado hoje em dia é o modelo relacional, onde as estruturas têm a forma de tabelas, compostas por linhas e colunas. No projeto em questão foi adotado o sistema de banco de dados relacional Postegre. 2.6.1. MY SQL O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada) como interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo 2.6.2. POSTGRE SQL PostgreSQL é um poderoso, sistema de banco de dados relacional open source, ou seja, seu código fonte é aberto para a comunidade que deseja cooperar com seu desenvolvimento. Possui mais de 15 anos de desenvolvimento ativo e uma arquitetura amplamente aprovada que ganhou uma forte reputação devido a sua confiabilidade e integridade dos dados. Ele roda em todos os principais sistemas operacionais. Tem todo o apoio para chaves estrangeiras, joins, views, triggers, e procedimentos armazenados (em vários idiomas). Ela inclui a maioria dos tipos de dados SQL92 e SQL99, incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE INTERVAL, e TIMESTAMP. Também suporta armazenamento de objetos grandes binários, incluindo imagens, sons ou vídeos. Possui também uma documentação excepcional. 28 2.6.3. ORACLE O Oracle é um SGBD (sistema gerenciador de banco de dados) que surgiu no fim dos anos 70, quando Larry Ellison vislumbrou uma oportunidade que outras companhias não haviam percebido, quando encontrou uma descrição de um protótipo funcional de um banco de dados relacional e descobriu que nenhuma empresa tinha se empenhado em comercializar essa tecnologia. Ellison e os co-fundadores da Oracle Corporation, Bob Miner e Ed Oates, perceberam que havia um tremendo potencial de negócios no modelo de banco de dados relacional tornando assim a maior empresa de software empresarial do mundo. O SGBD da Oracle é líder de mercado. O Oracle 9i foi pioneiro no suporte ao modelo web. O Oracle 10g, mais recente, se baseia na tecnologia de grid. Recentemente fora lançado o Oracle 11g que veio com melhorias em relação ao Oracle 10g. Além da base de dados, a Oracle desenvolve uma suíte de desenvolvimento chamada de Oracle Developer Suite, utilizada na construção de programas de computador que interagem com a sua base de dados. A Oracle também criou a linguagem de programação PL/SQL, utilizada no processamento de transações. 2.7. PROGRAMAÇÃO ORIENTADA A OBJETOS A orientação a objetos, também conhecida como POO (Programação Orientada a Objetos) é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos. Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programação. A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos. Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento 29 (definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. No projeto em questão será utilizada a orientação ao objeto. 30 CAPÍTULO III 3. SISTEMA PROPOSTO O produto Sistema de Gerenciamento e Padronização de Documentos Eletrônicos visa facilitar a criação de um documento a ser moldado de acordo com o padrão adotado pela organização e gerenciamento dos mesmos, que serão utilizados por usuários de uma organização. Em alguns modelos de GED, o processo de criação do arquivo eletrônico é obtido através da digitalização do mesmo, mas no produto em questão não haverá digitalização do documento, ele será todo eletrônico desde o momento de sua criação. Neste projeto o sistema não receberá dados do meio físico, todo o processo para criação e gerenciamento do documento partirá do próprio sistema, tornando o processo mais ágil. 3.1. BENEFÍCIOS DO PRODUTO • Facilidade na localização do documento – reduz o tempo pesquisa, proporcionando maior agilidade nos processo da organização; • Segurança contra deterioração ou por extravio do meio físico – sem a perda do documento não haverá a o desperdício de tempo para refazer o mesmo; • Acessar o documento por vários usuários ao mesmo tempo – maior agilidade na disseminação da informação contida em um documento; • Economia de espaço físico para armazenamento dos documentos – reduz o custo financeiro, com a manutenção de grandes áreas destinadas ao arquivamento dos mesmos; • Agilidade na atualização dos documentos – economia de tempo; • Formatação automatiza – garantia de um documento padronizado de acordo com as normas da empresa; • Segurança através de códigos de acessos – maior confiabilidade da documentação eletrônica; 31 • Eliminação de papel. 3.2. DIAGRAMA DE CONTEXTO O Sistema de Gerenciamento e Padronização de Documentos Eletrônicos deve ser desenvolvido de modo que possibilite o gestor do sistema modelar o documento padronizando-o. E este mesmo documento modelado anteriormente poderá ser utilizado pelos usuários do sistema para gerar, alterar e consultar documentos que estarão armazenados no banco de dados. As configurações do documento modelado deverão ser salvas no banco de dados, como pode ser observado na Figura 3.1. Figura 3.1 – Diagrama de contexto. 3.3. USUÁRIOS Para este sistema haverá quatro tipos de usuários com níveis de acessos diferentes: 32 • Master – será o responsável pelos documentos, terá acesso a qualquer módulo do sistema, gestão de usuários, gestão do modelo padrão, gestão do documento, gestão do arquivo morto e impressão. • Gestor – gestão de usuários, gestão do modelo padrão, gestão do documento e impressão; • Digitador – terá uma serie de restrições, mas ainda assim terá liberdade para gestão do documento, limitado apenas a criar, alterar e imprimir; • Consultor – somente terá acesso a fazer pesquisas eletrônicas e impressão. 3.4. INTERFACE DE HARDWARE O projeto não utilizará nenhum equipamento em especial. 3.5. INTERFACE DE SOFTWARE Para a máquina servidora deverá constar os seguintes softwares: • Sistema Operacional – Windows 2000; • Banco de dados – Postgres. E para os periféricos: • Sistema Operacional – Windows XP; • Framework 2.0; • Driver ODBC 8.1 – para o postgres. 3.6. RESTRIÇÕES O projeto será desenvolvido por dois estudantes de Engenharia da Computação com prazo determinado por dois períodos no ano de 2008 limitados por seus horários empregatícios e aulas de preleção, de acordo com as normas de Trabalho de Conclusão de Curso da Universidade Católica de Goiás. Não gerencia documentos que não foram criados pelo próprio sistema, pois este trabalha com modelos pré-modelados por um gestor, para que tenha um padrão em todos os documentos. 33 3.7. REQUISITOS ESPECÍFICOS 3.7.1. REQUISITOS FUNCIONAIS • Deixar em aberto para o usuário responsável, a possibilidade de criar vários modelos diferentes de documentos; • Após a modelagem, o usuário poderá escolher um modelo de documento e inserir as informações do documento em cima do modelo escolhido. O documento não mais será produzido diretamente em um editor de texto, e sim em vários campos relacionados ao modelo gerado, automatizando a formatação do texto. • Após o documento ser gerado será indexado um código seqüencial para o controle de localização, e organização do documento. • Permitir que vários usuários possam, de acordo com o nível de permissão, consultar o mesmo documento no mesmo instante. • Em caso de alteração de um documento, manter o documento original inalterado e criar uma cópia onde poderão ser feitas novas alterações. De forma que possa ser visto um histórico das alterações em cada documento. • Restringir acesso ao documento enquanto o mesmo está em estado de alteração. • Liberar o documento para uso. • Divulgar o documento sempre que necessário, desde que o documento já esteja liberado. • Imprimir documento, desde que o documento já esteja liberado. • O usuário poderá enviar um documento para o arquivo morto, sempre que achar necessário; • Recuperar um documento do arquivo morto, conforme a necessidade; • O Master poderá eliminar o documento do arquivo morto; • Consultar no arquivo morto. • Criar níveis de permissão do usuário para a manipulação dos documentos; 34 3.7.1.1. CASOS DE USO Os casos de usos, aqui apresentados foram desenvolvidos de acordo com os padrões UML descritos em Larman [3] e desenhados utilizando a ferramenta case Jude Community . 3.7.1.1.1. DIAGRAMAS DOS CASOS DE USO Figura 3.2 – Diagrama de caso de uso acesso ao sistema. Observando-se figura 3.2, verifica-se como funcionará o acesso e o bloqueio dos usuários com relação às telas do sistema. Figura 3.3 – Diagrama de caso de uso gerenciamento de usuários. Observando-se a figura 3.3, verifica-se como o usuário poderá cadastrar, alterar e remover outros usuários. 35 Figura 3.4 – Diagrama de caso de uso modelagem do documento. Observando-se a figura 3.4, verifica-se que somente os usuários master ou gestor, poderão gerenciar a modelagem do documento, criando, alterando, removendo, salvando e registrando-o. Figura 3.5 – Diagrama de caso de uso gerenciamento do documento. Observando-se a figura 3.5, verifica-se como os usuários master ou gestor e digitador poderão gerenciar o documento, porém o usuário digitador não terá privilégios para remover um documento. 36 Figura 3.6 – Diagrama de caso de uso consultar documento. Observando-se a figura 3.6, verifica-se que todos os usuários poderão consultar ou imprimir os documentos. Figura 3.7 – Diagrama de caso de uso Arquivo Morto. Observando-se a figura 3.7, verifica-se que somente o usuário master poderá realizar operações referentes ao arquivo morto. 37 3.7.1.1.2. DESCRIÇÃO DOS CASOS DE USO COMPLETO Caso de uso CDU1: Acessar sistema Escopo: Libera acesso ao sistema, de acordo com o nível de usuário. Ator principal: Master. Interessados e interesses: − Usuário: Deseja acessar o sistema. − Empresa: Que o usuário acesse somente o que lhe foi permitido. Pré-condições: Usuário devidamente cadastrado. Pós-condições: Telas liberadas de acordo com o nível de acesso. Fluxo básico: 1. Sistema limpa campos de usuário e senha. 2. Sistema solicita usuário e senha. 3. Usuário informa usuário e senha. 4. Sistema faz uma consulta para verificar se o usuário existe. 5. Sistema verifica se usuário e senha são validos. 6. Sistema permite o acesso. Fluxos alternativos: *a. Campo usuário vazio. 1. Sistema informa que o campo usuário está vazio. *b. Campo senha está vazio. 1. Sistema informa que o campo senha está vazio. *c. Usuário não existe. 1. Sistema informa que o usuário não é cadastrado. 2. Sistema limpa o campo do usuário. 3. Usuário informa novamente qual é o seu usuário. *d. Usuário inválido. 1. Sistema informa que o usuário é invalido. 2. Sistema limpa o campo do usuário. 3. Usuário informa novamente qual é o seu usuário. 38 *e. Senha inválida. 1. Sistema informa que a senha é invalida. 2. Sistema limpa o campo da senha. 3. Usuário informa novamente qual é a sua senha. *f. A qualquer momento o usuário solicita o cancelamento do acesso antes que seja efetuado. 1. Sistema mantém o acesso do usuário bloqueado. 2. Sistema fecha tela de acesso. Caso de uso CDU2: Bloquear sistema Escopo: Bloqueia todo o acesso ao sistema. Ator principal: Master. Interessados e interesses: − Empresa: Manter o sistema inacessível aos usuários não cadastrados. Pré-condições: O sistema precisa estar desbloqueado. Pós-condições: Sistema bloqueado. Fluxo básico: 1. Usuário solicita o bloqueio do sistema. 2. Sistema bloqueia e minimiza todas as telas abertas. Fluxos alternativos: *a. Em caso de falha ao bloquear. 1. Aborta o sistema. 2. Informa o motivo do sistema está sendo abortado. Caso de uso CDU3: cadastrar usuário Escopo: Registra novos usuários. Ator principal: Gestor. Interessados e interesses: 39 − Usuário: Deseja ser cadastrado, para obter acesso ao sistema. − Empresa: Deseja ter o controle sobre quem está acessando o sistema. Pré-condições: − Não pode haver mais de um cadastro para o mesmo usuário. − O sistema precisa estar desbloqueado. − Apenas usuários “Master” e “Gestor”, poderão efetuar cadastros de usuários. Fluxo básico: 1. Usuário acessa tela de cadastro. 2. Sistema limpa todos os campos da tela de cadastro. 3. Usuário (Master ou Gestor) inicia um novo cadastro. 4. Usuário novo informa os dados (nome, CPF, usuário, senha, contra-senha, nível, etc.). 5. Sistema verifica se senha e contra-senha são iguais, e se não estão vazias. 6. Sistema valida CPF. 7. Sistema verifica pelo CPF se novo usuário já existe. 8. Sistema registra novo usuário. 9. Sistema registra qual usuário, data e hora que efetivou o cadastro. 10. Usuário recebe confirmação de cadastro. Fluxos alternativos: *a. Senha diferente de contra-senha. 1. Usuário recebe informação de que a senha e contra-senha estão diferentes. 2. Sistema limpa campos da senha e da contra-senha. *b. Campo senha não está preenchido. 1. Sistema informa que o campo senha está vazio. *c. Campo CPF está vazio. 1. Sistema informa que o campo CPF está vazio. *d. Campo nome está vazio. 1. Sistema informa que o campo nome está vazio. *e. Campo usuário está vazio. 1. Sistema informa que o campo usuário está vazio. *f. CPF inválido. 40 1. Sistema informa que o CPF é invalido. 2. Sistema limpa o campo do CPF para inserir novamente. *g. A qualquer momento o usuário solicita que tela de cadastro seja finalizada. 1. Sistema pergunta se usuário deseja salvar os dados presentes na tela. 2. Usuário informa opção desejada. a. Opção escolhida foi salvar. 1. Sistema continua a partir do passo 5 do fluxo básico. b. Opção escolhida foi descartar dados. 1. Sistema encerra tela de cadastro. *h. A qualquer momento usuário solicita novo cadastro antes de finalizar o cadastro atual. 1. Sistema pergunta se usuário deseja continuar cadastro atual. 2. Usuário informa opção desejada. a. Opção escolhida foi continuar. 1. Usuário continua cadastro atual. b. Opção escolhida foi começar um novo cadastro. 1. Sistema continua a partir do passo 2 do fluxo básico. *i. Usuário já está cadastrado. 1. Sistema informa que o usuário já está cadastrado. 2. Sistema limpa o campo do CPF. 3. Sistema continua a partir do passo 4 do fluxo básico. *j. Falha de registro no banco de dados. 1. Sistema informa qual foi a falha ocorrida. 2. Sistema continua a partir do passo 4 do fluxo básico. Caso de uso CDU4: alterar usuário Escopo: Alterar cadastro de usuários. Ator principal: Gestor. Interessados e interesses: − Usuário: Deseja atualizar seu cadastro. 41 Pré-condições: − Usuário deverá estar cadastrado no sistema. − O sistema precisa estar desbloqueado. − Apenas usuários “Master” e “Gestor”, poderão alterar os cadastros de usuários. Fluxo básico: 1. Acessa tela de cadastro. 2. Sistema limpa os campos da tela. 3. Usuário informa quem será alterado. 4. Sistema verifica se usuário existe. 5. Sistema mostra os dados do usuário escolhido. 6. Sistema solicita os novos dados. 7. Usuário informa os novos dados. 8. Sistema verifica se senha e contra-senha são iguais, e se não estão vazias. 9. Sistema valida CPF. 10. Sistema verifica pelo CPF se novo usuário já existe. 11. Sistema registra dados. 12. Sistema registra qual usuário, data e hora que efetivou a alteração. 13. Usuário recebe confirmação de alteração do cadastro. 14. Sistema limpa os campos da tela de cadastro. Fluxos alternativos: *a. Senha diferente de contra-senha. 1. Usuário recebe informação de que a senha e contra-senha estão diferentes. 2. Sistema limpa campos da senha e da contra-senha. *b. Campo senha não está preenchido. 1. Sistema informa que o campo senha está vazio. *c. Campo CPF está vazio. 1. Sistema informa que o campo CPF está vazio. *d. Campo nome está vazio. 1. Sistema informa que o campo nome está vazio. *e. Campo usuário está vazio. 1. Sistema informa que o campo usuário está vazio. 42 *f. CPF inválido. 1. Sistema informa que o CPF é invalido. 2. Sistema limpa o campo do CPF para inserir novamente. *g. A qualquer momento o usuário solicita que tela de cadastro seja finalizada. 1. Sistema pergunta se usuário deseja salvar os dados presentes na tela. 2. Usuário informa opção desejada. a. Opção escolhida foi salvar. 1. Sistema continua a partir do passo 7 do fluxo básico. b. Opção escolhida foi descartar dados. 1. Sistema encerra tela de cadastro. *h. A qualquer momento usuário solicita novo cadastro antes de finalizar o cadastro atual. 1. Sistema pergunta se usuário deseja continuar alteração de cadastro atual. 2. Usuário informa opção desejada. a. Opção escolhida foi continuar. 1. Usuário continua cadastro atual. b. Opção escolhida foi começar um novo cadastro. 1. Sistema continua a partir do passo 2 do fluxo básico. *i. Usuário já está cadastrado. 1. Sistema informa que o usuário já está cadastrado. 2. Sistema limpa o campo do CPF. 3. Sistema continua a partir do passo 6 do fluxo básico. *j. Falha de registro no banco de dados. 1. Sistema informa qual a falha ocorrida. 2. Sistema continua a partir do passo 6 do fluxo básico. Caso de uso CDU5: remover usuário Escopo: Remove o usuário desde que ele não tenha nenhum vinculo com os dados do sistema. Ator principal: Gestor. 43 Interessados e interesses: − Usuário: Deseja remover cadastro do sistema. Pré-condições: − Usuário a ser removido deverá estar cadastrado no sistema. − O sistema precisa estar desbloqueado. − Apenas usuários “Master” e “Gestor”, poderão remover os cadastros de usuários. Fluxo básico: 1. Usuário acessa tela de cadastro. 2. Sistema limpas os campos da tela. 3. Usuário informa quem será removido. 4. Sistema verifica se o usuário a ser removido está cadastrado. 5. Sistema mostra os dados do usuário. 6. Usuário solicita a remoção do cadastro. 7. Sistema solicita confirmação para remoção. 8. Sistema remove usuário. 9. Sistema registra qual usuário, data e hora que efetivou a remoção. 10. Sistema informa que usuário foi removido. Fluxos alternativos: *a. Usuário não está cadastrado. 1. Sistema informa que usuário não está cadastrado ou já foi removido. 2. Sistema continua a partir do passo 2 do fluxo básico. *b. Sistema não consegue encontrar as informações do usuário escolhido. 1. Sistema informa que teve problema para buscar os dados do usuário. 2. Sistema continua a partir do passo 2 do fluxo básico. *c. Na resposta de confirmação usuário opta por não remover. 1. Mantêm os dados do usuário na tela. 2. Aguarda próxima opção do usuário. *d. Erro no momento da remoção. 1. Sistema informa que não conseguiu remover o usuário. 2. Sistema continua a partir do passo 2 do fluxo básico. 44 Caso de uso CDU06: consultar usuário Escopo: Onde o sistema acessa uma lista de cadastro de usuários e retorna os dados do usuário em questão. Ator principal: Sistema. Interessados e interesses: − Usuário: Deseja saber seus dados. Pré-condições: − O sistema precisa estar desbloqueado. Pós-condições: − Retorna os dados do usuário. Fluxo básico: 1. Usuário informa o critério para consulta (CPF ou nome). 2. Sistema pesquisa o usuário em uma lista de usuários já cadastrados. 3. Sistema retorna os dados do usuário encontrado. Fluxos alternativos: *a. Usuário não foi encontrado na lista. 1. Sistema informa que usuário não está cadastrado. Caso de uso CDU07: criar modelo Escopo: Cria um novo modelo, definindo os tipos diferentes de documentos prémoldados. Ator principal: Gestor. Interessados e interesses: − Empresa: Padronizar os documentos da empresa. Pré-condições: − Apenas usuários “Master” e “Gestor”, poderão fazer a modelagem do documento. − O sistema precisa estar desbloqueado. Fluxo básico: 45 1. Usuário acessa a tela de modelagem. 2. Sistema limpa toda a tela. 3. Usuário informa dados descritivos do modelo (id, nome, descrição, etc.). 4. Usuário adiciona campo. 1. Sistema cria o campo com nome padrão e disponibiliza o campo em uma lista de campos disponíveis. 2. Usuário informa as propriedades do campo (nome, tipo de letra, tamanho da letra, etc.). 3. Sistema verifica se foi informado o nome do campo. 4. Sistema verifica se já existe campo com este nome no mesmo modelo. 5. Usuário continua repetindo estes procedimentos até adicionar todos os campos desejados. 5. Usuário move o campo escolhido da lista de campos disponíveis, posicionando-o no local desejado da área modelagem. 6. Sistema registra qual usuário, data e hora que criou o modelo. Fluxos alternativos: *a. Ocorrer erro durante a criação do campo. 1. Sistema informa que ocorreu o erro. 2. Sistema retorna ao passo 4 do fluxo básico. *b. O nome do campo não foi informado. 1. Sistema informa que o nome do campo ainda não foi informado. 2. Sistema solicita que seja informado o nome do campo. 3. Sistema continua a partir do item 4.2 do fluxo básico. *c. Já existe um campo cadastrado no modelo com o mesmo nome. 1. Sistema informa que o campo já existe. 2. Continua a partir do passo 4 do fluxo básico. *d. Ocorreu um erro no momento em que o campo é movimentado. 1. Sistema informa o erro ocorrido. 2. Sistema retorna o campo para a lista de campos disponíveis. 3. Sistema continua a partir do passo 5 do fluxo básico. 46 *e. A qualquer momento usuário fecha ou solicita novo modelo antes de finalizar o modelo atual. 1. Sistema pergunta se usuário deseja continuar a modelagem atual. 2. Usuário informa opção desejada. a. Opção escolhida foi continuar. 1. Usuário continua modelagem atual. b. Opção escolhida foi não continuar. 2. Sistema continua a partir do passo 2 do fluxo básico. Caso de uso CDU08: consultar modelo Escopo: Onde o sistema acessa uma lista de modelos já cadastrados e retorna os dados do modelo em questão. Ator principal: Sistema. Interessados e interesses: − Sistema: Deseja saber se o modelo existe para não haja duplicidade. Pré-condições: − O sistema precisa estar desbloqueado. Pós-condições: − Retorna os dados do modelo. Fluxo básico: 1. Usuário informa o critério para consulta (Id ou nome). 2. Sistema pesquisa em uma lista de modelos já salvos. 3. Sistema retorna os dados do modelo encontrado. Fluxos alternativos: *a. Modelo não foi encontrado na lista. 1. Sistema informa que modelo não está cadastrado. 47 Caso de uso CDU09: alterar modelo Escopo: Onde o usuário irá alterar o modelo do documento, desde que nenhum documento tenha sido criado a partir do modelo a ser alterado. Ator principal: Gestor. Interessados e interesses: − Usuário: Poderá alterar um modelo, para que não haja a necessidade de excluir e criar outro. Pré-condições: − Apenas usuários “Master” e “Gestor”, poderão fazer alterações no modelo. − O sistema precisa estar desbloqueado. − O modelo precisa existir. − Não poderá existir nenhum documento produzido a partir do modelo a ser alterado. Fluxo básico: 1. Usuário acessa a tela de modelagem. 2. Sistema limpa a tela. 3. Usuário informa o modelo. 4. Sistema verifica se não existe nenhum documento produzido a partir do modelo a ser alterado. 5. Sistema busca dados do modelo. 6. Usuário informa os novos dados descritivos do modelo. 7. Usuário adiciona novos campos. 1. Sistema cria o campo com nome padrão e disponibiliza o campo em uma lista de campos disponíveis. 2. Usuário informa as propriedades do campo (nome, tipo de letra, tamanho da letra, etc.). 3. Sistema verifica se foi informado o nome do campo. 4. Sistema verifica se já existe campo com este nome no mesmo modelo. 5. Usuário continua repetindo estes procedimentos até adicionar todos os campos desejados. 8. Usuário altera campos do modelo. 48 1. Usuário seleciona o campo desejado. 2. Sistema informa as propriedades do campo escolhido. 3. Usuário informa as novas propriedades do campo. 4. Sistema verifica se foi informado o nome do campo. 5. Sistema verifica se já existe campo com este nome no mesmo modelo. 6. Usuário continua repetindo estes procedimentos até alterar todos os campos desejados. 9. Usuário exclui campos do modelo. 1. Usuário seleciona o campo desejado. 2. Sistema informa as propriedades do campo. 3. Usuário confirma exclusão. 4. Sistema exclui o campo. 10. Usuário movimenta os campos na tela alterando-os de posição de acordo com suas necessidades. 11. Sistema registra qual usuário, data e hora que efetivou a alteração. Fluxos alternativos: *a. Ocorrer erro durante a criação do campo. 1. Sistema informa que ocorreu o erro. 2. Sistema retorna ao passo 7 do fluxo básico. *b. Ocorrer erro durante a alteração do campo. 1. Sistema informa que ocorreu o erro. 2. Sistema retorna ao passo 8 do fluxo básico. *c. Ocorrer erro durante a remoção do campo. 1. Sistema informa que ocorreu o erro. 2. Sistema retorna ao passo 9 do fluxo básico. *d. O nome do campo não foi informado 1. Sistema informa que o nome do campo ainda não foi informado. 2. Sistema solicita que seja informado o nome do campo. *e. Já existe um campo cadastrado no modelo com o mesmo nome. 1. Sistema informa que o campo já existe. *f. Existe um documento produzido a partir do modelo desejado. 49 1. Sistema informa que não poderá alterar. 2. Sistema continua a partir do passo 2 do fluxo básico. *g. Ocorreu um erro no momento em que o campo é movimentado 1. Sistema informa o erro ocorrido. 2. Sistema retorna o campo para a lista de campos disponíveis. 3. Sistema continua a partir do passo 10 do fluxo básico. *h. A qualquer momento usuário fecha ou solicita novo modelo antes de finalizar a alteração do modelo. 1. Sistema pergunta se usuário deseja continuar alteração do modelo atual. 2. Usuário informa opção desejada. a. Opção escolhida foi continuar. 1. Usuário continua alteração do modelo atual. b. Opção escolhida foi não continuar. 3. Sistema continua a partir do passo 2 do fluxo básico. Caso de uso CDU10: remover modelo Escopo: O modelo pode ser removido desde que nenhum documento tenha sido produzido a partir do modelo a ser removido. Ator principal: Gestor. Interessados e interesses: − Usuário: Poderá remover o modelo que não tenha sido aprovado. Pré-condições: − Apenas usuários “Master” e “Gestor”, poderão remover um modelo. − O sistema precisa estar desbloqueado. − O modelo precisa existir. − Não poderá existir nenhum documento produzido a partir do modelo a ser removido. Fluxo básico: 1. Usuário acessa tela de modelagem. 2. Sistema limpas os campos da tela. 3. Usuário informa o modelo para ser removido. 50 4. Sistema verifica se o modelo a ser removido está cadastrado. 5. Sistema verifica se não existe documento produzido a partir do modelo desejado. 6. Sistema mostra os dados do modelo. 7. Usuário solicita a remoção do modelo. 8. Sistema solicita confirmação para remoção. 9. Sistema remove modelo. 10. Sistema registra qual usuário, data e hora que efetivou a remoção. 11. Sistema informa que modelo foi removido. Fluxos alternativos: *a. Modelo não está cadastrado. 1. Sistema informa que modelo não existe. 2. Sistema continua a partir do passo 2 do fluxo básico. *b. Sistema não consegue encontrar as informações do modelo escolhido. 1. Sistema informa que teve problema para buscar os dados do modelo. 2. Sistema continua a partir do passo 2 do fluxo básico. *c. Existe um documento produzido a partir do modelo desejado. 1. Sistema informa que documento não pode ser removido. 2. Sistema continua a partir do passo 2 do fluxo básico. *d. Na resposta de confirmação usuário opta por não remover. 1. Mantêm os dados do modelo na tela. 2. Aguarda próxima opção do usuário. *e. Erro no momento da remoção. 3. Sistema informa que não conseguiu remover o modelo. 4. Sistema continua a partir do passo 2 do fluxo básico. Caso de uso CDU11: liberar modelo Escopo: Libera o modelo para poder dar continuidade na produção do documento. Ator principal: Gestor. Interessados e interesses: − Usuário: Quando estiver pronto o usuário poderá validar antes de liberá-lo para uso. 51 Pré-condições: − Apenas usuários “Master” e “Gestor”, poderão liberar o modelo. − O sistema precisa estar desbloqueado. − O modelo precisa estar registrado no banco. Fluxo básico: 1. Usuário informa o modelo desejado. 2. Sistema verifica se foi informado o modelo 3. Sistema verifica se o modelo existe. 4. Sistema verifica se o modelo não está liberado. 5. Sistema libera o modelo para uso. 6. Sistema registra qual usuário, data e hora que liberou o modelo. 7. Sistema informa que o modelo está liberado. Fluxos alternativos: *a. O modelo não foi informado. 1. Sistema informa que faltou informar o modelo. 2. Sistema solicita que seja informado o modelo. *b. O modelo desejado não existe. 1. Sistema informa que o modelo não existe. 2. Sistema solicita que seja informado outro modelo. Caso de uso CDU12: criar documento Escopo: Insere os dados do novo documento de acordo com o modelo escolhido. Ator principal: Digitador. Pré-condições: − Apenas usuários “Master”, “Gestor” e “Digitador”, poderão criar o documento. − O sistema precisa estar desbloqueado. − O modelo precisa estar liberado. Fluxo básico: 1. Sistema limpa a tela. 2. Usuário informa um nome para o documento. 52 3. Sistema verifica se não existe um documento com o mesmo nome. 4. Usuário informa o modelo desejado a partir de uma lista de modelos já registrados e liberados. 5. Sistema preenche a tela com os campos do modelo escolhido. 6. Usuário preenche os campos do modelo. 7. Usuário salva o documento. 8. Sistema salva as informações dos campos. 9. Sistema salva as informações do documento. 10. Sistema registra qual usuário, data e hora que criou o documento. 11. Sistema informa que novo documento foi criado. Fluxos alternativos: *a. Já existe um documento com o nome desejado. 1. Sistema informa que já existe documento. 2. Sistema continua a partir do passo 4 do fluxo básico. *b. Sistema não consegue buscar os campos do modelo 1. Sistema informa o erro. *c. O modelo desejado não existe. 1. Sistema informa que o modelo não existe. 2. Sistema solicita que seja informado outro modelo. Caso de uso CDU13: consultar documento Escopo: Onde o sistema acessa uma lista de documentos já registrados e retorna os dados do documento em questão. Ator principal: Consultor. Interessados e interesses: − Usuário: Deseja obter as informações do documento. Pré-condições: − O sistema precisa estar desbloqueado. Pós-condições: − Retorna os dados do documento. 53 Fluxo básico: 1. Usuário informa o critério para consulta (Id ou nome). 2. Sistema pesquisa em uma lista de documentos já registrados e liberados. 3. Sistema retorna os dados do documento encontrado. Fluxos alternativos: *a. Documento não foi encontrado na lista. 1. Sistema informa que documento não está cadastrado. Caso de uso CDU14: alterar documento Escopo: É feito uma copia do documento escolhido, onde as alterações serão realizadas na copia, deixando a original inalterada. Para que no futuro possa ser visualizada a diferença entre cada versão do documento já alterado. Ator principal: Digitador. Interessados e interesses: − Usuário: Poderá alterar o documento, para que não haja a necessidade de excluir e criar outro. Pré-condições: − Apenas usuários “Master”, “Gestor” e “Digitador”, poderão fazer alterações no modelo. − O sistema precisa estar desbloqueado. − O documento precisa existir. Fluxo básico: 1. Sistema limpa a tela. 2. Usuário informa o documento. 3. Sistema verifica se existe o documento. 4. Sistema busca os dados do documento. 5. Sistema cria um copia idêntica do documento incrementando a versão que será alterada. 6. Sistema mostra na tela os dados do documento. 7. Usuário informa os novos dados do documento (nome, id, descrição, etc.). 54 8. Usuário informa os novos dados dos campos. 9. Usuário salva documento. 10. Sistema valida os dados. 11. Sistema verifica se já existe documento com o mesmo nome. 12. Sistema salva dados dos campos. 13. Sistema salva dados do documento. 14. Sistema registra qual usuário, data e hora que alterou o documento. 15. Sistema informa que documento foi alterado. Fluxos alternativos: *a. Não existe o documento. 1. Sistema informa que não poderá alterar. 2. Sistema continua a partir do passo 1 do fluxo básico. *b. A qualquer momento usuário fecha ou solicita novo documento antes de finalizar a alteração do documento. 1. Sistema pergunta se usuário deseja continuar alteração do documento atual. 2. Usuário informa opção desejada. a. Opção escolhida foi continuar. 1. Usuário continua alteração do documento atual. b. Opção escolhida foi não continuar. 4. Sistema continua a partir do passo 1 do fluxo básico. Caso de uso CDU15: remover documento Escopo: Onde o usuário irá remover o documento. Ator principal: Master. Interessados e interesses: − Usuário: Poderá remover os documentos considerados inutilizados para obter mais disponibilidade de espaço. Pré-condições: − Apenas usuário “Master”, poderá remover documento. − O sistema precisa estar desbloqueado. 55 − O documento precisa existir. Fluxo básico: 1. Sistema limpa a tela. 2. Usuário informa o documento. 3. Sistema verifica se existe o documento. 4. Sistema busca e informa os dados do documento. 5. Usuário confirma exclusão. 6. Sistema remove documento. 7. Sistema registra qual usuário, data e hora que removeu o documento. 8. Sistema informa que o documento foi removido. Fluxos alternativos: *a. Não existe o documento. 1. Sistema informa que não poderá remover. 2. Sistema continua a partir do passo 1 do fluxo básico. Caso de uso CDU16: liberar documento Escopo: Libera o documento para que os demais usuários possam utilizá-los conforme as atribuições de cada um. Ator principal: Master. Interessados e interesses: − Usuário: Controlar as disponibilidades do documento. Pré-condições: − Apenas usuário “Master”, irá liberar o documento. − O sistema precisa estar desbloqueado. Fluxo básico: 1. Usuário informa o documento que deseja liberar. 2. Sistema verifica se o documento existe. 3. Sistema verifica se o documento não está liberado. 4. Sistema informa os dados do documento na tela. 56 5. Usuário escolhe quais os usuários que terão permissão de uso em relação ao documento. 6. Usuário confirma liberação. 7. Sistema libera documento. 8. Sistema registra qual usuário, data e hora que liberou o documento. 9. Sistema informa que o documento foi liberado com sucesso. Fluxos alternativos: *a. O documento informado não existe. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. *b. Documento já consta como liberado. 1. Sistema informa que o documento desejado já está liberado. Caso de uso CDU17: divulgar documento Escopo: Após o sistema liberar o documento, o sistema irá enviar e-mail para cada usuário selecionado para visualizar o documento. Ator principal: Digitador. Interessados e interesses: − Usuário: Informa aos outros usuários que o documento está pronto para ser utilizado. Pré-condições: − Apenas usuários “Master”, “Gestor” e “Digitador”, irão divulgar o documento. − O documento precisa estar liberado. − O sistema precisa estar desbloqueado. Fluxo básico: 1. Usuário informa o documento que deseja divulgar. 2. Sistema verifica se o documento existe. 3. Sistema verifica se o documento está liberado. 4. Sistema envia e-mail para os usuários com permissão de uso do documento. 5. Sistema registra qual usuário, data e hora que divulgou o documento. 57 6. Sistema informa que o documento foi divulgado com sucesso. Fluxos alternativos: *a. O documento informado não existe. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. *b. Sistema não consegue enviar e-mail. 1. Sistema informa que não conseguiu fazer a divulgação. *c. Documento não consta como liberado 1. Sistema informa que o documento desejado não está liberado. Caso de uso CDU18: imprimir documento Escopo: Impressão do documento. Ator principal: Consultor. Interessados e interesses: − Usuário: Poder enviar para outras empresas ou setores que não utilizam o sistema. Pré-condições: − O documento precisa estar liberado para o usuário que deseja imprimir o documento. − O sistema precisa estar desbloqueado. Fluxo básico: 1. Usuário informa o documento que deseja imprimir. 2. Sistema verifica se o documento existe. 3. Sistema verifica se o documento está liberado. 4. Sistema imprime documento. Fluxos alternativos: *a. O documento informado não existe. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. *b. Documento não consta como liberado 1. Sistema informa que o documento desejado não está liberado. 58 Caso de uso CDU19: mover documento para arquivo morto Escopo: Enviar para arquivo morto os documentos que atualmente não estão em uso. Ator principal: Master. Interessados e interesses: − Master: Poder diminuir a carga de documento no sistema. Pré-condições: − O sistema precisa estar desbloqueado. Fluxo básico: 1. Usuário informa o documento que deseja enviar para arquivo morto. 2. Sistema verifica se o documento existe. 3. Usuário confirma o envio. 4. Sistema envia para o arquivo morto 5. Sistema registra qual usuário, data e hora que enviou o documento. 6. Sistema informa que o documento foi enviado para o arquivo morto. Fluxos alternativos: *a. O documento informado não existe 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. Caso de uso CDU20: recuperar documento do arquivo morto Escopo: Recuperar documentos do arquivo morto, para que possam ser usados novamente. Ator principal: Master. Interessados e interesses: − Master: Disponibilizar um documento considerado inativo. Pré-condições: − O sistema precisa estar desbloqueado. − Documento precisa estar no arquivo morto. 59 Fluxo básico: 1. Usuário informa o documento que deseja recuperar. 2. Sistema verifica se o documento existe no arquivo morto. 3. Usuário confirma a recuperação. 4. Sistema verifica se já existe documento com o mesmo nome nos arquivos ativos. 5. Sistema recupera o documento. 6. Sistema registra qual usuário, data e hora que recuperou o documento. 7. Sistema informa que o documento foi recuperado. Fluxos alternativos: *a. O documento informado não existe no arquivo morto. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. *b. Já existe um documento com o mesmo nome na lista de documentos ativos. 1. Sistema informa que já existe documento com o mesmo nome. 2. Sistema solicita que seja informado um novo nome para o documento que está sendo recuperado. 3. Usuário informa o novo nome. Caso de uso CDU21: remover do arquivo morto Escopo: Remove definitivamente do sistema o documento. Ator principal: Master. Interessados e interesses: − Master: Diminuir a carga de dados no arquivo morto. Pré-condições: − O sistema precisa estar desbloqueado. − Documento precisa estar no arquivo morto. Fluxo básico: 1. Usuário informa o documento que deseja remover. 2. Sistema verifica se o documento existe no arquivo morto. 3. Usuário confirma a remoção. 60 4. Sistema remove documento do arquivo morto. 5. Sistema registra qual usuário, data e hora que removeu o documento. 6. Sistema informa que o documento foi removido do arquivo morto. Fluxos alternativos: *a. O documento informado não existe no arquivo morto. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. Caso de uso CDU22: consultar arquivo morto Escopo: Onde o sistema acessa uma lista de documentos já registrados no arquivo morto e retorna os dados do documento em questão. Ator principal: Master. Interessados e interesses: − Master: Visualizar o documento do arquivo morto. Pré-condições: − O sistema precisa estar desbloqueado. Fluxo básico: 1. Usuário informa o documento. 2. Sistema verifica se o documento existe no arquivo morto. 3. Sistema pesquisa em uma lista de documentos já registrados no arquivo morto. 4. Sistema retorna os dados do documento encontrado. Fluxos alternativos: *a. O documento informado não existe no arquivo morto. 1. Sistema informa que não existe. 2. Sistema solicita que seja informado outro documento. 3.7.2. REQUISITOS NÃO FUNCIONAIS • Registrar copia do documento gerado com formato pdf em HD; • Copia de segurança do banco de dados; 61 3.8. DIAGRAMA DE CLASSES Figura 3.8 – Diagrama de classes. Observando-se a figura 3.8, verifica-se a composição das classes e seus relacionamentos. 62 3.9. DIAGRAMA DE ENTIDADES E RELACIONAMENTOS DO BANCO DE DADOS Figura 3.9 – Diagrama de relacionamentos do bando de dados. Observando-se a figura 3.9, verifica-se a composição das entidades do banco de dados e seus relacionamentos, criados a partir do modelo de dados orientados ao objeto. 63 3.10. DIAGRAMA DE SEQUÊNCIA Figura 3.10 – DDS01 Diagrama de seqüência acessar sistema. Observando-se a figura 3.10, verifica-se a seqüência de eventos e interações entre o sistema e o usuário, necessários para o desbloqueio das funcionalidades do sistema de acordo com o nível de permissão do usuário ao sistema. 64 Figura 3.11 – DDS02 Diagrama de seqüência bloquear sistema. Observando-se a figura 3.11, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para o bloqueio das telas utilizadas por determinado usuário. 65 Figura 3.12 – DDS03 Diagrama de seqüência cadastrar usuário. Observando-se a figura 3.12, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar o cadastro do usuário. 66 Figura 3.13 – DDS04 Diagrama de seqüência alterar usuário. Observando-se a figura 3.13, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar a alteração do cadastro do usuário. 67 Figura 3.14 – DDS05 Diagrama de seqüência remover usuário. Observando-se a figura 3.14, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar a remoção do usuário. 68 Figura 3.15 – DDS06 Diagrama de seqüência consultar usuário. Observando-se a figura 3.15, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar consulta de usuários. Figura 3.16 – DDS08 Diagrama de seqüência consultar modelo. Observando-se a figura 3.16, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar consulta aos modelos. 69 Figura 3.17 –DDS07 Diagrama de seqüência criar modelo. Observando-se a figura 3.17, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para a criação do modelo. 70 Figura 3.18 – DDS09 Diagrama de seqüência alterar modelo. Observando-se a figura 3.18, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para alterar o modelo. 71 Figura 3.19 – DDS10 Diagrama de seqüência remover modelo. Observando-se a figura 3.19, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar a remoção do modelo. 72 Figura 3.20 – DDS11 Diagrama de seqüência liberar modelo. Observando-se a figura 3.20, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para liberar o modelo para uso. 73 Figura 3.21 – DDS12Diagrama de seqüência criar documento. Observando-se a figura 3.21, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para criar o documento. 74 Figura 3.22 – DDS13 Diagrama de seqüência consultar documento. Observando-se a figura 3.22, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar consulta de documentos. 75 Figura 3.23 – DDS14 Diagrama de seqüência alterar documento. Observando-se a figura 3.23, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para alterar o documento. 76 Figura 3.24 – DDS15 Diagrama de seqüência remover documento. Observando-se a figura 3.24, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar a remoção do documento. 77 Figura 3.25 – DDS16 Diagrama de seqüência liberar documento. Observando-se a figura 3.25, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para liberar o documento. 78 Figura 3.26 – DDS17 Diagrama de seqüência divulgar documento. Observando-se a figura 3.26, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se efetuar a divulgação do documento. 79 Figura 3.27 – DDS18 Diagrama de seqüência imprimir documento. Observando-se a figura 3.27, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para imprimir o documento. 80 Figura 3.28 – DDS19 Diagrama de seqüência mover documento para o arquivo morto. Observando-se a figura 3.28, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para mover o documento para o arquivo morto. 81 Figura 3.29 – DDS20 Diagrama de seqüência recuperar documento do arquivo morto. Observando-se a figura 3.29, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para recuperar o documento do arquivo morto. 82 Figura 3.30 – DDS21 Diagrama de seqüência remover documento do arquivo morto. Observando-se a figura 3.30, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para remover o documento do arquivo morto. Figura 3.31 – DDS22 Diagrama de seqüência consultar documento no arquivo morto. Observando-se a figura 3.31, verifica-se a seqüência de eventos e interações entre o usuário e o sistema, necessários para se consultar o documento no arquivo morto. 83 3.11. INTERFACES DE USUÁRIO Nesta seção são ilustradas a figuras que representam os modelos de telas do sistema a serem apresentadas aos usuários, conforme a função desejada. Figura 3.32 – Tela 01 - Tela principal do sistema. Observando-se a figura 3.32, verifica-se a tela principal do sistema, seus menus: Arquivo, Documento, Modelo e Usuário. Temos também no canto inferior esquerdo: a imagem de um cadeado indicando que o sistema está bloqueado, no meio uma mensagem indicando que nenhum usuário está logado e no canto inferior direito a seqüência numérica que indica a versão do sistema. 84 Figura 3.33 – Tela 02 - Tela principal do sistema. Observando-se a figura 3.33, verifica-se o sub menu do menu Arquivo, onde o usuário poderá escolher as ações de configurar, liberar, bloquear e sair do sistema. 85 Figura 3.34 – Tela 03 - Tela principal do sistema. Observando-se a figura 3.34, verifica-se o sub menu do menu Documento, onde o usuário poderá escolher as ações de gerenciar e liberar o documento. 86 Figura 3.35 – Tela 04 - Tela principal do sistema. Observando-se a figura 3.35, verifica-se o sub menu do menu Modelo, onde o usuário poderá escolher as ações de modelar ou liberar o modelo. 87 Figura 3.36 – Tela 05 - Tela principal do sistema. Observando-se a figura 3.36, verifica-se o sub menu do menu Usuário, onde o usuário poderá escolher a ação de cadastrar outro usuário no sistema. 88 Figura 3.37 – Tela 06 - Acessar sistema. Observando-se a figura 3.37, verifica-se a tela de acesso ao sistema, onde o usuário poderá inserir o nome de usuário e a senha de acesso ao sistema. 89 Figura 3.38 – Tela 07 - Configurar sistema. Observando-se a figura 3.38, verifica-se a tela de configuração do sistema, onde o usuário poderá editar as preferências do sistema: modo de inicialização do sistema e modo de apresentação da tela de acesso ao sistema. 90 Figura 3.39 – Tela 08 – Configurar sistema. Observando-se a figura 3.39, verifica-se a aba de teste de conexão Banco, na tela de configuração do sistema, onde o usuário poderá informar o nome do driver ODBC Postegre para a conexão com o banco de dados. 91 Figura 3.40 – Tela 09 – Teste de conexão do banco de dados. Observando-se a figura 3.40, verifica-se a tela de configuração do sistema, onde o usuário ao clicar no ícone , inicializará um teste de conexão do sistema com o banco de dados, apresentado pela tela Teste de conexão, que irá mostrar o andamento do teste e seus resultados. 92 Figura 3.41 – Tela 10 – Gerenciamento de usuário. Observando-se a figura 3.41, verifica-se a tela gerenciamento de usuários, onde o usuário poderá escolher usuários em uma lista, limpar os campos do formulário ( por nome de usuário ( ), salvar dados ( ), remover ( ) ou fechar a tela ( ). ), pesquisar 93 Figura 3.42 – Tela 11 – Gerenciamento de modelos. Observando-se a figura 3.42, verifica-se a tela de gerenciamento de modelos, onde o usuário poderá criar um novo modelo ( ), pesquisar modelos existentes na lista Modelos (lado esquerdo), pesquisar através do código ou o nome do modelo ( na lista Modelos (lado esquerdo) salvar ( Visual ( ), remover ( ), pesquisar modelos existentes ), acessar o menu Campos ( ) ou fechar a tela Modelos do sistema clicando no ícone . ) e 94 Figura 3.43 – Tela 12 – Gerenciamento de modelos. Observando-se a figura 3.43, verifica-se na tela de gerenciamento de modelos o sub menu do menu Campos, onde o usuário poderá adicionar campos fixos ou campos flexíveis ao modelo. 95 Figura 3.44 – Tela 13 – Gerenciamento de modelos. Observando-se a figura 3.44, verifica-se na tela de gerenciamento de modelos o sub menu do menu Visual, onde o usuário poderá atualizar o layout de construção do modelo (Renderizar) e visualizar o modelo. 96 Figura 3.45 – Tela 14 – Visualizar modelo. Observando-se a figura 3.45, verifica-se a tela de visualização do modelo, onde o usuário poderá visualizar, atualizar ( ícone . ) a imagem do modelo ou fechar a tela clicando no 97 Figura 3.46 – Tela 15 – Liberar modelo. Observando-se a figura 3.46, verifica-se a tela Liberar modelos, onde o usuário poderá selecionar os modelos em uma lista de modelos a serem liberados, confirmar os modelos escolhidos clicando em no ícone e fechar a tela, clicando no ícone . 98 Figura 3.47 – Tela 16 – Gerenciamento de documentos. Observando-se a figura 3.47, verifica-se a tela de gerenciamento de documentos, onde o usuário poderá criar um novo documento ( ) a partir do modelo selecionado, salvar ( pesquisar através do código ou nome do documento ( tela ( ), remover documentos ( ), pesquisar os documentos em uma lista de documentos. ), ), fechar a 99 Figura 3.48 – Tela 17 – Liberar documento. Observando-se a figura 3.48, verifica-se a tela Liberar documentos, onde o usuário poderá selecionar os documentos em uma lista de documentos a serem liberados, limpar os campos com as informações dos documentos ( no ícone e fechar a tela, clicando no ícone ), confirmar os documentos escolhidos clicando . 100 Figura 3.49 – Tela 18 – Consultar documento. Observando-se a figura 3.48, verifica-se a tela Consultar documentos, onde o usuário poderá selecionar o documento que deseja visualizar em uma lista de documentos que estão devidamente liberados para o usuário em especifico, limpar o espaço onde o do documento escolhido aparece ( clicando no ícone ), imprimir o documento escolhido clicando no ícone ( . ) e fechar a tela, 101 Figura 3.50 – Tela 19 – Divulgar documento. Observando-se a figura 3.50, verifica-se a tela Divulgar documento, onde o usuário poderá selecionar os documentos em uma lista de documentos a serem divulgados, limpar os campos com as informações dos documentos ( selecionados ( ) ou fechar a tela ( ). ), divulgar o documento aos usuários 102 Figura 3.51 – Tela 20 – Arquivo Morto. Observando-se a figura 3.51, verifica-se a tela Arquivo morto, onde o usuário poderá visualizar se o documento desejado está no arquivo morto ou o arquivo corrente, limpar para preparar a tela e atualizar ambas as listas de arquivos ( ( ), pesquisar o documento por nome ), poderá enviar um documento para o arquivo morto arrastando o documento da lista documentos operantes para a lista de documentos desativados, quando for para restaurar um arquivo que está localizado no arquivo morto basta arrastar o arquivo da lista de arquivos desativados para a lista de arquivos operantes, remover some removerá documentos localizados no arquivo morto ( ) ou fechar a tela ( ). 103 CAPÍTULO IV 4. CONCLUSÃO O objetivo inicial deste projeto foi aprofundar os conhecimentos na especialidade de engenharia de software, seguindo as principais técnicas utilizadas para o desenvolvimento de sistemas de software. Tal objetivo foi alcançado a contento devido aos estudos realizados durante toda a fase de projeto, melhorando e ampliando os conhecimentos. Concluímos que os processos descritos, apesar de aparentemente simples no contexto, ocultam uma grande variedade de padrões com graus de complexidade variáveis. Porém o uso de ferramentas case como apoio ao desenvolvimento do sistema contribuiu significativamente com a agilidade da análise do mesmo. Observamos que o modelo em espiral do processo de software foi a melhor escolha, pois ao longo de todo o processo por várias vezes percebemos que teria de haver acréscimos ou mudanças em algumas fases do modelo. Apesar de ser um sistema GED, o sistema desenvolvido ainda não é capaz de gerenciar documentos eletrônicos que não fazem parte dele ou que não foram produzidos por ele, pois dois períodos não seriam suficientes para abordar esse tópico. Mas em contra partida o sistema é capaz de padronizar um documento e gerenciá-lo, evitando que documentos de mesma espécie tenham formatações diferentes. No futuro poderiam ser acrescentadas novas funcionalidades ao sistema, como por exemplo, gerenciar outros tipos de documentos eletrônicos, digitalizar e gerenciar documentos que estão em papel, inserir assinatura digital, reconhecimento do usuário por digital e visualização de um documento por uma página na web. 104 REFERÊNCIAS BIBLIOGRÁFICAS 1. ARQDIGITAL. Gerenciamento eletrônico de documentos – GED. Disponível em: <http://www.arqdigital.com.br/ged.htm>. Acesso em: 16 de Fevereiro, 2008. 2. Sommerville, Ian. Engenharia de software. Tradução: Selma Shin Shimuzu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa. São Paulo: Pearson Addison Wesley, 2007 – Sommerville. 3. Larman, Craig. Utilizando UML e padrões: Uma itrodução à análise e ao projeto orientados a objeto e ao desenvolvimento iterativo. Tradução Rosana Vaccare Braga. Porto Alegre: Bookman, 2007. 4. Presman, Roger S. Engenharia de software. Tradução Rosângela Delloso Penteado. São Paulo: McGall-Hill, 2006. 5. Deitel, H. M.. Visual Basic .NET : como programar . Tradução Célia Yumi Okano Taniwaki. São Paulo: Pearson Education do Brasil, 2004. 6. Majela, Geraldo Ferreira de Macedo. Bases para implantação de um sistema de gerenciamento eletrônico de documentos – GED. Disponível em: <http://teses.eps.ufsc.br/defesa/pdf/12288.pdf>. Acesso em: 10 de Abril, 2008. 7. Chaves, Prado Tecnologia e digitalização S/C Ltda. Disponível em: Captura, reconhecimento e armazenamento de imagens digitais <http://www.pradochaves.com.br/download/Digitalizacao.pdf>. Acesso em: 14 de Abril, 2008. 105 8. Martins Rossio, Neire. Reiney, Alice. Pires, Reinaldo. Digitalização de documentos. Disponível em: <http://www.powerbrasil.com.br/pdf/Digitalizacao_Unicamp.pdf>. Acesso em: 18 de Abril, 2008. 9. Luiz, Flavio D’Oliveira e Silva. Gerenciamento eletrônico de documentos (GED): Principio e aplicações. Disponível em: <http://www.arquivar.com.br/espaco_profissional/sala_leitura/teses-dissertacoes-emonografias/GED_natureza_principios_aplicacao.pdf>. Acesso em: 18 de Abril, 2008. 10. Vinícius, Marcos Mendonça Andrade. Gerenciamento eletrônico da informação: Ferramenta para a gerência eficiente dos processos de trabalho. Disponível em: <http://www.ndc.uff.br/textos/gei.pdf >. Acesso em: 19 de Abril, 2008. 11. Murrieta, Maíra Costa. A gestão eletrônica de documentos no estado maior da aeronáutica. Fundação Getúlio Vargas: MBA em administração estratégica de sistemas de informação. 2004, 73p. 12. PostegreeSql. About. Disponível em: <http://www.postgresql.org/about/>. Acesso em: 19 de Novembro, 2008. 106 GLOSSÁRIO Stakeholders – Se refere a qualquer pessoa ou grupo afetado pelo sistema a ser implantado, direta ou indiretamente. Os stakeholders incluem os usuários finais que interagem com o sistema e todo o pessoal na organização que possa ser afetado por sua instalação. Outros stakeholders podem ser os engenheiros que estão desenvolvendo ou mantendo sistemas relacionados, gerentes de negócios, especialistas do domínio e representantes do sindicato. Document Imaging - Processo de conversão dos documentos em suporte de papel ou microfilme em bitmaps eletrônico. Escanerização (ou digitalização) - Processo de conversão dos documentos em papel ou microfilme para uma seqüência de códigos binários feito, geralmente por scanner. Elicitar - Do lat. elicitus, part. pass. de elicere, ‘extrair’, ‘tirar de’, + -ar2; ingl. (to) elicit. Ferramenta CASE - Uma ferramenta CASE (do inglês Computer-Aided Software Engineering) é uma ferramenta de software como um editor de projeto ou debugger (depurador) de programa, usado para apoiar uma atividade no processo de desenvolvimento de software. UML – uma linguagem gráfica usada no desenvolvimento orientado a objetos, que inclui diversos tipos de modelos que fornecem diferentes visões de um sistema. A UML tornou-se um padrão de fato para a modelagem orientada a objetos.