ACADÊMICO - ACADSISTEM

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

Download "ACADÊMICO - ACADSISTEM"

Transcrição

1 FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS FATEC PROFESSOR JESSEN VIDAL CHRISTIANNE DE MELO SILVA PARAÍSO DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO - ACADSISTEM São José dos Campos 2011

2 CHRISTIANNE DE MELO SILVA PARAÍSO DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO - ACADSISTEM Trabalho de Graduação apresentado à Faculdade de Tecnologia São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Informática com Ênfase em Banco de Dados. Orientador: Me. Juliana Forin Pasquini Martinez São José dos Campos 2011

3 Dados Internacionais de Catalogação-na-Publicação (CIP) Divisão de Informação e Documentação PARAÍSO, Christianne M. S. Desenvolvimento de um Sistema de Controle Acadêmico - ACADSISTEM. São José dos Campos, f. Trabalho de Graduação Curso de Tecnologia em Informática com Ênfase em Banco de dados, FATEC de São José dos Campos: Professor Jessen Vidal, Orientador: Me. Juliana ForinPasquini Martinez. 1. Banco de Dados. I. Faculdade de Tecnologia. FATEC de São José dos Campos: Professor Jessen Vidal. Divisão de Informação e Documentação. II. Desenvolvimento de um Sistema de Controle Acadêmico ACADSISTEM. 2. REFERÊNCIA BIBLIOGRÁFICA PARAÍSO, Christianne M. S. Desenvolvimento de um Sistema de Controle Acadêmico - ACADSISTEM f. Trabalho de Graduação - FATEC de São José dos Campos: Professor Jessen Vidal CESSÃO DE DIREITOS NOME DO AUTOR: Christianne de Melo Silva Paraíso TÍTULO DO TRABALHO: Desenvolvimento de um Sistema de Controle Acadêmico - ACADSISTEM TIPO DO TRABALHO/ANO: Trabalho de Graduação / É concedida à FATEC de São José dos Campos: Professor Jessen Vidal permissão para reproduzir cópias deste Trabalho e para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte deste Trabalho pode ser reproduzida sem a autorização do autor. Christianne de Melo Silva Paraíso Av. Marechal Castelo Branco nº1400 Apto 543-B CEP Caçapava São Paulo

4 iii Christianne de Melo Silva Paraíso DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO - ACADSISTEM Trabalho de Graduação apresentado à Faculdade de Tecnologia São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Informática com Ênfase em Banco de dados. Murilo da Silva Dantas, Mestre em Computação Aplicada, Instituto Nacional de Pesquisas Espaciais - INPE Carlos Augusto Lombardi Garcia, Mestre em Engenharia Eletrônica e Computação, Instituto Tecnológico de Aeronáutica - ITA Juliana Forin Pasquini Martinez, Mestre em Ciências, Instituto Tecnológico de Aeronáutica ITA. / / DATA DA APROVAÇÃO

5 iv Dedico este trabalho a minha família que sempre esteve ao meu lado em todos os momentos.

6 v AGRADECIMENTOS Agradeço primeiramente a Deus por me proporcionar a realização deste trabalho e conclusão do mesmo com êxito, a minha família pela compreensão e atenção, aos professores da Faculdade de Tecnologia Jessen Vidal pelo que me foi ensinado, ao apoio da Faculdade Federal de Pelotas e a professora Juliana Forin Pasquini Martinez pela orientação deste trabalho.

7 vi RESUMO Ter o acompanhamento acadêmico dos alunos e orientadores é algo muito importante e relevante, além de ser um passo a frente para as Universidades. Isto torna-se difícil quando este processo é de forma manual, mas não quando se tem um sistema automatizado para tal. Com este intuito, no objetivo de solucionar esta situação, desenvolveu-se um sistema acadêmico denominado Sistema de Controle Acadêmico - ACADSISTEM, que tem como principal função o gerenciamento de alunos, orientadores e publicações. O software desenvolvido, além de fornecer o gerenciamento de alunos, orientadores e publicações, também apresenta os dados (informações) em tabelas e gera relatório de alunos. Neste projeto foi utilizado o conceito de Engenharia de Software, Banco de Dados, Padrões de Projetos e Processo Unificado da Rational. Palavra Chave: Controle acadêmico; universidade; pós-graduação; aluno; orientador; publicação; engenharia de software; banco de dados.

8 vii ABSTRACT Have the academic monitoring of students and supervisors is very important and relevant, and is a step forward for universities. This becomes difficult when this process is done manually, but not when you have an automated system to do so. For this purpose, in order to resolve this situation, we developed a system called academic Control System Academic - ACADSISTEM, whose main function is the management of students, advisors and publications. The software developed, and provides management of students, advisors and publications, it also presents the data (information) and generates tables of students report. In this project we used the concept of Software Engineering, Database, Design Patterns and Rational Unified Process. Keywords: Control academic; university; graduate; student; counselor; publishing; software engineering, database..

9 viii LISTA DE FIGURAS Figura 1 Modelo Cascata 19 Figura 2 - Ciclo de vida de desenvolvimento 21 Figura 3 As duas dimensões do RUP 22 Figura 4 As quatro fases do RUP 23 Figura 5 Exemplo de diagrama de caso de uso 27 Figura 6 - Exemplo de diagrama de sequência 28 Figura 7 Exemplo de diagrama de atividade 28 Figura 8 Exemplo de diagrama de Classe 29 Figura 9 Exemplo de diagrama de Estado 29 Figura 10 Exemplo de diagrama de Componente 30 Figura 11 Exemplo de diagrama de Utilização 30 Figura 12 Exemplo do Modelo Conceitual 31 Figura 13 Exemplo do Modelo Lógico 32 Figura 14 Exemplo de uma Classe 33 Figura 15 Representação de Herança e Polimorfismo 34 Figura 16 - Linguagem Orientada a Objetos, objetos trocando mensagem 35 Figura 17 - Visão geral da ferramenta AstahCommunity 36 Figura 18 - Visão geral da ferramenta BrModelo 37 Figura 19 - Driver para o servidor de banco de dados MySQL 37 Figura 20 Diagrama de Caso de Uso do Sistema 42 Figura 21 Diagrama de Classes do Sistema MVC 45 Figura 22 Diagrama View 46 Figura 23 Diagrama Controllers 47 Figura 24 Diagrama Model 48 Figura 25 Diagrama de Sequência - Autenticação 49 Figura 26 Diagrama de Sequência - Cadastro de Aluno 50 Figura 27 Diagrama de Atividade de Exclusão de Orientador 51 Figura 28 Diagrama de Atividade de Pesquisa de Aluno 52 Figura 29 Diagrama de Estado de Cadastro de Usuário 53 Figura 30 Diagrama de Componente Geral 53 Figura 31 - Tela de Autenticação 54 Figura 32 Modelo Conceitual do Sistema 55 Figura 33 - Modelo Lógico do Sistema 56 Figura 34 Interface Sujeito 57 Figura 35 Classe Modelo 58 Figura 36 Classe Usuário 59 Figura 37 Interface Observador 59 Figura 38 Classe GerenciamentoView 60 Figura 39 - Interface Cadastro 60 Figura 40 Classe CadastroUsuário 61 Figura 41 Tela de Autenticação 102 Figura 42 Tela de Principal do Administrador 103 Figura 43 Tela de Principal do Usuário Comum 103 Figura 44 Tela De Gerenciamento de Aluno 104 Figura 45 Tela De Gerenciamento de Usuário 105 Figura 46 Tela De Gerenciamento de Orientador 105 Figura 47 Tela De Gerenciamento de Publicação 106

10 Figura 48 Tela de Pesquisa de Aluno 107 Figura 49 Tela de Pesquisa de Usuário 107 Figura 50 Tela de Pesquisa de Orientador 108 Figura 51 Tela de Pesquisa e Upload de Publicação 108 Figura 52 Tela de Solicitação de Relatório de Aluno 109 Figura 53 Detalhes da Tela de Autenticação 117 Figura 54 Detalhes da Tela Principal do Administrador 118 Figura 55 Detalhes da Barra de Menu: Navegar 118 Figura 56 Detalhes da Barra de Menu: Ajuda 118 Figura 57 Detalhes da Tela Principal do Usuário Comum 120 Figura 58 Detalhes da Tela de Gerenciamento de Usuário 121 Figura 59 Detalhes da Tela de Gerenciamento de Aluno 123 Figura 60 Detalhes da Tela de Gerenciamento de Orientador 125 Figura 61 Detalhes da Tela de Gerenciamento de Publicação 127 Figura 62 Detalhes da Tela de Pesquisa de Aluno 129 Figura 63 Detalhes da Tela de Pesquisa de Orientador 130 Figura 64 Detalhes da Tela de Pesquisa de Publicação 131 Figura 65 Detalhes da Tela de Pesquisa de Usuário 132 Figura 66 Detalhes da Tela de Visualização da Publicação 133 Figura 67 Detalhes da Tela de Solicitação de Relatório de Aluno 134 Figura 68 Detalhes da Tela de Relatório de Aluno 135 ix

11 x LISTA DE TABELAS Tabela 1 Requisitos Funcionais 40 Tabela 2 Requisitos Não Funcionais 41 Tabela 3 Autenticar 42 Tabela 4 Pesquisar Usuário 43 Tabela 5 Pesquisar Aluno 43 Tabela 6 Pesquisar Orientador 43 Tabela 7 Pesquisar Publicação 43 Tabela 8 Gerenciar Aluno 43 Tabela 9 Gerenciar Orientador 43 Tabela 10 Gerenciar Publicação 43 Tabela 11 Gerenciar Usuário 44 Tabela 12 Gerar Relatório 44 Tabela 13 Upload 44 Tabela 14 Definição do Problema 86 Tabela 15 Requisitos Funcionais 87 Tabela 16 Requisitos Não Funcionais 88 Tabela 17 Definições do Sistema 91 Tabela 18 Requisitos de Design e Qualidade 92 Tabela 19 Requisitos de Confiabilidade 93 Tabela 20 Caso de Uso Autenticar 96 Tabela 21 Caso de Uso Pesquisar Usuário 96 Tabela 22 Caso de Uso Pesquisar Aluno 96 Tabela 23 Caso de Uso Pesquisar Orientador 97 Tabela 24 Caso de Uso Pesquisar Publicação 97 Tabela 25 Caso de Uso Pesquisar Usuário 97 Tabela 26 Caso de Uso Gerenciar Aluno 98 Tabela 27 Caso de Uso Gerenciar Orientador 98 Tabela 28 Caso de Uso Gerenciar Publicação 98 Tabela 29 Caso de Uso Gerar Relatório de Aluno 98 Tabela 30 Caso de Uso Upload de Publicação 99 Tabela 31 Tabela Aluno 112 Tabela 32 Tabela Orientador 112 Tabela 33 Tabela Publicação 112 Tabela 34 Tabela Usuário 113 Tabela 35 Descrição da Tela de Autenticação 117 Tabela 36 Descrição da Tela Principal do administrador 119 Tabela 37 Descrição da Tela Principal do Usuário Comum 120 Tabela 38 Descrição da Tela de Gerenciamento de Usuário 121 Tabela 39 Descrição da Tela de Gerenciamento de Aluno 123 Tabela 40 Descrição da Tela de Gerenciamento de Orientador 125 Tabela 41 Descrição da Tela de Gerenciamento de Publicação 127 Tabela 42 Descrição da Tela de Pesquisa de Aluno 129 Tabela 43 Descrição da Tela de Pesquisa de Orientador 130 Tabela 44 Descrição da Tela de Pesquisa de Publicação 131 Tabela 45 Descrição da Tela de Pesquisa de Usuário 132 Tabela 46 Descrição da Tela de Visualização da Publicação 133 Tabela 47 Descrição da Tela de Solicitação de Relatório de Aluno 134

12 Tabela 48 Descrição da Tela de Relatório de Aluno 135 Tabela 49 Itens de Teste 145 Tabela 50 - Teste de Integridade de Dados e de Banco de Dados 147 Tabela 51 Teste de Interface 147 Tabela 52 Teste de Função 148 Tabela 53 Perfil de desempenho 149 Tabela 54 Teste de Segurança e Controle de Acesso 149 Tabela 55 Resultado do Teste de Integridade de Dados e de Banco de Dados 152 Tabela 56 Resultado do Teste de Função 152 Tabela 57 Resultado do Teste de Interface 153 Tabela 58 Resultado do Teste de Desempenho 153 Tabela 59 Resultado do Teste de Segurança e Controle de Acesso 154 xi

13 xii LISTA DE ABREVITATURAS E SIGLAS UFPel Universidade Federal de Pelotas IES Instituições de Ensino Superior. RUP Rational Unified Process. IDE Integrated Development Environment. UML Unified Modeling Language. OMG Object Management Group. DER Diagrama de Entidade Relacionamento. SGBD Sistema Gerenciador De Banco De Dados SQL Structured Query Language. DDL Data Definition Language. DML Data ManipulationLanguage. DCL Data ControlLanguage. JAVA Linguagem de Programação. JVM Java Virtual Machine. MVC Model View Controller. Univag Universidade de Várzea Grande. C Linguagem de Programação. C++ Extensão da Linguagem de Programação C.

14 xiii SUMÁRIO 1- INTRODUÇÃO Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologia Conteúdo do Trabalho LEVANTAMENTO TEÓRICO PARA DESENVOLVIMENTO DO SISTEMA DE CONTROLE ACADÊMICO Engenharia de Software Definição Ciclo de Vida de Desenvolvimento Processo Unificado da Rational Arquitetura do RUP Dimensões Dimensão Dinâmica Dimensão Estática Melhores Práticas Desenvolver Software Iterativamente Gerenciamento de Requisitos Uso de Arquitetura Baseada em Componentes Modelagem Visual de Software Verificar Qualidade de Software Controle de Alterações no Software A Linguagem UML Principais Diagramas UML Diagrama de Caso de Uso Diagrama de Sequência Diagrama de Atividade Diagrama de Classe Diagrama de Estado Diagrama de Componente Diagrama de Utilização Banco de Dados Projeto de Banco de Dados A Linguagem Sql Orientação a Objetos Classes Objetos Polimorfismo Herança A Linguagem Java Padrões de Projetos Padrão Mvc FERRAMENTAS Astah Community Brmodelo Netbeans 37

