sistema de egressos
Propaganda
CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO BRUNO MARTINS DA COSTA CAYO M. DA CRUZ FONTANA SISTEMA DE EGRESSOS VILA VELHA 2008 BRUNO MARTINS DA COSTA CAYO M. DA CRUZ FONTANA SISTEMA DE EGRESSOS Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso apresentada ao Curso de Ciência da Computação do Centro Universitário de Vila Velha, como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, sob orientação do prof. Cristiano Biancardi. Orientador: Cristiano Biancardi VILA VELHA 2008 BRUNO MARTINS DA COSTA CAYO M. DA CRUZ FONTANA SISTEMA DE EGRESSOS BANCA EXAMINADORA Prof. Msc. Cristiano Biancardi Centro Universitário Vila Velha Orientador Prof. Msc. Otacílio José Pereira Centro Universitário Vila Velha Prof. Msc. Susiléa Abreu dos Santos Lima Centro Universitário Vila Velha Trabalho de Conclusão de Curso aprovado em 21/10/2008. Aos meus pais ... AGRADECIMENTOS Agradecemos primeiramente a Deus, por estar sempre presente em nossas vidas, assim como neste trabalho nos dando força, coragem, concentração e crença pelo projeto, onde nos superamos a todo o momento. Aos nossos Pais, pelo apoio e credibilidade depositada em nós e em nosso trabalho. Ao apoio dos nossos colegas de sala, que sempre nos ajudaram, seja pela troca de conhecimentos ou pela imensa ajuda na hora das maiores dificuldades. Ao orientador do trabalho, pela oportunidade concedida, pelo apoio, contribuição e disponibilização que foram essenciais para a conclusão deste trabalho. Aos professores do curso de Ciência da Computação da instituição, pela contribuição em nosso conhecimento acadêmico, imprescindível para o desenvolvimento deste trabalho. Às nossas companheiras Brunella e Pollyanna, pela compreensão e companheirismo desde o início do trabalho, pois estivemos ausentes em inúmeros momentos durante o desenvolvimento deste. E finalmente, agradecemos a todos de uma forma geral que, diretamente ou indiretamente, contribuíram para completar nosso objetivo. Muito obrigado à todos vocês! ""A estratégia é a ciência do emprego do espaço e do tempo. O espaço, podemos reganhá-lo. O tempo não!" autor desconhecido. LISTA DE FIGURAS 1 Fonte X Técnica de Levantamento . . . . . . . . . . . . . . . . . . . . . 24 2 Problemas levantados X Causas . . . . . . . . . . . . . . . . . . . . . . 25 3 Enterprise Architect 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4 Visual Studio 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 MySQL Server 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6 Fireworks 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7 DB-Designer 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8 Diagrama de Caso de Uso Principal . . . . . . . . . . . . . . . . . . . . 29 9 Diagrama de Caso de Uso, Administrador . . . . . . . . . . . . . . . . . 31 10 Descrição do Caso de uso: Manter Curso . . . . . . . . . . . . . . . . . 32 11 Descrição do Caso de uso: Manter Coordenador . . . . . . . . . . . . . 32 12 Descrição do Caso de uso: Manter Fórum . . . . . . . . . . . . . . . . . 33 13 Diagrama de Casos de Uso, Coordenador . . . . . . . . . . . . . . . . . 34 14 Descrição do Caso de uso: Avaliar Empresa . . . . . . . . . . . . . . . 35 15 Descrição do Caso de uso: Validar Oportunidade . . . . . . . . . . . . . 35 16 Descrição do Caso de uso: Gerenciar Fórum . . . . . . . . . . . . . . . 36 17 Descrição do Caso de uso: Gerar Relatório . . . . . . . . . . . . . . . . 36 18 Diagrama de Casos de Uso, Empresa . . . . . . . . . . . . . . . . . . . 37 19 Descrição do Caso de uso: Manter Dados Empresa . . . . . . . . . . . 38 20 Descrição do Caso de uso: Manter Oportunidade . . . . . . . . . . . . . 38 21 Descrição do Caso de uso: Gerar Feedback . . . . . . . . . . . . . . . . 39 22 Diagrama de Casos de Uso, Egresso 40 . . . . . . . . . . . . . . . . . . . 23 Descrição do Caso de uso: Manter Dados Egresso . . . . . . . . . . . . 41 24 Descrição do Caso de uso: Visualizar Oportunidade . . . . . . . . . . . 41 25 Descrição do Caso de uso: Interagir Fórum . . . . . . . . . . . . . . . . 42 26 Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 27 Diagrama de Pacotes do subsistema Administrador . . . . . . . . . . . 45 28 Diagrama de Pacotes do subsistema Cliente . . . . . . . . . . . . . . . 45 29 Diagrama de Classes da camada Entity, pacote Administrador . . . . . 46 30 Diagrama de Classes da camada Business, pacote Administrador . . . 47 31 Classe Genérica que efetua a conexão com o banco de dados . . . . . 48 32 Diagrama de Classes, camada Data Access, pacote Administrador . . . 49 33 Diagrama de Classes da camada Facade, pacote Administrador . . . . 50 34 Diagrama de Classes da camada UI, pacote Administrador . . . . . . . 51 35 Diagrama de Classes da camada Entity, pacote Cliente . . . . . . . . . 52 36 Diagrama de Classes da camada Business, pacote Cliente . . . . . . . 53 37 Diagrama de Classes da camada Data Access, pacote Cliente . . . . . 54 38 Diagrama de Classes da camada Facade, pacote Cliente . . . . . . . . 55 39 Diagrama de Classes da camada UI, pacote Cliente . . . . . . . . . . . 56 40 Diagrama de Estados do Objeto Oportunidade . . . . . . . . . . . . . . 57 41 Diagrama de Navegação . . . . . . . . . . . . . . . . . . . . . . . . . . 58 42 Diagrama Relacional do Banco de Dados . . . . . . . . . . . . . . . . . 59 43 Diagrama de Sequência - Manter Curso . . . . . . . . . . . . . . . . . . 61 44 Diagrama de Sequência - Manter Coordenador . . . . . . . . . . . . . . 62 45 Diagrama de Sequência - Inserir Tópico, Fórum, Mensagem . . . . . . 63 46 Diagrama de Sequência - Avaliar Empresa . . . . . . . . . . . . . . . . 64 47 Diagrama de Sequência - Validar Oportunidade . . . . . . . . . . . . . . 65 48 Diagrama de Sequência - Gerar Relatório . . . . . . . . . . . . . . . . . 66 49 Diagrama de Sequência - Manter Dados Empresa . . . . . . . . . . . . 67 50 Diagrama de Sequência - Manter Oportunidade . . . . . . . . . . . . . . 68 51 Diagrama de Sequência - Manter Dados Egresso . . . . . . . . . . . . . 69 52 Diagrama de Sequência - Visualizar Oportunidades . . . . . . . . . . . 70 53 Botões e Imagens do Sistema . . . . . . . . . . . . . . . . . . . . . . . 72 54 Prototipagem - Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 55 Prototipagem - Cadastro de Egressos . . . . . . . . . . . . . . . . . . . 75 56 Prototipagem - Cadastro de Empresa . . . . . . . . . . . . . . . . . . . 75 57 Prototipagem - Cadastro de coordenador . . . . . . . . . . . . . . . . . 76 58 Prototipagem - Cadastro de curso . . . . . . . . . . . . . . . . . . . . . 76 59 Prototipagem - Exibição, Alteração e Desativação de Curso . . . . . . . 77 60 Prototipagem - Exibição do menu do Coordenador . . . . . . . . . . . . 77 61 Prototipagem - Exibição de Oportunidades para Coordenador . . . . . . 78 62 Prototipagem - Exibição de Oportunidade detalhada . . . . . . . . . . . 78 63 Prototipagem - Validação de Oportunidades . . . . . . . . . . . . . . . . 79 64 Prototipagem - Exibição de Oportunidade para Empresa . . . . . . . . . 80 65 Prototipagem - Cadastro de Oportunidades . . . . . . . . . . . . . . . . 81 66 Prototipagem - Exibição de Oportunidades para Egresso . . . . . . . . 81 67 Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 68 Pacotes Lógicos do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 84 69 Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 LISTA DE SIGLAS E ABREVIATURAS IES: Instituição de Nível Superior. UML: Unified Modeling Language. OMG: Object Management Group. CSS: Cascading Style Sheets. HTML: Hyper Text Markup Language. XML: EXtensible Markup Language. DLL: Dynamic-link library. WEB: World Network POP: Post Office Protocol SMTP: Simple Mail Transfer Protocol IIS: Internet Information Service SUMÁRIO RESUMO ABSTRACT 1 INTRODUÇÃO 16 1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 CONCEITOS 18 2.1 ANÁLISE DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 LEVANTAMENTO DE REQUISITOS . . . . . . . . . . . . . . . . . . . . 18 2.3 LINGUAGEM DE MODELAGEM UNIFICADA . . . . . . . . . . . . . . . 19 2.4 CONCEITOS DE ORIENTAÇÃO A OBJETOS . . . . . . . . . . . . . . . 19 2.5 ANÁLISE ORIENTADA A OBJETOS . . . . . . . . . . . . . . . . . . . . 20 2.6 ATORES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7 MODELO DE CASO DE USO . . . . . . . . . . . . . . . . . . . . . . . . 20 2.8 DIAGRAMA DE CLASSE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.9 DIAGRAMA DE SEQUÊNCIA . . . . . . . . . . . . . . . . . . . . . . . . 22 2.10 DIAGRAMA DE ESTADOS DE NAVEGAÇÃO . . . . . . . . . . . . . . . 22 2.11 DIAGRAMA DE PACOTES . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.12 MODELO RELACIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 LEVANTAMENTO DE REQUISITOS 24 3.1 ENTREVISTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 MODELAGEM DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 TECNOLOGIAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 DIAGRAMAS DE CASO DE USO . . . . . . . . . . . . . . . . . . . . . . 28 3.4.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.2 LISTA DOS CASOS DE USO . . . . . . . . . . . . . . . . . . . . 30 3.5 DESCRIÇÃO DOS CASOS DE USO . . . . . . . . . . . . . . . . . . . . 31 3.5.1 CASOS DE USO DO ATOR ADMINISTRADOR . . . . . . . . . . 31 3.5.2 CASOS DE USO DO ATOR COORDENADOR . . . . . . . . . . 34 3.5.3 CASOS DE USO DO ATOR EMPRESA . . . . . . . . . . . . . . 37 3.5.4 CASOS DE USO DO ATOR EGRESSO . . . . . . . . . . . . . . 40 4 ESPECIFICAÇÃO DE PROJETO 43 4.1 DIAGRAMA DE PACOTES . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 DIVISÃO EM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3 DIAGRAMAS DE CLASSES . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.1 CAMADA DE ENTIDADES (ENTITY), ADMINISTRADOR . . . . 46 4.3.2 CAMADA DE NEGÓCIOS (BUSINESS), ADMINISTRADOR . . 47 4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3.4 CAMADA DE FACHADA (FACADE), ADMINISTRADOR . . . . . 49 4.3.5 CAMADA DE INTERFACE COM O USUÁRIO (UI), ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.6 CAMADA DE ENTIDADES (ENTITY), CLIENTE . . . . . . . . . 52 4.3.7 CAMADA DE NEGÓCIOS (BUSINESS), CLIENTE . . . . . . . . 53 4.3.8 CAMADA DE ACESSO AOS DADOS (DATA ACCESS), CLIENTE 53 4.3.9 CAMADA DE FACHADA (FACADE), CLIENTE . . . . . . . . . . 54 4.3.10 CAMADA DE INTERFACE COM O USUÁRIO (UI) , CLIENTE . . 55 4.4 DIAGRAMA ESTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.4.1 OPORTUNIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5 DIAGRAMA DE NAVEGAÇÃO . . . . . . . . . . . . . . . . . . . . . . . 58 4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS . . . . . . . . . . . 58 5 DIAGRAMAS DE SEQUÊNCIA 60 5.1 ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.1 MANTER CURSO . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.2 MANTER COORDENADOR . . . . . . . . . . . . . . . . . . . . 62 5.1.3 MANTER FÓRUM (INCLUI GERENCIAR FÓRUM) . . . . . . . 62 5.2 COORDENADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.1 AVALIAR EMPRESA . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO) . 64 5.2.3 GERENCIAR FÓRUM . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.4 GERAR RELATÓRIO . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3 EMPRESA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3.1 MANTER DADOS EMPRESA . . . . . . . . . . . . . . . . . . . . 67 5.3.2 MANTER OPORTUNIDADE . . . . . . . . . . . . . . . . . . . . 67 5.4 EGRESSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.4.1 MANTER DADOS EGRESSO . . . . . . . . . . . . . . . . . . . 68 5.4.2 VISUALIZAR OPORTUNIDADE . . . . . . . . . . . . . . . . . . 68 5.4.3 INTERAGIR FÓRUM . . . . . . . . . . . . . . . . . . . . . . . . . 69 6 PADRONIZAÇÃO 71 7 PROTOTIPAGEM 73 8 DOCUMENTOS DE ARQUITETURA 82 8.1 VISÃO FÍSICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8.2 VISÃO LÓGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 9 ESTRUTURA TECNOLÓGICA 9.1 HOSPEDAGEM DO SITE (FATORES A CONSIDERAR) . . . . . . . . . 86 86 10 PROJETO DE SEGURANÇA 88 11 CONCLUSÃO 89 12 REFERÊNCIAS BIBLIOGRÁFICAS 90 ANEXO A 92 RESUMO RESUMO Necessitando a busca por profissionais qualificados e de conhecimentos tácitos, as empresas têm recorrido às instituições de ensino superior (IES) para contratação de pessoas. Os contratantes passaram a fazer contatos diretamente com as coordenações dos cursos com o intuito de encontrar os estudantes mais qualificados por meio de referências dos coordenadores. Entretanto, por conflitos de horários entre o trabalho e a faculdade, ou mesmo por falta de experiência profissional, os contratantes e os próprios coordenadores, têm preferência por alunos formados, ou seja, os alunos que egressaram da IES. Partindo deste conceito, este trabalho propõe projetar e implementar uma aplicação Web, com a finalidade de prover um novo conceito em egressos acadêmicos possibilitando a interação entre o mercado de trabalho, o recém formado e a intituição. Para isso, serão utilizadas as seguintes ferramentas: plataforma .NET, especificamente a linguagem C-Sharp por ser uma poderosa tecnologia de desenvolvimento de softwares tanto para a Web quanto para as demais aplicações, a ferramenta case Enterprise Architect 6.5 para análise e modelagem da UML (Unified Modeling Language), Macromedia FireWorks 8 para a edição de imagens e bitmaps na interface do projeto e o MySQL Server 5.0 para a persistência dos dados utilizados. Palavras-chave: IES, UML. ABSTRACT ABSTRACT: Need to search for qualified professionals and tacit knowledge, companies have resorted to higher education institutions (HEI) to employ people. Contractors started to make contact directly with the coordination of courses with the aim of finding the most qualified students by means of references coordinators. However, in times of conflict between work and college, or even a lack of professional experience, contractors and their coordinators, have formed a preference for students, ie students who graduate s(egress) from the ISS. Under this concept, this paper proposes designing and implementing a Web application, in order to provide a new concept in academic graduates allowing the interaction between the labor market, and the newly formed institution. This will use the following tools: platform. NET, specifically the C-Sharp language as a powerful technology for the development of software for both the Web and for the other applications, the tool case Enterprise Architect 6.5 for analysis and modeling of UML (Unified Modeling Language), Macromedia Fireworks 8 for the editing of images and bitmaps at the interface of the project and MySQL Server 5.0 for the persistence of the data used. Keywords: HEI, UML. 16 1 INTRODUÇÃO Atualmente o mercado de trabalho tem sido muito exigente na contratação de profissionais. Os contratantes passaram a fazer contatos diretamente com as coordenações das IES, buscando estudantes qualificados por meio de referências dos coordenadores. Após a conclusão da graduação, os vínculos do egresso com a IES podem ser comprometidos, inviabilizando o contato direto da coordenação com esse egresso. Desta forma, a instituição não consegue referenciar aos contratantes estes novos profissionais. Ao ingressar em uma instituição, o aluno passa a criar um forte vínculo com colegas de curso, professores, coordenadores e outros colaboradores da instituição. Entretanto este vínculo não é somente acadêmico, passa a ser também profissional. Com a conclusão do curso, caso o aluno não queira fazer uma especialização (pósgraduação, mestrado, etc.) na mesma IES, esses vínculos adquiridos ao longo do curso possivelmente enfraquecem. Diante dessa situação, este trabalho visa implementar um sistema que possibilitará as instituições manterem vínculos com os alunos formados através da atualização dos seus dados profissionais e pessoais, bem como dispor de anúncios de empregos, concursos, novos cursos, cursos de extensão, eventos profissionais, etc. Desta forma, as empresas, ao procurarem por profissionais nas IES, terão uma maior expectativa na contratação de profissionais qualificados. Da mesma maneira, os egressos terão um grande meio de comunicação com a instituição e empresas da sua área de atuação. 1.1 MOTIVAÇÃO Com base em pesquisas realizadas nas principais IES nacionais, não foram encontradas soluções que realizassem a interação entre o mercado de trabalho, os egressos e as instituições. 17 Ao concluir a graduação, há possibilidade do egresso sentir dificuldade em ingressar no mercado de trabalho. 1.2 JUSTIFICATIVA O Sistema de Egressos é uma solução que visa relacionar as principais exigências e necessidades do atual mercado de trabalho, desvendar quais as regras desta nova economia, quais as perspectivas do mercado de trabalho para os próximos anos e fornecer subsídios aos profissionais quanto às atitudes e habilidades a serem desenvolvidas para atender esta nova demanda profissional e, assim, estar em condições de conquistar uma posição na atual economia e manter sua empregabilidade no futuro. As empresas serão beneficiadas com uma nova ferramenta para encontrar profissionais qualificados. As IES que utilizarem a ferramenta terão um diferencial para oferecer aos seus egressos, bem como poderá utilizar os relatórios estatísticos para obter o perfil dos profissionais exigidos pelo mercado de trabalho atual. 1.3 OBJETIVO Desenvolver um sistema WEB que auxilie os egressos de uma IES a ingressarem no mercado de trabalho, mantendo seus dados atualizados, disponibilizando-os para a instituição poder acompanhar sua trajetória profissional e acadêmica, aproximando o mercado do egresso. 18 2 CONCEITOS Seguem os principais conceitos para a análise e desenvolvimento do projeto Sistema de Egressos. 2.1 ANÁLISE DE REQUISITOS A análise de requisitos, primeira fase do desenvolvimento de um software, é o momento em que o engenheiro de software estuda o problema e tenta entender o que precisa ser feito pelo sistema a ser desenvolvido. O estudo dos requisitos é muito importante, pois o mesmo exerce um forte impacto na qualidade do produto final. Sem o entendimento completo e correto dos requisitos não será possível desenvolver um sistema que atenda de forma satisfatória às necessidades do cliente. Os conceitos apresentados a seguir foram de suma importância para a organização, compreensão e desenvolvimento do Sistema de Egressos. 2.2 LEVANTAMENTO DE REQUISITOS Através do levantamento de requisitos são compreendidas e identificadas às principais funcionalidades (requisitos funcionais) e restrições (requisitos não-funcionais) que devem ser consideradas para atender às necessidades do cliente. O requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos, ou seja, é uma ação (requisitos funcionais) ou propriedade (requisitos não-funcionais) [BEZERRA - 2002]. 19 2.3 LINGUAGEM DE MODELAGEM UNIFICADA Na metade da década de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de métodos orientados a objetos, começaram a utilizar as melhores idéias e partiram para a criação de uma linguagem unificada de modelagem. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta mais utilizável [HTTP://WWW.LINHADECODIGO.COM.BR]. A UML é a linguagem padrão para especificar, visualizar, comunicar, documentar e construir artefatos de um sistema de software utilizando diversos diagramas [FALBO - 2002]. A mesma foi utilizada para modelar os requisitos levantados para o Sistema de Egressos traduzindo-os em forma de diagramas. 2.4 CONCEITOS DE ORIENTAÇÃO A OBJETOS A orientação a objetos gerencia a complexidade dos problemas do mundo real, abstraindo conhecimento relevante e encapsulando-o dentro de objetos. Do ponto de vista da modelagem de sistemas, um objeto é uma entidade que incorpora uma abstração relevante no contexto de uma aplicação. Um objeto possui um estado (informação), exibe um comportamento bem definido, expresso por um número de operações para examinar ou alterar seu estado, e tem identidade única [FALBO - 2002]. Para o desenvolvimento do projeto foi preciso: • Identificar as classes (classe: modelo que descreve a estrutura e o comportamento de um objeto [FALBO - 2002]); • Identificar Hierarquias de Generalização/Especialização (características comuns ou específicas - Herança [FALBO - 2002]); • Identificar Hierarquias de Generalização/Especialização (características comuns ou específicas - Herança [FALBO - 2002]); 20 • Identificar associações e atributos (relações e propriedades dos objetos e classes [FALBO - 2002]); • Definir as operações (interações das classes e objetos). 2.5 ANÁLISE ORIENTADA A OBJETOS Formalmente, o termo análise corresponde a "quebrar"um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. Em um processo de desenvolvimento orientado a objetos, o resultado da análise são modelos que representam as estruturas das classes de objetos componentes do sistema. Além disso, a análise também resulta em modelos que especificam as funcionalidades do sistema de software. [BEZERRA - 2002]. 2.6 ATORES Atores são usuários e/ou outros meios externos que desenvolvem algum papel na aplicação, gerando informações para o sistema ou necessidade de informações geradas a partir do mesmo. Existem atores que podem desempenhar mais de um papel no sistema, No Sistema de Egressos existem usuários com diferentes permissões, com isso foi necessário criar um ator para cada diferente tipo de situação possível no ambiente. Os atores são quem desempenham os casos de uso, um mesmo ator pode estar em um ou mais casos de uso. Cada ator possui um nome que terá relação direta com a sua função, possuirá uma descrição que definirá o que ele faz e com quem ele interage [HTTP://IMASTERS.UOL.COM.BR]. Na terminologia da UML, qualquer elemento externo que interage com o sistema é denominado ator. 2.7 MODELO DE CASO DE USO Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e é uma descrição de um conjunto de seqüências de ações realizadas 21 pelo sistema para produzir um resultado de valor observável por um ator [BOOCH 2000]. Um modelo de caso de uso descreve como diferentes tipos de usuários interagem com o sistema para resolver um problema. Como tal, ele descreve as metas dos usuários, as interações entre os usuários e o sistema, bem como o comportamento necessário do sistema para satisfazer estas metas. O mesmo consiste em um conjunto de elementos de modelo. Os elementos de modelo mais importantes são: casos de uso, atores e as relações entre eles. O diagrama de caso de uso é usado para descrever graficamente um subconjunto do modelo para simplificar a comunicação. Normalmente existirão vários diagramas de caso de uso associados a um determinado modelo, cada um mostrando um subconjunto de elementos relevantes para um determinado fim. O mesmo elemento de modelo pode ser exibido em vários diagramas de caso de uso, mas cada instância tem que ser consistente. Se alguma ferramenta for usada para manter o modelo de caso de uso, esta restrição de consistência deve ser automatizada, de forma que quaisquer alterações em um elemento de modelo (alteração do nome, por exemplo) serão automaticamente refletidas em todos os diagramas que mostram o elemento. O modelo de caso de uso pode conter pacotes que são usados para estruturar o modelo e simplificar a análise, a comunicação, a navegação, o desenvolvimento, a manutenção e o planejamento do projeto. 2.8 DIAGRAMA DE CLASSE Classe é a representação de um conjunto de coisas reais ou abstratas que são reconhecidos como sendo do mesmo tipo por compartilhar as mesmas características de atributos, operações, relações e semântica [FURLAN, 1998]. O diagrama denota a estrutura estática de um sistema, isto é, as classes, os relacionamentos entre suas instâncias (objetos), restrições e hierarquias. O diagrama é considerado estático, pois a estrutura descrita é sempre válida em qualquer ponto no ciclo de vida do sistema. 22 2.9 DIAGRAMA DE SEQUÊNCIA O diagrama de Sequência é utilizado para representar as características da iteração dos casos de uso, representa a colaboração dinâmica entre um número de objetos, sendo seu objetivo principal mostrar a seqüência de mensagens enviadas entre objetos. É um gráfico bidimensional, onde a dimensão vertical representa o tempo e a dimensão horizontal os diferentes objetos [BOOCH - 1998]. O comportamento do sistema é uma descrição do que um sistema faz, sem explicar como ele o faz. Uma parte desta descrição é um diagrama de seqüência do sistema, ilustrando as interações de atores e as operações iniciadas por eles [LARMAN - 2000]. 2.10 DIAGRAMA DE ESTADOS DE NAVEGAÇÃO Trata-se de representação gráfica especializada, que contém os diversos elementos que compõem a arquitetura do software, tais como: as páginas e links, os componentes, módulos e elementos de base de dados, as interfaces com sistemas externos (protocolos de comunicação), entre outros, bem como a interligação desses elementos através do fluxo de navegação da interface. Esse tipo de representação é uma importante ferramenta no processo de manutenção de sistemas de softwares, a primeira atividade nesse tipo de projeto é identificar os itens que compõem a arquitetura do sistema bem como os seus relacionamentos (definição do escopo do projeto de manutenção) [HTTP://WWW.DGZ.ORG.BR]. 2.11 DIAGRAMA DE PACOTES Em muitos casos um único diagrama de classes pode ser exageradamente grande para representar todo o sistema. Assim é conveniente utilizar-se de um elemento para organizar os subsistemas do modelo. Para isto utilizam-se os diagramas de pacote. Um pacote representa um grupo de classes (ou outros elementos) que se relaciona com outros pacotes através de uma relação de dependência. Um diagrama de pacotes pode ser utilizado em qualquer fase do processo de modelagem e visa organizar os modelos. 23 A utilização do diagrama de pacotes se faz necessário para que se possa obter uma visão de nível mais ampla do sistema, mostrando sua decomposição em subsistemas [FURLAN, 1998]. A UML define um diagrama de pacotes como um modelo que descreve como os elementos são organizados dentro de pacotes e suas dependências. Esse diagrama mostra pacotes importados e extensões de pacotes [MEDEIROS - 2004]. 2.12 MODELO RELACIONAL O modelo relacional é um modelo de dados, adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princípio em que todos os dados estão guardados em tabelas (ou, matematicamente falando, relações). Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos. O modelo relacional foi o primeiro modelo de banco de dados formal. Somente depois seus antecessores (bancos de dados hierárquicos e em rede) passaram a ser também descritos em linguagem formal. 24 3 LEVANTAMENTO DE REQUISITOS Para levantar os requisitos deste projeto utilizamos a técnica da Entrevista, que consiste especificamente de uma conversa formal com o entrevistado no formato pergunta-resposta, por se tratar de uma forma eficiente de se obter informações pertinentes ao desenvolvimento do sistema. 3.1 ENTREVISTA Seguem as figuras 1 e 2 com as informações obtidas durante a fase de levantamento de requisitos. Fonte Professores: Cristiano Biancardi e Otacílio Pereira. Técnica de Levantamento Entrevista. Figura 1: Fonte X Técnica de Levantamento 3.2 MODELAGEM DO SISTEMA Durante a fase de modelagem foram definidas as ferramentas para o desenvolvimento do projeto, os atores e suas funcionalidades, os casos de uso e suas descrições. A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo [WWW.WIKIPEDIA.ORG]. 25 Problemas levantados Pouca interação do ex-aluno(egresso)com a instituição após a conclusão da graduação. Não há a utilização, por parte da instituição, de uma ferramenta específica com fins de informações aos egressos, como opertuniidades, seminários, cursos, entre outros. Pouca interação do mercado de trabalho (empresas),IES e egressos. A instituição não possui um acompanhamento dos dados profissionais e pessoais dos seus ex-alunos. Falta de um meio informatizado das empresas atuantes no mercado, divulgarem oportunidades especificamente aos egressos de uma instituição. Causas Atualmente são uitilizadas outras ferramentas (e-mail, etc.) que não tem sido eficazes para a interação com os alunos formados, e que na maioria dos casos, tal interação fica muito enfraquecida. A instituiçãofaz uso de uma ferramenta semelhante, blog acadêmico, para os alunos matriculados, mas para os egressos não. Solução ainda não proposta anteriormente. A instituição não utiliza uma ferramenta que a mantenha atualizada quanto a trajetória profissional dos seus ex-alunos. Não há um controle de vínculos com empresas, tampouco, gerenciamento de oportunidades. Figura 2: Problemas levantados X Causas 26 3.3 TECNOLOGIAS UTILIZADAS Segue abaixo as tecnologias utilizadas para a engenharia do projeto: A figura 3 refere-se a uma tela de demonstração da ferramenta Enterprise Architect 6.5, uma ferramenta bastante completa e poderosa para a modelagem da UML, além de possuir uma boa integração com o Visual Studio, outra ferramenta que também será utilizada. Figura 3: Enterprise Architect 6.5 A figura 4 refere-se a uma tela de demonstração da ferramenta Visual Studio 2008, que permite aos desenvolvedores criarem aplicações de pequena à grande porte, com um alto nível de abstração e orientação a objetos. Esta ferramenta, além de ser robusta na construção de seus projetos, possibilita criar aplicativos mais seguros, gerenciáveis e confiáveis. Figura 4: Visual Studio 2008 A figura 5 refere-se a uma tela de demonstração da ferramenta de banco de dados 27 MySQL Server 5.0, uma poderosa ferramenta de gerenciamento de dados bastante confiável que fornece recursos de proteção e desempenho para clientes de aplicativos incorporados, utilizando simples armazenamento de dados locais. Esta ferramenta também possui uma integração profunda com o Visual Studio, no qual utilizaremos no desenvolvimento deste projeto. Figura 5: MySQL Server 5.0 A figura 6 refere-se a uma tela de demonstração da ferramenta Fireworks 8, uma Excelente ferramenta para se trabalhar com imagens, oferecendo integração com Java script’s pré-prontos. Muito útil na criação de layouts na web e com muita rapidez, oferecendo uma interface direta com recursos indispensáveis para trabalhar com a camada de apresentação. Figura 6: Fireworks 8 A figura 7 refere-se à logomarca do software DB-Designer 4, uma ferramenta gratuita de designer visual para modelagem relacional de dados, oferecendo uma maneira eficiente para os projetos. Proporciona uma visão ampla da estrutura completa, 28 além dos relacionamentos das tabelas, evitando erros comuns nas relações das mesmas. Figura 7: DB-Designer 4 3.4 DIAGRAMAS DE CASO DE USO O modelo de caso de uso molda os requisitos funcionais do sistema, facilitando o entendimento do negócio por parte do analista e permite que clientes, sem conhecimento de análise, consigam perceber quais os requisitos estarão sendo desenvolvidos no processo de desenvolvimento do sistema [BEZERRA - 2002]. 3.4.1 OBJETIVO O objetivo desse documento é compilar os artefatos gerados durante a fase de análise e detalhamento de requisitos do projeto. A figura 8 descreve o cenário retratando as interações de todos os atores do sistema e seus respectivos casos de uso. Segue abaixo descrição dos atores do sistema proposto: Administrador: esse ator tem privilégios irrestritos no sistema, ele é o principal gestor da aplicação. Dentre as ações possíveis que o administrador pode executar, destacam-se o gerenciamento dos dados pertinentes aos cursos da instituição, coordenadores dos cursos, egressos e empresas. Tornando-o assim peça chave na utilização da solução. Coordenador: uma vez inserido um coordenador de um curso, ele terá as funções 29 de validar ou não as vagas disponibilizadas pelas empresas devidamente cadastradas, gerenciar fóruns, dentre outras. Empresa: o ator empresa tem a função de criar, atualizar ou excluir seu cadastro no sistema, enviar oportunidades disponíveis para o coordenador avaliá-las, enviar feedbacks para a instituição em relação aos resultados de seus processos seletivos, ou seja, se houve ou não a contração do egresso, com o objetivo de gerar uma base estatística com fins de gerar relatórios para tomadas de decisões da instituição de ensino, entre outras. Egresso: o egresso tem função de criar, atualizar ou excluir seu cadastro, uma vez que ele tem total responsabilidade sobre a veracidade dos dados inseridos. Como também, analisar as vagas existentes e candidatar-se, participar de fóruns criando enquetes e postando mensagens. Figura 8: Diagrama de Caso de Uso Principal 30 3.4.2 LISTA DOS CASOS DE USO Segue a lista dos principais casos de uso. CASOS DE USO DO ATOR ADMINISTRADOR • Manter Curso; • Manter Coordenador; • Manter Fórum (Inclui Gerenciar Fórum). CASOS DE USO DO ATOR COORDENADOR • Avaliar Empresa; • Validar Oportunidade; • Gerenciar Fórum. • Gerar Relatório. CASOS DE USO DO ATOR EMPRESA • Manter Dados Empresa; • Manter Oportunidades (Inclui Gerar Feedback). CASOS DE USO DO ATOR EGRESSO • Manter Dados Egresso; • Interagir Fórum; • Visualizar Oportunidade. 31 3.5 DESCRIÇÃO DOS CASOS DE USO Seguem as descrições de seqüências de eventos que cada ator pode desempenhar no sistema para completar um processo. 3.5.1 CASOS DE USO DO ATOR ADMINISTRADOR A figura 9 representa os casos de uso do ator administrador, que é destinado ao usuário de autoridade máxima do sistema. Hierarquicamente seu perfil espelharia o de um diretor de graduação de uma IES. Figura 9: Diagrama de Caso de Uso, Administrador As figuras 10, 11 e 12 descrevem os casos de uso de ator Administrador. 32 Figura 10: Descrição do Caso de uso: Manter Curso Figura 11: Descrição do Caso de uso: Manter Coordenador 33 Figura 12: Descrição do Caso de uso: Manter Fórum 34 3.5.2 CASOS DE USO DO ATOR COORDENADOR A figura 13 representa os casos de uso do ator coordenador, que é destinado a um professor de determinado curso. Geralmente, este usuário é o real coordenador do curso na Instituição, mas isso pode variar conforme escolha do Administrador, descrito anteriormente. Figura 13: Diagrama de Casos de Uso, Coordenador As figuras 14, 15, 16 e 17 descrevem os casos de uso de ator Coordenador. 35 Figura 14: Descrição do Caso de uso: Avaliar Empresa Figura 15: Descrição do Caso de uso: Validar Oportunidade 36 Figura 16: Descrição do Caso de uso: Gerenciar Fórum Figura 17: Descrição do Caso de uso: Gerar Relatório 37 3.5.3 CASOS DE USO DO ATOR EMPRESA A figura 18 representa os casos de uso do ator empresa, que é destinado às empresas, principalmente aquelas atuantes no mercado local. Figura 18: Diagrama de Casos de Uso, Empresa As figuras 19, 20 e 21 descrevem os casos de uso de ator Empresa. 38 Figura 19: Descrição do Caso de uso: Manter Dados Empresa Figura 20: Descrição do Caso de uso: Manter Oportunidade 39 Figura 21: Descrição do Caso de uso: Gerar Feedback 40 3.5.4 CASOS DE USO DO ATOR EGRESSO A figura 22 representa os casos de uso do ator egresso, que é destinado aos alunos que concluíram a graduação. Figura 22: Diagrama de Casos de Uso, Egresso As figuras 23, 24 e 25 descrevem os casos de uso de ator Egresso. 41 Figura 23: Descrição do Caso de uso: Manter Dados Egresso Figura 24: Descrição do Caso de uso: Visualizar Oportunidade 42 Figura 25: Descrição do Caso de uso: Interagir Fórum 43 4 ESPECIFICAÇÃO DE PROJETO Durante a fase de projeto, ficaram definidos os subsistemas (pacotes), a quantidade de camadas que a aplicação irá trabalhar as relações das entidades de cada pacote em cada camada, o dicionário de dados dos diagramas classes, o diagrama de estados da entidade oportunidade, diagrama de navegação, o diagrama relacional do banco de dados e dicionário de dados, os diagramas de sequências e a padronização do sistema. 4.1 DIAGRAMA DE PACOTES O projeto foi subdividido em três subsistemas, contendo um pacote administrativo, pertinentes ao Administrador e ao Coordenador (gestores da aplicação), o pacote Cliente referente ao Egresso e Empresa, e o pacote Utilitário. Cada pacote representa um subsistema do projeto. A figura 26 mostra a divisão em pacotes do Sistema de Egressos Figura 26: Diagrama de Pacotes As funcionalidades comuns aos subsistemas Administrador e Cliente estão contidas 44 no pacote Utilitário, com o intuito de prover a reusabilidade, ou seja, a utilização dessas funcionalidades em outros projetos. 4.2 DIVISÃO EM CAMADAS Utilizando o conceito de divisão em camadas, baseado na arquitetura .NET de padrões de projetos, os pacotes foram divididos nas camadas: User Interface (UI), Services Interfaces (Facade), Business Component, Entity e Data Access. User Interface (UI): camada de apresentação onde o usuário terá a interface de interação com o sistema, podendo, a todo o momento, trocar informações com o mesmo. Services Interface (Facade): conhecida como Fachada, esta camada faz a interface entre a camada de apresentação (UI) e a camada de Negócios (Business Layer) onde é utilizada uma forma simples para acessar vários objetos do negócio. Business Component: onde são realizadas as regras de negócios do sistema. Também conhecida como Business Layer, esta camada trata as principais funcionalidades e complexidades do sistema. Entity : esta camada representa todas as classes ou estruturas do sistema. Aqui os objetos são estruturados para poderem ser criados em outras camadas da aplicação. Data Access: didaticamente conhecida como Gerência de Dados, esta camada possui todas as operações que o sistema necessitará para trocar mensagens ou informações com o banco de dados físico [CUNNINGHAM, 2003]. A seguir, as figuras 27 e 28 mostram os pacotes divididos nas cinco camadas, em cada pacote: 45 Figura 27: Diagrama de Pacotes do subsistema Administrador Figura 28: Diagrama de Pacotes do subsistema Cliente 46 4.3 DIAGRAMAS DE CLASSES A seguir estão representados os diagramas de classe dos pacotes Administrador e Cliente. 4.3.1 CAMADA DE ENTIDADES (ENTITY), ADMINISTRADOR O diagrama de classes da camada Entity (Entidades) representa todos os objetos e suas características. A figura 29 representa o diagrama de classes da camada de entidades do pacote Administrador. Figura 29: Diagrama de Classes da camada Entity, pacote Administrador 47 O dicionário de dados do diagrama de classes da camada Entity do pacote administrador encontra-se no Anexo A. 4.3.2 CAMADA DE NEGÓCIOS (BUSINESS), ADMINISTRADOR O diagrama de classes da camada Business (Negócios) representa todas as regras de negócios e operações dos objetos, mostrando suas relações, dependências, agregações e composições. A figura 30 representa o diagrama de classes da camada de negócios do pacote Administrador. Figura 30: Diagrama de Classes da camada Business, pacote Administrador O dicionário de dados do diagrama de classes da camada Business do pacote administrador encontra-se no Anexo A. 48 4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINISTRADOR O diagrama de classes da camada Data Access (Acesso a Dados) representa todos os objetos e suas características. A figura 31 representa a classe de acesso à dados do pacote Administrador. Note que todas as classes dependem da classe genérica, que é onde a aplicação acessa o banco de dados fisicamente, por através de um conjunto de classes (Dll’s) que foram abstraídas na implementação do projeto. Figura 31: Classe Genérica que efetua a conexão com o banco de dados A figura 32 representa o método SalvarDados, utilizado no exemplo, recebe os parâmetros vindos de outras classes da camada Data Access, retornando em uma estrutura de lista (vetor) os possíveis resultados da consulta física. 49 Figura 32: Diagrama de Classes, camada Data Access, pacote Administrador 4.3.4 CAMADA DE FACHADA (FACADE), ADMINISTRADOR A camada de fachada (facade) representa uma interface da camada de apresentação com a camada de negócios (Business) e entidades (Entity), contemplando todas as funcionalidades da camada de negócios. Apenas contêm as operações e o seu tipo de retorno, deixando toda a implementação lógica na camada de negócios. A figura 33 representa o diagrama de classes da camada de fachada do pacote administrador. 50 Figura 33: Diagrama de Classes da camada Facade, pacote Administrador 4.3.5 CAMADA DE INTERFACE COM O USUÁRIO (UI), ADMINISTRADOR O diagrama de classes da camada User Interface (Interface com o Usuário) representa todas as classes desta camada. A figura 34 representa o diagrama de classes da camada de entidades do pacote Administrador 34.. 51 Figura 34: Diagrama de Classes da camada UI, pacote Administrador 52 4.3.6 CAMADA DE ENTIDADES (ENTITY), CLIENTE O diagrama de classes da camada Entity (Entidade) representa todos os objetos e suas características. A figura 35 representa o diagrama de classes da camada de entidades do pacote Cliente 35.. Figura 35: Diagrama de Classes da camada Entity, pacote Cliente O dicionário de dados do diagrama de classes da camada Entity do pacote cliente encontra-se no Anexo A. 53 4.3.7 CAMADA DE NEGÓCIOS (BUSINESS), CLIENTE O diagrama de classes da camada Business (Negócios) representa todas as regras de negócios e operações dos objetos, mostrando suas relações, dependências, agregações e composições. A figura 36 representa o diagrama de classes da camada de negócios do pacote Cliente 36. Figura 36: Diagrama de Classes da camada Business, pacote Cliente O dicionário de dados do diagrama de classes da camada Business do pacote cliente encontra-se no Anexo A. 4.3.8 CAMADA DE ACESSO AOS DADOS (DATA ACCESS), CLIENTE O diagrama de classes da camada Data Access (Acesso a Dados) representa todos os objetos suas características. A figura 37 representa o diagrama de classes da camada de acesso aos dados do pacote Cliente. 54 Note que todas as classes dependem da camada de Data Access contida no pacote Administrador, onde estão implementadas as classes de acesso ao banco de dados físico 37. Figura 37: Diagrama de Classes da camada Data Access, pacote Cliente 4.3.9 CAMADA DE FACHADA (FACADE), CLIENTE A camada de fachada (facade) representa uma interface da camada de apresentação com a camada de negócios (Business) e entidades (Entity), contemplando todas as funcionalidades da camada de negócios. Apenas contêm as operações e o seu tipo de retorno, deixando toda a implementação lógica na camada de negócios. A figura 38 representa o diagrama de classes da camada de fachada do pacote cliente 38. 55 Figura 38: Diagrama de Classes da camada Facade, pacote Cliente 4.3.10 CAMADA DE INTERFACE COM O USUÁRIO (UI) , CLIENTE O diagrama de classes da camada User Interface (Interface com o Usuário) representa todas as classes desta camada. A figura 39 representa o diagrama de classes da camada de entidades do pacote Cliente 39. 56 Figura 39: Diagrama de Classes da camada UI, pacote Cliente 57 4.4 DIAGRAMA ESTADOS 4.4.1 OPORTUNIDADE A figura 40 mostra que ao ser inserida uma oportunidade no sistema, atinge o estado pendente. Após passar pelo processo de validação, onde ela poderá ou não ser visualizada pelos egressos, ele atingirá os estados: válido ou inválido exclusivamente 40. Figura 40: Diagrama de Estados do Objeto Oportunidade 58 4.5 DIAGRAMA DE NAVEGAÇÃO O diagrama de navegação permite a visualização do fluxo principal do sistema proposto. Muitas vezes não é possível, antes da implementação do projeto, traçar exatamente todas as possíveis telas e funcionalidades que a aplicação terá. A figura 41 representa o diagrama de navegação do Sistema 41. Figura 41: Diagrama de Navegação 4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS O diagrama relacional mostra as relações que ocorrem nas tabelas (chamadas de entidades na fase de modelagem). Através deste, é possível saber como será a persistência física de todas as informações que serão inseridas, atualizadas ou removidas do Sistema de Egressos. A figura 42 representa o diagrama relacional do banco de dados 42. 59 Figura 42: Diagrama Relacional do Banco de Dados O dicionário de dados do diagrama relacional do banco de dados encontra-se no Anexo A deste. 60 5 DIAGRAMAS DE SEQUÊNCIA Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Em síntese, ele representa as interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Uso e dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens, os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações [HTTP://PT.WIKIPEDIA.ORG]. O Sistema de Egressos apresentou os seguintes Diagramas de Sequência: 5.1 ADMINISTRADOR Seguem os diagramas de sequência referentes aos Casos de Uso do ator administrador. 5.1.1 MANTER CURSO O Caso de Uso Manter Curso engloba as operações de inserir, alterar e desativar um curso no portal de acordo com os mesmos oferecidos pela Instituição de ensino. Assim, a figura 43 visa manter um curso no Sistema de Egressos 43. 61 Figura 43: Diagrama de Sequência - Manter Curso 62 5.1.2 MANTER COORDENADOR O Diagrama de Sequência apresentado na figura 44 visa manter um coordenador no Sistema de Egressos 44. Figura 44: Diagrama de Sequência - Manter Coordenador 5.1.3 MANTER FÓRUM (INCLUI GERENCIAR FÓRUM) Incluir "Gerenciar Fórum"significa que o ator administrador tem as mesmas permissões e funcionalidades que o ator coordenador, porém, somente o coordenador poderá inserir um "Fórum". Os diagramas de sequência "EXCLUIR FÓRUM, TÓPICO, MENSAGEM"e "ALTERAR FÓRUM, TÓPICO, MENSAGEM"não foram apresentados pela semelhança ao diagrama "INSERIR FÓRUM, TÓPICO, MENSAGEM". O Diagrama de Sequência apresentado na figura 45 visa inserir um fórum, um tópico ou uma mensagem no Sistema de Egressos 45. 63 Figura 45: Diagrama de Sequência - Inserir Tópico, Fórum, Mensagem 5.2 COORDENADOR Seguem os diagramas de sequência referentes aos Casos de Uso do ator coordenador. 5.2.1 AVALIAR EMPRESA O Diagrama de Sequência apresentado na figura 46 visa avaliar uma empresa no Sistema de Egressos 46. 64 Figura 46: Diagrama de Sequência - Avaliar Empresa 5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO) O Diagrama de Sequência apresentado na figura 47 visa avaliar uma nova oportunidade lançada por uma empresa devidamente cadastrada Sistema de Egressos 47. 5.2.3 GERENCIAR FÓRUM O diagrama de sequência "GERENCIAR FÓRUM"não foi apresentado pela semelhança ao diagrama de sequência "MANTER FÓRUM"do Caso de Uso "Administrador". Diferem-se na ação de inserir um novo fórum, podendo somente o administrador executar tal sequência na aplicação. 65 Figura 47: Diagrama de Sequência - Validar Oportunidade 66 5.2.4 GERAR RELATÓRIO O Diagrama de Sequência apresentado na figura 48 visa gerar relatórios de diversos dados, como por exemplo, egressos contratados num determinado período, quantidade de vagas oferecidas num determinado período, quantitativos de vagas no momento, quantidade de empresas cadastradas, etc 48. Figura 48: Diagrama de Sequência - Gerar Relatório 5.3 EMPRESA Seguem os diagramas de sequência referentes aos Casos de Uso do ator empresa. 5.3.1 MANTER DADOS EMPRESA O Diagrama de Sequência apresentado na figura 49 visa manter os dados (inserir, alterar ou excluir) do perfil de uma empresa devidamente castrada no Sistema de Egressos 49. 67 Figura 49: Diagrama de Sequência - Manter Dados Empresa 5.3.2 MANTER OPORTUNIDADE O Diagrama de Sequência apresentado na figura 50 visa manter os dados (inserir, alterar ou excluir) do perfil de um egresso devidamente castrado no Sistema de Egressos50. 5.4 EGRESSO Seguem os diagramas de sequência referentes aos Casos de Uso do ator egresso. 5.4.1 MANTER DADOS EGRESSO O Diagrama de Sequência apresentado na figura 51 visa manter os dados (inserir, alterar ou excluir) do perfil de um egresso devidamente castrado no Sistema de Egressos51. 68 Figura 50: Diagrama de Sequência - Manter Oportunidade 5.4.2 VISUALIZAR OPORTUNIDADE O Diagrama de Sequência apresentado na figura 52 visa visualizar as oportunidades enviadas pelas empresas cadastradas no portal e validadas pelo coordenador 52. 5.4.3 INTERAGIR FÓRUM O diagrama de sequência "INTERAGIR FÓRUM"não foi apresentado pela semelhança ao diagrama de sequência "GERENCIAR-FÓRUM"do Caso de Uso "COORDENADOR". Nesse caso os dois atores poderão inserir, alterar e excluir tópicos e mensagens. 69 Figura 51: Diagrama de Sequência - Manter Dados Egresso Figura 52: Diagrama de Sequência - Visualizar Oportunidades 70 6 PADRONIZAÇÃO padronização da interface com o usuário, em sua maioria, é descrita em um arquivo CSS, linguagem de estilos para HTML e XML. Topo Superior (Master Page): Imagem azul com figuras dissolvidas de alunos à esquerda. Logo da instituição dissolvida à direita. Corpo das Telas (padrões WEB): Cor de fundo azul bem claro: #EDF7FC; Fonte: FONT-WEIGHT: normal; FONT-SIZE: 11px; COLOR: black; FONT-FAMILY: Tahoma, Verdana, Arial, Helvetica, sans-serif; BACKGROUND-COLOR: #f9f9f9; MS Sans Serif, normal, tamanho 10, cor preta; Telas centralizadas no centro da tela do usuário; Tabelas HTML: table.bordasimples border-collapse: collapse; table.bordasimples tr td border:0px solid white; table.bordasimples2 border-collapse: collapse; table.bordasimples2 tr td border:0px solid red; table.bordafrente border-collapse: collapse; table.bordafrente tr td border:0px solid #efefef; Classe de caixa de texto: FONT-WEIGHT: bold; 71 FONT-SIZE: 11px; COLOR: Black; FONT-FAMILY: Verdana; TEXT-DECORATION: none. Figura 53: Botões e Imagens do Sistema 72 7 PROTOTIPAGEM Um protótipo pode ser considerado uma implementação concreta, embora parcial, de um programa. Os protótipos podem ser criados para explorar múltiplas questões durante o desenvolvimento do software. Um protótipo de uma interface com o usuário tem como principal objetivo conseguir captar as necessidades efetivas e concretas do utilizado. Através da prototipagem foi possível obter as reais necessidades das principais vertentes da solução. A figura 54 representa a página inicial do Sistema (Home). Através do menu disponível na parte superior, o usuário poderá navegar pelo sistema. Observe que, inicialmente, não temos todas as funcionalidades disponíveis no sistema. Para tanto, o usuário necessitará autenticar-se na aplicação 54. A figura 55 representa o formulário de cadastro de egressos. Este formulário possui um web service onde o usuário entra com o CEP e o sistema retorna o endereço completo 55. A figura 56 representa o formulário de cadastro de empresas. Assim como o formulário anterior, este formulário possui um web service onde o usuário entra com o CEP e o sistema retorna o endereço completo 56. As figuras 57, 58 e 59 estão relacionadas ao usuário administrador. A figura 57 representa o formulário de cadastro de coordenador. Note o nome do usuário autenticado, na barra de menu da aplicação. Nesta ocasião, um administrador está autenticado 57. A figura 58 representa o formulário de cadastro de cursos 58. A figura 59 representa o formulário de consulta a cursos através de um componente web chamado GridView, onde podemos também alterar os dados do curso ou desativá-lo 59. 73 Figura 54: Prototipagem - Principal As figuras 60, 61, 62 e 63 estão relacionadas ao usuário coordenador. A figura 60 representa a página inicial do usuário coordenador sendo exibida a árvore do item consultas. Note o nome do usuário autenticado, na barra de menu da aplicação. Nesta ocasião, um coordenador está autenticado 60. A figura 61 representa o formulário de consulta às oportunidades lançadas, pelas empresas, direcionadas ao curso no qual é coordenado pelo usuário autenticado. No item Detalhes, o usuário poderá ver todos os detalhes da oportunidade 61. A figura 62 representa a visão da oportunidade detalhada 62. A figura 63 representa o formulário de consulta às oportunidades que estão em estado de espera. Esta situação ocorre quando a oportunidade, enviada pela empresa, aguarda a validação do coordenador. Caso seja válida, a oportunidade é exibida para todos os egressos do curso, caso contrário, a oportunidade é removida 63. As figuras 64 e 65 estão relacionadas ao usuário Empresa. A figura 64 representa o formulário onde são exibidas as oportunidades que já foram cadastradas pelo usuário. Além de poder visualizar as mesmas, o usuário ainda poderá excluir, caso seja necessário. Note o nome do usuário autenticado, na barra 74 Figura 55: Prototipagem - Cadastro de Egressos de menu da aplicação. Nesta ocasião, uma empresa está autenticada 64. A figura 65 representa o formulário de cadastro de oportunidades. Note que a empresa poderá associar qualquer curso, que esteja disponível, para determinada oportunidade 65. A figura 66 representa o formulário para o egresso, autenticado neste momento, onde são exibidas as oportunidades disponibilizadas pelo coordenador do seu curso. Note o nome do usuário autenticado na barra de menu da aplicação 66. 75 Figura 56: Prototipagem - Cadastro de Empresa Figura 57: Prototipagem - Cadastro de coordenador 76 Figura 58: Prototipagem - Cadastro de curso Figura 59: Prototipagem - Exibição, Alteração e Desativação de Curso 77 Figura 60: Prototipagem - Exibição do menu do Coordenador Figura 61: Prototipagem - Exibição de Oportunidades para Coordenador 78 Figura 62: Prototipagem - Exibição de Oportunidade detalhada Figura 63: Prototipagem - Validação de Oportunidades 79 Figura 64: Prototipagem - Exibição de Oportunidade para Empresa Figura 65: Prototipagem - Cadastro de Oportunidades 80 Figura 66: Prototipagem - Exibição de Oportunidades para Egresso 81 8 DOCUMENTOS DE ARQUITETURA 8.1 VISÃO FÍSICA A visão física (visão de contexto) mostra uma visão em alto nível do funcionamento do sistema e da seqüência geral dos processos e é contemplada na figura 67. A visão física do sistema mostra os nós (computadores clientes e servidores) e componentes físicos (executáveis, bibliotecas e aplicações de bancos de dados) da solução 67. Servidor WEB, onde a aplicação estará fisicamente disponível para os usuários, com a. NET Framework 3.5 instalado, rodando um Windows 2003 com IIS 7.0, garantindo o máximo de desempenho nesta plataforma. Conectado ao .NET WEB Server, terá o Servidor de Banco de Dados MySQL Server com a versão 5.0 (versão estável do banco) onde serão persistidas todas as informações do sistema. Também terá um servidor pop/smtp para envio/recebimento de emails, o Exchange Server atendendo principalmente a demanda de envio de emails automáticos pelas funcionalidades do sistema. Pela intranet ou pela internet, o sistema poderá ser acessado por qualquer categoria de usuário. 82 Figura 67: Visão Física 8.2 VISÃO LÓGICA A visão lógica descreve as mais importantes classes e a sua organização dentro de pacotes de serviços e subsistemas, além da organização desses subsistemas em camadas. Diagramas de pacotes podem ser incluídos para ilustrar o relacionamento entre camadas, pacotes, subsistemas e classes que são significantes arquiteturalmente. As figuras 68 e 69 exibem a visão lógica do sistema de forma explicativa e ilustrativa respectivamente, mostrando a sua organização em pacotes lógicos. Nesta tabela são descritos os principais pacotes lógicos do sistema: 83 Figura 68: Pacotes Lógicos do Sistema 84 Figura 69: Visão Lógica 85 9 ESTRUTURA TECNOLÓGICA A instalação física de um projeto de software necessita de uma infra-estrutura de hardware e rede para troca de dados, além dos custos gerados pela hospitalidade da solução. 9.1 HOSPEDAGEM DO SITE (FATORES A CONSIDERAR) Segue abaixo alguns aspectos a considerar na hospedagem de uma web site: Os custos fixos mensais, incluindo as taxas extras para instalação, gestão de domínios, mudança de provedor. Mensalidades que variem de acordo com o número de acessos e o volume de conteúdo publicado (se o site é muito acessado ou muito atualizado, tarifas extras podem pesar no orçamento). O preço do serviço nem sempre é o principal fator de avaliação, na medida em que outros requisitos podem ser mais críticos para a hospedagem do site, de acordo com os seus objetivos de negócio e a natureza do conteúdo. A compatibilidade do servidor com diferentes tecnologias, seja Linux, ASP.NET, Java, PHP, Perl, Ajax, scripts CGI e outras. O Suporte a conexões com bancos de dados (MySQL, SQL Server). O desempenho do sistema, a resposta dos programas e das páginas, a base de equipamentos atualizada, o espaço em disco disponível, com discos redundantes. Número de conexões de alta velocidade disponíveis, de forma que haja garantia de que, ao cair uma delas, as outras manterão o(s) site(s) no ar. É importante também que a taxa de utilização destas conexões não esteja próxima do seu limite de demanda. 86 Contabilização e análise, em tempo real, dos acessos dos usuários, com informações sobre número de visitas únicas, de páginas visitadas, sites de origem, palavraschave utilizadas em ferramentas de busca, tempo médio da visita, percursos mais visitados. Essas questões são de grande importância quando é feito um estudo de custos e benefícios com a hospedagem de uma aplicação na WEB. 87 10 PROJETO DE SEGURANÇA • Manutenção do sistema: realização de backups diários, manutenção de servidores web redundantes (para o caso de emergências), firewalls e medidas de segurança (incluindo a segurança das instalações). • Acesso ao sistema: A segurança do sistema será feita através do controle da entrada de dados no sistema, ou seja, pela utilização do código de acesso e senha. Todos os usuários serão cadastrados no banco de dados e terão um código de acesso (login) e uma senha de no mínimo seis caracteres. • Entrada de dados: os seguintes controles serão usados nos campos que receberão dados como a utilização de tabelas para facilitar os preenchimentos; tamanhos dos campos limitados ao tamanho do banco de dados; Se algum campo obrigatório não for preenchido, o sistema apresenta uma mensagem avisando que o campo deve ser preenchido; os campos das telas de entrada de dados estão agrupados de acordo com a sua natureza. • Backup: o backup do banco de dados será feito através de um script automático, onde será realizado o backup dos dados do banco e dos arquivos da aplicação, caso seja feita alguma alteração de programa equivocada, o arquivo correto poderá ser restaurado. O horário que será realizado a rotina de backup será definida pela empresa que utilizará o sistema. 88 11 CONCLUSÃO O Sistema de Egressos tem a proposta de prover a integração entre o mercado de trabalho, instituição de ensino e egressos, possibilitando a interação online para fins profissionais e/ou acadêmicos. A organização na distribuição de oportunidades aos egressos permite que as mesmas sejam disponibilizadas de acordo com sua área pertinente, previamente selecionada pelo empregador. Dessa forma, o Sistema de Egressos será um diferencial da instituição com os mercados de trabalho, agregando aos seus egressos informações pertinentes as suas respectivas áreas profissionais. O desenvolvimento deste projeto teve como grande benefício o aprendizado para o complemento da grade acadêmica e profissional, pois foi possível aplicar uma gama considerável de conhecimentos adquiridos durante o curso de Ciência da Computação, praticando as atividades de analista de sistemas e programador. De maneira geral, este sistema pode ser utilizado em qualquer Instituição de ensino que deseja manter vínculos com seus alunos egressos e propiciar a reciclagem constante da grade curricular dos cursos oferecidos, focando atender as verdadeiras e atuais necessidades do mercado de trabalho. Tem-se como propostas de trabalhos futuros, a integração do Banco de Dados da Instituição (Centro Universitário de Vila Velha - UVV) com o da aplicação, dessa forma será possível importar os Coordenadores e Egressos para a aplicação sem a necessidade de o ator Administrador inserir um coordenador ou o próprio egresso se cadastrar, e o desenvolvimento do Schedulador (System Scheduler) - sistema gerenciador de tarefas previamente agendadas pelo administrador do sistema, funcionará como uma espécie de Robô na execução de operações - para enviar mensagens aos egressos quanto à chegada de datas de processos seletivos das vagas disponibilizadas pelas empresas devidamente cadastradas na aplicação. 89 12 REFERÊNCIAS BIBLIOGRÁFICAS [BEZERRA - 2002] - BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 8a ed. Rio de Janeiro: Elsevier , 2002. [HTTP://WWW.LINHADECODIGO.COM.BR] - NOGUEIRA, Admilson. UML - Unified Modeling Language - Introdução e Histórico. Disponível em <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=763>. Acesso em 28 dez. 2008, 22:30:00. [FALBO - 2002] - FALBO, Ricardo. Análise de Sistemas - Notas de Aula. Vitória: UFES, 2002. [FALBO - 2003] - FALBO, Ricardo. Projeto de Sistemas - Notas de Aula. Vitória: UFES, 2003. [HTTP://IMASTERS.UOL.COM.BR] - NOGUEIRA, Admilson. UML - Projetos de Sistemas Orientados a Objetos. Disponível em <http://imasters.uol.com.br/artigo/3877/atores>. Acesso em 28 dez. 2008, 22:00:30. [BOOCH - 1998] - BOOCH, Grady; JACOB, Jean Paul; RUMBAUGH, James. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998. [LARMAN - 2000] - LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução a Análise e ao Projeto Orientados a Objetos; trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. [HTTP://WWW.DGZ.ORG.BR] - ARAKAKI, Reginaldo; SOUZA, Alexandra A. Processo de Manutenção de Software Web apoiado pela modelagem IHC. Disponível em Http://www.dgz.org.br/dez06/Art01.htm. Acesso em 19 out. 2008, 18:00:00. [MEDEIROS - 2004] - MEDEIROS, Ernani Sales de. Desenvolvendo Software com UML 2.0 : definitivo, São Paulo: Makron Books, 2004. 90 CUNNINGHAM, Ward. Enterprise Solution Patterns Using Microsoft.NET. Microsoft, 2003. JEZIERSKI, Edward A., Application Architecture for .NET: Designing Applications and Services. Microsoft, 2002. MARIANI, Rico; BOHLING, Brandon; SMITH, Connie U.; BARBER, Scott. Improving .NET Application Performance and Scalability. Microsoft, 2004. WITHALL, Stephen. Software Requirement Patterns. Microsoft, 2007. [FURLAN - 1998] - Furlan, José Davi. Modelagem de Objetos através da UML: Análise e Desenho Orientados a Objetos, São Paulo: Makron Books, 1998. [WWW.WIKIPEDIA.ORG] - Enciclopédia Livre. Disponível em <http://pt.wikipedia.org/wiki/Engenharia de software >. Acesso em 17 out. 2008, 21:45:00. [HTTP://PT.WIKIPEDIA.ORG] - Enciclopédia Livre. Disponível em <http://pt.wikipedia.org/wiki/Diagrama de sequC3AAncia>. Acesso em 20 out. 2008, 19:45:00. 91 ANEXO A Este anexo contém as tabelas com os dicionários de dados dos diagramas de classes: 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120
