UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO SIGEP - SISTEMA DE GERÊNCIA DE PROJETO / FUNDAÇÃO AROEIRA FELIPE DOS SANTOS CARVALHO GILOWSKY WELLINGTON BATISTA DE SIQUEIRA Goiânia 2007

2 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO SIGEP - SISTEMA DE GERÊNCIA DE PROJETO / FUNDAÇÃO AROEIRA Trabalho de Conclusão de Curso apresentado por Felipe dos Santos Carvalho Gilowsky e Wellington Batista de Siqueira à Universidade Católica de Goiás, como requisito principal para a obtenção do título de Bacharel em Ciência da Computação aprovado em / / pela Banca Examinadora: Professor Vicente Paulo de Camargo, Orientador

3 AGRADECIMENTOS Ao Professor Vicente de Camargo, orientador acadêmico, pelo apoio e confiança depositada. Ao Professor Alexandre Ribeiro pela sua inestimável colaboração. Aos colegas Jandilson Morais Oliveira e João Luis da Costa Leandro pelas discussões técnicas e inestimáveis sugestões. À Fundação Aroeira que tornou possível a realização desse projeto.

4 RESUMO Este trabalho faz uma abordagem do uso do RUP (Processo Unificado) e da metodologia de Orientação a Objetos no desenvolvimento de sistemas voltados para ambiente web, enfatizando a importância da UML (Linguagem de Modelagem Unificada) na modelagem para a melhor compreensão e controle da complexidade do sistema, vantagens da utilização do padrão MVC na arquitetura de aplicativos, focando princípios de reuso, manutenibilidade, portabilidade, segurança e nas vantagens do uso de técnicas e padrões como apoio para maximizar a implementação destes conceitos, tornando o processo de desenvolvimento de sistemas em ambiente web mais barato, rápido e padronizado. Será abordado também aqui uso de novas linguagens e tecnologias para tornar os aplicativos web mais dinâmicos e iterativos com o usuário. Os conceitos adquiridos a partir destas abordagens são aplicados em todas as fases do desenvolvimento de um Sistema de Gerência de Projetos destinado ao uso da Fundação Aroeira. Palavras-Chave: RUP,OO, UML, MVC, PHP, FRAMEWORK.

5 ABSTRACT This work makes a boarding of the use of RUP (Unifed Process) and of the methodology of Orientation the Objects in the development of systems directed toward environment web, emphasizing the importance of the UML (Unified Modeling Language ) in the modeling for the best understanding of systems, advantages of the use of standard MVC in the architecture of applicatory, focalized principles of reutilized, management, portability, security and in the advantages of the use of techniques and standards as support for maximizing the implementation of these concepts, becoming the process of development of systems in environment web cheaper, fast and standardized. Will be boarded also here the use of new technologies to become the applicatory web more dynamic and interactive with the user. The acquired concepts from these approaches are applied in all the phases of development of a Project Management System destined to the use of the Aroeira Foundation. Keywords: RUP, OO, UML, MVC, PHP, FRAMEWORK

6 SIGEP - SISTEMA DE GERÊNCIA DE PROJETO / FUNDAÇÃO AROEIRA SUMÁRIO LISTA DE FIGURAS viii LISTA DE ABREVIATURAS E SIGLAS xi INTRODUÇÃO 1 2. FUNDAMENTAÇÃO TEÓRICA Conceitos da Orientação a Objetos Classes Atributos e Operações Herança Polimorfismo Encapsulamento UML Processo Unificado e RUP Processo dirigido por casos de uso Processo centrado na arquitetura Processo iterativo e incremental MVC (Model View - Controller) Modelo Visão Controle HTML PHP e Páginas Dinâmicas Conceitos Básicos JavaScript e DHTML Framework Características Básicas de um Framework Vantagens e Desvantagens do uso de Framework Vantagens Desvantagens O framework Prado PROJETO SIGEP Objetivo 24

7 3.2. As delimitações do projeto Justificativa Desenvolvimento Relação dos Requisitos Relação dos Requisitos Funcionais Relação dos Requisitos Não Funcionais Organização dos Requisitos Relação dos Casos de Uso Conceitos Consultas / Relatórios Expansão dos casos de uso Descrição dos casos de uso Diagrama dos Casos de uso Diagramas de seqüência Modelo Conceitual (Diagrama de classe da análise) Contratos de Funcionalidade Lista Básica de Funcionalidades do Sistema Especificação das Funcionalidades do Sistema Diagrama de Classes do Projeto Mapeamento do diagrama de classes Dicionário de Dados Tabelas Atributos Camada de Interface Diagrama de Estado de Navegação Especificação das Janelas 105 CONCLUSÃO 112 REFERÊNCIAS BIBLIOGRÁFICAS 113 GLOSSÁRIO 115 ANEXOS 117 Anexo A Documento Visão 117 Anexo B Pautas de Reunião 119

8 B1 Pauta do dia 14/09/ B2 Pauta do dia 05/10/ B3 Pauta do dia 11/10/ B4 Pauta do dia 19/10/ Anexo C Lista Mestra de Requisitos 128 C1 - Lista Geral de Requisitos Funcionais 128 C2 - Lista Geral de Requisitos Não Funcionais 128 Anexo D Requisitos 129 D1 Manter Pré-Projeto 129 D2 Avaliar Pré-Projeto 129 D3 Manter Projeto 130 D4 Manter Profissionais 130 D5 Manter Fornecedores 131 D6 Manter Patrocinadores 131 D7 Manter Correspondências 132 D8 Manter Cronograma de Projeto 132 D9 Acompanhar Gastos 133 D10 Emitir Relatório Circunstanciado 133 D11 Emitir Relatório de Pré-Projeto 134 D12 Emitir Relatório Analítico de Projetos 134 D13 Emitir Relatório Completo de Projetos 135 D14 Emitir Relatório de Profissionais 135 D15 Emitir Relatório de Fornecedores 136 D16 Emitir Relatório de Patrocinadores 136 D17 Manter Proponente Físico 137 D18 Manter Proponente Jurídico 137 D19 Manter Usuário 137 D20 Validar CPF 138 D21 Efetuar Logon 138 D22 Exibir logomarca no rodapé 138 D23 Efetuar rotinas de backup diariamente 139