15 3.4- Mysql O SISTEMA PROPOSTO Concepção Levantamento de Dados e Análise de Requisitos Necessidade do Negócio Descrição dos Envolvidos Visão Geral do Sistema Proposto Objetivos do Sistema Descrição do Escopo do Projeto Impactos Gerados pelo Projeto Requisitos do Sistema Requisitos Funcionais Requisitos Não Funcionais Relatório de Caso de Uso Descrição dos Casos de Uso Elaboração Diagrama de Classes Diagrama de Sequência Diagrama de Atividades Diagrama de Estado Diagrama de Componente Construção Protótipo de Tela Projeto de Banco de Dados Diagramas Dicionário de Dados Desenvolvimento do Sistema Mvc Model Modelo Interface Sujeito Classe Modelo Classe Usuário View Visão Interface Observador Visãogerenciamentoview Controller Controlador Interface Cadastro Controlador Classe Cadastrousuario Transição Testes Plano de Teste Procedimento de Teste Resultado de Teste CONSIDERAÇÕES FINAIS Contribuições E Conclusão Contribuições Conclusão 63 APÊNDICES 68 xiv

16 xv LISTA DE APÊNDICE Apêndice A Questionário para Levantamento de Requisitos 68 Apêndice B Documento de Visão 73 Apêndice C Documento de Requisitos 83 Apêndice D Especificação Suplementar 89 Apêndice E Descrição do Caso de Uso 94 Apêndice F Protótipo de Tela 100 Apêndice G Dicionário de Dados 110 Apêndice H Manual de Instruções do AcadSistem 114 Apêndice I Plano de Teste 137 Apêndice J Procedimento de Teste 143 Apêndice L Resultado dos Testes 150

17 16 1- INTRODUÇÃO 1.1- Motivação Atualmente Instituições de Ensino Superior - IESs tem avançado bastante. Com isso as IESs precisam se estruturar para orientar seus alunos e professores (TACHIZAWA, 1999). Uma Instituição de ensino é um conjunto de pessoas se interagindo, que ao se relacionar com alunos através do poder do ensino, consegue passar a ideia em mente e tentar garantir que os alunos saiam dali com um pensamento feito (TACHIZAWA, 1999). Segundo a entrevista realizada com o pesquisador e professor Adjunto I da Universidade Federal de Pelotas - UFPel, no Rio Grande do Sul, Dr. Hueder Paulo Moisés de Oliveira (Oliveira, 2011): O Programa de Pós-Graduação da Universidade Federal de Pelotas UFPel oferece cursos de mestrado e doutorado em Química. A Universidade tem a grande necessidade de organizar relatórios com perfis de alunos para ter um bom acompanhamento de desempenhos acadêmicos e controle desses alunos de pós-graduação. Porém a Universidade não tem um aplicativo automatizado que proporcione, à administração, emitir um relatório com o perfil de cada aluno e orientador, onde possam ser contidos todos os dados cadastrais e institucionais de cada um deles. O Dr. Oliveira ainda concluiu que: Sem um aplicativo automatizado para armazenar esses dados, a única solução encontrada até hoje pela administração foi recorrer à planilha do Microsoft Office Excel para informações relacionadas aos alunos e orientadores, porém não há certa segurança, porque esses dados armazenados nas planilhas podem ser perdidos em caso de perda de arquivo. Portanto, torna se necessário automatizar esta atividade, a fim de assegurar estes dados, a eficiência e a agilidade às tarefas desempenhadas pela administração da UFPel. A solução proposta nesse projeto é desenvolver um software de banco de dados relacional para o sistema de controle acadêmico, que possibilite a universidade acompanhar o desempenho de alunos de Pós-Graduação Objetivos Nesta seção serão apresentados os objetivos deste trabalho.

18 Objetivo Geral Este trabalho tem como objetivo desenvolver um sistema de software para o sistema de controle acadêmico do curso de Pós-Graduação da Universidade Federal de Pelotas, denominado SISTEMA DE CONTROLE ACADÊMICO - ACADSISTEM Objetivos Específicos Os objetivos específicos deste Trabalho são: a. Pesquisar o referencial teórico para o desenvolvimento do ACADSISTEM; b. Recolher os requisitos funcionais e não funcionais do ACADSISTEM com o cliente UFPel; c. Realizar o projeto de Banco de Dados Relacional; d. Implementar o ACADSISTEM; e. Realizar testes no ACADSISTEM e; f. Analisar os resultados Metodologia O software será desenvolvido por meio do processo de engenharia de software Rational Unified Process - RUP, utilizado de forma customizada, utilizando assim, parte do processo RUP, pois ele é um processo muito complexo. O RUP apresenta seis das melhores práticas para um bom desenvolvimento de como desenvolver o software iterativamente, gerar requisitos, usar arquiteturas baseadas em componentes, modelar software visualmente, verificar a qualidade do software, controlar as mudanças do software (IBMb, 1998). A modelagem do software será realizada com a utilização das ferramentas StarUml(versão 5.0.2, 2005) e BrModelo (versão 2.0, 2007) para que possam proporcionar um padrão para a arquitetura do sistema de software. A linguagem que será usada para a implementação será Java (versão 1.6, 2006) e a NetBeansIDE (versão 6.8, 2009) e foi selecionado um Sistema Gerenciador de Banco de Dados livre, o MySQL (versão 5.1, 2008).

19 Conteúdo do Trabalho O presente trabalho está estruturado em cinco Capítulos, cujo conteúdo é sucintamente apresentado a seguir: No Capítulo 2 é feito o Levantamento Teórico para Desenvolvimento do Sistema de Controle Acadêmico ACADSISTEM: Apresenta os conceitos envolvidos no desenvolvimento de software. O Capítulo 3 - Ferramentas envolvidas no desenvolvimento: Apresenta quais as ferramentas selecionadas para auxiliar no desenvolvimento do software. No Capítulo 4 - O Sistema Proposto: Demonstrar o processo de desenvolvimento de software composto pelas seguintes fases: concepção, elaboração, construção e transição. Finalmente, o Capítulo 5 apresenta as conclusões deste trabalho a partir da análise dos resultados obtidos e trabalhos futuros.

20 19 2- LEVANTAMENTO TEÓRICO PARA DESENVOLVIMENTO DO SISTEMA DE CONTROLE ACADÊMICO Este capítulo tem como objetivo apresentar os conceitos básicos para o desenvolvimento do sistema de controle acadêmico - ACADSISTEM Engenharia de Software Nesta seção apresenta-se a definição sobre Engenharia de Software, Ciclo de Vida de um software e Processo Unificado da Rational Definição Engenharia de Software é uma das grandes áreas da computação, onde envolve criação, construção, análise, desenvolvimento e manutenção do software. Este tipo de tratamento pode proporcionar ao desenvolvedor a produção de um software com qualidade e resultado desejado.(sommerville, 2007) Ciclo de Vida de Desenvolvimento Para alguns sistemas o ciclo de vida não é longo, portanto é necessário entender que um software nunca estará totalmente acabado; ele poderá estar pronto para uso, mas sempre sofrerá implementações e melhorias (REZENDE, 2005). Este ciclo abrange algumas etapas: análise, projeto, implementação, testes e manutenção. O modelo cascata, mais conhecido como modelo de ciclo de vida, tem essas cinco fases denominada de uma forma diferente, como mostra a Figura 1 (SOMMERVILLE, 2007). Figura 1 Modelo Cascata Fonte: Adaptada de Sommerville (2007)

21 20 Para melhor especificação do sistema, é necessário recolher todos os requisitos e finalidades do sistema na primeira fase: Definição de Requisitos. Na segunda, é definida a arquitetura, tanto no aspecto software, com os requisitos funcionais, quanto no aspecto hardware, os requisitos não funcionais. Na terceira fase, Implementação e Teste de Unidade, o software começa a ser implementado e testado, de maneira a verificar se está atendendo a sua finalidade. Para verificar se todos os requisitos atendem as expectativas, na fase de Integração e Teste de Sistema, o software é testado como um todo. E por último, na fase de Operação e Manutenção, após a entrega do software, ele é requerido a novas alterações, relacionadas a erros não detectados nos testes (SOMMERVILLE, 2007). O ciclo de vida de um software também está representado na Figura 2. Como já dito, um software sempre estará em desenvolvimento, pois no decorrer de seu uso haverá sempre a necessidade de modificações (BROOKSHEAR, 2003). A fase de Manutenção concentra-se nas: Correções: Mudanças que estão associadas à correção de defeitos (Manutenção Corretiva); Adaptações: são exigidas à medida que o ambiente do sistema evolui e (Manutenção Adaptativa); Melhoramento Funcional produzidas por exigências variáveis do cliente (Manutenção perfectiva). Prevenção: O software de computador se deteriora devido a modificações, e; Surge a manutenção preventiva, frequentemente chamada de reengenharia de software; Em essência, a manutenção preventiva faz modificações nos programas de computador, de modo que eles possam ser mais facilmente corrigidos, adaptados e melhorados;

22 21 Figura 2 - Ciclo de vida de desenvolvimento Fonte: Adaptada de Brookshear (2003) Processo Unificado da Rational O Rational Unified Process - RUP que traduzido para o português significa Processo Unificado da Rational, é um processo de engenharia de software. Com o objetivo de garantir um software de alta qualidade que, dentro de um cronograma e um orçamento previsíveis, atendam às necessidades dos seus usuários finais, o RUP fornece uma abordagem disciplinada para a atribuição de tarefas e responsabilidades na organização do desenvolvimento. Utiliza a linguagem UML no desenvolvimento dos casos de uso e a orientação a objetos (KRUCHTEN, 2003) Arquitetura do RUP fases. Nesta seção será apresentada a arquitetura do RUP composta por dimensões e Dimensões a seguir: O RUP apresenta duas dimensões, a dinâmica e a estática, como mostra a figura

23 22 Figura 3 As duas dimensões do RUP Fonte: Adaptada de Kruchten (2003) A dimensão horizontal representa o aspecto dinâmico do processo, o ciclo de vida. Essa dimensão faz com que o projeto do software seja elaborado com uma sequência de iterações incrementais. A dimensão vertical representa o aspecto estático, descrito em termos de componentes do processo: atividades, disciplinas, artefatos e papéis do processo (KRUCHTEN, 2003) Dimensão Dinâmica A arquitetura do RUP apresenta quatro fases no aspecto dinâmico: concepção, elaboração, construção e transição, como apresenta a figura 4. Essas fases podem conter várias iterações (KRUCHTEN, 2003).

24 23 Figura 4 As quatro fases do RUP Fonte: Adaptada de Kruchten (2003) A Concepção é a fase da criação do escopo do projeto; nela é realizada a avaliação de risco, uma estimativa dos recursos necessários e o cronograma dos marcos temporais mais importantes. Todos os atores envolvidos na iteração do sistema também são identificados nesta fase. Nesta fase são desenvolvidos, também, os seguintes artefatos: Caso de negócio inicial; Formulação do documento de visão geral dos requisitos do projeto; Relatório inicial de avaliação de risco; Estimativa de recursos; Cronograma inicial e; Protótipos iniciais. A elaboração é a especificação e eliminação dos pontos de maior risco. Nesta fase são desenvolvidos os seguintes requerimentos: Modelo de casos de uso Análise e projeto do sistema; Relatórios de Riscos; Plano de gerenciamento; Alocação da equipe; Planejamento das fases, mostrando suas iterações e conteúdos. Realiza-se a analise do domínio do problema e projeta uma arquitetura para o sistema. A construção é o início do desenvolvimento do sistema, ao final de cada ciclo, pode surgir uma versão utilizável do processo. Nesta fase são desenvolvidos os seguintes requerimentos:

25 24 Sistema de software funcionando e documentação associada pronta para ser liberada aos usuários; Casos de teste baseados em cenários, e resultados de testes; Por ultimo a transição: implantação do software e transferência do software para o usuário do sistema (KRUCHTEN, 2003) Dimensão Estática A dimensão estática possui quatro conceitos chaves que definem quem faz o quê, como e quando? Workers (trabalhadores) quem; Atividades como; Artefatos o quê; Fluxos de trabalho (workflows) quando. O RUP possui também, nove disciplinas, as quais estão detalhadas a seguir: Modelagem do negócio - Esta disciplina visa o entendimento da estrutura e a dinâmica da organização; o entendimento dos problemas e; a identificação das melhorias. Requisitos - Nesta disciplina é possível estabelecer uma concordância entre os envolvidos no projeto sobre os requisitos do sistema, bem como os limites do sistema, estimar o tempo e custo de desenvolvimento. Análise e Projeto - Esta disciplina visa transformar os requisitos em projeto; construir uma arquitetura para oi sistema e; adaptar o projeto ao ambiente. Implementação - Visa estruturar o código, bem como implementar classes e objetos; testar e integrar as unidades. Testes - Nesta disciplina é testado o sistema para a identificação de erros, esses erros são identificados e documentados; é possível validar o sistema de acordo com o que foi especificado e validar se o sistema foi desenvolvido de acordo com o projetado. Implantação - Esta disciplina visa a certificação da entrega do sistema ao usuário final. Gerência de Configuração e Mudança - Nesta disciplina é controlado os artefatos produzidos no desenvolvimento do projeto.

26 25 Gerenciamento e Planejamento - Esta disciplina controla o gerenciamento de riscos. Além de disponibilizar guias para planejar, executar, acompanhar e monitorar o projeto. Ambiente - Visa focar nas atividades relacionadas à adaptação do processo organizacional (do projeto) (KRUCHTEN, 2003) Melhores Práticas As melhores práticas apresentadas no RUP descreve como implantar um bom desenvolvimento de software para equipes desenvolvedoras. São elas: Desenvolver Software Iterativamente O RUP sugere que o desenvolvedor adote uma abordagem iterativa, pois nela é necessário uma maior compreensão do problema através de melhoras sucessivas, para gerar gradativamente uma solução eficaz a cada iteração. A abordagem iterativa no desenvolvimento verifica os itens de maior risco em cada etapa do ciclo de vida, reduzindo significativamente o perfil de um projeto de risco(ibmb, 1998). Pois cada iteração termina com uma versão executável, o desenvolvedor permanece focado em produzir resultados e a checagem de status frequentes ajudam a garantir que o projeto permaneça dentro do cronograma. Uma abordagem iterativa também torna mais fáceis as mudanças táticas nos requisitos, nas funcionalidades e/ou no cronograma (IBMb, 1998) Gerenciamento de Requisitos O RUP sugere ao desenvolvedor uma excelente maneira de capturar os requisitos funcionais. Essa prática apresenta como obter, organizar o documento de funcionalidade e restrições; como acompanhar e documentar compromissos e decisões; e facilmente como capturar os requisitos de negócio (IBMb, 1998) Uso de Arquitetura Baseada em Componentes O processo concentra-se no desenvolvimento inicial de uma arquitetura robusta executável. Ele descreve como projetar uma arquitetura flexível, acomoda as mudança, é intuitivamente compreensível e promove a reutilização de software mais eficiente. O RUP apóia o desenvolvimento de software baseado em componentes (IBMb, 1998).

