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 i

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 i

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. ii

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. iii

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 iv

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 v

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 B1 Pauta do dia 14/09/ vi

8 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 vii

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 Figura 3.11 Diagrama de Seqüência referente a Manter Profissionais 60 Figura 3.12 Diagrama de Seqüência referente a Manter Fornecedores 61 viii

10 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 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 ix

11 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 x

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 PHP RUP SGDB Grupo de Gerenciamento de Objetos 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 xi

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 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 1

14 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. 2

15 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 3

16 } 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 4

17 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 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á 5

18 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 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. 6

19 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 7

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]: 8

21 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 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 9

22 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. 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 10

23 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 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 é 11

24 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. 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 12

25 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] 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] 13