9 LISTA DE FIGURAS Figura Classe Pessoa codificada em linguagem PHP. 4 Figura 2.2 (a) - Diagrama de Caso de Uso 7 Figura 2.2 (b) Diagrama de seqüência mostra o cadastro de cliente 7 Figura 2.2 (c) Diagrama de Classes mostra a relação entres as classes 8 Figura 2.3 A ênfase em cada uma das fases no RUP 10 Figura 2.4 O Modelo de desenvolvimento em três camadas. 13 Figura Fluxo de eventos e informações em uma arquitetura MVC. 14 Figura Esqueleto de uma página Html, que se divide em duas partes 14 essenciais: Corpo e Cabeçalho. Figura 2.7 Fluxo entre cliente e servidor 16 Figura Mostra quando é possível criar um FrameWork. 19 Figura 2.9 (a) e (b) - Diferenças entre o uso de bibliotecas e frameworks. 20 Figura 3.1 Diagrama de Caso de Uso 1ª Parte 50 Figura 3.2 Diagrama de Caso de Uso 2ª Parte 51 Figura 3.3 Diagrama de Caso de Uso 3ª Parte 52 Figura 3.4 Diagrama de Seqüência referente a Manter Proponente Físico 53 Figura 3.5 Diagrama de Seqüência referente a Manter Proponente Jurídico 54 Figura 3.6 Diagrama de Seqüência referente a Manter Pré-Projeto 55 Figura 3.7 Diagrama de Seqüência referente a Manter Usuário 56 Figura 3.8 Diagrama de Seqüência referente a Efetuar Login 57 Figura 3.9 Diagrama de Seqüência referente a Avaliar Pré-Projeto 58 Figura 3.10 Diagrama de Seqüência referente a Manter Projeto 59

10 Figura 3.11 Diagrama de Seqüência referente a Manter Profissionais 60 Figura 3.12 Diagrama de Seqüência referente a Manter Fornecedores 61 Figura 3.13 Diagrama de Seqüência referente a Manter Patrocinadores 62 Figura 3.14 Diagrama de Seqüência referente a Manter Correspondências 63 Figura 3.15 Diagrama de Seqüência referente a Manter Cronograma 64 Figura 3.16 Diagrama de Seqüência referente a Acompanhar Gastos 65 Figura 3.17 Diagrama de Seqüência referente à Emissão do Relatório 66 Circunstanciado Figura 3.18 Diagrama de Seqüência referente à Emissão do Relatório 66 de Pré-Projeto Figura 3.19 Diagrama de Seqüência referente à Emissão do Relatório 67 Analítico de Projetos Figura 3.20 Diagrama de Seqüência referente à Emissão do Relatório 67 Completo de Projetos Figura 3.21 Diagrama de Seqüência referente à Emissão do Relatório 68 de Profissionais Figura 3.22 Diagrama de Seqüência referente à Emissão do Relatório 68 de Fornecedores Figura 3.23 Diagrama de Seqüência referente à Emissão do Relatório 69 de Patrocinadores Figura 3.24 Modelo Conceitual 1ª Parte 70 Figura 3.25 Modelo Conceitual 2ª Parte 71 Figura 3.26 Modelo Conceitual 3ª Parte 72 Figura 3.27 Diagrama de Classes do Projeto 1ª Parte 84 Figura 3.28 Diagrama de Classes do Projeto 2ª Parte 85 Figura 3.29 Diagrama de Classes do Projeto 3ª Parte 86 Figura 3.30 Mapeamento do Diagrama de Classes 1ª Parte 87

11 Figura 3.31 Mapeamento do Diagrama de Classes 2ª Parte 88 Figura 3.32 Mapeamento do Diagrama de Classes 3ª Parte 89 Figura 3.33 Diagrama de Estado de Navegação 1ª Parte 102 Figura 3.34 Diagrama de Estado de Navegação 2ª Parte 103 Figura 3.35 Diagrama de Estado de Navegação 3ª Parte 104 Figura 3.36 Tela de Login 105 Figura 3.37 Tela do Menu Principal 106 Figura 3.38 Tela de Manutenção de Proponentes 108

12 LISTA DE ABREVIATURAS E SIGLAS CSS DOM HTML MVC MYSQL O.O Cascating Style Document Object Model Linguagem de Marcação de Texto Modelo Visão Controle Linguagem de acesso ao Banco de Dados Orientação a Objetos OMG Grupo de Gerenciamento de Objetos PHP RUP SGDB Pré-processador de hipertexto Rational Unfied Process (Processo Unificado) Sistema Gerenciador de Banco de Dados UML Linguagem de Modelagem Unificada XML Linguagem de marcação expansível

13 INTRODUÇÃO A Internet tem se consolidado cada vez mais, abrangendo vários segmentos e negócios: comerciais, industriais, governamentais e outros. Muitas empresas vêem as informações relativas a seus negócios como um de seus mais importantes patrimônios e querem ter acesso a estas de maneira rápida, barata, descentralizada e segura, pois no mundo dos negócios ter a informação certa na hora certa pode fazer toda a diferença na tomada de decisões. Porém, desenvolver sistemas que estejam disponíveis em browser é uma tarefa ainda complexa, cara e demorada que envolve diversos problemas, como portabilidade e segurança, sem falar que as aplicações web geralmente são pouco interativas com os usuários e oferecem recursos limitados se comparados com as tradicionais aplicações para desktop. Desenvolver sistemas para ambiente web com qualidade é uma tarefa complexa que envolve vários processos, metodologias, padrões e tecnologias. Como a Internet é um ambiente de domínio público e acessado por usuários com os mais variados perfis, questões importantes como portabilidade e segurança devem receber atenção especial quando se trata de desenvolver sistemas para este ambiente. O padrão três camadas MVC (Model View Controller, Modelo Visão - Controle) será usado aqui para tratar boa parte destes problemas, dividindo a arquitetura do sistema em camadas distintas, o que aumenta a segurança das informações e facilitam mudanças para adequações a diferentes browsers, possibilitando, ainda, a distribuição das tarefas entre programadores e web designers. Primeiramente, para que a informação possa ser acessada via browser, ela deve estar em formato HTML, que é uma linguagem padrão para apresentação de conteúdo em um navegador (ou browser). Ela basicamente nos possibilita inserir textos, imagens, vídeos e criar links para outras páginas, não oferecendo recursos adicionais para iteração com o usuário, implementação da camada de negócios e iteração com a camada de dados (SGDB). Para estas