27 Modelagem Visual de Software As abstrações visuais ajudam o desenvolvedor a se comunicar com os diferentes aspectos software; a ver comoos elementos do sistema se encaixam; manter a coerência entre um projeto e sua execução; e promover a comunicação inequívoca (IBMb, 1998) Verificar Qualidade de Software Atualmente o fraco desempenho de aplicativos e a pouca confiabilidade são fatores comuns que impedem drasticamente a aceitação dos pedidos de software. Assim, a qualidade deve ser focada no que diz respeito aos requisitos baseados em confiabilidade, funcionalidade, desempenho da aplicação e desempenho do sistema. Esta prática auxilia no planejamento do projeto, na implementação, na execução e na avaliação dos teste(ibmb, 1998) Controle de Alterações no Software Em todo software há mudanças, em alguns casos, estas mudanças são inevitáveis, por isso a capacidade de gerir a mudança e de ser capaz de acompanhar as mudanças é essencial. Esta prática descreve como controlar, acompanhar e monitorar as mudanças para permitir o desenvolvimento iterativo sucesso (IBMb, 1998) A Linguagem UML A Unified Modeling Language - UML é uma especificação da Object Management Group - OMG (OMG, ). É uma linguagem gráfica de modelagem para visualizar, especificar, construir e documentar os artefatos de sistemas de objetos distribuídos (UML, 2011). A UML possui treze modelos gráficos que estão divididos em duas categorias, os diagramas de aplicações estáticas que representam a estrutura e os diagramas de comportamentos, no entanto dentro desta última categoria, existe uma subcategoria que compõe os diagramas de interação (SILVA, 2007). A categoria de diagramas de Estrutura inclui diagrama de classe, diagrama de objeto, diagrama de componentes, diagrama de estrutura composta, diagrama de pacote e diagrama de utilização (SILVA, 2007). Os diagramas de Comportamento são: diagrama de caso de uso, diagrama de máquina de estados e diagrama de atividades. Em sua subcategoria Interação estão

28 27 inclusos os diagramas de sequência, comunicação, visão geral de interação e por ultimo, porém não menos importante o de temporização (SILVA, 2007) Principais Diagramas UML Os diagramas UML abordados neste projeto são os de: Caso de Uso, Sequência, Atividade, Classe, Estado e Utilização Diagrama de Caso de Uso O diagrama de caso de uso está relacionado à modelagem dinâmica do sistema. Ele é composto por elementos sintáticos denominados atores e relações que envolvem esses elementos (SILVA, 2007). A figura 5 apresenta um exemplo de um diagrama de caso de uso. Figura 5 Exemplo de diagrama de caso de uso Fonte: Adaptada de Silva (2007) Diagrama de Sequência O diagrama de sequência também está relacionado à modelagem dinâmica do sistema. E representa a interação entre os objetos na troca de mensagens na ordem temporal em que elas acontecem. A leitura das mensagens que são enviadas de objetos para outros objetos é feita de cima para baixo (SILVA, 2007). A figura 6 apresenta um exemplo de um diagrama de sequência.

29 28 Figura 6 - Exemplo de diagrama de sequência Fonte: Adaptada de Silva (2007) Diagrama de Atividade O diagrama de atividades é composto por atividades, vista como um conjunto de atividades ou de ações. Este diagrama representa uma atividade correspondente ao sistema. Conforme mostrado na figura 7. Figura 7 Exemplo de diagrama de atividade Fonte: Adaptada de Silva (2007)

30 Diagrama de Classe O diagrama de classes representa a estrutura e os relacionamentos das classes. No entanto, as classes e os relacionamentos cedidos a elas, são os elementos sintáticos básicos do diagrama de classes (SILVA, 2007). A figura 8 apresenta um exemplo de um diagrama de classe. Figura 8 Exemplo de diagrama de Classe Fonte: Adaptada de Silva (2007) Diagrama de Estado O diagrama de estado representa o estado em que um objeto se encontra no sistema. Com isso, os elementos principais desse diagrama são os estados e as transições. Um objeto muda de estado com o auxilio de uma transição (SILVA, 2007). A figura 9 apresenta um exemplo de um diagrama de estado. Figura 9 Exemplo de diagrama de Estado Fonte: Adaptada de Silva (2007)

31 Diagrama de Componente Este diagrama demonstra os componentes do sistema e a relação entre esses componentes. Assim o diagrama representa a classe organizada, especificando a qual classe pertence cada um dos componentes. Conforme a figura 10. Figura 10 Exemplo de diagrama de Componente Fonte: Adaptada de Silva (2007) Diagrama de Utilização O diagrama de utilização, mais conhecido como diagrama de implantação representa os elementos do sistema necessários para a execução. Representando assim, a modelagem estrutural do sistema, através de nodos ou instâncias de nodos. Conforme a figura 11. Figura 11 Exemplo de diagrama de Utilização Fonte: Adaptada de Silva (2007)

32 Banco de Dados Banco de dados é um conjunto de dados persistentes, com o intuito de armazenar informações de uma determinada organização. Esses dados são mantidos por um software chamado de Sistema Gerenciador de Banco de Dados (SGBD), onde os usuários desse sistema podem realizar busca, exclusão, inserção e alteração nesses arquivos de banco de dados (DATE, 2003). Alguns autores definem que dados e informações tem o mesmo significado, por outro lado, outros definem dados como os valores fisicamente armazenados no banco de dados e informações como o significado gerado a partir de um determinado dado (DATE, 2003) Projeto de Banco de Dados Na maioria dos projetos de banco de dados são utilizados dois modelos de banco de dados em duas fases: o modelo conceitual e o modelo lógico, porém existe mais um modelo: o físico. Na primeira fase é abstraído o modelo conceitual. Este modelo descreve o banco de dados de forma independente, sem necessitar do SGBD. O projeto de banco de dados é representado em um DER Diagrama de Entidade Relacionamento, como mostra a figura a seguir (HEUSER, 1998). Figura 12 Exemplo do Modelo Conceitual Fonte: Adaptada de Heuser (1998) E na segunda fase é abstraído o modelo lógico. Modelo que representa o banco de dados na maneira como é visto pelo usuário do SGBD. Ao contrário do conceitual, depende do SGBD utilizado no projeto. E é gerado a partir do modelo conceitual desenvolvido na primeira fase do projeto de banco de dados (HEUSER, 1998).

33 32 Figura 13 Exemplo do Modelo Lógico Fonte: Adaptada de Heuser (1998) 2.4- A Linguagem SQL A Structured Query Language- SQL que traduzido para o português significa Linguagem de Consulta Estruturada, é a linguagem padrão para definição e manipulação no banco de dados relacional (IBMc, 2011). É uma linguagem simples e de fácil uso (DAMAS, 2007). A linguagem SQL se divide em três principais grupos: DDL, DML e DCL. A DDL (Data Definition Language Linguagem de Definição de Dados) trabalha com os objetos e tem os seguintes comandos: ALTER altera um objeto do banco de dados (uma tabela, por exemplo), CREATE cria um objeto na base de dados e DROP apaga um objeto da base de dados; Os comandos ALTER e CREATE, podem ser usados para index (indices) e view (visões). Outro grupo é a DML (Data Manipulation Language Linguagem de Manipulação de Dados), ela trabalha com as tuplas (linhas), seus comandos são SELECT consuta os dados armazenados em uma tabela, INSERT insere uma linha na tabela, DELETE deleta e UPDATE permite alterar quantas linhas de dados for preciso em uma tabela. E por último, porém não menos importante, a DCL (Data Control Language Linguagem de Controle de Dados) trabalha com os utilizadores, controla o acesso aos dados, seus principais comandos são: GRANT seta os privilégios, permite o acesso aos dados ao usuário e REVOKE remove os privilégios dado ao usuário. A linguagem SQL faz parte de uma das cinco gerações de linguagens, a quarta geração. Ela atende a quase todas as necessidades para o desenvolvimento de um banco de dados, porém para completar as necessidades que a SQL não atende, em algumas ocasiões o desenvolvedor concilia a linguagem SQL com alguma outra linguagem de programação (DAMAS, 2007).

34 Orientação a Objetos A programação orientada a objetos é implementada pelo envio de mensagens a objetos. Ela reúne alguns conceitos que precisam ser entendidos antes iniciar uma programação orientada a objetos, como classe, objetos, herança e polimorfismo Classes Uma classe é um modelo ou protótipo onde os objetos serão criados e definidos. Assim, a classe define o estado e o comportamento de um objeto físico do mundo real, como está representado na figura 14 (RICARTE, 2001). Figura 14 Exemplo de uma Classe Fonte: Adaptada de Ricarte (2001) Objetos Objeto é uma instância de uma classe, sendo assim ele é um objeto físico do mundo real. São justamente os objetos que caracterizam a programação orientada a objetos. O objeto tem seus devidos atributos e métodos que o manipulam (RICARTE, 2001) Polimorfismo Polimorfismo consiste em implementar um código considerando classes abstratas ou interfaces, ao invés de classes concretas (SIERRA, 2007) Herança A herança organiza e estruturar o software. As classes herdam o estado e o comportamento de suas superclasses. Com a herança, classes podem herdar características da classe pai, como por exemplo, atributos e métodos. Podendo assim a subclasse, especificar ou estender a superclasse (RICARTE, 2001). A figura 15 apresenta um exemplo de herança e polimorfismo. Foram criadas três classes de tipos diferentes de canetas, porem todas são derivadas de outra classe. As

35 34 classes CanetaFlor, CanetaPalhaço e CanetaRelógio herdam os atributos e métodos (mesma assinatura) da classe Caneta. Porém as ações dos métodos são diferentes para cada uma das classes que estão herdando (MARIANI, 2010). Figura 15 Representação de Herança e Polimorfismo Fonte: Adaptada de Mariani (2010) A Linguagem Java Java foi desenvolvido em 1991 por um grupo secreto da Sun Microsystems denominado por The Green Project, que traduzido para o português significa o Projeto Verde, com o intuito de desenvolver uma linguagem de grande importância na área de informática (SERSON, 2008). Java é uma linguagem de programação utilizada no desenvolvimento de software que tem portabilidade entre as plataformas, através da máquina virtual ou JAVA VIRTUAL MACHINE (JVM). Além disso, ela é orientada a objetos, o que possibilita a reutilização de códigos desenvolvidos em outros projetos e trabalha com a troca de mensagens entre os objetos, como mostra a figura 16 (SOMERA, 2006). Linguagem de programação orientada a objetos é mais fácil de programar, principalmente para iniciantes que tem certa dificuldade no inicio, pois a orientação a objetos consegue fazer com que o programador se sinta mais a vontade no desenvolvimento (SERSON, 2008).

36 35 Figura 16 - Linguagem Orientada a Objetos, objetos trocando mensagem Fonte: Adaptada de Serson (2008) 2.6- Padrões de Projetos Em uma definição mais recente, padrões de projeto não são projetos, como listas encadeadas e tabelas de acesso aleatório, que podem ser codificadas em classes e ser reutilizadas tais como então. Tampouco são projetos complexos, de domínio especifico, para uma aplicação inteira ou subsistemas [...] Padrões de Projeto são descrições de objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular. (GAMMA, 2005). Apesar de existirem diversos padrões de projeto, padrões têm sido descritos em diferentes formatos Padrão MVC O Padrão MVC Model View Controller é um dos mais usados atualmente. Ele é dividido em três camadas: a. Model (Modelo): Representa os dados da organização e as regras de negócios que governam o acesso e atualizações de dados. b. View (Visão): Acessa os dados da organização através do modelo e especifica como os dados devem ser apresentados. Quando o modelo é alterado, é a visão é quem fica responsável por manter a consistência na sua apresentação. c. Controller (Controlador) - Traduz as interações com a visão em ações a serem realizadas pelo modelo. Com base na interação do usuário e os resultados das ações do modelo, o controlador responde ao selecionar uma visão apropriada (SUN, ).

37 36 3- FERRAMENTAS Foram selecionadas algumas ferramentas de desenvolvimento que serão usadas neste projeto com o intuito de melhor desempenho do software ASTAH COMMUNITY A ferramenta Astah Community é open source e é utilizada para o desenvolvimento da modelagem de software. É flexível e extensível e contém vários recursos. Nela é possível desenvolver vários diagramas: diagrama de casos de uso, diagrama de classe, diagrama de sequência, diagrama de estados, diagrama de atividades, diagrama de componentes, diagrama de implantação, diagrama de estrutura composta, diagrama de comunicação e diagrama de pacote, como mostra a figura 17 (ASTAH_COMMUNITY, 2011). Figura 17 - Visão geral da ferramenta Astah Community. Fonte: Adaptada de Paraíso (2011) 3.2- BRMODELO A ferramenta BrModelo é um aplicativo totalmente livre para modelagem de software. É um resultado de um trabalho de graduação do curso de pós-graduação de banco de dados de um aluno da Universidade de Várzea Grande Univag. O BrModelo

38 37 tem como base a metodologia defendida pelo professor Heuser, em seu livro. Ele possui as seguintes funcionalidades: construção do modelo de entidade e relacionamento, como apresenta a figura 18, e mapeamento para o modelo relacional de banco de dados (SIS, 2007). Figura 18 - Visão geral da ferramenta BrModelo NETBEANS A ferramenta NetBeans foi fundada no ano de 2000 pela Sun Microsystems, totalmente open-source. É um ambiente de desenvolvimento integrado para desenvolvedores de software.escrito em totalmente em Java, porém compila qualquer tipo de linguagem (NETBEANSa, 2011). O IDE vem com drivers para os servidores de banco de dados MySQL e PostgreSQL como mostra a figura 19 (NETBEANSb, 2011). Figura 19 - Driver para o servidor de banco de dados MySQL Fonte: Adaptada de NetBeansb (2011) 3.4- MYSQL O MySql é o sistema gerenciador de banco de dados (SGBD) de código aberto mais conhecido no mundo que trabalha com a linguagem SQL. Pois tem excelente