14 2 finalidades é necessário destacar as vantagens do uso de outras linguagens e técnicas de programação como PHP e JavaScript aliadas a HTML para criação de sistemas mais interativos e funcionais. Visto que desenvolver sistemas para ambiente web é uma tarefa que envolve várias linguagens e técnicas diferentes, cada uma com sua finalidade, a proliferação de linhas de código é muito grande, o que torna o processo de implementação lento e caro. Uma das soluções para amenizar este problema é o uso de frameworks, que são estruturas de classes inter-relacionadas, as quais constituem uma implementação inacabada para um conjunto de aplicações de um domínio, e que além de permitir a reutilização de um conjunto de classes, minimiza o esforço de desenvolvimento de aplicações, por portar a definição da arquitetura das aplicações [11]. Este trabalho visa apresentar o desenvolvimento de um SISTEMA DE GERENCIA DE PROJETOS para web, adotando o RUP como o processo no seu desenvolvimento, com Framework, JavaScript e PHP, de modo a atender as necessidades da Fundação Aroeira. A motivação de se fazer este trabalho, é de tornar possível a criação de um produto de qualidade com o desenvolvimento de um software O.O através da aplicação dos conhecimentos adquiridos na graduação integrados com a realidade empresarial. O presente trabalho será dividido em três capítulos. O capítulo dois faz uma abordagem inicial aos padrões, metodologias e tecnologias que serão adotadas e utilizadas em todas as fases do desenvolvimento de um Sistema de Gerência de Projetos destinado ao uso da Fundação Aroeira. No capítulo três será feita uma análise e descrição do sistema e dos artefatos de projeto produzidos durante o seu ciclo de vida.

15 3 CAPÍTULO II 2 - FUNDAMENTAÇÃO TEÓRICA Conceitos Básicos da O.O Orientação a Objetos Segundo Adílson da Silva Lima [08], objetos são coisas do mundo real, como carros, animais, etc.., que possuem propriedades ou características. Essas características são os atributos. Os objetos possuem comportamentos que são mais conhecidos como métodos (são as funções que os objetos executam). Na construção de um sistema precisamos buscar todas as propriedades que existem em comum para a execução da tarefa. O ato de buscar ou abstrair objetos comuns a uma determinada realidade denomina-se Abstração [08] Classes Uma classe de objetos descreve um grupo de objetos com propriedades e comportamentos similares, relacionamentos comuns com outros objetos e uma semântica comum. Um objeto que pertence a uma determinada classe é chamado de instância dessa classe. A figura 2.1 mostra a codificação em PHP, da classe Pessoa. Os elementos da classe ficam entre chaves, os atributos $nome, $nascimento e $documento aparecem primeiro com seus tipos. Depois logo em seguida vem os métodos da classe que são as operações da classe. class Pessoa { public $nome; public $nascimento; public $documento; funcion setnome($valor) { $this->nome = $valor }

16 4 funcion setnascimento($valor) { $this->nascimento = $valor } funcion setdocumento($valor) { $this->documento = $valor } } Figura 2.1 Classe Pessoa codificada em linguagem PHP Atributos e Operações (Comportamento) Os atributos de uma classe são as propriedades dos objetos. Esses atributos possuem algumas características importantes, como a visibilidade (escopo), nome, tipo e valor inicial. Segundo Adilson da Silva lima [08], a visibilidade de um atributo pode ser pública, privada, protegida e de pacote (disponível em algumas linguagens, como Java e PHP). O tipo de dado e o valor inicial dependem da linguagem de programação utilizada no modelo. As operações são funções que as classes irão executar, e geralmente os métodos implementam essas funções ou operações. Assim como os atributos, as operações também possuem algumas características como: visibilidade, nome, lista de argumentos e tipo de retorno Herança A herança é um dos principais conceitos da Orientação a Objetos. Com ela surgem mais dois conceitos importantes: superclasse e subclasse. Os objetos além de possuírem características iguais, podem possuir algumas específicas, por exemplo, um objeto Roberto que é instância de uma classe pessoa possui nome e CPF como atributos, mas podemos acrescentar mais atributos ou operações ao objeto, de forma que aquelas características sejam

17 5 específicas dele. A superclasse é a classe mãe por exemplo (Pessoa), cujos objetos são instanciados com os mesmos atributos e operações, e subclasse é a classe filha por exemplo (Funcionário), que além de possuir os atributos e operações da superclasse (no caso pessoa), ela agrega mais características a sua estrutura [08] Polimorfismo O polimorfismo trabalha com a idéia de que objetos diferentes podem possuir as mesmas características e operações, porém executam as tarefas diferentemente [08] Encapsulamento O encapsulamento trabalha de maneira que as informações de como funciona uma operação e seus respectivos detalhes de implementação não fiquem disponíveis, ou seja, podese usar a operação mesmo sem saber detalhes do seu funcionamento interno. A O.O acrescentou importantes conceitos à área de engenharia de software apesar do seu tempo de implementação ser muito maior do que as linguagens procedurais. Uma vez feito o trabalho corretamente e bem feito o retrabalho é desnecessário e a manutenção é muito mais rápida. [11] UML (Unified Modeling Language) Desenvolver sistemas de informação é uma tarefa complexa, onde os engenheiros de software não possuem idéia concreta do que será construído, por isso a importância de se modelar antes de construir para evitar interpretações errôneas do que deveria e do que está sendo desenvolvido [07]. Após a popularização do conceito de orientação a objeto surgiram vários modelos com o objetivo de modelar sistemas que utilizassem este conceito. A comunidade de