39 38 desempenho, confiabilidade e facilidade de uso. Tem uma grande portabilidade, funciona em mais de 20 plataformas, sendo elas as principais, Linux, Windows, Mac e Solaris e foi escrito em C e C++ (MYSQL, 2010).

40 39 4- O SISTEMA PROPOSTO Para o processo de desenvolvimento do ACADSISTEM utilizou-se o RUP de forma customizada. O RUP é descrito no capítulo 2 seção Este capítulo descreve as fases do processo de desenvolvimento do sistema, são elas: Concepção, Elaboração, Construção e Transição Concepção Nesta fase realizou-se o levantamento de dados e análise dos requisitos. Gerouse alguns artefatos importantes para o andamento do projeto como ata da entrevista e documento de visão. As seções a seguir detalham esta fase Levantamento de Dados e Análise de Requisitos Realizaram-se reuniões e entrevistas com o cliente da Universidade Federal de Pelotas UFPel para levantamento e entendimento das necessidades do ACADESISTEM, vide apêndice A. Em Seguida gerou-se um documento de visão com o objetivo de apresentar uma visão geral do sistema, listando as necessidades e funcionalidades gerais, bem como os envolvidos, vide apêndice B Necessidade do Negócio A Universidade Federal de Pelotas de pós-graduação tem a grande necessidade de organizar relatórios com perfis de alunos, para ter um bom acompanhamento do desempenho acadêmico e controle desses alunos, como por exemplo, quantidade e acompanhamento das matérias cursadas pelos alunos. Com isso, a Universidade sente falta de um sistema automatizado que proporcione, à administração, emitir um relatório com o perfil de cada aluno, onde possam ser contidos todos os dados cadastrais e institucionais de cada um deles Descrição dos Envolvidos a. Christianne Melo Silva Paraíso: Desenvolvedora do Software. b. UFPel: mentora da idéia do aplicativo; c. Hueder Paulo Moisés de Oliveira: Professor Adjunto I da UFPel; orientador pela UFPel e cliente do projeto; d. Administração da UFPel: interessada em acompanhar o perfil acadêmico dos alunos e orientadores; e. Juliana Forin Pasquini Matinez: orientadora pela Fatec.

41 Visão Geral do Sistema Proposto sistema. Nesta subseção serão apresentadas algumas informações relacionadas ao Objetivos do Sistema Desenvolver um sistema que seja capaz de: a. Acesso através de autenticação com usuário e senha; b. Armazenar dados cadastrais e institucionais de alunos e orientadores; c. Arquivar publicações, como por exemplo, artigos e teses; d. Fazer upload dessas publicações; e. Pesquisar por aluno ou orientador Descrição do Escopo do Projeto Um software personalizado para o sistema de pós-graduação precisa ser desenvolvido para que a Universidade Federal de Pelotas (UFPel) possa controlar dados cadastrais de alunos e orientadores, bem como as publicações feitas por eles, emitir relatório com o perfil de cada aluno e com isso ter um melhor controle no sistema de pós-graduação Impactos Esperados pelo Projeto a. Melhor acompanhamento dos alunos, com relação ao desempenho de cada um; b. Controle de orientadores; c. Acompanhamento das publicações feitas por alunos Requisitos do Sistema Nesta seção apresentam-se os requisitos funcionais e não funcionais do sistema, vide apêndice C Requisitos Funcionais A tabela apresenta os requisitos funcionais do sistema ACADSISTEM.

42 41 Tabela 1 Requisitos Funcionais Código RF01 RF02 RF03 RF04 RF05 RF06 Requisito Possuir dois tipos de usuários: Administrador e Usuário Comum. Permitir a liberação do sistema após autenticação do usuário. Permitir as seguintes consultas aos usuários sobre alunos: RF Condição perante o programa de pós-graduação; RF Disciplinas cursadas; RF Disciplinas dependentes; RF Status de proficiência em língua estrangeira; RF Matricula em mestrado ou doutorado e; RF Em qual curso está matriculado; RF Publicações realizadas. Para o usuário Administrador permitir o gerenciamento de: RF Usuários comuns; RF Alunos; RF Orientadores e; RF Publicações. Gerar relatório a partir dos resultados obtidos na pesquisa. Fazer upload das publicações Requisitos Não Funcionais apêndice C. A tabela apresenta os requisitos não funcionais do sistema ACADSISTEM. Vide Tabela 2 Requisitos Não Funcionais Código Requisito RNF01 Acessível apenas em modo desktop. RNF02 Desenvolvido em JAVA. RNF03 Compatível com Windows XP e Seven. RNF04 MySQL SGBD utilizado. RNF05 Hardware: Servidor superior a: RNF0501-2GB de RAM; RNF GB disponível em HD. RNF06 Níveis de acesso.

43 Relatório de Caso de Uso A figura 20 apresenta o diagrama de caso de uso do sistema, contendo todos os casos de uso do sistema e os usuários. A descrição desse caso de uso encontra-se no apêndice E. Figura 20 Diagrama de Caso de Uso do Sistema Descrição dos Casos de Uso A seguir será apresentada uma simples descrição sobre o caso de uso, mas esta descrição está detalhada com o passo a passo no apêndice D. Nome: Descrição: Tabela 3 Autenticar Autenticar A tela de autenticação aparecerá para o usuário e ele deverá informar nos campos indicados, o seu nome e senha.

44 43 Nome: Descrição: Tabela 4 Pesquisar Usuário Pesquisar usuário Após passar pela autenticação, o usuário poderá realizar pesquisas sobre outros usuários. Como por exemplo, pesquisar para efetuar algumas alterações. Nome: Descrição: Tabela 5 Pesquisar Aluno Pesquisar aluno Após passar pela autenticação, o usuário poderá realizar pesquisas sobre alunos. Como por exemplo, saber o nome, o RA, em qual curso está matriculado, etc. Nome: Descrição: Tabela 6 Pesquisar Orientador Pesquisar orientador Após passar pela autenticação, o usuário poderá realizar pesquisas sobre orientadores. Como por exemplo, saber o nome, curso, efetuar alterações e exclusões. Nome: Descrição: Tabela 7 Pesquisar Publicação Pesquisar publicação Após passar pela autenticação, o usuário poderá realizar pesquisas sobre publicações. Como por exemplo, saber o autor(aluno) e ler o conteúdo. Nome: Descrição: Tabela 8 Gerenciar Aluno Gerenciar Aluno O administrador do sistema devidamente autenticado poderá cadastrar, alterar e excluir alunos do banco de dados. Nome: Descrição: Tabela 9 Gerenciar Orientador Gerenciar Orientador O administrador do sistema devidamente autenticado poderá cadastrar, alterar e excluir orientadores do banco de dados. Nome: Descrição: Tabela 10 Gerenciar Publicação Gerenciar Publicação O administrador do sistema devidamente autenticado poderá cadastrar e excluir publicações de alunos.

45 44 Nome: Descrição: Tabela 11 Gerenciar Usuário Gerenciar Usuário O administrador do sistema devidamente autenticado poderá cadastrar e excluir usuários. Nome: Descrição: Tabela 12 Gerar Relatório Gerar Relatório de Aluno O usuário poderá gerar um relatório simples sobre o aluno com as informações selecionadas ou gerar um relatório completo, composto de todas as informações sobre o aluno. Nome: Descrição: Tabela 13 Upload Upload de Publicação Usuário poderá pesquisar por uma publicação e realizar o upload de tal arquivo Elaboração Esta seção descreve a segunda fase do processo de desenvolvimento do ACADSISTEM. Nesta fase foram realizados os diagramas de classe, de sequência, de atividade, de estado, de componente e de utilização Diagrama de Classes A figura 21 apresenta o diagrama de classes do sistema. Neste diagrama utilizouse o padrão de projeto: o Padrão MVC Model View Controller. A parte amarela representa a View, a parte azul representa o Controller e a parte rosa representa o Model.

46 Figura 21 Diagrama de Classes do Sistema MVC. 45

47 46 Para melhor visualização do diagrama, ele foi dividido em três partes como mostra as figuras 22 representando a view, 23 representando os controllers e 24 representando o model. Figura 22 Diagrama View.

48 Figura 23 Diagrama Controllers. 47

49 Figura 24 Diagrama Model. 48

50 Diagrama de Sequência A figura 25 representa a autenticação de um usuário no sistema. O usuário informa o devido nome e senha na tela de autenticação e em seguida os dados serão conferidos, se os dados estiverem incorretos, aparecerá uma mensagem informando o erro, caso contrário, o usuário terá acesso ao sistema, pois ele estará logado. Figura 25 Diagrama de Sequência - Autenticação. A figura 26 representa o cadastro de um aluno feito pelo usuário administrador. O usuário informa os dados do aluno na tela de cadastro, esses dados serão enviados e conferidos na classe Aluno, se estes dados estiverem incorretos, será informado a mensagem informando o erro, caso contrário, será chamado o método da classe AlunoDao que irá adicionar o aluno no banco de dados do sistema.

51 50 Figura 26 Diagrama de Sequência - Cadastro de Aluno Diagrama de Atividades A figura 27 descreve a atividade realizada pelo usuário administrador ao efetuar uma exclusão relacionada ao orientador. O usuário informa os dados do orientador, em seguida o sistema consulta esse orientador. Se o registro for encontrado o usuário visualiza os dados que o sistema irá recuperar e o usuário confirma a exclusão, caso o registro não exista, o sistema informará uma mensagem.

52 51 Figura 27 Diagrama de Atividade de Exclusão de Orientador. A figura 28 descreve a atividade realizada pelo usuário ao efetuar uma pesquisa relacionada a aluno. O usuário informa o nome do aluno a ser consultado na tela de pesquisa e em seguida o sistema busca este aluno no banco de dados. Se retornar mais de um registro, o sistema informará uma lista contendo estes registros ao usuário, caso contrário, se não for encontrado nenhum registro, o sistema informará ao usuário uma mensagem dizendo que o aluno que estar sendo pesquisado é invalido no sistema, ou seja, nenhum aluno cadastrado no banco de dados com o nome informado.

53 52 Figura 28 Diagrama de Atividade de Pesquisa de Aluno Diagrama de Estado A figura 29 representa o diagrama de estado do cadastro de usuário. O cadastro será iniciado a partir da informação dos dados do usuario a ser cadastro, o objeto passará para o estado de Processando Requisição e em seguida estes dados serão enviados ao banco de dados, se os dados estiverem corretos, o objeto passa para o estado de Finalizado, caso contrário, ele passa para estado de Não Cadastrado, assim ele pode voltar ao estado Enviado, enviando os dados novamente, ou passar para o estado Cancelado.

54 53 Figura 29 Diagrama de Estado de Cadastro de Usuário Diagrama de Componente O diagrama de componentes deste projeto é composto pelas três partes do MVC Modelo, Visão e Controladores; e o DAO, conforme mostrado na figura 30. Figura 30 Diagrama de Componente Geral.

55 Construção Nesta seção apresenta-se a fase de construção. Nesta fase foram desenvolvidos os protótipos de telas e o projeto de banco de dados Protótipo de Tela A figura a seguir representa uma das principais interfaces do software com o usuário. As demais encontram-se anexadas no apêndice F. Figura 31 - Tela de Autenticação Projeto de Banco de Dados - Diagramas Serão apresentadas as fases de modelagem do banco de dados, conforme as figuras 33 e 34. A figura 33 demonstra o modelo conceitual do banco de dados, a sua estrutura; e a figura 34 apresenta o modelo lógico, onde são demonstrados os detalhes de implementação de cada campo das tabelas a partir do modelo conceitual.

56 Figura 32 Modelo Conceitual do Sistema. 55

57 56 Figura 33 - Modelo Lógico do Sistema Dicionário de Dados As tabelas com o dicionário de dados encontram-se em anexo no apêndice G Desenvolvimento do Sistema Nesta fase foi realizado a implementação do ACADSISTEM. Com detalhes da estrutura do Padrão utilizado, o MVC Model View Controller Mvc As subseções a seguir mostrarão o que cada padrão representa no Padrão MVC.

58 Model Modelo A parte do Modelo está composta neste projeto, pela interface Sujeito, as classes Modelo, Aluno, Usuario, Publicacao e Orientador. E também as classes do padrão DAO: AlunoDAO, UsuarioDAO, PublicacaoDAO e OrientadorDAO. Porém apenas as classes e interfaces relacionadas a classe Usuario será representada nesta primeira parte de apresentação da implementação Interface Sujeito A figura 34 ilustra a interface Sujeito. Figura 34 Interface Sujeito Classe Modelo A figura 35 ilustra a classe Modelo.

59 58 Figura 35 Classe Modelo Classe Usuario A classe usuário contém seus devidos atributos e os métodos getters e setters. A Figura 36 representa a classe Usuário.

60 59 Figura 36 Classe Usuário View Visão A parte view está composta pela interface Observador e pelas visões AutenticacaoView, GerenciamentView e PesquisaView, apenas a visão GerenciamentoView e a interface Observador serão representadas Interface Observador A Figura 37 ilustra a interface Observador. Figura 37 Interface Observador

61 Visão GerenciamentoView A figura 38 ilustra a classe GerenciamentoView que implementa a interface Observador. Figura 38 Classe GerenciamentoView Controller - Controlador A parte Controller, está composta por cinco famílias de controladores: Autenticacao, Cadastro, Alteracao, Exclusao e Pesquisa. Serão representadas aqui a interface Cadastro e uma classe da família de Cadastro, a CadastroUsuario Interface Cadastro Controlador A Figura 39 representa a interface Cadastro. Figura 39 - Interface Cadastro

62 Classe CadastroUsuario A classe CadastroUsuario implementa a interface Cadastro, assim ela implementa também os métodos abstratos. A Figura 40 representa a classe CadastroUsuario que implementa a interface Cadastro. Figura 40 Classe CadastroUsuário 4.4- Transição Nessa seção apresenta-se a última fase do RUP, a fase de Transição. Nessa fase foram realizados os testes e entregue o ACADSISTEM com todas as funcionalidades desenvolvidas para serem validadas pelo cliente Testes Esta fase de teste foi dividida em três fases: a primeira é o plano de teste, em seguida o procedimento de teste e por ultimo o resultado de teste Plano de teste O Plano de Teste encontra-se em anexo no apêndice I. Nele foram identificados os casos e requisitos de teste necessários para testar o sistema ACADSISTEM.