18 6 Engenharia de Software sentia a necessidade de um modelo que padronizasse as boas práticas de modelagem. Em 1994 James Rumbaugh juntou-se a Grady Booch na Rational Software Corporation e os dois começaram a trabalhar para unificar seus processos. Em seguida juntou-se a eles Ivan Jacobson. Trabalhado juntos para unificar seus processos, liberaram, em 1996, as versões preliminares da UML, a qual foi muito bem aceita pela a comunidade de Engenharia de Software e se tornou uma espécie de padrão [07]. Segundo o OMG, a UML é uma linguagem para especificação, construção, visualização e documentação de artefatos de um sistema ou negócio [07]. A UML é bastante flexível e não depende de processo, linguagem ou metodologia adotada no desenvolvimento de um sistema, por isso pode ser perfeitamente utilizada para modelar e documentar aplicativos voltados para qualquer ambiente: web ou desktop. Os diagramas padronizados da UML envolvem a identificação de itens que formam o vocabulário do sistema e a especificação de como estes itens relacionam-se entre si, um diagrama UML é um conjunto de itens e relacionamentos [10]. As Figuras 2.2 (a), (b) e (c) mostram três dos diagramas mais utilizadas na modelagem de sistemas. A figura 2.2 (a), mostra o diagrama de caso de uso que é a modelagem de um de terminado caso de uso, sua estrutura básica consiste nos atores representados pelos bonecos, as associações com os casos de uso e os casos de uso. A figura 2.2 (b), mostra o diagrama de seqüência que geralmente é modelado após já ter sido feito a expansão e modelagem dos casos de uso, sua estrutura consiste em atores, objetos que simbolizam a aplicação e o sistema e as associações entre os objetos. A figura 2.2 (c), mostra o diagrama de classes, que modela as classes do sistema e mostra como elas se relacionam. Sua estrutura básica são as classes representadas por tabelas e as associações entre elas.

19 7 Video Locadora Cadastra Cliente Funcionario Efetua Emprestimo Figura 2.2 (a) - Diagrama de Caso de Uso Aplicação Video Locadora Funcionario Dados do Cliente CadastraCliente(Dados) Cadastro Realizado Figura 2.2 (b) Diagrama de seqüência mostra o cadastro de cliente

20 Efetuar Emprestimo Cod_Emprestimo Cod_Cliente Data_Emp Data_Dev Valor : int : int : Date : Date : Float + efetuaremprestimo () : boolean * Cod_Cliente Nome CPF Endereco Cliente : int : String : String : String incluircliente () excluircliente () alterarcliente () consultarcliente () : Boolean : Boolean : Boolean : Boolean Figura 2.2 (c) Diagrama de Classes mostra a relação entres as classes. 2.3 Processo Unificado e RUP (Rational Unified Process) O RUP foi criado por Ivan Jacobson, James Rumbaugh e Grady Booch para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemática para se obter real vantagem no uso da UML. De fato, ele não é exatamente um processo de software: é uma infra-estrutura genérica de processo de software que pode ser especializada para uma ampla classe de sistemas de software, para diferentes áreas de aplicação, tipos de organização, níveis de competência e tamanhos de projetos [07]. Segundo Jacobson et al [07], Um processo é um conjunto de passos que define quem está fazendo o que, quando e como para alcançar determinado objetivo [07]. A UML, é uma linguagem para modelagem orientada a objetos e amplamente independente de processo, indica apenas como criar e ler modelos padronizados, mas não aponta quais modelos serão criados nem quando deverão ser criados. Essa tarefa cabe ao processo de desenvolvimento adotado. O RUP explora integralmente as capacidades do padrão UML e baseia-se em algumas das melhores práticas de desenvolvimento de software. O Processo Unificado possui a característica de ser orientado por casos de uso, ser centrado na arquitetura e ser interativo e incremental. O RUP possui fases bem definidas, o que favorece uma padronização do processo. São elas: concepção, elaboração, construção e transição [07]: Concepção: nesta fase, são estabelecidos o escopo do projeto e suas delimitações, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados

21 9 com a precisão necessária para se proceder a estimativas de prazos e custos. Ao término dessa fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento. Elaboração: o propósito desta fase é analisar mais detalhadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do desenvolvimento. Construção: durante esta fase, um produto é desenvolvido de maneira iterativa e incremental, para que esteja pronto para ser entregue ao usuário. Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que vão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto, implementação e testes, é realizado. De uma iteração para outra (sendo que cada iteração consiste em fazer levantamento de requisitos, análise, projeto, implementação e testes) e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 2.3, em que a cor mais escura indica grande ênfase, enquanto a cor branca indica muito pouca ênfase. Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos, levantamento de requisitos e análise. Na fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir. Finalmente, a fase de transição concentra-se nos testes, visando garantir que o sistema possua o nível adequado de qualidade. Além disso, os usuários devem ser treinados e as características ajustadas.

22 10 Levantamento de Requisitos Análise Projeto Implementação Testes Concepção Elaboração Construção Transição Figura 2.3 A ênfase em cada uma das fases no RUP Processo dirigido por casos de uso (use cases): O RUP é dirigido a casos de uso, pois são os casos de uso que orientam todo o processo de desenvolvimento. Caso de uso é um modelo que define o que o sistema deve fazer da perspectiva dos usuários, subsistemas ou periféricos, e ator é algo que interage com o sistema. Todos os casos de uso de um sistema compõem a especificação funcional do ponto de vista do usuário, ou seja, definem os requisitos do sistema. Os casos de uso dirigem várias atividades de desenvolvimento como: definição dos ciclos iterativos, validação e verificação, implementação e elaboração dos casos de testes Processo centrado na Arquitetura Por ser centrado na arquitetura, o RUP fornece uma base sólida para a construção do software, pois, conforme Ivan Jacobson et al. a arquitetura é a visão de todos os artefatos que juntos representam o sistema como um todo [07]. O conceito de arquitetura de software engloba os aspectos estáticos e dinâmicos mais significantes do sistema. A arquitetura é influenciada por muitos fatores como, a plataforma na qual o software será implementado, os blocos de construção reutilizáveis, requisitos não