63 Procedimento de Teste O Procedimento de Teste encontra-se em anexo no apêndice J. Foi elaborado para servir de auxilio na execução dos testes do sistema ACADSISTEM antes da entrega final ao cliente UFPel. Nele encontram-se todos os passos de execução de testes com os resultados requeridos para um resultado esperado Resultado de Teste Os testes foram aplicados conforme o que foi especificado no procedimento de teste. Foi aplicado e testado na máquina do cliente UFPel, foi também, avaliado todos os aspectos descritos no plano de teste. Todos os testes, sendo eles, de integridade de dados, função, interface, desempenho e de segurança, obtiveram resultados satisfatórios. Para resultados detalhados vide apêndice L.

64 63 5- CONSIDERAÇÕES FINAIS Um sistema de controle acadêmico é muito importante para instituições de ensino, devido à facilidade de gerenciamento de dados acadêmicos com segurança Contribuições e Conclusão Contribuições Neste trabalho foi possível desenvolver um software para o sistema de controle acadêmico do curso de pós-graduação da Universidade Federal de Pelotas. a. Foi estudado o referencial teórico para o desenvolvimento de um software; b. Recolhido os requisitos funcionais e não funcionais da UFPel; c. Foi realizado o projeto de Banco de Dados Relacional; d. Implementado um sistema de software denominado AcadSistem; e. Foi também, realizado os testes em cima do software desenvolvido e; f. Os resultados foram analisados de acordo com o que foi pedido Conclusão Antes, sem um aplicativo automatizado para armazenar os dados dos alunos e orientadores, a única solução encontrada pela administração era recorrer à planilha do Microsoft Office Excel para informações, o que não garantia segurança pela facilidade de perda de dados, agora, com um sistema personalizado, é possível uma administração mais segura e confiável a universidade, onde o administrador do sistema pode gerenciar todos os alunos, orientadores, publicações e usuários da Universidade. O sistema desenvolvido - ACADSISTEM - proporcionou a universidade o cadastro e gerenciamento de alunos, usuários, orientadores e publicações. Nesta versão do software, foi implementado visualização em tabelas os dados destes alunos, usuários, orientadores e publicações. Foi implementado também, a possibilidade de usuários tanto administradores quanto comuns fazer upload de publicações de alunos da universidade. Para próximas versões será implementado o gerenciamento de matérias, para um melhor relacionamento entre matérias e alunos. E o software será aplicado no sistema de graduação da universidade, pois nesta primeira versão, o software foi implementado para o sistema de pós-graduação da universidade.

65 64 Uma dificuldade encontrada neste trabalho foi a elaboração das interfaces de integração com o usuário. Pois as interfaces do sistema exigiram diversos protótipos de tela até que se chegasse ao resultado final aprovado pelo cliente. Definir as necessidades do usuário ao elaborar uma interface incomum é um trabalho muito complexo. Este trabalho contribuiu para o aprimoramento dos processos da Universidade Federal de Pelotas - UFPel.

66 65 REFERÊNCIAS ASTAH_COMMUNITY, Site Oficial Astah Comumunity. Disponível em <http://astah.change-vision.com/en/product/astah-community.html > Acesso em 09/06/2011. BROOKSHEAR, J. G. Ciência da Computação - Uma Visão Abrangente. Porto alegre: Bookman, DAMAS, L. SQL Structured Query Language. Rio de Janeiro: LCT, DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Elsevier: GAMMA, E. H., R. J., R. Padrões de Projeto. Porto Alegre: Bookman, HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Sagra, IBMa, Rational Unified Process. Disponível em: < estpractices_tp026b.pdf > Acessado em: 27/03/2011. IBMb, Site Oficial IBM. Disponível em <http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.ud b.admin.doc/doc/c htm > Acessado em 10 de Abril de KRUCHTEN, P. The Rational Unified Process - An Introduction. São Paulo: ADDISON WESLEY, 2003.

67 66 MARIANI, A. C. O Mundo dos Atores: uma perspectiva de introdução à programação orientada a objetos. Disponível em <http://www.inf.ufsc.br/poo/atores/sbie98/sbie98-atores.html> Acessado em 06/04/2011. MYSQL, Site Oficial MySQL. Disponível em < >Acessado em 09/04/2011. NETBEANSa, Site Oficial NetBeans. Disponível em < Acessado em 09/04/2011. NETBEANSb, Site Oficial NetBeans. Disponível em < Acessado em 09/04/2011. OLIVEIRA, H. P. M Professor Adjunto I da Universidade Federal de Pelotas - UFPel. OMG, Site Oficial OMG. Disponível em < > Acessado em 10/04/2011. REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro: Brasport, RICARTE, I. L. M., Programação Orientada a Objetos: Uma Abordagem com Java. Disponível em < > Acessado em 29/03/2011. SERSON, R. R. Programação Orientada a Objetos com Java 6. Rio de Janeiro: Brasport, SIERRA, K.; BATES, B. Use a cabeça! Java. Rio de Janeiro: Alta Books, SILVA, R. P. Uml2 Em Modelagem Orientada a Objetos. Florianópolis: Visual Books, 2007.

68 67 SIS, Site Oficial BrModelo. Disponível em <http://www.sis4.com/brmodelo/ > Acesso em 07/04/2011. SOMERA, G. Tratamento Profissional em Java. São Paulo: Digerati, SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, SUN, Model - View - Controller. Disponível em < > Acesso em 09/06/2011. UML, Site Oficial UML. Disponível em < > Acessado em 10/04/2011. TACHIZAWA, E. T.; ANDRADE, R. O. B. Gestão De Instituições De Ensino e Organizações Escolares. Rio de Janeiro: FGV, 1999.

69 68 APÊNDICES Apêndice A Questionário Questionário - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Questionário para Levantamento de Requisitos

70 69 SUMÁRIO 1- QUESTIONÁRIO 70

71 70 1- QUESTIONÁRIO Nove de Março de 2011, pesquisador e professor Adjunto I da Universidade Federal de Pelotas UFPel, no Rio Grande do Sul, Hueder Paulo Moisés de Oliveira responde ao questionário sobre o projeto. Questões referentes ao Projeto ACADSISTEM: 1. Qual é o objetivo do sistema? Desenvolver um software de banco de dados para o sistema de pós-graduação onde possam ser armazenados todos os dados cadastrais dos alunos e dos orientadores. Além disso, o software deve permitir que as publicações sejam arquivadas e possa ser feito upload desses arquivos. Esse aplicativo (software) é o Trabalho de Conclusão de Curso da interessada. O aplicativo será desenvolvido em parceria entre a FATEC (que terá um orientador para a aluna) e a UFPel (mentora da idéia do aplicativo) (que também terá um orientador para a aluna). 2. Que área vai atender? Ele atenderá a área Educativa. 3. Que tipo de usuários e quantos usuários estarão interagindo com o sistema? Pessoal administrativo. 4. Quais são as principais funcionalidades que o sistema deverá possuir? O sistema deverá realizar cadastro alunos e orientadores, gerar ficha completa (relatório) ou somente com os dados solicitados dos alunos, arquivar publicações (entre elas, artigos, dissertações e teses) junto à ficha do aluno. 5. Quais funcionalidades os usuários poderão acessar? Gerar ficha completa ou somente com os dados solicitados dos alunos (por exemplo, nome, data nascimento, RG, CPF, sexo, etc), arquivar e fazer upload das publicações. Entretanto modificações que afetem tanto o sistema quanto a ficha cadastral somente poderão ser feitas por pessoal autorizado.

72 71 Questões referentes à Infra Estrutura 6. É necessário utilizar perfil de usuário para definir acesso aos usuários? Sim. O administrador terá acesso a todas as funcionalidades do software. E os usuários comuns terão acesso apenas à pesquisa de alunos e publicações. 7. Qual plataforma o sistema irá utilizar? plataformas. Plataforma Windows. Futuramente se for de interesse, colocar para outras 8. Qual banco de dados que irá utilizar? Será utilizado um SGBD livre, no caso, o MYSQL. 9. O sistema estará alocado dentro da Universidade ou em servidor de terceiros? Dentro da Universidade. 10. Qual é o prazo de entrega? 10/12/2011. Preferencialmente. 11. Necessita de uma equipe para o treinamento do Projeto? Não. Somente a desenvolvedora do sistema. 12. Há disponibilidade de alguém para acompanhar o desenvolvimento? Sim. Pessoal administrativo. 13. Necessita treinamento no processo a ser sistematizado? Sim, da desenvolvedora. 14. Necessidade de alguma linguagem especifica? O software será desktop, no entanto a linguagem para esse projeto será JAVA.

73 Já há informações em arquivos ou banco de outros sistemas? Sim, várias informações estão em planilhas (Excel) feitas pelo pessoal administrativo. 16. Sistema terá integração com outros sistemas atuais? Não. 17. Qual é a configuração padrão das máquinas da empresa (Windows 95, 98, 2000, XP ou Linux)? A maioria com Windows XP. 18. O sistema atenderá mais franquias da própria empresa? Não

74 73 Apêndice B Documento de Visão Documento de Visão - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Documento de Visão

75 74 SUMÁRIO 1- SOBRE O DOCUMENTO Objetivos do Documento Escopo Referências NECESSIDADE DO NEGOCIO OBJETIVO DO PROJETO DECLARAÇÃO PRELIMINAR DO ESCOPO Descrição Produtos a Serem Entregues Requisitos Requisitos Funcionais Requisitos Não Funcionais RESTRINÇOES Restrição de Tempo PREMISSAS DESCRIÇÃO DO USUÁRIO INFLUÊNCIA DAS PARTES INTERESSADAS 82

76 75 1- SOBRE O DOCUMENTO 1.1- Objetivos do Documento Este documento trata principalmente do registro das necessidades de negócios, da justificativa do Sistema de Controle Acadêmico, do entendimento atual das necessidades do cliente e descreve resumidamente o novo produto, serviço ou resultado que deve satisfazer esses requisitos. Tem o objetivo de alinhar as expectativas dos interessados para formalizar o início do projeto. Nenhum detalhamento de funcionalidades será feito neste documento. Outros documentos de definições de requisitos serão gerados ao longo do projeto Escopo Acadêmico. O escopo deste documento trata do desenvolvimento de um Sistema de Controle 1.3- Referências Para a construção deste documento foram utilizadas as seguintes referências: Reuniões com um dos professores da UFPel, vide o anexo com apêndice A; Análise do sistema de banco de dados atual na universidade. Este documento influencia o seguinte documento: Documento de Requisitos

77 76 2- NECESSIDADES DO NEGÓCIO Um software de banco de dados para o sistema de pós-graduação precisa ser desenvolvido para que a Universidade Federal de Pelotas (UFPel) possa controlar dados cadastrais de alunos e orientadores, bem como as publicações feitas por eles, emitir relatório com o perfil de cada aluno e com isso ter um melhor controle no sistema de pós-graduação.

78 77 3- OBJETIVO DO PROJETO Desenvolver um sistema que seja capaz de: a. Acesso através de autenticação com usuário e senha; b. Armazenar dados cadastrais e institucionais de alunos e orientadores; c. Arquivar publicações, como por exemplo, artigos e teses; d. Fazer upload dessas publicações; e. Pesquisar por aluno ou orientador.

79 78 4- DECLARAÇÃO PRELIMINAR DO ESCOPO 4.1- Descrição A Universidade Federal de Pelotas de pós-graduação tem a grande necessidade de organizar relatórios com perfis de alunos, para ter um bom acompanhamento desempenho acadêmico e controle desses alunos. Com isso, a Universidade sente falta de um sistema automatizado que proporcione, à administração, emitir um relatório com o perfil de cada aluno, onde possam ser contidos todos os dados cadastrais e institucionais de cada um deles Produtos a Serem Entregues Os seguintes itens são considerados produtos do projeto. Os itens a seguir serão entregues em etapas distintas do projeto: 1ª etapa: Motivação e Referencial Teórico; 2ª etapa: Modelagem do sistema e da base de dados; 3ª etapa: Implementação do sistema e da base de dados; 4ª etapa: Testes e Análise de Resultados. 5ª etapa: Sistema de Banco de Dados Acadêmico Final Requisitos Requisitos Funcionais O sistema deverá ter apenas um usuário administrador, o qual será responsável por manter todos os outros usuários, gerenciar todos os dados cadastrais, assim cadastrar alunos e orientadores. Os demais usuários poderão efetuar pesquisar, gerar os relatórios com perfis de alunos e fazer upload das publicações. Para mais detalhes vide documento de requisitos, encontra-se em anexo no apêndice C Requisitos Não Funcionais O sistema utilizará a metodologia RUP, deverá ser escrito em linguagem JAVA, ser um software desktop e ser compatível principalmente com a plataforma Windows XP. A base de dados do Sistema ACADSISTEM deverá ser instalada em máquina separada do ambiente de produção. Para mais detalhes vide documento de requisitos, encontra-se em anexo no apêndice C.

80 79 5- RESTRIÇÕES 5.1- Restrição de Tempo Este projeto tem uma data prevista para entrega, dia dez de dezembro de No entanto, até essa data, o software precisa estar funcionando com os devidos requisitos.

81 80 6- PREMISSAS O projeto contará com o apoio de um orientador da Universidade; O projeto contará com o apoio de uma orientadora da Faculdade Fatec.

82 81 7- DESCRIÇÃO DO USUÁRIO O software será utilizado pelo pessoal administrativo da UFPel. Uma pessoa será responsável pela administração do software. Esta mesma terá acesso a todas as funcionalidades do software. Sendo assim, ela será responsável pelo cadastro de outros usuários que terão acesso apenas a algumas funcionalidades

83 82 8- INFLUÊNCIA DAS PARTES INTERESSADAS a. Christianne Melo Silva Paraíso: Desenvolvedora do Software. b. Universidade Federal de Pelotas: mentora da idéia do aplicativo; c. Hueder Paulo Moisés de Oliveira: Professor Adjunto I da Universidade Federal de Pelotas; orientador pela UFPel e cliente do projeto; d. Administração da UFPel: interessada em acompanhar o perfil acadêmico dos alunos e orientadores; e. Juliana Pasquini: orientadora pela Fatec;

84 83 Apêndice C Documento de Requisitos Documento de Requisitos - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Documento de Requisitos

85 84 SUMÁRIO 1- INTRODUÇÃO DEFINIÇÃO DO PROBLEMA REQUISITOS FUNCIONAIS REQUISITOS NÃO-FUNCIONAIS 88

86 85 1- INTRODUÇÃO Este documento faz uma especificação dos requisitos do sistema para o cliente, usuários finais e desenvolvedores de software, especificando o que foi requisitado pelo cliente.