23 11 funcionais, blocos responsáveis por requisitos passíveis de mudanças e requisitos fundamentais do sistema. O RUP orienta o arquiteto de sistema de maneira a se concentrar nas metas, como a inteligibilidade, a capacidade de mudanças, a manutenção e a reutilização [08] Processo Iterativo e Incremental Durante o desenvolvimento de um sistema, é prático dividi-lo em mini-projetos. Segundo Jacobson cada mini-projeto é uma iteração que resulta em um incremento. Para garantir mais efetividade, as iterações devem ser controladas, ou seja, devem ser executadas de modo planejado [07]. Para definir quais casos de uso do sistema deverão ser abordados em determinado ciclo iterativo, os analistas levam em conta fatores como as funcionalidades essenciais do sistema e as que oferecem maior risco para o sucesso do projeto. Estas deverão ser abordadas nos primeiros ciclos, sendo refinadas em sucessivas iterações. O ciclo de vida adotado no RUP é tipicamente evolutivo. Este modo de operação torna mais fácil a adaptação do sistema a mudanças dos requisitos, controla riscos do projeto e aceleram o tempo de desenvolvimento MVC (Model View Controller) Modelo Visão Controle O padrão MVC é um padrão de arquitetura de aplicação cujo objetivo é promover uma maior independência entre os componentes do projeto. O padrão MVC separa a lógica da aplicação (Modelo), da interface do usuário (Visão) e do fluxo da aplicação (Controle). É muito comum em grandes projetos a existência de complexas regras de negócio e projetos de interfaces rebuscados, e a redução do acoplamento entre os componentes é bastante importante para se atingir maior reusabilidade e mais facilidade de manutenção sem comprometer todo o sistema. O padrão MVC entra como uma solução, por sinal muito usado em aplicações web, para a construção de sistemas cada vez mais coesos e menos acoplados.

24 12 Modelo: É a camada que contém a lógica da aplicação. É responsável por conter as regras de negócio e, para sistemas persistentes, todo o controle de acesso e tratamento de dados vindos do banco. Recebe as requisições e geram respostas a partir do que foi pedido. Responsável por tudo que a aplicação vai fazer: modela os dados e o comportamento por atrás do processo de negócios preocupa-se apenas com o armazenamento, manipulação e geração de dados é um encapsulamento de dados e de comportamento independente da apresentação. Visão: É a camada de apresentação ao usuário. É a interface que proporcionará a entrada de dados e a visualização das respostas geradas. Em aplicações web é representado pelo HTML que é processado e mostrado pelo navegador. Geralmente contém formulários de entrada de dados e tabelas, grids, etc. Essa camada não contém lógicas de negócio, portanto todo o processamento é feito pelo Modelo e então a resposta é repassada para a Visão. Também chamada de camada de apresentação ou visualização, não esta preocupada em como a informação foi obtida ou onde ela foi obtida, apenas exibe a informação. inclui os elementos de exibição no cliente : HTML, XML, Applets. É a camada de interface com o usuário. É usada para receber a entrada de dados e apresentar o resultado Controle: Já falamos de quem recebe as requisições e de quem as manda. Mas temos que concordar que tudo isso viraria uma grande bagunça se não houvesse alguém para organizar tudo isso. Essa é a função da chamada de controle. Essa camada funciona como um intermediário entre a camada de apresentação e a camada de negócios. Exerce um controle como o próprio nome sugere, determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica [12]. controla e mapeia as ações Todo o acesso do cliente ao banco de dados, é feito de acordo com as regras contidas no servidor de aplicações. O cliente não tem acesso direto ao banco de dados, sem antes passar pelo servidor de aplicações. A figura 2.4 exemplifica isso. [11]

25 13 Servidor de Aplicações Servidor do banco de dados No modelo de três camadas, toda a Lógica do negócio fica no servidor de Aplicações. Com isso, a atualização das regras do negócio fica mais fácil. Cliente Cliente Cliente Cliente Cliente Figura 2.4 O Modelo de desenvolvimento em três camadas[11]. Geralmente as alterações que uma equipe de desenvolvimento faz em um software, voltam-se mais para a lógica do negócio e este estando separado possibilita a manutenção com mais facilidade e rapidez. A Figura 2.5 explica o fluxo de eventos e informações da Arquitetura MVC onde, a camada de visão fornece as informações para a camada de controle que, altera a camada de modelo conforme a lógica de negócio, depois a camada de modelo lança os eventos de mudança para a camada de visão: [9] Figura 2.5 Fluxo de eventos e informações em uma arquitetura MVC HTML

26 14 A HTML (Hypertext Markup Language - Linguagem de Marcação de Hipertexto) é uma linguagem dedicada à construção de páginas web, possibilitando a criação de páginas estáticas, inserção de textos, imagens, vídeos, formatando-os da forma como irão ficar na página. A HTML possibilita também criar links para outras páginas. A HTML foi criada, a princípio, com objetivos de divulgação de conteúdo na web. Contudo, a HTML não tinha sido projetada para as novas exigências que surgiram no mercado. Para o maior entendimento a figura 2.5 mostra o esqueleto de uma página HTML com os seus devidos componentes: [11] <html> Tag de início do documento <head> (cabeça do documento) <title>título do documento</title> </head> (final de cabeça do documento) <body> (tag de início do corpo) <h1>primeiro nível de cabeçalho</h1> <h2>segundo nível de cabeçalho</h2> </body> (tag de final do corpo) CABEÇALHO CORPO </html> Tag de final do documento Figura Esqueleto de uma página Html, que divide-se em duas partes essenciais: Corpo e Cabeçalho. A HTML possui etiquetas ou tags com o formato <B>, por exemplo. Cada etiqueta possui um significado. Por exemplo, <B> quer dizer que o texto que aparecer na tela sairá em negrito. Porém, páginas desenvolvidas em HTML são páginas estáticas, ou seja, a cada requisição do usuário ele terá que esperar a página e apresentar sempre o mesmo conteúdo. É muito simples a criação destas páginas, embora ofereçam poucas vantagens tanto aos desenvolvedores quanto aos visitantes. Surge então uma nova abordagem: páginas dinâmicas [05] PHP e Páginas Dinâmicas PHP é o acrônimo de Hyper Preprocessor (pré-processador de hipertexto), uma poderosa linguagem de programação open source, mundialmente utilizada, principalmente no