87 86 2- DEFINIÇÃO DO PROBLEMA A tabela 14 apresenta a definição do problema. O Problema Quem é afetado TABELA 14 DEFINIÇÃO DO PROBLEMA A Universidade tem a grande necessidade de organizar relatórios com perfis de alunos para ter um bom acompanhamento de desempenhos acadêmicos e controle desses alunos de pós-graduação. Porém a Universidade não tem um aplicativo automatizado que proporcione, à administração, emitir um relatório com o perfil de cada aluno e orientador, onde possam ser contidos todos os dados cadastrais e institucionais de cada um deles Administradores da Universidade Federal de Pelotas. Uma Boa Solução poderia ser Desenvolver um sistema de software para o sistema de controle acadêmico do curso de pós-graduação da Universidade Federal de Pelotas.

88 87 3- REQUISITOS FUNCIONAIS A tabela 15 apresenta os requisitos funcionais. Tabela 15 Requisitos Funcionais Código Requisito RF01 RF02 RF03 RF04 RF05 RF06 Possuir dois tipos de usuários: Administrador e Usuário Comum. Permitir a liberação do sistema após autenticação do usuário. Permitir as seguintes consultas aos usuários sobre alunos: RF Condição perante o programa de pós-graduação; RF Disciplinas cursadas; RF Disciplinas dependentes; RF Contagem de crédito; RF Status de proficiência em língua estrangeira; RF Matricula em mestrado ou doutorado e; RF Em qual curso está matriculado; RF Publicações realizadas. Para o usuário Administrador permitir o gerenciamento de: RF Usuários comuns; RF Alunos; RF Orientadores e; RF Publicações. Gerar relatório a partir dos resultados obtidos na pesquisa. Fazer upload das publicações.

89 88 4- REQUISITOS NÃO FUNCIONAIS A tabela 16 apresenta os requisitos não funcionais. Tabela 16 Requisitos Não Funcionais Código Requisito RNF01 Acessível apenas em modo desktop. RNF02 Desenvolvido em JAVA. RNF03 Compatível com Windows XP e Seven. RNF04 MySQL SGBD utilizado. RNF05 Hardware: Servidor superior a: RNF0501-2GB de RAM; RNF GB disponível em HD. RNF06 Níveis de acesso.

90 89 Apêndice D Especificação Suplementar Especificação Suplementar - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Especificação Suplementar

91 90 SUMÁRIO 1- DEFINIÇÕES LEGAIS E REGULARES ATRIBUTOS DE QUALIDADE AO SISTEMA ATRIBUTOS DE CONFIABILIDADE 93

92 91 1- DEFINIÇÕES LEGAIS E REGULARES A tabela a seguir apresenta a todos os envolvidos do projeto a definição do título do sistema, da propriedade e distribuição. Tabela 17 Definições do Sistema Definições Gerais do Sistema Título do Sistema AcadSistem Sistema de Controle Acadêmico. Propriedade do Sistema O sistema AcadSistem é de propriedade de seus idealizadores. Distribuição do Sistema A distribuição do sistema é de responsabilidade de seus idealizadores. Não é garantida nenhuma exclusividade no uso do sistema.

93 92 2- ATRIBUTOS DE QUALIDADE AO SISTEMA Na tabela a seguir são apresentados os requisitos de design do sistema AcadSistem que será desenvolvido para uso da Universidade Federal de Pelotas. Cores da Interface com o Usuário Logotipo na Interface Intuitividade e Usabilidade na Interface Compatibilidade de Browsers Restrições de Design Tabela 18 Requisitos de Design e Qualidade Requisitos de Design e Qualidade As cores utilizadas na interface de interação com o usuário serão as cores laranja, azul e preto. O logotipo do sistema deverá ser inserido em todas interfaces de interação com o usuário. As interfaces do sistema deverão ser intuitivas, de forma que se gaste o menor tempo possível com treinamento do pessoal que utilizará o sistema. O sistema deverá ser compativel com o Sistema Operacional Windows. Cores destoantes. Logotipo com tamanho incompativel.

94 93 3- ATRIBUTOS DE CONFIABILIDADE A tabela abaixo registra os requisitos de confiabilidade do sistema, são abordados tempo de disponibilidade, tempo médio entre falhas e reparos taxa aceitavel de erros ou defeitos. Disponibilidade do Sistema Tempo Médio Entre Falhas Tempo Médio de Reparo Taxa de Erros Categorizados Tabela 19 Requisitos de Confiabilidade Requisitos de Confiabilidade O sistema deverá estar disponível aos usuários 24h por dia. Após a fase de implantação do sistema o tempo médio entre falhas será de 30 dias. O tempo de reparo deverá respeitar o limite maximo de 48h para finais de semana e 24h para dias de semana, sendo que, durante a semana o trabalho de reparo será efetuado após o horário de expediente da Universidade. Para caso de extrema necessidade será tolerado o limite máximo de 2h para reparos durante o expediente da Universidade. Erros importantes serão aceitos desde que se respeite o tempo de reparo estipulado. Erros críticos não serão aceitos. Entende-se por erro importante: incapacidade de utilizar determinada parte do sistema. Entende-se por erro crítico: perda total de dados.

95 94 Apêndice E Descrição do Caso de Uso Descrição do Caso de Uso - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Descrição do Caso de Uso

96 95 SUMÁRIO 1- CASO DE USO DO SISTEMA 96

97 96 1- CASO DE USO DO SISTEMA As tabelas a seguir detalham os casos de uso do sistema. Tabela 20 Caso de Uso Autenticar Nome: Autenticar Atores: Todos os tipos de usuários Precondições: Nenhuma. 1. Usuário abre o sistema AcadSistem. 2. O usuário deve informar no local indicado o login e a senha e Fluxo clicar no botão logar. Principal: 3. Caso seja usuário do tipo Administrador, irá abrir a tela principal do administrador; caso contrário, abrirá a tela principal comum. Fluxo de Exceção [3]: 3.1.Caso o login ou senha esteja incorreto ou login não exista no banco de dados, o sistema enviará uma mensagem informando o erro; 3.2.Usuário confirma a informação e tenta o login novamente. Tabela 21 Caso de Uso Pesquisar Usuário Nome: Pesquisar usuário. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Por Usuário no menu de pesquisas; Principal: 2. Usuário deve informar nome ou parte do nome do usuário na tela de pesquisa de usuário e clicar no botão Pesquisar ; 3. Em seguida o sistema retornará uma lista de usuários que tem o nome ou parte do nome informado; 4. Usuário seleciona o usuário desejado. Fluxo de Exceção [3]: 1.1.Caso não exista nenhum usuário com o nome ou parte do nome informado, o sistema retornará uma mensagem informando que não existe nenhum usuário cadastrado com aquele nome. 1.2.Em seguida o usuário confirma a informação. Tabela 22 Caso de Uso Pesquisar Aluno Nome: Pesquisar aluno. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Por Aluno no menu de pesquisas; Principal: 2. Usuário deve informar nome ou parte do nome do aluno na tela de pesquisa de aluno e clicar no botão Pesquisar ; 3. Em seguida o sistema retornará uma lista de aluno que tem o nome ou parte do nome informado; 4. Usuário seleciona o aluno desejado.

98 97 Fluxo de Exceção [3]: 3.1.Caso não exista nenhum aluno com o nome ou parte do nome informado, o sistema retornará uma mensagem informando que não existe nenhum aluno cadastrado com aquele nome. 3.2.Em seguida o usuário confirma a informação. Tabela 23 Caso de Uso Pesquisar Orientador Nome: Pesquisar orientador. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Por Orientador no menu de pesquisas; Principal: 2. Usuário deve informar nome ou parte do nome do orientador na tela de pesquisa de aluno e clicar no botão Pesquisar ; 3. Em seguida o sistema retornará uma lista de orientadores que tem o nome ou parte do nome informado; 4. Usuário seleciona o orientador desejado. Fluxo de Exceção [3]: 3.1.Caso não exista nenhum orientador com o nome ou parte do nome informado, o sistema retornará uma mensagem informando que não existe nenhum orientador cadastrado com aquele nome. 3.2.Em seguida o usuário confirma a informação. Tabela 24 Caso de Uso Pesquisar Publicação Nome: Pesquisar publicação. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Por Publicação no menu de pesquisas; Principal: 2. Usuário deve informar nome ou parte do nome da publicação na tela de pesquisa de publicação e clicar no botão Pesquisar ; 3. Em seguida o sistema retornará uma lista de publicações que tem o nome ou parte do nome informado; 4. Usuário seleciona a publicação desejada. Fluxo de Exceção [3]: 3.1.Caso não exista nenhuma publicação com o nome ou parte do nome informado, o sistema retornará uma mensagem informando que não existe nenhuma publicação cadastrada com aquele nome. 3.2.Em seguida o usuário confirma a informação. Tabela 25 Caso de Uso Pesquisar Usuário Nome: Gerenciar Usuário. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Usuário no menu de gerenciamento;

99 98 Principal: Fluxo Exceção: de 2. Em seguida o sistema retornará a página de cadastro de usuário. Caso o usuário deseje realizar alterações ou exclusões de usuários, deverá pesquisar por tal primeiro. N/A Tabela 26 Caso de Uso Gerenciar Aluno Nome: Gerenciar Aluno Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Aluno no menu de gerenciamento; Principal: 2. Em seguida o sistema retornará a página de cadastro de aluno. Caso o usuário deseje realizar alterações ou exclusões de alunos, deverá pesquisar por tal primeiro. Fluxo Exceção: de N/A Tabela 27 Caso de Uso Gerenciar Orientador Nome: Gerenciar Orientador. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Orientador no menu de gerenciamento; Principal: 2. Em seguida o sistema retornará a página de cadastro de orientador. Caso o usuário deseje realizar alterações ou exclusões de orientadores, deverá pesquisar por tal primeiro. Fluxo Exceção: de N/A Tabela 28 Caso de Uso Gerenciar Publicação Nome: Gerenciar Publicação. Atores: Usuários Administradores. Precondições: Usuário ser administrador e estar logado no sistema. Fluxo 1. Usuário seleciona Publicação no menu de gerenciamento; Principal: 2. Em seguida o sistema retornará a página de cadastro de publicação. Caso o usuário deseje realizar alterações ou exclusões de publicações, deverá pesquisar por tal primeiro. Fluxo Exceção: de N/A Nome: Atores: Tabela 29 Caso de Uso Gerar Relatório de Aluno Gerar Relatório de Aluno Todos os tipos de usuários.

100 99 Precondições: Estar logado no sistema. Fluxo 1. Usuário seleciona Aluno no menu de relatório; Principal: 2. O sistema retornará a página solicitando o nome do aluno. 3. O usuário deve informar o nome ou parte do nome do aluno no campo solicitado. 4. Em seguida o sistema retornará uma lista de alunos que tem o nome ou parte do nome informado; 5. Usuário seleciona o aluno desejado. 6. Sistema retorna o relatório completo do aluno. Fluxo Exceção: de N/A Tabela 30 Caso de Uso Upload de Publicação Nome: Upload de Publicação Atores: Todos os tipos de usuários. Precondições: Estar logado no sistema. Fluxo 1. Usuário seleciona Publicação no menu de upload; Principal: 2. O sistema retornará a página solicitando o nome do arquivo. 3. O usuário deve informar o nome ou parte do nome do arquivo no campo solicitado. 4. Em seguida o sistema retornará uma lista de arquivos que tem o nome ou parte do nome informado; 5. Usuário seleciona o arquivo desejado. 6. Sistema retorna o arquivo. Fluxo Exceção: de N/A

101 100 Apêndice F Protótipo de Tela Protótipo de Tela - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Protótipo de Tela

102 101 SUMÁRIO 1- PROTÓTIPO DE TELA Autenticar Principal Administrador Principal Comum Gerenciar Aluno Gerenciar Usuário Gerenciar Orientador Gerenciar Publicação Pesquisar Aluno Pesquisar Usuário Pesquisar Orientador Pesquisar e Upload de Publicação Relatório de Aluno 109

103 PROTÓTIPO DE TELA As figuras a seguir apresentam os protótipos de tela do sistema ACADSISTEM Autenticar A figura 41 demonstra a tela de autenticação. Figura 41 Tela de Autenticação A tela de autenticação tem dois campos no qual solicita o login e a senha do usuário respectivamente e um botão que verificar o valor digitado no campo e o redireciona a página principal do sistema Principal Administrador A figura 42 demonstra a tela principal do usuário administrador.

104 103 Figura 42 Tela de Principal do Administrador Nesta tela é possível ao usuário administrador gerenciar e pesquisar outros usuários, alunos, orientadores e publicações, além de gerar relatórios dos alunos Principal Comum A figura 43 demonstra a tela principal do usuário comum. Figura 43 Tela de Principal do Usuário Comum

105 104 Nesta tela é possível ao usuário comum, pesquisar e realizar upload de por publicações, além de gerar relatórios de alunos Gerenciar Aluno A figura 44 demonstra a tela de gerenciamento de aluno. Figura 44 Tela De Gerenciamento de Aluno Esta tela é composta por vários campos de texto, que solicitam os dados dos alunos a serem cadastrados Gerenciar Usuário A figura 45 demonstra a tela de gerenciamento de usuário.

106 105 Figura 45 Tela De Gerenciamento de Usuário Esta tela é composta por vários campos de texto, que solicitam os dados dos usuários a serem cadastrados Gerenciar Orientador A figura 46 demonstra a tela de gerenciamento de orientador. Figura 46 Tela De Gerenciamento de Orientador

107 106 Esta tela é composta por vários campos de texto, que solicitam os dados dos orientadores a serem cadastrados Gerenciar Publicação A figura 47 demonstra a tela de gerenciamento de publicação. Figura 47 Tela De Gerenciamento de Publicação Esta tela é composta por vários campos de texto, que solicitam os dados das publicações a serem cadastrados Pesquisar Aluno A figura 48 demonstra a tela de pesquisa de aluno.

108 107 Figura 48 Tela de Pesquisa de Aluno Esta tela é composta por um campo de texto que recebe o nome do aluno a ser pesquisado e uma tabela que retornará uma lista de alunos Pesquisar Usuário A figura 49 demonstra a tela de pesquisa de usuário. Figura 49 Tela de Pesquisa de Usuário Esta tela é composta por um campo de texto que recebe o nome do usuário a ser pesquisado e uma tabela que retornará uma lista de usuários.

109 Pesquisar Orientador A figura 50 demonstra a tela de pesquisa de orientador. Figura 50 Tela de Pesquisa de Orientador Esta tela é composta por um campo de texto que recebe o nome do orientador a ser pesquisado e uma tabela que retornará uma lista de orientadores Pesquisar e Upload de Publicação A figura 51 demonstra a tela de pesquisa e upload de publicação. Figura 51 Tela de Pesquisa e Upload de Publicação

110 109 Esta tela é composta por um campo de texto que recebe o nome da publicação a ser pesquisada e uma tabela que retornará uma lista de publicações Relatório De Aluno A figura 52 demonstra a tela de solicitação de relatório de aluno. Figura 52 Tela de Solicitação de Relatório de Aluno Esta tela receberá o RA do aluno, pesquisará o mesmo e retornará todos os dados do aluno requerido pelo usuário do sistema.

111 110 Apêndice G Dicionário de Dados Dicionário de Dados - AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Dicionário de Dados

112 111 SUMÁRIO 1- DICIONÁRIO DE DADOS 112

113 DICIONÁRIO DE DADOS A seguir serão descritas as tabelas que formarão o software. Tabela 31 Tabela Aluno Nome da tabela: Aluno Descrição: Tabela que armazenará os dados do aluno. Campo Constraint Tipo numérico Descrição ALU_RA PRIMARY KEY INT(2) Código de identificação ALU_NOME NOT NULL VARCHAR(50) Nome ALU_SEXO NOT NULL VARCHAR(1) Sexo ALU_DATANASC NOT NULL DATE Data de nascimento ALU_CPF UNIQUE VARCHAR(20) CPF ALU_FILIACAO NOT NULL VARCHAR(50) Nome da mãe ALU_ENDEREÇO NOT NULL VARCHAR(50) Endereço ALU_TELEFONE NOT NULL VARCHAR(20) Telefone ALU_DATAMATR NOT NULL DATE Data da matricula ALU_DISCCONC VARCHAR(250) Disciplinas cursadas ALU_DISCPEND VARCHAR(250) Disciplinas pendentes ALU_PROFIC VARCHAR (1) Proficiência em língua estrangeira ALU_SISTEMA NOT NULL VARCHAR(20) Mestrado ou doutorado ALU_CURSO NOT NULL VARCHAR(20) Curso ORIENT_ID FOREING KEY INT(2) Código do orientador Tabela 32 Tabela Orientador Nome da tabela: Orientador Descrição: Tabela que armazenará os dados do orientador. Campo Constraint Tipo numérico Descrição ORIENT_ID PRIMARY INT(2) Código de identificação KEY ORIENT_NOME NOT NULL VARCHAR(50) Nome ORIENT_DATANASC NOT NULL DATE Data de nascimento ORIENT_CPF UNIQUE VARCHAR(20) CPF ORIENT_INSTITUICAO NOT NULL VARCHAR(50) Nome da mãe ORIENT_TITULACAO NOT NULL VARCHAR(50) Endereço Tabela 33 Tabela Publicação Nome da tabela: Publicação Descrição: Tabela que armazenará os dados das publicações. Campo Constraint Tipo numérico Descrição PUBL_ID PRIMARY INT(2) Código de identificação KEY PUBL_TITULO NOT NULL VARCHAR(50) Nome PUBL_DATAPUBL NOT NULL DATE Data de publicação PUBL_TIPO VARCHAR(15) Tipo. Ex: tese ou artigo PUBL_DIRETORIO NOT NULL VARCHAR(200) Diretório do arquivo

114 113 ALU_RA ORIENT_ID FOREIGN KEY FOREIGN KEY INT(2) INT(2) Código do aluno que fez Código do orientador Tabela 34 Tabela Usuário Nome da tabela: Usuário Descrição: Tabela que armazenará os dados do usuário. Campo Constraint Tipo numérico Descrição USU_ID PRIMARY INT(2) Código de identificação KEY USU_NOME NOT NULL VARCHAR2(50) Nome USU_LOGIN NOT NULL VARCHAR2(50) Login USU_TEL NOT NULL VARCHAR2(30) Telefone USU_SENHA NOT NULL VARCHAR2(10) Senha USU_TIPO NOT NULL CHAR(1) Tipo. Ex: administrador ou usuário comum

115 114 Apêndice H Manual de Instruções do AcadSistem Manual de Instruções do AcadSistem Cliente: Universidade Federal de Pelotas Aplicação: AcadSistem DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE ACADÊMICO ACADSISTEM Manual de Instruções do AcadSistem

116 115 SUMÁRIO 1- INTRODUÇÃO ACESSO AO SISTEMA ACADSISTEM ACESSO PRINCIPAL DO USUÁRIO ADMINISTRADOR ACESSO PRINCIPAL DO USUÁRIO COMUM GERENCIAMENTO DE USUÁRIO GERENCIAMENTO DE ALUNO GERENCIAMENTO DE ORIENTADOR GERENCIAMENTO DE PUBLICAÇÃO PESQUISAR POR ALUNO PESQUISAR POR ORIENTADOR PESQUISAR POR PUBLICAÇÃO PESQUISAR POR USUÁRIO VISUALIZAÇÃO DA PUBLICAÇÃO SOLICITAÇÃO DE RELATORIO DE ALUNO RELATÓRIO COMPLETO DE ALUNO 135

117 INTRODUÇÃO Este documento tem o objetivo de orientar o usuário final na utilização do sistema para que possa aproveitar os recursos oferecidos.

118 ACESSO AO SISTEMA ACADSISTEM A figura 53 mostra os detalhes da tela de autenticação. Figura 53 Detalhes da Tela de Autenticação Tabela 35 Descrição da Tela de Autenticação Campo Descrição 1 Login: campo destinado a identificação do usuário. 2 Senha: campo destinado a senha do usuário. 3 Logar: Botão de acesso ao sistema 4 Sair: Botão de saída do sistema. Tanto o usuário comum quanto o usuário administrador acessam o sistema através desta página. Os campos 01 e 02 são obrigatórios para o acesso ao sistema.

119 ACESSO PRINCIPAL DO USUÁRIO ADMINISTRADOR A figura 54 mostra os detalhes da tela principal do usuário administrador. Figura 54 Detalhes da Tela Principal do Administrador As figura 56 e 57 mostram os detalhes da barra de menu. Figura 55 Detalhes da Barra de Menu: Navegar Figura 56 Detalhes da Barra de Menu: Ajuda

120 119 Tabela 36 Descrição da Tela Principal do Administrador Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Ir: Botão de acesso ao cadastro de usuário. 4 Ir: Botão de acesso ao cadastro de aluno. 5 Ir: Botão de acesso ao cadastro de orientador. 6 Ir: Botão de acesso ao cadastro de publicação. 7 Pesquisar: Botão de acesso à pesquisa de aluno. 8 Pesquisar: Botão de acesso à pesquisa de orientador. 9 Pesquisar: Botão de acesso à pesquisa de publicação. 10 Pesquisar: Botão de acesso à pesquisa de usuário. 11 Gerar: Gerar relatório completo de aluno. 12 Sair: Botão de saída do sistema. 13 Logoff: Botão de saída do sistema. 14 Conteúdo da ajuda: Redirecionamento à ajuda. 15 Sobre: Título do Sistema. Esta tela é de acesso restrito a usuários administradores. Os campos 13, 14 e 15 estarão na maioria das telas a seguir, por isso não serão descritos novamente.

121 ACESSO PRINCIPAL AO USUÁRIO COMUM A figura 57 mostra os detalhes da tela principal do usuário comum. Figura 57 Detalhes da Tela Principal do Usuário Comum Tabela 37 Descrição da Tela Principal do Usuário Comum Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Pesquisar: Botão de acesso à pesquisa de publicação. 4 Gerar: Gerar relatório completo de aluno. 5 Sair: Botão de saída do sistema. Esta tela é de acesso restrito a usuários comuns. Nela o usuário pode pesquisar por publicações e solicitar relatório completo de alunos.

122 GERENCIAMENTO DE USUÁRIO A figura 58 mostra os detalhes da tela de gerenciamento de usuário. Figura 58 Detalhes da Tela de Gerenciamento de Usuário Tabela 38 Descrição da Tela de Gerenciamento de Usuário Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Id: Campo destinado ao id do usuário. 4 Telefone: Campo destinado ao telefone do usuário. 5 Nome: Campo destinado ao nome do usuário. 6 Senha: Campo destinado à senha do usuário. 7 Login: Campo destinado ao login do usuário. 8 Tipo: Campo destinado ao tipo do usuário. 9 Novo: Botão para um novo cadastro. 10 Editar: Botão de edição de cadastro. 11 Alterar: Botão de alteração de cadastro. 12 Salvar: Botão de conclusão de cadastro. 13 Excluir: Botão de exclusão de cadastro. 14 Voltar: Redirecionamento à página inicial.

123 Sair do Sistema: Botão de saída do sistema. Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os campos com * deverão ser preenchidos no ato do cadastro ou da alteração.

124 GERENCIAMENTO DE ALUNO A figura 59 mostra os detalhes da tela de gerenciamento de aluno. Figura 59 Detalhes da Tela de Gerenciamento de Aluno Tabela 39 Descrição da Tela de Gerenciamento de Aluno Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 RA: Campo destinado ao ra do aluno. 4 Nome: Campo destinado ao nome do aluno. 5 Sexo: Campo destinado ao sexo do aluno. 6 Data de Nasc: Campo destinado à data de nascimento do aluno. 7 Filiação: Campo destinado à filiação do aluno. 8 CPF: Campo destinado ao cpf do aluno. 9 Endereço: Campo destinado ao endereço do aluno. 10 Telefone: Campo destinado ao telefone do aluno. 11 Data de Matr.:Campo destinado à data da matricula do aluno. Curso: Campo destinado ao curso em que o aluno está 12 matriculado. 13 Teste: Campo destinado ao teste de proficiência em inglês.

125 Sistema: Campo destinado ao sistema em que o aluno está matriculado. 15 Orientador: Campo destinado ao id do orientador do aluno. 16 Disc. Concl.:Campo destinado as matérias concluídas pelo aluno. 17 Disc. Pend.:Campo destinado as matérias pendentes do aluno. 18 Novo: Botão para um novo cadastro. 19 Editar: Botão de edição de cadastro. 20 Alterar: Botão de alteração de cadastro. 21 Salvar: Botão de conclusão de cadastro. 22 Excluir: Botão de exclusão de cadastro. 23 Voltar: Redirecionamento à página inicial. 24 Sair do Sistema: Botão de saída do sistema. Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os campos com * deverão ser preenchidos no ato do cadastro ou da alteração.

126 GERENCIAMENTO DE ORIENTADOR A figura 60 mostra os detalhes da tela de gerenciamento de orientador. Figura 60 Detalhes da Tela de Gerenciamento de Orientador Tabela 40 Descrição da Tela de Gerenciamento de Orientador Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Id: Campo destinado ao id do orientador. 4 Nome: Campo destinado ao telefone do orientador. Data de Nasc.:Campo destinado à data de nascimento do 5 orientador. 6 CPF: Campo destinado ao CPF do orientador. 7 Titulação: Campo destinado à titulação do orientador. 8 Instituição: Campo destinado à instituição do orientador. 9 Novo: Botão para um novo cadastro. 10 Editar: Botão de edição de cadastro. 11 Alterar: Botão de alteração de cadastro. 12 Salvar: Botão de conclusão de cadastro. 13 Excluir: Botão deexclusão de cadastro.

127 Voltar: Redirecionamento à página inicial. 15 Sair do Sistema: Botão de saída do sistema. Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os campos com * deverão ser preenchidos no ato do cadastro ou da alteração.

128 GERENCIAMENTO DE PUBLICAÇÃO A figura 61 mostra os detalhes da tela de gerenciamento de publicação. Figura 61 Detalhes da Tela de Gerenciamento de Publicação Tabela 41 Descrição da Tela de Gerenciamento de Publicação Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Upload: Botão para realizar upload do arquivo. 4 Id: Campo destinado ao id do orientador. 5 Data de Publ.:Campo destinado à data publicada da publicação. 6 Titulo: Campo destinado ao título da publicação. 7 Tipo: Campo destinado ao tipo da publicação. 8 Orientador: Campo destinado ao orientador da publicação. 9 Aluno: Campo destinado ao aluno que escreveu a publicação. 10 Diretório: Campo destinado ao diretório da publicação 11 Procurar: Botão para procurar diretório. 12 Novo: Botão para um novo cadastro. 13 Editar: Botão de edição de cadastro. 14 Alterar: Botão de alteração de cadastro.

129 Salvar: Botão de conclusão de cadastro. 16 Excluir: Botão de exclusão de cadastro. 17 Voltar: Redirecionamento à página inicial. 18 Sair do Sistema: Botão de saída do sistema. Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os campos com * deverão ser preenchidos no ato do cadastro ou da alteração.

130 PESQUISAR POR ALUNO A figura 62 mostra os detalhes da tela de pesquisa de aluno. Figura 62 Detalhes da Tela de Pesquisa de Aluno Tabela 42 Descrição da Tela de Pesquisa de Aluno Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. Nome: Campo destinado ao nome ou parte do nome do aluno a 3 ser pesquisado. 4 Pesquisar: Botão para realizar a pesquisa. 5 Tabela: Tabela destinada aos resultados encontrados. 6 Voltar: Redirecionamento à página inicial. 7 Sair do Sistema: Botão de saída do sistema. Pesquisa destinada somente aos usuários administradores. É preciso preencher o campo com o nome ou parte do nome do aluno para que o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os resultados (alunos) existentes no banco de dados.

131 PESQUISAR POR ORIENTADOR A figura 63 mostra os detalhes da tela de pesquisa de orientador. Figura 63 Detalhes da Tela de Pesquisa de Orientador Tabela 43 Descrição da Tela de Pesquisa de Orientador Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. Nome: Campo destinado ao nome ou parte do nome do 3 orientador a ser pesquisado. 4 Pesquisar: Botão para realizar a pesquisa. 5 Tabela: Tabela destinada aos resultados encontrados. 6 Voltar: Redirecionamento à página inicial. 7 Sair do Sistema: Botão de saída do sistema. Pesquisa destinada somente aos usuários administradores. É preciso preencher o campo com o nome ou parte do nome do orientador para que o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os resultados (orientadores) existentes no banco de dados.