27 15 ambiente web. [10] PHP trabalha do lado do servidor. É gratuita, não depende de plataforma. Tem uma grande aceitação no mundo. É uma das melhores opções para a construção de sites, intranets e sistemas disponíveis via browser. Antes da página ser visualizada pelo cliente, o PHP pode acessar bases de dados, fazer conexões em rede a fim de preparar a página que será mostrada. PHP se escreve dentro do código HTML, o que o faz realmente fácil de utilizar [05]. Como o código HTML é portável a todos os navegadores, o PHP acaba sendo muito bem aceito para a criação em Web. A utilização de PHP é vantajosa, pois além de gratuita e independente, ela é rápida e segura. Com o PHP a criação de aplicações Web fica mais simples, pois possui um inúmero conjunto de funções prontas para serem usadas. As páginas dinâmicas são, portanto a utilização de PHP embutido em HTML. [05] Atualmente PHP se encontra em sua versão 5 que incorpora todas as funcionalidades para suportar a metodologia de orientação a objetos, hoje sendo um importante diferencial no mundo da programação, principalmente pelo fato de poder reutilizar códigos. A figura 2.7 mostra o fluxo entre o cliente e um Servidor Web, o cliente faz uma requisição a alguma informação, o Browser passa a requisição para o Servidor. Dentro do servidor fica o Servidor Web, o PHP e o MySql Server. Eles se comunicam resultando no acesso ao banco de dados que retorna a informação para o servidor e consecutivamente retornará a informação para o cliente.[03]

28 16 Figura Fluxo entre cliente e servidor O PHP não é a única linguagem de implementação para web, existem outras como por exemplo o JavaScript, Visual Basic Script, ASP, JSP e outras. O PHP foi escolhido pois é uma plataforma gratuita, que abrange diversos recursos, é portável e possui uma vasta bibliografia Conceitos Básicos Sobre JavaScript e DHTML Idealmente, uma interface com o usuário deve ser invisível, fornecendo apenas as opções de que eles precisam quando necessário ou, de outro modo, ficando fora do caminho, deixando-os livres para focalizarem o problema em questão. Infelizmente, isso é muito difícil de conseguir e, assim, nós acostumamos ou nos resignamos a trabalhar diariamente com UIs improdutivas quando se trata de aplicativos para Web. O aplicativo Web clássico com que estamos acostumados começa a se quebrar sob o esforço que os serviços baseados na Web cada vez mais sofisticados empoem sobre ele. Uma variedade de tecnologias esta sendo convocada para preencher a lacuna com clientes mais ricos, mais inteligentes e mais aprimorados. O JavaScript é capaz de entregar isso utilizando apenas as tecnologias já instaladas nos computadores modernos.

29 17 Aqui, rico refere-se ao modelo de interação do cliente. Um modelo de interação rica com o usuário é aquele que pode suportar uma variedade de métodos de entrada e que responde de maneira rica com o usuário podendo suportar uma variedade de métodos de entrada e que responde de maneira intuitiva no momento oportuno, comparado a geração atual de aplicativos comuns (desktop). Se comparados aos aplicativos desktop os aplicativos Web são visivelmente limitados em termos de interação com o usuário [12]. O JavaScript é uma linguagem de programação de uso geral de descendência híbrida, com uma leve semelhança com a família das linguagens C. Grosso modo, o JavaScript pode ser caracterizado como a uma linguagem de criação de scripts de uso geral, interpretada e fracamente tipada [12]. Fracamente tipada significa que as variáveis não são declaradas especificamente como string, inteiros ou objetos e que é possível atribuir valores de diferentes tipos á mesma variável. Interpretada significa que não é compilada no código executável, mas o código fonte e executado diretamente. Ao instalar um aplicativo Web JavaScript, o código-fonte e colocado no servidor e transmitido diretamente pela Internet até o navegador Web. Uso geral significa que a linguagem é adequada para uso com a maioria dos algoritmos e tarefas de programação. A linguagem JavaScript básica contém suporte a números, string, datas e horas, arrays, expressões regulares para processamento de texto e funções matemáticas como trigonometria e geração de números aleatórios. Dentro do ambiente do navegador Web, partes da funcionalidade nativa do navegador, incluindo CSS e DOM são expostos ao mecanismo JavaScript, permitindo que os autores de paginas controlem mais ou menos programaticamente a página.[12] O DOM (Document Object Model) apresenta a estrutura das paginas Web como um conjunto de objetos programáveis que pode ser manipulado com JavaScript. Criar scripts com o DOM permite que um aplicativo modifique a interface com usuário instantaneamente, redesenhando eficazmente partes da pagina. A interface com o usuário é manipulada e atualizada utilizando JavaScript para manipular DOM, redesenhando e reorganizando continuamente os dados apresentados aos usuários e processando suas interações baseadas no mouse e no teclado.[12] As folhas de estilo em cascata (Cascading Sttyle Sheets CSS) fornecem aparência e comportamento consistentes para o aplicativo e um atalho poderoso para a manipulação programática do DOM. As folhas de estilo em cascata são uma parte bem estabelecida do