132 PESQUISAR POR PUBLICAÇÃO A figura 64 mostra os detalhes da tela de pesquisa de publicação. Figura 64 Detalhes da Tela de Pesquisa de Publicação Tabela 44 Descrição da Tela de Pesquisa de Publicação Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. 2 Ajuda: campo destinado ao acesso aos campos Conteúdo da Ajuda e Sobre. 3 Nome: Campo destinado ao título ou parte do título da publicação a ser pesquisada. 4 Pesquisar: Botão para realizar a pesquisa. 5 Tabela: Tabela destinada aos resultados encontrados. 6 Voltar: Redirecionamento à página inicial. 7 Sair do Sistema: Botão de saída do sistema. Pesquisa destinada tanto para os usuários administradores quanto para usuários comuns. É preciso preencher o campo com o título ou parte do título da publicação para que o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os resultados (publicações) existentes no banco de dados.

133 PESQUISAR POR USUÁRIO A figura 65 mostra os detalhes da tela de pesquisa de usuário. Figura 65 Detalhes da Tela de Pesquisa de Usuário Tabela 45 Descrição da Tela de Pesquisa de Usuário Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. 2 Ajuda: campo destinado ao acesso aos campos Conteúdo da Ajuda e Sobre. 3 Nome: Campo destinado ao nome ou parte do nome do usuário a ser pesquisado. 4 Pesquisar: Botão para realizar a pesquisa. 5 Tabela: Tabela destinada aos resultados encontrados. 6 Voltar: Redirecionamento à página inicial. 7 Sair do Sistema: Botão de saída do sistema. Pesquisa destinada somente aos usuários administradores. É preciso preencher o campo com o nome ou parte do nome do usuário para que o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os resultados (usuários) existentes no banco de dados.

134 VISUALIZACAO DA PUBLICACAO A figura 66 mostra os detalhes da tela de visualização da publicação. Figura 66 Detalhes da Tela de Visualização da Publicação Tabela 46 Descrição da Tela de Visualização da Publicação Campo Descrição 1 Navegar: campo destinado ao acesso ao campo Logoff. Ajuda: campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 Upload: Botão para realizar upload do arquivo. 4 Id: Campo destinado ao id do orientador. 5 Data de Publ.:Campo destinado à data publicada da publicação. 6 Titulo: Campo destinado ao título da publicação. 7 Tipo: Campo destinado ao tipo da publicação. 8 Orientador: Campo destinado ao orientador da publicação. 9 Aluno: Campo destinado ao aluno que escreveu a publicação. 10 Diretório: Campo destinado ao diretório da publicação 11 Voltar: Redirecionamento à página inicial. 12 Sair do Sistema: Botão de saída do sistema. Visualização de publicação destinada para usuários comuns. Nesta tela é possível o usuário realizar o upload do arquivo.

135 SOLICITAÇÃO DE RELATORIO DE ALUNO A figura 67 mostra os detalhes da tela de solicitação de relatório de aluno. Figura 67 Detalhes da Tela de Solicitação de Relatório de Aluno Tabela 47 Descrição da Tela de Solicitação de Relatório de Aluno Campo Descrição 1 Navegar:Campo destinado ao acesso ao campo Logoff. Ajuda: Campo destinado ao acesso aos campos Conteúdo da 2 Ajuda e Sobre. 3 RA: Campo destinado ao RA do aluno solicitado. 4 Pesquisar: Botão para realizar a pesquisa. 5 Voltar: Redirecionamento à página inicial. 6 Sair do Sistema: Botão de saída do sistema. Pesquisa destinada tanto a usuários administradores quanto a usuários comuns. É preciso preencher o campo com o RA do aluno solicitado, senão não será possível a solicitação de relatório.

136 RELATÓRIO COMPLETO DE ALUNO A figura 68 mostra os detalhes da tela de relatório de aluno. Figura 68 Detalhes da Tela de Relatório de Aluno Tabela 48 Descrição da Tela de Relatório de Aluno Campo Descrição 1 Arquivo:Acesso ao campo Voltar e Logoff. 2 Nome: Campo de retorno do nome do aluno. 3 Data de Nasc.:Campo de retorno da data de nascimento do aluno. 4 Endereço: Campo de retorno do endereço do aluno. 5 Filiação: Campo de retorno da filiação do aluno. 6 Sexo: Campo de retorno do sexo do aluno. 7 CPF: Campo de retorno do cpf do aluno. 8 Telefone: Campo de retorno do telefone do aluno. 9 RA: Campo de retorno do RA do aluno. 10 Sistema: Campo de retorno do sistema em que o aluno está matriculado. 11 Data de Matr.: Campo de retorno da data de matricula do aluno. 12 Curso: Campo de retorno do curso em que o aluno está matriculado. 13 Proficiência: Campo de retorno do teste de proficiência feito ou não pelo aluno. 14 Orientador: Campo de retorno do orientador do aluno. 15 Disc. Concluídas: Campo de retorno das matérias concluídas pelo aluno

DESENVOLVIMENTO DE APLICATIVO GERENCIADOR DE CONTROLE E ACIONAMENTO PARA PLATAFORMA ios 1

DESENVOLVIMENTO DE APLICATIVO GERENCIADOR DE CONTROLE E ACIONAMENTO PARA PLATAFORMA ios 1 DESENVOLVIMENTO DE APLICATIVO GERENCIADOR DE CONTROLE E ACIONAMENTO PARA PLATAFORMA ios 1 Diego Baltieri 2 Wladimir da Costa 3 RESUMO Ter uma ferramenta que gerencie os controles e acionamentos do setor

Leia mais

UML - Unified Modeling Language

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

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Engenharia de Software I

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

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

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

Leia mais

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

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

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

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

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

Leia mais

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

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

Leia mais

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

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

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

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

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

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

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

Leia mais

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

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

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

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

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

Leia mais

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

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

Leia mais

Fase 1: Engenharia de Produto

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

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

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

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

Leia mais

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Roosewelt Sanie Da Silva¹ 1 Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC) Rodovia

Leia mais

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

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

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

Leia mais

Algumas propriedades dos objetos:

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

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

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

Leia mais

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR NITERÓI 2010 IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO

Leia mais

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

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

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

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

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

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Sistema de Inteligência Patrimônial. Especificação dos Requisitos

Sistema de Inteligência Patrimônial. Especificação dos Requisitos Sistema de Inteligência Patrimônial Especificação dos Requisitos Especificação dos Requisitos Data Versão: 18 / 11 / 2015 Histórico das Revisões Data Versão Descrição Autor 23 / 11/ 2015 1.0 Versão Inicial

Leia mais

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini Banco de Dados Conceitos e Arquitetura de Sistemas de Banco de Dados Profa. Flávia Cristina Bernardini Relembrando... Vantagens da Utilização de SGBD Redundância controlada Consistência dos dados armazenados

Leia mais

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1. Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco

Leia mais

ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS

ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS Sumário 1. Finalidade... 2 2. Justificativa para contratação... 2 3. Premissas para fornecimento e operação

Leia mais

Documento de Requisitos Sistema WEB GEDAI

Documento de Requisitos Sistema WEB GEDAI Universidade Federal de São Carlos Centro de Ciências Exatas e de Tecnologia Departamento de Computação GEDAI-Grupo de Estudo e Desenvolvimento em Automação Industrial Documento de Requisitos Sistema WEB

Leia mais

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

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

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe: Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael

Leia mais

Fundamentos dos Sistemas de Informação Organização de Dados e Informações

Fundamentos dos Sistemas de Informação Organização de Dados e Informações Fundamentos dos Sistemas de Informação Organização de Dados e Informações http://professor.fimes.edu.br/milena milenaresende@fimes.edu.br Sistema de Gerenciamento de Bases de Dados (DBMS) A implementação

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

BANCO DE DADOS WEB AULA 4. linguagem SQL: subconjuntos DCL, DDL e DML. professor Luciano Roberto Rocha. www.lrocha.com

BANCO DE DADOS WEB AULA 4. linguagem SQL: subconjuntos DCL, DDL e DML. professor Luciano Roberto Rocha. www.lrocha.com BANCO DE DADOS WEB AULA 4 linguagem SQL: subconjuntos DCL, DDL e DML professor Luciano Roberto Rocha www.lrocha.com O que é SQL? Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL,

Leia mais

A Linguagem de Modelagem Unificada (UML)

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

Leia mais

Roteiro 2 Conceitos Gerais

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

Leia mais

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

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

Leia mais

Essencial ao Desenvolvimento de Software

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

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

Leia mais

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

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

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I CONCEITOS BÁSICOS 1. Conceitos básicos de BD, SBD e SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0 Plano de Projeto G Stock Plano de Projeto G Stock Versão 1.0 Histórico das Revisões Data Versão Descrição Autores 10/09/2010 1.0 Descrição inicial do plano de projeto Denyson José Ellís Carvalho Isadora

Leia mais

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

Manual de Instalação, Administração e Uso do Sistema Elétric

Manual de Instalação, Administração e Uso do Sistema Elétric Manual de Instalação, Administração e Uso do Sistema Elétric Versão 1.0 Autores Bruna Cirqueira Mariane Dantas Milton Alves Robson Prioli Nova Odessa, 10 de Setembro de 2013 Sumário Apoio 1. Licença deste

Leia mais

Sistema de Gerenciamento de Planos de Curso: Uma ferramenta de aperfeiçoamento para o processo de controle de planos de curso nas universidades

Sistema de Gerenciamento de Planos de Curso: Uma ferramenta de aperfeiçoamento para o processo de controle de planos de curso nas universidades Sistema de Gerenciamento de Planos de Curso: Uma ferramenta de aperfeiçoamento para o processo de controle de planos de curso nas universidades André Torres, Ednaldo Onofre, Francisco Celestino, Jafet

Leia mais

UML Unified Modeling Language

UML Unified Modeling Language UML Unified Modeling Language Linguagem de Modelagem Unificada A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem para especificação, É uma linguagem para

Leia mais

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Edson Alves de Oliveira Junior 1, Itana Maria de Souza Gimenes 1 1 Departamento de

Leia mais

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br)

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Algumas definições Engenharia de Software conjunto de tecnologias e práticas usadas para construir software de qualidade

Leia mais

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

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

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

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

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

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

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

Leia mais

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ELETRÔNICA. Sistema de Gerenciamento Eletrônico de Documentos

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ELETRÔNICA. Sistema de Gerenciamento Eletrônico de Documentos UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ELETRÔNICA Sistema de Gerenciamento Eletrônico de Documentos Autor: Evandro Bastos Tavares Orientador: Antônio Claudio Gomez

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

A história de UML e seus diagramas

A história de UML e seus diagramas A história de UML e seus diagramas Thânia Clair de Souza Vargas Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Florianópolis, SC Brazil thania@inf.ufsc.br Abstract.

Leia mais

2 Diagrama de Caso de Uso

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

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

Banco de Dados. Profª. Ana Leda

Banco de Dados. Profª. Ana Leda Banco de Dados Profª. Ana Leda Introdução 1 DADO PROCESSAMENTO INFORMAÇÃO 2 Dados x Informação DADO = REPRESENTAÇÃO DE UM FATO, OBJETO, EVENTO, PESSOA, ETC. ENTIDADE = FATO, OBJETO, EVENTO, PESSOA, ETC,

Leia mais

Introdução à Engenharia da Computação. Banco de Dados Professor Machado

Introdução à Engenharia da Computação. Banco de Dados Professor Machado Introdução à Engenharia da Computação Banco de Dados Professor Machado 1 Sistemas isolados Produção Vendas Compras Banco de Dados Produtos... Banco de Dados Produtos... Banco de Dados Produtos... Desvantagens:

Leia mais

e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos

e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos Luis Paulo da Silva Carvalho, Moara Sousa Brito, Pablo Freire Matos, Lucas Amparo Barbosa, Cremildo Lima Gomes, Ivick Roberta

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML UML (Unified Modeling Language Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de

Leia mais

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III FERRAMENTAS DE GERENCIAMENTO DE PROJETOS TRAC E DOTPROJECT ORIETADOS AO RUP ACADÊMICOS: GUSTAVO

Leia mais

SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO

SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO Marcelo Karpinski Brambila 1, Luiz Gustavo Galves Mahlmann 2 1 Acadêmico do Curso de Sistemas de Informação da ULBRA Guaíba < mkbrambila@terra.com.br

Leia mais

Documento de Projeto de Sistema

Documento de Projeto de Sistema Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda,

Leia mais

UNIVERSIDADE ESTADUAL DE PONTA GROSSA

UNIVERSIDADE ESTADUAL DE PONTA GROSSA UNIVERSIDADE ESTADUAL DE PONTA GROSSA SECRETARIA MUNICIPAL DE GESTÃO DE RECURSOS HUMANOS CONCURSO PÚBLICO PARA ANALISTA DE SUPORTE 08 DE NOVEMBRO DE 2009... (NOME COMPLETO EM LETRA DE FORMA) INSTRUÇÕES

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

Sistema de Aprendizado de Linguagem de Acesso à Dados em um Simulador Compacto de Banco de Dados (Ferramenta Tupan)

Sistema de Aprendizado de Linguagem de Acesso à Dados em um Simulador Compacto de Banco de Dados (Ferramenta Tupan) Sistema de Aprendizado de Linguagem de Acesso à Dados em um Simulador Compacto de Banco de Dados (Ferramenta Tupan) Daniel, H. S. Atilio 1, Gabriel, C. Arroyo 1, Luis, A. da Silva 1 1 Curso de Tecnologia

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java Leonardo Gresta Paulino Murta Gustavo Olanda Veronese Cláudia Maria Lima Werner {murta, veronese, werner}@cos.ufrj.br COPPE/UFRJ Programa

Leia mais

O Processo Unificado: Captura de requisitos

O Processo Unificado: Captura de requisitos O Processo Unificado: Captura de requisitos Itana Gimenes Graduação em Informática 2008 Captura de Requisitos Modelagem do negócio: Visão de negócios Modelo de objetos de negócio de negócio Especificação

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br BANCO DE DADOS info 3º ano Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br BANCO DE DADOS Unidade 1 - Introdução Dados; Banco de Dados; Base de Dados; Projeto de Banco de Dados.

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

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

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan 1 Unidade 2 Introdução a SQL 2 Leitura Obrigatória ELMASRI,

Leia mais

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II UNIOESTE - Universidade Estadual do Oeste do Paraná CCET - Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Curso de Bacharelado em Informática PROJETO DA DISCIPLINA PES II Processo de

Leia mais

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Modelagem de Negócios e de Sistemas com Casos de Uso Denize Terra Pimenta dpimenta@gmail.com www.analisetotal.com.br Índice 2 1 Objetivos Esta palestra é uma introdução à modelagem

Leia mais