30 18 design de paginas, e elas são muito utilizadas em aplicativos Web. Uma folha de estilo oferece uma maneira centralizada de definir categorias de estilos visuais, que então podem ser aplicadas a elementos individuais em uma pagina, além dos elementos óbvios de estilização como, cores, bordas, imagens de fundo, transparência e tamanho as folhas de estio podem definir a maneira como os elementos são organizados em relação um ao outro e também a sua interatividade simples com o usuário, permitindo que efeitos visuais bastante poderosos sejam alcançados apenas por meio de folhas de estilo e JavaScript.[12] Muito convenientemente, todas essas tecnologias já esta pré-instaladas nos navegadores Web mais modernos, incluindo o Microsoft Internet Explores, a família dos navegadores Mozilla/Gecko, Firefox, Mozilla Suíte, Netscape Navigator e Camino, Opera, Safári, Konqueror. Frustrantemente, as implementações dessas tecnologias são diferentes em relação a alguns navegadores com relação a alguns detalhes que irão variar de uma versão para outra, mas essa situação foi amenizada nos últimos cinco anos e há maneiras de lidar de um modo claro com a incompatibilidade de múltiplos navegadores.[12] 2.8 Framework Um framework orientado a objetos é uma estrutura de classes inter-relacionadas, que constitui uma implementação para um conjunto de aplicações de um domínio, além de permitir a reutilização de um conjunto de classes, um framework minimiza o esforço de desenvolvimento de aplicações, por portar a definição da arquitetura das aplicações [04]. Os padrões de projeto podem ser usados na definição da estrutura de classe do framework, ou para refinar a estrutura de classe ao longo do projeto. Usar padrões de projeto demanda conhecê-los para compreender como o framework aplica estes em sua estrutura. O presente trabalho aborda o uso de frameworks que implementam o padrão arquitetônico MVC que será implementado na arquitetura do sistema a ser desenvolvido. Um framework captura a funcionalidade comum a várias aplicações. As aplicações devem ter algo razoavelmente grande em comum e pertencerem a um mesmo domínio de problema, como mostra a figura 2.9 [04].

31 19 Figura 2.8 Mostra quando é possível criar um FrameWork Para se construir um framework capaz de se adaptar a um conjunto de aplicações diferentes, é fundamental que se disponha de modelagens de um conjunto significativo de aplicações do domínio. Os frameworks disponíveis hoje no mercado se propõem a fornecer formas de re-uso que vão além de código: re-uso de análise, design, código. [04] Um framework orientado a objetos provê uma solução para uma família de problemas semelhantes, usando um conjunto de classes e interfaces comuns a esta família. O conjunto de classes deve ser flexível e extensível para permitir a construção de várias aplicações com pouco esforço, especificando apenas as particularidades de cada aplicação. Observe-se que um framework é uma aplicação quase completa, mas com pedaços faltando; ao receber um framework seu trabalho consiste em prover os pedaços que são específicos para sua aplicação. [04] A figura 2.10 (a) e (b) mostra a diferença entre o Framework e as bibliotecas de classes orientadas a objetos. As bibliotecas usam classes instanciadas pelo cliente, já o Framework utiliza customização com subclasse ou composição. A figura 2.10 (b) descreve essas diferenças.

32 20 (a) (b) Figura 2.9 (a) e (b) diferenças entre o uso de bibliotecas e frameworks. [05] Não se pode embutir conhecimento do domínio como análise e design em uma biblioteca de classes, já no framework isso e possível, o que reduz consideravelmente o tempo de codificação. [04]

33 Características Básicas de um Framework Deve ser reutilizável; Bem documentado; Bem estruturado; Otimizado; Completo Vantagens e desvantagens do uso de framework Vantagens Redução de custos; Redução de tempo na codificação; Maximização de reuso na análise, design, código, testes; Permite o desenvolvedor concentrar-se mais nos propósitos e menos no design da aplicação; Explora aspectos comuns a várias aplicações; Estabilização melhor do código, menos defeitos devido ao uso em várias aplicações; Potencial minimização de esforço para a reutilização Desvantagens Construir um framework é complexo e exige amplo conhecimento do domínio para o qual se pretende construir; Reuso não vem sozinho, dever ser planejado; Desenvolvimento de um framework demanda flexibilidade (alterabilidade + flexibilidade).

34 O framework Prado Prado é um framework baseado em componentes e orientado a eventos, permitindo aos desenvolvedores serem mais produtivos visto que o foco do framework é a programação web que lida na maior parte do tempo com interações com os usuários. Utilizar o framework basicamente consiste em criar classes novas estendendo as classes base existentes no framework. Benefícios do uso do PRADO no desenvolvimento de aplicações para Web: Reusabilidade: os códigos dos componentes do PRADO são reutilizáveis; Facilidade de utilização: criar e usar componentes é extremamente fácil, geralmente envolve simplesmente configurar propriedades destes componentes. Robusto: PRADO reduz o esforço empreendido pelos desenvolvedores na criação de mais código, codificam nos termos dos objetos, métodos e propriedades. Fornece um mecanismo de relatório de erro mais preciso. Desempenho: PRADO usa uma técnica de caching para assegurar o desempenho das aplicações baseadas nele. Integração da equipe: PRADO permite a separação da camada lógica e da apresentação, implementa MVC em sua arquitetura de aplicações. Ainda segundo o Manual do Prado [14], 50 a 75% do trabalho de uma aplicação web é realizado para gerar front end e validar os dados fornecidos pelos usuários. Entre seus principais recursos estão : Html separado do código PHP Alto nível de reusabilidade por utilizar o conceito de componentes. Componentes para validação de formulários

35 23 Suporte a módulos Arquivos em XML definem a configuração da aplicação dos módulos e dos componentes. Suporte a internacionalização. Recursos de cache para aumentar a performance da aplicação.

36 24 CAPÍTULO III PROJETO SIGEP Este trabalho tem como propósito o desenvolvimento de um sistema de Gerência e Acompanhamento de Projetos destinado à Fundação Aroeira. Este capítulo descreve as características do sistema proposto, quais técnicas que serão utilizadas inicialmente para sua construção, o porquê da sua construção e as expectativas em relação a sua implantação. O sistema será desenvolvido de acordo com as necessidades identificadas junto a Fundação Aroeira. 3.1 Objetivo O objetivo principal desse trabalho é informatizar as tarefas de gerência e acompanhamento de projetos administrados pela Fundação Aroeira, garantindo a segurança, disponibilidade e integridade destas informações. Garantir que as informações do projeto estejam armazenadas de maneira mais otimizada, a fim de que o usuário não perca tanto tempo com consultas à documentos e planilhas eletrônicas. 3.2 As Delimitações do Projeto As delimitações são necessárias a qualquer projeto de um sistema, assim, poderemos definir o que realmente será implementado no sistema. O sistema deverá incluir funcionalidades para manter projetos conforme identificado nos requisitos do Anexo - D, funcionalidade para o acompanhamento das atividades realizadas e das pessoas envolvidas. O sistema ainda deve incluir consultas às informações relativas aos projetos, permitindo também a geração de relatórios destas informações. Para garantir maior segurança destas informações, serão criados dois níveis de usuário: Administrador e Usuário Padrão.

37 Justificativa O desenvolvimento deste sistema para a Fundação é de extrema relevância, pois, irá garantir fácil acesso às informações importantes dos projetos administrados pela Fundação, uma vez que este processo é feito manualmente através de planilhas eletrônicas e documentos o que dificulta a organização e a manutenção das informações. Outro fator importante é a segurança das informações que serão mantidas em um servidor que diariamente irá executar rotinas de backup. Do ponto de vista acadêmico este trabalho será de extrema importância, pois estaremos envolvidos na execução de todas as fases de desenvolvimento de software, desde a fase de concepção até a transição, oferecendo embasamento teórico e prático sobre o assunto. 3.4 Desenvolvimento Foram realizadas varias reuniões relacionadas no anexo B, juntamente com os responsáveis pela Gerência de Projetos da Fundação Aroeira, onde foi definido e aprovado o escopo inicial do projeto conforme consta no Anexo A. Posteriormente foram levantados, especificados e aprovados os principais requisitos, conforme Anexos C e D. O RUP (Processo Unificado) foi adotado neste projeto como processo de desenvolvimento, pois implementa a maioria das boas práticas de engenharia de software. Na arquitetura foi utilizado MVC que nos possibilita a divisão do sistema em camadas. Foram implementados os princípios de Orientação a Objetos e, evidentemente, da UML na modelagem do sistema. Segue a relação dos artefatos gerados no desenvolvimento do projeto, este artefato consiste no levantamento e análise de requisitos e artefatos de projeto.

38 Relação dos Requisitos Relação dos Requisitos Funcionais: A relação com os requisitos funcionais estará descrita no anexo C Relação dos Requisitos Não Funcionais A relação com os requisitos não funcionais estará descrita no anexo C.

39 Organização dos Requisitos Relação dos Casos de Uso Nome Atores Descrição Manter Proponente Físico Manter Proponente Jurídico Manter Pré-Projeto Manter Usuário Efetuar Login Avaliar Pré-Projeto Manter Projeto Manter Profissionais Administrador Administrador Administrador Administrador e Usuários do Sistema Administrador e Usuários do Sistema Administrador Administrador Administrador Manter Fornecedores Administrador Manter Patrocinadores Manter Correspondências Manter Cronograma de Projeto Acompanhar Gastos Emitir Relatório Circunstanciado Emitir Relatório de Pré-Projeto Administrador Administrador Administrador Administrador Administrador Administrador Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite a entrada da pessoa no sistema. Avaliar o pré-projeto para definir se será um projeto ou não. Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite utilizar operações de manutenção (I,A,E,C). Permite emitir um relatório como resumo dos projetos em andamento e concluídos Permite emitir um relatório com os status dos pré-projetos. Referências Cruzadas RF001, NF001 RF001, NF001 RF017, RF0018, NF001 NF001 RF019 RF001, NF001 RF001, RF002, RF004, RF005, RF007, NF001 RF003, NF001 RF003, NF001 RF003, NF001 RF003, RF004, RF005, RF006, NF001 RF003, NF001 RF003, RF004, RF005, NF001 RF003, NF001 RF001, RF002,

40 28 Emitir Relatório Analítico de Projetos Emitir Relatório Completo de Projeto Emitir Relatório de Profissionais Emitir Relatório de Fornecedores Emitir Relatório de Patrocinadores Administrador Administrador Administrador Administrador Administrador Permite emitir um relatório com as principais informações do projeto. Permite emitir um relatório com todos os dados de um projeto. Permite emitir um relatório de todos os profissionais contidos no sistema. Permite emitir um relatório de todos os fornecedores contidos no sistema. Permite emitir um relatório de todos os patrocinadores contidos no sistema. NF001 RF003, NF001 RF003, NF001 RF003, RF004, NF001 RF003, RF005, NF001 RF003, RF006, NF Conceitos Nota: I = inclusão, A = alteração, E = exclusão, C = consulta. Conceito I A E C Observação Ref. Cruzada Proponente Físico x x x x Proponente do Projeto. RF001, NF001 Proponente Jurídico x x x x Proponente do Projeto RF001, NF001 Pré-Projeto x x x x É a fase inicial. Para que ele chegue a ser um projeto é necessária a sua aprovação. Usuário x x x x Pessoas que utilizaram o sistema. NF001 Avaliar Pré- Definição da aceitação ou não do préprojeto. x x x x Projeto Projeto x x x x É o pré-projeto aprovado e com mais algumas informações adicionais. RF017, RF018, NF001 RF001, NF001 RF001, RF002, RF004, RF005, RF007, NF001 Profissionais x x x x Profissionais ligados diretamente e indiretamente aos projetos. RF003, NF001 Fornecedores x x x x Fornecedores ligados diretamente e indiretamente aos projetos. RF003, NF001 Patrocinadores x x x x Patrocinadores ligados aos projetos. RF003, NF001 Correspondências x x x x RF003, RF004, Correspondências enviadas e RF005, RF006, recebidas durante o projeto. NF001 Cronograma Gastos x x x x x x x x É o cronograma previsto para a realização das atividades do projeto É o acompanhamento dos gastos destinados ao projeto RF003, NF001 RF003, RF004, RF005, NF001