Issuu on Google+

FACULDADE DE E NGENHARIA DE G UARATINGUETÁ E SPECIALIZAÇÃO EM I NFORMÁTICA E MPRESARIAL

Sistema Web para Controle de Processos Acadêmicos

Jaqueline Blanco

Guaratinguetá - SP Junho, 2006


Sistema Web para Controle de Processos Acadêmicos

Jaqueline Blanco

Monografia apresentada à Faculdade de Engenharia de Guaratinguetá, da Universidade Estadual Paulista, como parte dos requisitos para a obtenção do certificado de Especialista em Informática Empresarial.

Orientador: Prof. Dr. José Celso Freire Junior

Guaratinguetá - SP Junho, 2006


Ficha catalográfica preparada na Seção de Aquisição e Tratamento da Informação do Serviço Técnico de Biblioteca e Documentação - FEG/UNESP

Blanco, Jaqueline B641s

Sistema Web para Controle de Processos Acadêmicos / Jaqueline Blanco, Guaratinguetá, 2006. 132 f.:il. Bibliografia: f. 73-76 Monografia de Especialização em Informática Empresarial - Univer-

sidade Estadual Paulista, Faculdade de Engenharia de Guaratinguetá, 2006. Orientador: Prof. Dr. José Celso Freire Junior.

1. UML (Linguagem de modelagem padrão) I. Título CDU 519.682


Sistema Web para Controle de Processos Acadêmicos

DADOS CURRICULARES

Jaqueline Blanco NASCIMENTO: 10/11/1979 - Nova Odessa, SP

FILIAÇÃO:

Célio Blanco Ana Maria Mendes Blanco

2000

Tecnólogo em Processamento de Dados Faculdade de Tecnologia de Americana

UNESP/FEG-CEIE, 2006

i


Sistema Web para Controle de Processos Acadêmicos

DEDICO À Deus "Hoje posso dizer que venci, mas é verdade que se não me curvei pelo cansaço e não me abati pelas dificuldades foi porque nos momentos difíceis voltei-me para meu coração e lá Te encontrei" (Giselle Silva Magalhães)

À minha família e aos meus queridos amigos "Falar é completamente fácil, quando se tem palavras em mente que expressem sua opinião. Difícil é expressar por gestos e atitudes o que realmente queremos dizer, ou o quanto queremos dizer, antes que a pessoa se vá. Fácil é demonstrar raiva e impaciência quando algo o deixa irritado. Difícil é expressar o seu amor a alguém que realmente te conhece, te respeita e te entende." (Carlos Drummond de Andrade)

UNESP/FEG-CEIE, 2006

ii


Sistema Web para Controle de Processos Acadêmicos

AGRADECIMENTOS

Primeiramente a Deus, que permitiu que mais uma etapa fosse superada. A minha família e aos amigos, que em todo momento deram o apoio necessário, me incentivaram e contribuíram diretamente ou indiretamente. A Universidade de Taubaté, que serviu de base para o desenvolvimento do protótipo do Sistema de Controle de Processos. Ao orientador, Prof. Dr. José Celso Freire Júnior e aos professores, Prof. Dr. Edson Luiz França Senne e Prof. Dr. Galeno José de Sena, pela orientação e ajuda na confecção deste trabalho.

UNESP/FEG-CEIE, 2006

iii


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

iv


Sumário

1 Introdução

1

1.1

Breve Descrição do Sistema Atual . . . . . . . . . . . . . . . . . . . . .

2

1.2

Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2.1

Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . .

3

Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

2 Modelagem Orientada a Objetos 2.1

Breve Descrição de Orientação a Objetos . . . . . . . . . . . . . . . . .

5

2.1.1

Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.2

Tipos de Metodologias Orientadas a Objetos . . . . . . . . . . .

8

2.1.2.1

Booch . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.1.2.2

OMT (Object Modeling Technique | Técnica de Modelagem de Objetos) . . . . . . . . . . . . . . . . . . . .

9

OOSE (Object-Oriented Software Engineering) . . . .

9

UML (Unified Modeling Language) . . . . . . . . . . . . . . . . . . . .

9

2.1.2.3 2.2

2.3

5

2.2.1

Fases do Desenvolvimento de um Sistema em UML . . . . . . .

11

2.2.2

Os Componentes da UML . . . . . . . . . . . . . . . . . . . . .

13

2.2.3

Visões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2.4

Modelos de Elementos . . . . . . . . . . . . . . . . . . . . . . .

15

2.2.5

Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

UWE (UML-based Web Engineering) . . . . . . . . . . . . . . . . . . .

21


Sistema Web para Controle de Processos Acadêmicos

3 Modelagem do Sistema de Controle de Processos Acadêmicos 3.1

3.2

25

Modelagem utilizando UWE . . . . . . . . . . . . . . . . . . . . . . . .

25

3.1.1

Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . .

25

3.1.2

Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . .

27

3.1.3

Modelo Conceitual . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.1.4

Modelo de Navegação . . . . . . . . . . . . . . . . . . . . . . .

32

3.1.5

Modelo de Apresentação . . . . . . . . . . . . . . . . . . . . . .

35

Modelagem de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4 Tecnologias Utilizadas

39

4.1

JavaServer Pages - JSP . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.2

Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.2.1

Ciclo de Vida do Servlet . . . . . . . . . . . . . . . . . . . . . .

44

4.3

PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.4

JDBC (Java DataBase Connectivity) . . . . . . . . . . . . . . . . . . . .

47

4.5

JSP x Tecnologias concorrentes . . . . . . . . . . . . . . . . . . . . . . .

48

4.5.1

ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.5.2

PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5 Funcionamento do Sistema

49

5.1

Módulo Controle de Usuários . . . . . . . . . . . . . . . . . . . . . . . .

52

5.2

Módulo Controle de Assuntos . . . . . . . . . . . . . . . . . . . . . . .

54

5.3

Módulo Controle de Departamentos . . . . . . . . . . . . . . . . . . . .

55

5.4

Módulo Controle de Despachos . . . . . . . . . . . . . . . . . . . . . . .

60

5.5

Módulo Controle de Processos . . . . . . . . . . . . . . . . . . . . . . .

62

5.6

Módulo Controle de Status dos Processos . . . . . . . . . . . . . . . . .

65

6 Conclusão

71

6.1

Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.2

Oportunidades futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

UNESP/FEG-CEIE, 2006

vi


Sistema Web para Controle de Processos Acadêmicos

Referências Bibliográficas

73

A Modelo Casos de Uso - SCPA

77

B Descrição dos Casos de Uso

81

C Modelo de Estrutura de Navegação - SCPA

101

D Modelo de Apresentação - SCPA

107

E Diagramas de Seqüências

111

F Dicionário de Dados

131

UNESP/FEG-CEIE, 2006

vii


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

viii


Lista de Figuras 2.1

Exemplo de Classe / Sub-classe . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Etapas do desenvolvimento de sistemas . . . . . . . . . . . . . . . . . .

11

2.3

Representação de Classe em UML . . . . . . . . . . . . . . . . . . . . .

15

2.4

Representação de Objeto em UML . . . . . . . . . . . . . . . . . . . . .

16

2.5

Agregação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.6

Generalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.7

Dependência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.8

Representação de Dependências e Refinamentos . . . . . . . . . . . . . .

18

2.9

Representação de Pacotes com relacionamentos . . . . . . . . . . . . . .

18

2.10 Representação de Componentes . . . . . . . . . . . . . . . . . . . . . .

19

2.11 Tipos de Diagramas - UML 1.5 . . . . . . . . . . . . . . . . . . . . . . .

20

2.12 Modelos da UWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.13 Representação de Diagrama de Casos de Uso . . . . . . . . . . . . . . .

22

2.14 Representação de Diagrama de Classes . . . . . . . . . . . . . . . . . . .

23

3.1

JUDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2

Caso de Uso Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.3

Caso de Uso Controle de Assuntos . . . . . . . . . . . . . . . . . . . . .

28

3.4

Caso de Uso Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.5

Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.6

Modelo de Espaço Navegacional . . . . . . . . . . . . . . . . . . . . . .

32

3.7

Modelo de Estrutura Navegacional - Visão Administrador - Parte A . . . .

34


Sistema Web para Controle de Processos Acadêmicos

3.8

Modelo de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.9

Diagrama Entidade-Relacionamento . . . . . . . . . . . . . . . . . . . .

37

4.1

Modelo de Aplicação J2EE (fonte: http://java.sun.com/j2ee/appmodel.html) .

40

4.2

Java Server Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.3

API Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.4

Comparativo PostgreSQL X Outros SGBD (fonte:www.cgk.com.br) . . . .

46

5.1

Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.2

Tela Principal - Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.3

Módulo Controle de Usuários- Menu . . . . . . . . . . . . . . . . . . . .

52

5.4

Controle de Tipos de Usuários . . . . . . . . . . . . . . . . . . . . . . .

53

5.5

Módulo Controle de Assuntos - Cadastro de Assuntos . . . . . . . . . . .

54

5.6

Módulo Controle de Departamentos - Menu . . . . . . . . . . . . . . . .

55

5.7

Áreas Cadastradas - Atualização . . . . . . . . . . . . . . . . . . . . . .

56

5.8

Área Selecionada - Atualização . . . . . . . . . . . . . . . . . . . . . . .

57

5.9

Módulo Controle de Departamentos - Cadastro de Departamentos . . . .

58

5.10 Módulo Controle de Departamentos - Atualização de Departamentos . . .

59

5.11 Módulo Controle de Despachos - Cadastro de Despachos . . . . . . . . .

60

5.12 Tela de Confirmação de Exclusão de Despachos . . . . . . . . . . . . . .

61

5.13 Informação mostrada conforme operação realizada . . . . . . . . . . . .

61

5.14 Módulo Controle de Processos - Menu . . . . . . . . . . . . . . . . . . .

62

5.15 Módulo Controle de Processos - Cadastro de Processos . . . . . . . . . .

64

5.16 Módulo Controle de Processos - Exclusão de Processos . . . . . . . . . .

65

5.17 Módulo Controle de Status Processos - Menu . . . . . . . . . . . . . . .

66

5.18 Módulo Controle de Status Processos - Enviar Processo . . . . . . . . . .

67

5.19 Módulo Controle de Status Processos - Receber Processo . . . . . . . . .

68

5.20 Módulo Controle de Status Processos - Atualizar Status . . . . . . . . . .

69

5.21 Atualizar Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

UNESP/FEG-CEIE, 2006

x


Sistema Web para Controle de Processos Acadêmicos

A.1 Caso de Uso - Controle de Usuários . . . . . . . . . . . . . . . . . . . .

77

A.2 Caso de Uso - Controle de Áreas . . . . . . . . . . . . . . . . . . . . . .

78

A.3 Caso de Uso - Controle de Departamentos . . . . . . . . . . . . . . . . .

78

A.4 Caso de Uso - Controle de Despachos . . . . . . . . . . . . . . . . . . .

79

A.5 Caso de Uso - Controle de Processos . . . . . . . . . . . . . . . . . . . .

79

C.1 Estrutura de Navegação - Visão Administrador - Parte B . . . . . . . . . 101 C.2 Estrutura de Navegação - Visão Administrador - Parte C . . . . . . . . . 102 C.3 Estrutura de Navegação - Visão Funcionário - Parte A . . . . . . . . . . . 103 C.4 Estrutura de Navegação - Visão Funcionário - Parte B . . . . . . . . . . . 104 C.5 Estrutura de Navegação - Visão Funcionário - Parte C . . . . . . . . . . . 105 D.1 Modelo de Apresentação - Menu Assuntos . . . . . . . . . . . . . . . . . 107 D.2 Modelo de Apresentação - Menu Departamentos . . . . . . . . . . . . . 108 D.3 Modelo de Apresentação - Menu Despachos . . . . . . . . . . . . . . . . 108 D.4 Modelo de Apresentação - Menu Processos . . . . . . . . . . . . . . . . 109 D.5 Modelo de Apresentação - Menu Status Processos . . . . . . . . . . . . . 109 D.6 Modelo de Apresentação - Menu Usuários . . . . . . . . . . . . . . . . . 110 E.1 Diagrama de Seqüência - Incluir Usuário . . . . . . . . . . . . . . . . . . 111 E.2 Diagrama de Seqüência - Alterar Usuário . . . . . . . . . . . . . . . . . 112 E.3 Diagrama de Seqüência - Excluir Usuário . . . . . . . . . . . . . . . . . 113 E.4 Diagrama de Seqüência - Incluir Assunto . . . . . . . . . . . . . . . . . 114 E.5 Diagrama de Seqüência - Alterar Assunto . . . . . . . . . . . . . . . . . 115 E.6 Diagrama de Seqüência - Excluir Assunto . . . . . . . . . . . . . . . . . 116 E.7 Diagrama de Seqüência - Incluir Area . . . . . . . . . . . . . . . . . . . 117 E.8 Diagrama de Seqüência - Alterar Area . . . . . . . . . . . . . . . . . . . 118 E.9 Diagrama de Seqüência - Excluir Area . . . . . . . . . . . . . . . . . . . 119 E.10 Diagrama de Seqüência - Incluir Departamento . . . . . . . . . . . . . . 120 E.11 Diagrama de Seqüência - Alterar Departamento . . . . . . . . . . . . . . 121 UNESP/FEG-CEIE, 2006

xi


Sistema Web para Controle de Processos Acadêmicos

E.12 Diagrama de Seqüência - Excluir Departamento . . . . . . . . . . . . . . 122 E.13 Diagrama de Seqüência - Incluir Despacho . . . . . . . . . . . . . . . . . 123 E.14 Diagrama de Seqüência - Alterar Despacho . . . . . . . . . . . . . . . . 124 E.15 Diagrama de Seqüência - Excluir Despacho . . . . . . . . . . . . . . . . 125 E.16 Diagrama de Seqüência - Incluir Processo . . . . . . . . . . . . . . . . . 126 E.17 Diagrama de Seqüência - Alterar Processo . . . . . . . . . . . . . . . . . 127 E.18 Diagrama de Seqüência - Excluir Processo . . . . . . . . . . . . . . . . . 128 E.19 Diagrama de Seqüência - Enviar Processo . . . . . . . . . . . . . . . . . 129 E.20 Diagrama de Seqüência - Receber Processo . . . . . . . . . . . . . . . . 129 E.21 Diagrama de Seqüência - Atualizar Status Processo . . . . . . . . . . . . 130 E.22 Diagrama de Seqüência - Consultar Status Processo . . . . . . . . . . . . 130 F.1

Dicionário de Dados - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . 131

F.2

Dicionário de Dados - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . 132

UNESP/FEG-CEIE, 2006

xii


Sistema Web para Controle de Processos Acadêmicos

Blanco, Jaqueline. - Sistema Web para Controle de Processos Acadêmicos. Guaratinguetá, 2006. 166p. - Monografia (Especialização em Informática Empresarial) - Faculdade de Engenharia de Guaratinguetá, Universidade Estadual Paulista.

Resumo

Este trabalho pretende mostrar os benefícios da modelagem de sistemas, utilizando a Linguagem de Modelagem Unificada - UML e como empregá-la no desenvolvimento de um sistema de Controle de Processos Acadêmicos, tendo como estudo de caso a Universidade de Taubaté. Algumas funcionalidades serão apresentadas utilizando JSP, para que o sistema possa ser usado na Intranet.

Palavras-Chave: UML, UWE, JSP, Intranet.

UNESP/FEG-CEIE, 2006

xiii


Sistema Web para Controle de Processos Acadêmicos

Blanco, Jaqueline. - Web system for Control of Academic Processes. Guaratinguetá, 2006. 166p. - Monografia (Especialização em Informática Empresarial) - Faculdade de Engenharia de Guaratinguetá, Universidade Estadual Paulista.

Abstract

This work intends to show the benefits of modeling systems, using the Unified Modeling Language - UML and as to use it in the development of a system for Control of Academic Processes, having as case study the University of Taubaté. Some functionalities will be presented using JSP, so that the system can be used in the Intranet.

Key Words: UML, UWE, JSP, Intranet.

UNESP/FEG-CEIE, 2006

xiv


Capítulo 1 Introdução A constante evolução da Tecnologia da Informação tem aumentado a possibilidade de utilização da Informática em qualquer estrutura organizacional e isto tem se tornado um fator chave para a descentralização de atividades. Atualmente as organizações devem atingir seus objetivos a custos baixos, com rapidez e qualidade, para permanecerem competitivas. Um dos recursos para se conseguir atingir tais objetivos é a utilização de Intranets e de demais recursos da Internet. A Intranet pode ser definida como um sistema de distribuição de informações que usa ferramentas e tecnologias da Internet dentro de uma corporação. Desta forma, a Intranet torna-se uma ferramenta eficaz para combater o desperdício de tempo, esforço e materiais dentro de uma organização e, ao mesmo tempo, pode gerar novas oportunidades para colaboração e produtividade pessoal. Como nos dias atuais a informação assume uma importância crescente, é necessário que o desenvolvimento de sistemas acompanhe a mutação constante das informações. Para isso, as aplicações devem ser mais flexíveis e com menor taxa de manutenção, e para que isso seja alcançado, é imprescindível a utilização de metodologias e ferramentas para o desenvolvimento de aplicações. O uso de uma linguagem padrão, como a UML (Unified Modeling Language) [OMG - UML1 2005], para especificar, visualizar, construir e documentar os artefatos de um sistema de software é um passo nesta direção. A utilização de UML é muito comum em sistemas orientados a objetos. Neste trabalho serão apresentados conceitos básicos sobre Modelagem de Sistemas


Sistema Web para Controle de Processos Acadêmicos

Orientados a Objetos e UML, e como empregá-los no desenvolvimento de um sistema de Controle de Processos Acadêmicos, tendo como estudo de caso a Universidade de Taubaté. Além disso será proposto um novo sistema utilizando a linguagem JSP (Java Server Pages) [Sun - JSP 2005], que se baseia na tecnologia JAVA e permite o desenvolvimento e processamento de sites dinâmicos.

1.1 Breve Descrição do Sistema Atual O Sistema de Controle de Processos, atualmente utilizado na Universidade de Taubaté (UNITAU), encontra-se em apenas dois setores da Universidade. Foi desenvolvido na linguagem Clipper [VIDAL 1995] e hoje não atende aos demais setores e departamentos por questões de instabilidade da linguagem quando utilizada em rede e pela falta de segurança no armazenamento das informações, pois existe o risco de corrupção dos dados. Embora o Clipper tenha sido uma das ferramentas mais populares no desenvolvimento de sistemas, é inegável que hoje esta ferramenta, quando utilizada em ambiente corporativo, apresenta diversos problemas, entre os quais pode-se citar:

• Índices corrompidos e reorganização freqüente de índices; • Baixa performance em rede; • Inconsistências no acesso multiusuário; • Utilização de tecnologias antigas de banco de dados.

A proposta de construção de um novo sistema, baseado no ambiente Web, vem justamente no sentido de evitar os problemas citados e aproveitar a Intranet, que já está disponibilizada a todos os setores e departamentos da UNITAU. Além disto, pretende-se propor o uso de um banco de dados livre, como o PostgreSQL [PostgreSQL 2005], para que a nova implementação seja de baixo custo. Os benefícios de um sistema Web de Controle de Processos Acadêmicos serão o controle mais efetivo da localização dos processos e a diminuição de papéis circulando na Universidade. UNESP/FEG-CEIE, 2006

2


Sistema Web para Controle de Processos Acadêmicos

1.2 Objetivos do Trabalho Este trabalho tem como objetivo mostrar a utilização da UML para o desenvolvimento de sistemas, tomando como estudo de caso, o sistema de Controle de Processos Acadêmicos da Universidade de Taubaté e a aplicação desta metodologia no desenvolvimento do sistema Web para controle de tais processos.

1.2.1 Objetivos Específicos • Ilustrar como utilizar a UML para modelar aplicações Web; • Ilustrar o funcionamento do sistema de Controle de Processos Acadêmicos, através de modelagem UWE (UML-based Web Engineering); • Ilustrar como utilizar JSP para desenvolver aplicações Web.

1.3 Organização do Documento Este trabalho está organizado da seguinte forma: O Capítulo 2 apresenta os conceitos de Modelagem Orientada a Objeto, as características da Linguagem de Modelagem UML e a utilização da UML em aplicações Web. No Capítulo 3 é apresentada a modelagem do sistema de Controle de Processos Acadêmicos, bem como a ferramenta JUDE, sugerida e utilizada no processo de modelagem. O Capítulo 4 apresenta a ferramenta JSP para criação de aplicações Web, com suas características. No Capítulo 5 serão apresentadas as funcionalidades do sistema desenvolvido, bem como será feita a descrição das páginas que compõem o sistema de Controle de Processos Acadêmicos, mais especificamente o módulo de Controle de Processos. O Capítulo 6 apresenta as considerações finais deste trabalho e observações sobre os assuntos abordados, bem como sugestões de trabalhos futuros.

UNESP/FEG-CEIE, 2006

3


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

4


Capítulo 2 Modelagem Orientada a Objetos 2.1 Breve Descrição de Orientação a Objetos Nos dias atuais as questões relativas ao tempo e custo do desenvolvimento, tecnologias utilizadas e ferramentas de apoio são decisivas para o desenvolvimento de sistemas. A aplicação de boas práticas, estabelecidas pela Engenharia de Software, possibilita a construção de sistemas com um menor custo, mais confiáveis e com boa qualidade. A Orientação a Objeto é uma prática adotada pelas empresas atuais de desenvolvimento de software. O uso de objetos permite a utilização de abstrações mais naturais e próximas dos problemas reais, facilitando o mapeamento das soluções em modelos e implementações computacionais. Segundo [SOMMERVILLE 2003]:

• A orientação a objetos é uma tecnologia para a produção de modelos que especifiquem o domínio do problema de um sistema;

• Quando construídos corretamente, sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e provêm a oportunidade de criar e implementar componentes totalmente reutilizáveis;

• Modelos orientados a objetos são implementados convenientemente utilizando uma linguagem de programação orientada a objetos, por exemplo, Java e C++;


Sistema Web para Controle de Processos Acadêmicos

• A orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovadas, usada em inúmeros projetos e para construção de diferentes tipos de sistemas.

2.1.1 Conceitos Básicos Objeto: Consiste na junção de atributos e métodos, ou seja, engloba o "estado" e o "comportamento" dos dados em uma única entidade (física, conceitual ou de software).

Atributos são dados que caracterizam o objeto.

Métodos são procedimentos que manipulam tais dados, ou melhor, operações que o objeto pode executar.

Como exemplo, para um objeto Empregado, poderíamos ter como atributos, nome e salário e como método, calcular-salário.

O objeto, por si só, consiste em uma particularização de uma classe, podendo ser chamado de instância de uma classe.

Classe: Conjunto de objetos que possuem as mesmas propriedades (atributos) e o mesmo comportamento (métodos). Como exemplo, poderíamos citar a classe Funcionários.

As classes são organizadas hierarquicamente, ou seja, uma super-classe pode possuir uma ou mais sub-classes, sendo estas criadas por possuírem propriedades particulares, como mostra a Figura 2.1, onde veículo é uma super-classe e automóvel e caminhão são sub-classes desta super-classe.

Generalização: processo de criação de super-classes.

Especialização: processo de criação de sub-classes. UNESP/FEG-CEIE, 2006

6


Sistema Web para Controle de Processos Acadêmicos

Figura 2.1: Exemplo de Classe / Sub-classe

Mensagens: Representam a comunicação entre o usuário e um objeto ou entre objetos, sendo que para cada mensagem recebida por um objeto existe um método que realiza o tratamento apropriado. Encapsulamento: técnica de ocultamento de informações, ou seja, um objeto omite informações sobre si mesmo de outros objetos, omite os detalhes de sua implementação, garantindo a integridade e a consistência dos dados, permitindo pequenas mudanças sem afetar as aplicações que utilizam tal objeto. "A chave para o encapsulamento é o conceito de interface. Interfaces definem que a comunicação com o objeto se dá através de métodos pré-definidos, com os dados do objeto sendo acessíveis unicamente através destes métodos." [FREIRE 2005] Polimorfismo: "Permite que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam. Assim, um mesmo método pode apresentar várias formas, de acordo com seu contexto. O polimorfismo é importante pois permite que a semântica de uma interface seja efetivamente separada da implementação que a representa." [Wikipedia 2006] Herança: Capacidade de uma nova classe compartilhar os atributos e métodos, baseados em um relacionamento, de uma classe já existente, ou seja, a sub-classe herda os atributos de sua super-classe. Na super-classe ficam todos os atributos e métodos que são comuns as diversas sub-classes, e qualquer alteração na super-classe reflete automaticamente nas sub-classes.

UNESP/FEG-CEIE, 2006

7


Sistema Web para Controle de Processos Acadêmicos

Segundo [PRESSMAN 2002], para entender o ponto de vista orientado a objetos, basta tomar como exemplo, do mundo real, uma cadeira, esta é uma instância de uma classe muito mais ampla de objetos que chamamos de mobiliário. A cadeira, sendo membro de mobiliário, herda todos os atributos, como custo, dimensões, peso, localização, cor, entre outros, definidos para a classe. Todo o objeto da classe mobiliário pode ser manipulado de diversos modos. Pode ser comprado e vendido, fisicamente modificado, ou movido de um lugar para o outro. Cada uma dessas operações (métodos) vai modificar um ou mais atributos do objeto. O objeto cadeira, e todos os objetos em geral, encapsula dados (os valores de atributos de cadeira), outros objetos, constantes (valores estabelecidos), e outras informações relacionadas.

2.1.2 Tipos de Metodologias Orientadas a Objetos Dentre todas as metodologias orientadas a objeto existentes, três se destacaram por serem as principais que deram origem a notação UML. Apresenta-se, a seguir, uma breve descrição de cada uma delas:

2.1.2.1 Booch Criada por Grady Booch, a metodologia de Booch [BOOCH 1994] descreve um objeto como sendo um modelo do mundo real, que consiste de dados e habilidades para o seu tratamento. A modelagem Booch inclui a identificação e a semântica de classes e objetos e define relacionamentos entre eles. Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas. A metodologia de Booch trazia uma simbologia complexa de ser desenhada a mão, continha também o processo pelo qual sistemas são analisados por macro e micro visões. O projeto orientado a objeto é organizado via abstrações algorítmicas, de forma parecida à programação orientada a objeto. UNESP/FEG-CEIE, 2006

8


Sistema Web para Controle de Processos Acadêmicos

2.1.2.2 OMT (Object Modeling Technique | Técnica de Modelagem de Objetos) Criado por Rumbaugh, a metodologia OMT [RUMBAUGH 1991] é baseada na modelagem semântica de dados, ou seja, cobre as diversas fases do desenvolvimento orientado a objeto. Essa metodologia é parecida com a das metodologias estruturadas e utiliza a notação de modelo de objeto que suporta conceitos de modelagem de dados, objetos e herança. Também é empregado para categorizar classes e instâncias. O ponto forte desta metodologia é a notação utilizada e o enfoque relativamente conservador no uso da teoria de objetos. Por outro lado, um problema apresentado é a falta de notação específica para representar a passagem de mensagem de um objeto a outro.

2.1.2.3 OOSE (Object-Oriented Software Engineering) A metodologia OOSE, [JACOBSON 1992] foi criado por Jacobson e o que o diferencia das outras metodologias orientadas a objeto é o seu foco em casos de uso e a categorização de pessoas e equipamentos dependendo de seu papel no sistema global. É baseado em modelos de requerimentos e análise que consistem de um conjunto de casos de uso, de um modelo de domínio de problema e de uma descrição da interface do sistema. Na seção seguinte, será apresentada a UML propriamente dita, bem como todo o processo que a originou, conceitos envolvidos e principais aplicações.

2.2 UML (Unified Modeling Language) A UML [OMG - UML1 2005] é uma tentativa de padronizar a modelagem orientada a objetos, de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistência, facilidade de comunicação com outras aplicações, simplicidade de atualização e compreensibilidade. A UML tem origem na compilação das melhores práticas de engenharia que provaram ter sucesso na modelagem de sistemas grandes e complexos, ou seja, Grady Booch, James Rumbaugh e Ivar Jacobson combinaram as melhores características de suas metodologias individuais, de análise e projeto orientados a objetos, em uma metodologia unificada, a Linguagem de Modelagem Unificada - UML. UNESP/FEG-CEIE, 2006

9


Sistema Web para Controle de Processos Acadêmicos

Conforme [FREIRE 2005], pode-se dizer que a UML combina o melhor de: • Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento); • Modelagem Comercial (work flow); • Modelagem Orientada a Objetos; • Modelagem por Componentes. A versão 1.0 da UML foi publicada em 13 Jan.1997, e adotada como padrão pela OMG (Object Management Group - http://www.omg.org) no mesmo ano. UML é a linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema, e podendo ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação. Pode ser usada para: a. Mostrar as fronteiras de um sistema e suas funções principais utilizando atores e casos de utilização; b. Ilustrar a realização de casos de utilização com Diagramas de Interação; c. Representar uma estrutura estática de um sistema utilizando Diagramas de Classe; d. Modelar o comportamento de objetos com Diagramas de Transição de Estado; e. Revelar a arquitetura de implementação física com Diagrama de Componentes e de Implantação; f. Estender sua funcionalidade através de estereótipos. Um estereótipo é um mecanismo que possibilita que a UML seja extendida, ou seja, seu uso permite que sejam definidos elementos de modelagem não previstos na UML Atualmente, a UML encontra-se na versão 2.0 [OMG - UML2 2006]. A grande inovação do UML 2.0, em relação à versão anterior, está na implementação da Model Driven Architecture (MDA). A MDA é uma nova maneira de escrever especificações e de desenvolver aplicações, baseado em modelos independentes da plataforma, tendo como objetivos a portabilidade, interoperabilidade e reutilização. Conforme [Xpdian.com 2006], os novos diagramas da UML2.0 são: UNESP/FEG-CEIE, 2006

10


Sistema Web para Controle de Processos Acadêmicos

• Diagrama de Estrutura de Composições - descreve a estrutura interna de uma classe, componente ou caso de uso, incluindo os pontos de interação destes com outras partes do sistema; • Diagrama Temporal - Descreve as mudanças de um estado ou condição de um objeto ao longo do tempo, através de uma barra de tempo; • Diagrama de Vista Geral de Interação - fornece uma visão geral do fluxo de controle dentro de um processo de sistema ou de negócio. Na Seção 2.2.5 apresenta-se os demais diagramas utilizados na UML.

2.2.1 Fases do Desenvolvimento de um Sistema em UML A Figura 2.2, ilustra as diversas etapas do desenvolvimento de sistemas.

Figura 2.2: Etapas do desenvolvimento de sistemas

UNESP/FEG-CEIE, 2006

11


Sistema Web para Controle de Processos Acadêmicos

A seguir descreve-se, resumidamente, as etapas, apresentadas na figura acima, do desenvolvimento de sistemas, utilizando a UML. I. Análise de Requisitos: nesta fase, buscam-se as intenções e necessidades do usuário do sistema a ser desenvolvido com a utilização de funções chamadas de casos de uso (use-cases). Através do desenvolvimento de casos de uso, as entidades externas ao sistema (em UML chamadas de "atores") são modeladas, identificando as interações existentes. Cada caso de uso modelado é descrito através de um texto, e este especifica os requerimentos do ator externo que utilizará este caso de uso. O diagrama de caso de uso mostrará o que os atores externos, ou seja, os usuários do futuro sistema, deverão esperar do aplicativo, conhecendo toda sua funcionalidade, sem se importarem sobre como esta será implementada. II. Análise: a fase de análise está preocupada com as primeiras abstrações

1

(classes

e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas através de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colaborações entre classes também são mostradas neste diagrama para desenvolver os casos de uso modelados anteriormente. Estas colaborações são criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software. III. Concepção (Projeto): na fase de concepção, o resultado da análise é expandido em uma solução técnica. Novas classes serão adicionadas para prover uma infraestrutura técnica: interface do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros. O projeto resulta no detalhamento das especificações para a fase de programação do sistema. IV. Programação: na fase de programação, as classes provenientes do projeto são convertidas para o código da linguagem orientada a objetos escolhida (a utilização de linguagens não orientada a objetos não é, em nenhuma hipótese, recomendada). Dependendo das características da linguagem usada, essa conversão pode ser uma 1

Abstração: consiste nas características essenciais de um objeto que o distinguem de todos os outros objetos, ou seja, é uma forma de definição onde o ente (coisa, ser, substância, aquilo que existe ou supomos existir) é definido pelas propriedades que o caracterizam

UNESP/FEG-CEIE, 2006

12


Sistema Web para Controle de Processos Acadêmicos

tarefa fácil ou muito complicada. Nas fases anteriores, os modelos criados significam o entendimento e a estrutura do sistema. Assim, no momento da geração do código se o analista concluir antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. A programação é uma fase separada e distinta onde os modelos criados são convertidos em código. V. Testes: a fase de testes é onde os conceitos abstratos são colocados à prova. O processo pode ser subdividido em testes de unidade, integração e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos. Os testes de aceitação observam o sistema como uma "caixa preta" e verificam se o sistema está funcionando como o especificado nos diagramas de casos de uso. O sistema será testado pelo usuário final e este verificará se os resultados mostrados estão realmente de acordo com as suas intenções.

2.2.2 Os Componentes da UML As fases de análise de requisitos, análise e projeto utilizam em seu desenvolvimento cinco tipos de visões, vários tipos de diagramas e vários modelos de elementos, que serão utilizados na criação dos diagramas e mecanismos gerais. Todos esses diagramas e mecanismos, em conjunto, especificam e exemplificam a definição do sistema, tanto no que diz respeito à funcionalidade estática quanto dinâmica. Conforme [PAGLIOSA 2005], as partes que compõem a UML são: • Visões: mostram os diferentes aspectos do sistema que está sendo modelado. É uma abstração, consistindo de uma série de diagramas. Cada tipo de visão mostrará aspectos particulares do sistema, dando enfoque a ângulos e níveis de abstrações diferentes e possibilitando a construção de uma modelagem completa do sistema. • Modelos de Elementos: os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objeto, tais como classes, UNESP/FEG-CEIE, 2006

13


Sistema Web para Controle de Processos Acadêmicos

objetos, mensagens e relacionamentos entre as classes, incluindo associações, dependências e heranças. • Mecanismos Gerais: provêm comentários suplementares, informações ou semântica sobre os elementos que compõem os modelos. • Diagramas: São os gráficos que descrevem o conteúdo de uma visão.

2.2.3 Visões Um sistema é caracterizado por diversos aspectos: funcional (que é sua estrutura estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento dos módulos de código, etc.). Assim, um sistema é descrito em um certo número de visões, cada uma representando uma projeção da descrição completa e mostrando aspectos particulares do sistema. As visões que compõem um sistema são: • Visão de Casos de Uso: descreve a funcionalidade do sistema desempenhada pelos atores do sistema (usuários). O conteúdo da visão de Casos de Uso é a base para o desenvolvimento das outras visões do sistema. Representada pelos diagramas de casos de uso e eventualmente diagramas de atividades. • Visão Lógica: descreve como a funcionalidade do sistema será implementada. É feita principalmente pelos analistas e desenvolvedores. Observa e estuda o sistema internamente. Descreve e especifica a estrutura estática do sistema (classes, objetos e relacionamentos), através dos diagramas de classes e objetos, e as colaborações dinâmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funções do sistema, através dos diagramas de estado, seqüência, colaboração (ou comunicação) e atividade. Propriedades como persistência e concorrência são definidas nesta fase, bem como as interfaces e as estruturas de classes. • Visão de Componentes: é uma descrição da arquitetura física dos componentes de software, necessários à implementação dos módulos do sistema, e de suas dependências. É executado principalmente por desenvolvedores e consiste no diagrama UNESP/FEG-CEIE, 2006

14


Sistema Web para Controle de Processos Acadêmicos

de componentes. • Visão de Concorrência: trata da divisão do sistema em processos e processadores. Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor utilização do ambiente onde o sistema se encontrará, se o mesmo possuir execuções paralelas, e se existir dentro do sistema um gerenciamento de eventos assíncronos. Uma vez dividido o sistema em linhas de execução de processos concorrentes (threads), esta visão de concorrência deverá mostrar como se dará a comunicação e a concorrência destas threads. A visão de concorrência é suportada pelos diagramas dinâmicos, que são os diagramas de estado, sequência, colaboração (ou comunicação) e atividade e pelos diagramas de implementação e diagramas de componentes.

2.2.4 Modelos de Elementos Os conceitos usados nos diagramas são chamados de modelos de elementos. Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem que elementos podem ser mostrados em que tipos de diagramas. Alguns exemplos de modelos de elementos são as classes, objetos, estados, pacotes e componentes. Os relacionamentos também são modelos de elementos, e são usados para conectar outros modelos de elementos entre si.

• Classes: Em UML as classes são representadas por um retângulo dividido em três compartimentos, contendo o nome da classe, seus atributos e seus métodos, como mostra a Figura 2.3:

Figura 2.3: Representação de Classe em UML

UNESP/FEG-CEIE, 2006

15


Sistema Web para Controle de Processos Acadêmicos

• Objetos: Em UML um objeto é mostrado como uma classe cujo nome (do objeto) é sublinhado. Opcionalmente o nome do objeto pode ser mostrado precedido do nome da classe. Isto está ilustrado na Figura 2.4

Figura 2.4: Representação de Objeto em UML

• Estados: Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e é normalmente determinado pelos valores de seus atributos e ligações com outros objetos. Um objeto muda de estado como consequência de um evento. Através da análise da mudança de estados, de acordo com os eventos que ocorrem, pode-se prever todos os possíveis comportamentos dos objetos de um sistema. • Relacionamentos: Os relacionamentos ligam as classes ou objetos entre si, criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associações: uma associação representa que duas classes possuem uma ligação (link) entre elas, significando por exemplo que elas "conhecem uma à outra" , "estão conectadas com" , "para cada X existe um Y" e assim por diante. Agregação é um caso particular da associação e indica que uma das classes do relacionamento é uma parte ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em" , "contém" e "é parte de" . Uma agregação é representada por uma linha contínua com um losango em uma das extremidades, sendo que esta extremidade está conectada com a classe "todo" , conforme a Figura 2.5, onde a classe Loja contém a classe Departamento. UNESP/FEG-CEIE, 2006

16


Sistema Web para Controle de Processos Acadêmicos

Figura 2.5: Agregação

Generalização: é um relacionamento hierárquico entre classes, também conhecido como herança. É representada por uma linha contínua com uma seta em branco apontando sempre a super-classe, conforme mostra a Figura 2.6.

Figura 2.6: Generalização

O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. A generallização também é conhecida como um relacionamento "é um tipo de" . Dependências e Refinamentos: o relacionamento de dependência é uma conexão semântica entre dois modelos de elementos, um independente e outro dependente. Uma mudança no elemento independente irá afetar o modelo dependente. Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final de um dos lados, dependente, do relacionamento, conforme mostra a Figura 2.7. Sobre essa linha se indica o tipo de dependência que existe entre as duas classes.

Figura 2.7: Dependência

Os refinamentos são um tipo de relacionamento entre duas descrições de uma mesma classe, mas em níveis de abstração diferentes e podem ser usados para modelar diferentes implementações de um mesmo conceito (uma implementação simples e outra mais complexa, mas também mais eficiente). Os refinamentos são simbolizados por uma linha tracejada com um triângulo no final de um dos lados do relacionamento, ou seja, a classe que será refinada. UNESP/FEG-CEIE, 2006

17


Sistema Web para Controle de Processos Acadêmicos

Os tipos de relacionamentos, dependência e refinamento, são ilustrados na Figura 2.8

Figura 2.8: Representação de Dependências e Refinamentos

Pacotes: pacote é um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados e na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes (ver Figura 2.9). Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança). O conceito de pacote tem uma grande similaridade com o de agregação. O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição, desta forma se for destruído, todo seu conteúdo também será.

Figura 2.9: Representação de Pacotes com relacionamentos

UNESP/FEG-CEIE, 2006

18


Sistema Web para Controle de Processos Acadêmicos

Componentes: um componente pode ser tanto um código em linguagem de programação como um código executável já compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class é um componente do sistema. A Figura 2.10 mostra uma representação de componentes.

Figura 2.10: Representação de Componentes

UNESP/FEG-CEIE, 2006

19


Sistema Web para Controle de Processos Acadêmicos

2.2.5 Diagramas Ao fazer a modelagem, simplifica-se a realidade para um melhor entendimento do sistema em desenvolvimento. Diagramas representam diferentes partes do modelo de um sistema e podem, em UML, ser dos seguintes tipos: Diagramas de Casos de Uso, Classes, Objetos, Estados, Seqüência, Colaboração (ou Comunicação), Atividades, Componentes e Implementação, como mostra a Figura 2.11.

Figura 2.11: Tipos de Diagramas - UML 1.5

UML suporta modelos estáticos (estrutura estática), dinâmicos (comportamento dinâmico) e funcionais. A Modelagem Estática é suportada pelos Diagramas de Classes e de Objetos, que consistem nas classes e seus relacionamentos. Os relacionamentos podem ser de associação, generalização (herança), dependência ou refinamento. A Modelagem Dinâmica é suportada pelos Diagramas de Estado, Sequência, Colaboração (ou Comunicação) e Atividades. Já a Modelagem Funcional é suportada pelos Diagramas de Componentes e de Implementação. No próximo capítulo serão detalhados alguns diagramas UML utilizados na modelagem do Sistema de Controle de Processos Acadêmicos. Embora UML seja uma linguagem que pode ser utilizada na descrição de qualquer tipo de sistema, algumas extensões foram e estão sendo propostas para a abordagem de alguns tipos particulares. Entre estas proposições se pode citar a UML-based Web Engineering que pode ser utilizada para a modelagem de Sistemas Web. Esta proposta é detalhada na próxima seção. UNESP/FEG-CEIE, 2006

20


Sistema Web para Controle de Processos Acadêmicos

2.3 UWE (UML-based Web Engineering) A UML-based Web Engineering foi proposta por Koch, Hennicker e Kraus, [KOCH 2002], como uma extensão de UML para a modelagem de Sistemas Web. Nesta proposta, elementos de modelagem, especialmente classes, são estendidos, novas interfaces são definidas e é introduzida uma nova abordagem sobre modelagem de aplicações Web. A UWE é uma extensão conservadora da UML e introduz uma abordagem sobre a modelagem incluindo três modelos, cada um focando um aspecto central das aplicações Web: Modelo Conceitual, Modelo Navegacional e Modelo de Apresentação, conforme pode-se observar na Figura 2.12, onde os modelos são representados como pacotes.

Figura 2.12: Modelos da UWE

A metodologia UWE (UML-based Web Engineering) tem como foco principal a definição de um projeto sistemático, a personalização e a geração semi-automática de aplicações Web. Segundo [KOCH 2001], as características principais da UWE são: • Uma abordagem inteiramente orientada a objeto; • Apresenta modelo de referência visual como apresentado no modelo da UML; • Suporta técnicas de modelagem visual; • Fornece perfil de extensão UML adaptado para aplicações hipermídia; • Define um processo de desenvolvimento que cobre todo o processo de criação de aplicações hipermídia. UNESP/FEG-CEIE, 2006

21


Sistema Web para Controle de Processos Acadêmicos

A metodologia UWE inicia com uma fase de Análise de Requisitos que aborda a identificação de casos de uso. O resultado da análise de requisitos é chamado Modelo de Casos de Uso em UWE. O Modelo de Casos de Uso é utilizado para descrever a funcionalidade da aplicação e a sua interação com os usuários. Os casos de uso são apresentados utilizando Diagramas de Casos de Uso propostos pela UML, sendo escritos em termos de atores, casos de uso e do sistema a ser modelado. Os atores representam o papel de entidades externas, como por exemplo um usuário, um hardware ou até mesmo um outro sistema. Os atores se comunicam com a aplicação através dos casos de uso, que representam uma seqüência de ações a serem executadas, como mostra a Figura 2.13, que demonstra as funções de um ator externo de um sistema de controle bancário de um banco fictício. O diagrama especifica que funções o funcionário do banco poderá desempenhar, sem ter a preocupação com a implementação de cada uma destas funções, já que este diagrama apenas se resume a determinar que funções deverão ser suportadas pelo sistema modelado.

Figura 2.13: Representação de Diagrama de Casos de Uso

O Modelo de Casos de Uso é central, pois seu conteúdo é a base do desenvolvimento de outros diagramas e da implementação da aplicação [CAVALARI 2004]. UNESP/FEG-CEIE, 2006

22


Sistema Web para Controle de Processos Acadêmicos

O objetivo do Modelo Conceitual é construir um modelo do domínio da aplicação levando em conta as exigências observadas nos casos de uso. Nesse modelo, as classes e os objetos participantes do sistema, bem como as relações entre eles, são modelados utilizando-se técnicas tradicionais de orientação a objeto. Segundo [KOCH 2002], o modelo conceitual é representado por um Diagrama de Classes UML, conforme Figura 2.14.

Figura 2.14: Representação de Diagrama de Classes

O Modelo de Navegação de aplicações Web compreende a construção de dois modelos, o Modelo do Espaço de Navegação e o Modelo de Estrutura de Navegação. O Modelo do Espaço de Navegação é baseado no Modelo Conceitual e nos requisitos definidos nos casos de uso. A função desta modelagem é especificar quais classes do Modelo Conceitual serão visíveis ao usuário e quais serão os caminhos para se chegar a essas classes. O Modelo de Estrutura de Navegação é construído a partir do refinamento do espaço de navegação. Neste modelo, são adicionados elementos de acesso como índices, excursões, consultas e menus [KOCH 2001]. O Modelo de Apresentação, segundo [KOCH 2002], é a representação de onde e como os objetos da navegação e os acessos primitivos serão apresentados para o usuário. O projeto da apresentação suporta a transformação do Modelo da Estrutura da Navegação em um conjunto de modelos que mostram o local estático dos objetos visíveis para o usuário, o esquema de representação destes objetos (páginas no projeto da aplicação Web) e dos seus comportamentos dinâmicos. O esquema da representação é similar à técnica de desenvolvimento usada por alguns projetistas de interface. O projeto de apresentação foca UNESP/FEG-CEIE, 2006

23


Sistema Web para Controle de Processos Acadêmicos

a organização estrutural da apresentação, como por exemplo, textos, imagens, formulários e menus e não a aparência física em termos de formatos especiais, cores, etc.

UNESP/FEG-CEIE, 2006

24


Capítulo 3 Modelagem do Sistema de Controle de Processos Acadêmicos Neste capítulo apresenta-se a modelagem realizada, utilizando a UWE e a modelagem dos dados do Sistema de Controle de Processos Acadêmicos.

3.1 Modelagem utilizando UWE 3.1.1 Análise de Requisitos O Processo Acadêmico, no ambiente da Universidade de Taubaté, tem a caracterísitica de ser um documento que contém informações sobre requisições, do tipo Trancamento de Matrícula, Solicitação de Bolsa de Estudos, Prestação de Contas (Adiantamento), Guia de Transferências, entre outras, solicitadas por alunos, pelos próprios funcionários ou professores da Univerisade ou de outras instituições. Tais processos, dependendo do assunto, são encaminhados a outros departamentos ou setores da Universidade, porém atualmente esses processos são impressos, pois o sistema existente não está disponível à todos os departamentos ou setores da Universidade, devido as dificuldades citadas no Capítulo 1 na Seção 1.1. A dificuldade maior está justamente em não se ter um sistema distribuído pela Universidade, o que facilitaria a localização de tais processos, a obtenção de soluções com maior rapidez e ainda possibilitaria o fim da situação de processos perdidos ou extraviados. Desta maneira o desenvolvimento de um sistema, baseado no ambiente Web, aproveitando


Sistema Web para Controle de Processos Acadêmicos

a Intranet já existente na Universidade, facilitará principalmente a localização e a solução dos processos. De acordo com a análise de requisitos o sistema deve fornecer: • Informações sobre o Processo como Assunto, Interessado ou Departamento responsável; • A atual situação do Processo, ou seja, Localização e Status (Aguardando Solução, Deferido, Indeferido ou Arquivado); • Data e Hora das alterações efetuadas em relação ao envio ou recebimento dos processos. Além das consultas, o sistema deve possibilitar a inserção de assuntos, departamentos, processos e demais informações sobre os mesmos, como situação e localização. A ferramenta utilizada na modelagem do sistema foi o JUDE (Java and UML Developer Environment) [Change-Vision 2006], que suporta a modelagem orientada a objeto, através do padrão UML. O JUDE é fornecido em diferentes versões, pagas ou não. A versão gratuita, denominada JUDE Community, cuja interface é apresentada na Figura 3.1, é uma das mais poderosas ferramentas grátis para UML dentre as existentes. Sua performance impressiona, principalmente por se tratar de uma ferramenta que é Java Swing em sua totalidade.

UNESP/FEG-CEIE, 2006

26


Sistema Web para Controle de Processos Acadêmicos

Figura 3.1: JUDE

3.1.2 Modelo de Casos de Uso Conforme descrito na seção 2.3, o Modelo de Casos do Uso, segundo [KOCH 2002], é usado para descrever as exigências funcionais de uma aplicação. Através do Caso de Uso, observa-se que para a utilização do sistema de Controle de Processos Acadêmicos, há dois tipos de atores: o funcionário administrativo e o administrador do sistema. O funcionário administrativo pode realizar somente as funções de inclusão, alterações e consultas de Processos e Status do Processo. A função de exclusão nos módulos Processos e Status dos Processos fica sob a responsabilidade do usuário administrador do sistema. Ao administrador, todas as operações são permitidas, uma vez que cabe a esse ator a função de gerenciar o sistema. Na Figura 3.2, observa-se uma visão geral dos módulos disponíveis aos usuários, na Figura 3.4 são apresentadas todas as funcionalidades do sistema, observa-se que o usuário, após efetuar o login, terá disponível as funcionalidades correspondentes de acordo com o seu tipo, como, por exemplo, se o usuário for do tipo administrador ele poderá executar o caso de uso excluir usuário; e na Figura 3.3 nota-se as funcionalidades, especificamente, UNESP/FEG-CEIE, 2006

27


Sistema Web para Controle de Processos Acadêmicos

no módulo Controle de Assuntos. A descrição e os demais casos de uso, de cada módulo, podem ser encontrados nos Apêndices A e B.

Figura 3.2: Caso de Uso Principal

Figura 3.3: Caso de Uso Controle de Assuntos

UNESP/FEG-CEIE, 2006

28


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 3.4: Caso de Uso Detalhado

UNESP/FEG-CEIE, 2006

29


Sistema Web para Controle de Processos Acadêmicos

3.1.3 Modelo Conceitual A Figura 3.5 demonstra o Diagrama de Classes, utlizado para representar o Modelo Conceitual, do Sistema de Controle de Processos Acadêmicos. As classes que fazem parte do Modelo Conceitual são:

• Tipo Usuário: classe que indentifica os usuários que utilizarão o sistema. Essa classe é dividida em sub-classes, Administrador do Sistema, que possuirá todos os métodos disponíveis, sendo um nível de acesso de maior responsabilidade sobre o sistema, ou Funcionário Administrativo que possuirá alguns métodos disponíveis.

• Usuário: classe associada a classe Tipo usuário, ou seja representa os atributos e métodos dos usuários que utilizarão o sistema.

• Assunto: classe que servirá para representar os tipos de assuntos existentes na elaboração de um Processo.

• Despacho: classe que servirá para representar os tipos de despachos, que serão utilizados para identificar o status dos processos.

• Área: classe que representa as áreas de estudos da universidade, ou seja, área de humanas, biológicas e exatas.

• Departamento: classe associada a classe área, identifica os atributos dos departamentos da universidade.

• Processo: classe que será utilizada pelos usuários para elaboração dos processos, esta classe contém os atributos e métodos representativos do processo acadêmico.

• Status Processo: classe agregada a classe processo, possui os atributos referente ao status do processo.

UNESP/FEG-CEIE, 2006

30


Sistema Web para Controle de Processos Acadêmicos

Como se vê nesta figura, as classes possuem atributos e métodos e cada associação, entre as classes, são nomeadas de acordo com o relacionamento existente. Pode-se observar que a classe Usuário, possui um relacionamento do tipo agregação de composição com a classe Tipo Usuário, que possui, como sub-classes, a classe Funcionário Administrativo e Administrador do Sistema. A classe usuário está associada a classe Departamento, que por sua vez tem um relacionamento do tipo agregação com a classe Area, ou seja, áreas contém departamentos, as classes áreas e departamentos foram modeladas para representar os setores da universidade, que são divididos por áreas de estudos, ou seja, área de humanas, biológicas e exatas e dentro de cada área específica existem os departamentos. Como classe principal pode-se destacar a classe Processo, que está associada a classe Assunto e está agregada a classe Status do Processo, que possui associação com a classe Despacho.

Figura 3.5: Diagrama de Classes

UNESP/FEG-CEIE, 2006

31


Sistema Web para Controle de Processos Acadêmicos

3.1.4 Modelo de Navegação O Modelo de navegação compreende em dois modelos: Modelo de Espaço Navegacional que especifica quais objetos podem ser visitados por navegação através da aplicação (análise). Ele inclui as classes dos objetos e as associações que especificam que objetos podem ser alcançados através da navegação. As classes recebem o estereótipo de Classes de Navegação, ou navigation class. O Modelo de Espaço Navegacional criado para a aplicação é apresentado na Figura 3.6, nesse modelo, as classes de navegação representam as páginas e as associações representam os links, podendo ser observado que as classes Usuários, Departamentos, Assuntos e Despachos serão acessadas através da navegação somente se o usuário for do tipo Administrador do Sistema.

Figura 3.6: Modelo de Espaço Navegacional

UNESP/FEG-CEIE, 2006

32


Sistema Web para Controle de Processos Acadêmicos

Modelo de Estrutura Navegacional que define como estes objetos são alcançados (design). Ele é construído com base no Modelo de Espaço Navegacional e consiste em aumentar o Modelo de Espaço navegacional com índices, guias de navegação, consultas e menus. Parte do Modelo de Estrutura Navegacional criado para o sistema é representado na Figura 3.7, podendo observar o menu com os itens disponíveis, para o usuário do tipo Administrador e o estereótipo query, que indica qual opção selecionada e com classe de navegação terá ligação. No Apêndice C podem ser visualizadas as outras partes do Modelo de Estrutura Navegacional.

UNESP/FEG-CEIE, 2006

33


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 3.7: Modelo de Estrutura Navegacional - VisĂŁo Administrador - Parte A

UNESP/FEG-CEIE, 2006

34


Sistema Web para Controle de Processos Acadêmicos

3.1.5 Modelo de Apresentação

Conforme descrito na seção 2.3, é a representação de onde e como os objetos da navegação e os acessos primitivos serão apresentados para o usuário. A Figura 3.8 mostra o Modelo de Apresentação do Sistema Web de Controle de Processos Acadêmicos, observando que as classes que recebem o nome de presentation class, ou seja classe de apresentação, são as páginas desenvolvidas na aplicação Web. No Apêndice D podem ser visualizadas outras partes do Modelo de Apresentação, de acordo com os Módulos do Sistema.

Figura 3.8: Modelo de Apresentação

UNESP/FEG-CEIE, 2006

35


Sistema Web para Controle de Processos Acadêmicos

3.2 Modelagem de Dados Através da Modelagem de Dados é possível a representação, de forma clara, de toda a base de informações necessárias para um determinado sistema. Nesta seção apresenta-se a modelagem de dados que foi feita para o sistema desenvolvido. Para tanto utiliza-se um Modelo Entidade-Relacionamento (MER), representado pela Figura 3.9. Comparando esse modelo com o modelo conceitual, proposto pela UML e utilizado na UWE, observa-se que as entidades no MER nada mais são do que as classes, com estereótipos entity, do modelo Conceitual. Pode-se ainda observar no MER, que o relacionamento entre DESPACHOS e PROCESSOS é do tipo NxN, pois a cada nova localização do processo, existirá um novo despacho para o processo, ou seja um processo pode ter mais de um despacho e um despacho pode estar em mais de um processo, na verdade o despacho corresponde a situação do processo, ou seja se o processo está DEFERIDO, INDEFERIDO, AGUARDANDO SOLUCAO, AGUARDANDO INTERESSADO ou ARQUIVADO, desta forma centraliza-se em uma única tabela (STATUS-PROCESSOS) toda a situação e localização do processo; além disso é possível perceber o relacionamento ternário entre DESPACHOS, PROCESSOS e USUÁRIOS, onde a cada atualização ou deslocamento do processo poderá ser armazenada as informações de qual usuário está acessando determinado processo, em qual data e hora e qual a situação (despacho) do processo. Este modelo para o Sistema Web de Controle de Processos Acadêmicos foi desenvolvido utilizando a ferramenta DB Designer. [fabFORCE.net 2006] No Apêndice F está disponível o dicionário de dados utilizado no desenvolvimento do sistema.

UNESP/FEG-CEIE, 2006

36


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 3.9: Diagrama Entidade-Relacionamento

UNESP/FEG-CEIE, 2006

37


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

38


Capítulo 4 Tecnologias Utilizadas Neste capítulo faz-se uma apresentação sucinta de todas as tecnologias que foram utilizadas no desenvolvimento do sistema abordado neste trabalho.

4.1 JavaServer Pages - JSP JSP (Java Server Pages) é uma tecnologia para desenvolvimento de aplicações Web. Tem a vantagem da portabilidade de plataforma podendo ser executado em outros Sistemas Operacionais além dos da Microsoft. JSP faz parte da plataforma J2EE (Java 2 Enterprise Edition) [Sun - J2EE 2006] e juntamente com os Java Servlets (c.f. seção 4.2) e Java Beans [Sun - Javabeans 2006] pode ser usada para desenvolver rapidamente aplicações Web eficientes e seguras. A Plataforma J2EE possui várias características, sendo as mais importantes [SANTOS 2005]:

• Conceito de portabilidade "Write Once, Run Anywhere" : permite implementar facilmente a mesma aplicação em várias plataformas; • API JDBC (Java DataBase Connectivity) (c.f. seção 4.4): permite acessar e manipular dados obtidos de qualquer tipo de base de dados a partir da linguagem Java; • Tecnologia CORBA (Common Object Request Broker Architecture) [CORBA 2006]: infraestrutura que permite a interação entre aplicações através de redes.


Sistema Web para Controle de Processos Acadêmicos

Na Figura 4.1 [Sun Microsystems 2006] é apresentado o Modelo de Aplicação J2EE

Figura 4.1: Modelo de Aplicação J2EE (fonte: http://java.sun.com/j2ee/appmodel.html)

O JSP surgiu como uma forma de construir aplicações Web utilizando de forma facilitada a tecnologia Java Servlet. Uma página JSP é um documento baseado em texto no qual são colocadas informações estáticas (tipicamente HTML) juntamente com código Java, através de elementos JSP. Uma página JSP pode portanto ser entendida como uma página HTML na qual são inseridos, utilizando marcadores especiais, código Java. Elementos JSP são marcadores (tags) especiais, presentes no código da página, que determinam como a página vai ser construída. Estes elementos têm seu uso estimulado em substituição aos trechos de código Java, como meio de separar lógica e a apresentação em documentos JSP. Entre as diferentes alternativas existentes para a geração de páginas dinâmicas, utilizando a tecnologia Java, se pode citar: • Páginas JSP que contêm a lógica de aplicação e que geram o conteúdo das páginas; • Servlets que contêm a lógica de aplicação e que também geram o conteúdo das páginas;

UNESP/FEG-CEIE, 2006

40


Sistema Web para Controle de Processos Acadêmicos

• Servlets que contêm a lógica de aplicação e o JSP que geram o conteúdo das páginas. Pode-se utilizar no servlet de entrada uma estrutura de comandos baseada em um Modelo de Comandos, técnica que permite separar melhor a lógica do controle da aplicação. O Servlet funciona como um controlador entre as diferentes páginas JSP, de maneira que as solicitações a aplicação são dirigidas ao servlet e este determina a ações a serem executadas e a página JSP a ser apresentada. As páginas JSP fazem apenas a apresentação dos resultados e o controle do fluxo, através da aplicação, é feito pelo Servlet. Para eliminar a necessidade de que o servlet entenda o relacionamento exato que deve existir entre a página JSP e o objeto de comando deve-se definir uma maneira única para tratar todos os objetos de comando em uma única estrutura de controle, através de uma interface, assim trata-se o string de comando da requisição como um identificador único, a partir do qual o comando a ser executado é identificado e quando a referência exata ao objeto for identificada este é chamado. E para garantir, de algum modo, que as páginas JSP da aplicação sejam chamadas na ordem estabelecida no projeto da aplicação pode-se utilizar a técnica denominada Token de Comandos onde cada página só é executada se dispuser de um token que a autorize a se executar [FREIRE 2005]. A principal diferença entre JSP e Servlets é que uma página JSP, apesar de ser compilada em Java puro (exatamente como um Servlet), aceita linguagens de Scripts e tags HTML em seu conteúdo. Os Servlets não são parte imprescindível de uma implementação JSP, mas sua utilização é obrigatória em qualquer aplicação um pouco mais sofisticada, como acesso a banco de dados. Uma Aplicação Web que empregue a tecnologia JSP ou Servlet necessita que se utilize um Servidor de Aplicações (contêiner) para sua execução. Este servidor armazena as páginas JSP (ou os Servlets) para que quando as mesmas forem requisitadas por um cliente Web, cada página JSP requisitada seja transformada em uma classe Servlet que será então compilada e executada. Caso a solicitação seja para um Servlet ele é simplesmente compilado e executado [MACIEL 2002]. Este mecanismo é exemplificado na Figura 4.2 [COSTA 2005] Nesta figura, os números que representam a ordem de execução, têm o seguinte significado: UNESP/FEG-CEIE, 2006

41


Sistema Web para Controle de Processos Acadêmicos

Figura 4.2: Java Server Pages

1. O computador cliente envia um pedido ao servidor através da página .jsp; 2. O servidor analisa a página .jsp e verifica se tem código Java, se não tiver código Java poderá ser devolvido ao cliente; 3. Gera um servlet .java da página; 4. Compila o servlet .java para um arquivo .class; 5. Executa o arquivo no servidor; 6. Por fim devolve o resultado da execução do Java, englobando também o código html que se encontrava na página base. Conforme citado, tanto Servlets como páginas JSP devem ser executados em um Servidor de Aplicações (ou Contêiner de Aplicações). Um dos servidores mais populares é o Tomcat, disponível no site http://jakarta.Apache.org/tomcat. O Tomcat é o servidor de referência indicado pela Sun para a execução de aplicações Web que envolva servlets e páginas JSP.

UNESP/FEG-CEIE, 2006

42


Sistema Web para Controle de Processos Acadêmicos

4.2 Servlets A tecnologia Java Servlet permite ao desenvolvedor criar classes Java específicas que são executadas em um servidor Web. Os Servlets armazenados no servidor Web são acessados por meio de um modelo requisição-resposta (request-response), normalmente utilizando o protocolo HTTP (HiperText Transfer Protocol) [HTTP 2006]. Um Servlet é baseado na classe HttpServlet [Sun - API 2006] que por sua vez é baseada na classe GenericServlet [Sun - API 2006]. A Figura 4.3 faz uma demonstração da API Servlet [Pinheiro 2004].

Figura 4.3: API Servlet

As facilidades oferecidas por um Servlet são proporcionadas pelos métodos da classe GenericServlet. Entre os métodos existem o doGet e doPost, que são especificamente definidos para tratar requisições com métodos GET e POST respectivamentes. Esses métodos manipulam os objetos request e response com os dados da página [FREIRE 2005]. Para executar Servlets e JSP é preciso implantá-los em um Servidor de Aplicações (ou Container de Aplicações), que é responsável pela delegação de requisição HTTP para os UNESP/FEG-CEIE, 2006

43


Sistema Web para Controle de Processos Acadêmicos

servlets existentes e pelo controle dos servlets. No Tomcat, essas aplicações são mantidas na pasta "webapps/" .

4.2.1 Ciclo de Vida do Servlet O ciclo de vida de um servlet é determinado por três dos métodos definidos na interface Servlet: init(), service() e destroy(). Este ciclo de vida é controlado pelo container, que: I. Carrega a classe na memória, II. Cria uma instância da classe do servlet, III. Inicializa a instância chamando o método init(). Inicialização: • Um Servlet tem que ser inicializado antes de poder responder a algum pedido. • Durante a primeira carga o Servlet recebe informações sobre a configuração do ambiente através do objeto Servlet Config que é passado para o método init(). • O método init() é executado somente uma vez durante a carga do Servlet, até o mesmo ser destruído. • Nesta fase é que se deve inicializar "variáveis globais" e recursos que demandam um alto custo para carregá-los, como, por exemplo, conexões com Banco de Dados. Serviço: • Após a inicialização o Servlet está preparado para receber e responder solicitações. • Através do método service() são gerados os dois objetos básicos dos Servlets o ServletRequest, que contém a solicitação do cliente e o ServletResponse, que contém a resposta do servlet. • Suporta requisições padrões de clientes HTTP (GET, POST, PUT e DELETE). • Despacha cada requisição para o método correspondente (doGet, doPost, doPut e doDelete). UNESP/FEG-CEIE, 2006

44


Sistema Web para Controle de Processos Acadêmicos

Destruição: • Quando ocorre o término da execução ou por "time-out" . • Utilizando o método destroy(), tendo-se o cuidado de dar oportunidade ao servlet salvar ou liberar algum recurso que esteja sendo utilizado. Em linhas gerais, os servlets são ativados por documentos HTML e as respostas são enviadas ao cliente através do protocolo HTTP. O uso do servlet promove a otimização do que é executado no servidor, resultando em melhoras de desempenho na execução de tarefas e no envio de respostas ao cliente

UNESP/FEG-CEIE, 2006

45


Sistema Web para Controle de Processos Acadêmicos

4.3 PostgreSQL O PostgreSQL [PostgreSQL 2005] é um Sistema Gerenciador de Banco de Dados ObjetoRelacional (ORDBMS - Object-Relational Database Management System) de código fonte aberto, desenvolvido para plataformas Linux e Windows. Sua arquitetura foi projetada para se tornar totalmente compatível com o padrão ANSI/ISO SQL [ANSI/ISO 2006]. Dentre suas principais vantagens estão a capacidade de permitir herança entre tabelas, além de prover suporte a qualquer tipo de aplicação, que pode variar desde páginas Web simples até um sistema administrativo completo. Outros benefícios a serem destacados são: o excelente desempenho e suporte a transações e integridade referencial [RIVELO 2004]. A Figura 4.4 [PostgreSQL - CGK 2005] mostra o comparativo do PostgreSQL com os outros Sistemas Gerenciadores de Banco de Dados existentes no mercado.

Figura 4.4: Comparativo PostgreSQL X Outros SGBD (fonte:www.cgk.com.br)

UNESP/FEG-CEIE, 2006

46


Sistema Web para Controle de Processos Acadêmicos

4.4 JDBC (Java DataBase Connectivity) JDBC (Java DataBase Connectivity) é a API Java para comunicação com bancos de dados. O acesso ao banco é através de um driver JDBC, fornecido pelo vendedor do banco de dados ou por outro provedor de serviço. JDBC especifica a interface necessária para se conectar a um banco de dados, executar comandos SQL e queries, e interpretar resultados. Estas interfaces são independentes do banco de dados e da plataforma e "podem ser resumidas em quatro classes principais, a saber: I. java.sql.DriverManager: Gerencia o carregamento de drivers para criar conexões de banco de dados; II. java.sql.Connection: Representa uma conexão de um banco de dados específico; III. java.sql.Statement: Funciona como um container para declaração ou execução de comandos SQL; IV. java.sql.ResultSet: Controla o acesso aos resultados das consultas." [RIVELO 2004] As classes da API JDBC estão no pacote java.sql, que precisa ser importado para que uma classe Java possa fazer uso de alguma classe da API [HARTKE 2002].

UNESP/FEG-CEIE, 2006

47


Sistema Web para Controle de Processos Acadêmicos

4.5 JSP x Tecnologias concorrentes 4.5.1 ASP Uma das diferenças que pode ser fundamental para a escolha entre estas as tecnologias JSP e ASP é que ASP [ASP 2006] é tecnologia proprietária da Microsoft e executa apenas no servidor IIS (Internet Information Server). Além disso, aplicações ASP só podem ser executadas em ambiente Windows e todos os softwares necessários são pagos. JSP, pelo contrário, executa em qualquer plataforma que tenha uma Máquina Virtual Java (JVM - Java Virtual Machine) e um Servidor de Aplicações, como o Servidor de Aplicação Tomcat, do projeto Jakarta. Além disso existem poderosas IDEs (Integrated Development Environment), como o Eclipse Project [ECLIPSE 2005], para o desenvolvimento da aplicação.

4.5.2 PHP PHP [PHP 2006] é uma linguagem de script que deve ser executada no servidor. Foi criada em 1994 como um projeto pessoal de Rasmus Lerdorf. A sintaxe é fortemente baseada em C, mas possui elementos de C++, Java e Perl. Possui suporte à programação Orientada a Objetos por meio de classes e objetos. Possui também suporte extensivo à Banco de dados ODBC (Open Database Connectivity), MySql, Sybase, Oracle e outros. Segundo [OLIVEIRA 2001], a linguagem PHP é mais simples e menos rígida do que o JSP, sendo portanto recomendada no desenvolvimento de pequenas aplicações para Web. No entanto, à medida que passamos para aplicações de maior porte, o uso de PHP não é indicado, uma vez que se faz necessário o uso de linguagens com checagens mais rígidas e com maior suporte a escalabilidade, como é o caso do Java. Tanto PHP como JSP são totalmente portáveis tanto de uma máquina para outra como para outro sistema operacional.

UNESP/FEG-CEIE, 2006

48


Capítulo 5 Funcionamento do Sistema Neste capítulo será descrito o funcionamento do Sistema Web para Controle de Processos Acadêmicos, através da apresentação das diferentes telas que implementam as suas funcionalidades. Para efetuar o Login no sistema (c.f. Figura 5.1), um usuário deve digitar sua matrícula e senha. Os dados serão então verificados e após validação a tela principal do sistema, composta pelo Menu que dá acesso a cada módulo (c.f. Figura 5.2,) será apresentada.


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 5.1: Tela de Login

UNESP/FEG-CEIE, 2006

50


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 5.2: Tela Principal - Menu

UNESP/FEG-CEIE, 2006

51


Sistema Web para Controle de Processos Acadêmicos

5.1 Módulo Controle de Usuários No Módulo Controle de Usuários, o administrador do sistema poderá incluir, alterar ou excluir usuários que poderão utilizar o sistema (c.f. Figura 5.3). Deve-se lembrar que para a inclusão de usuários, a parte de Controle de Tipos de Usuários, conforme se mostrará adiante, já deverá ter sido finalizada, ou seja, os tipos de usuários do sistema já devem ter sido cadastrados.

Figura 5.3: Módulo Controle de Usuários- Menu

UNESP/FEG-CEIE, 2006

52


Sistema Web para Controle de Processos Acadêmicos

A Figura 5.4 apresenta a tela com os tipos de Usuários existentes, para a utilização do sistema.

Figura 5.4: Controle de Tipos de Usuários

UNESP/FEG-CEIE, 2006

53


Sistema Web para Controle de Processos Acadêmicos

5.2 Módulo Controle de Assuntos O módulo Controle de Assuntos será o local para inserção, alteração e exclusão dos assuntos utilizados na elaboração dos processos, lembrando que esses assuntos são definidos pelo administrador do sistema. A Figura 5.5 mostra a tela de cadastro de assuntos, onde Código do assunto é uma sigla de três caracteres, como por exemplo: "VCC" - Verificação de Currículo para Colação de Grau.

Figura 5.5: Módulo Controle de Assuntos - Cadastro de Assuntos

UNESP/FEG-CEIE, 2006

54


Sistema Web para Controle de Processos Acadêmicos

5.3 Módulo Controle de Departamentos O Módulo Controle de Departamentos está dividido em duas partes, como mostra a Figura 5.6. Uma para o Controle de Áreas, que se referem as Pró-Reitorias e às Áreas de ensino da Universidade (Biológicas, Exatas e Humanas) e outra para o Controle de Departamentos, onde é feita a inclusão, alteração ou exclusão dos departamentos e setores existentes na universidade. Para a cadastro de departamentos, as áreas já devem ter sido, anteriormente, cadastradas na opção Inserir Área, que se encontra nesse mesmo módulo.

Figura 5.6: Módulo Controle de Departamentos - Menu

UNESP/FEG-CEIE, 2006

55


Sistema Web para Controle de Processos Acadêmicos

A Figura 5.7 apresenta a tela com as áreas já cadastradas. Através desta tela se pode selecionar uma delas para alteração. Vale a pena ressaltar que na alteração, o campo chave não pode ser modificado, como mostra a Figura 5.8.

Figura 5.7: Áreas Cadastradas - Atualização

UNESP/FEG-CEIE, 2006

56


Sistema Web para Controle de Processos Acadêmicos

Figura 5.8: Área Selecionada - Atualização

UNESP/FEG-CEIE, 2006

57


Sistema Web para Controle de Processos Acadêmicos

Na Figura 5.9 observa-se a tela que é utilizada para o cadastro de departamentos enquanto que na Figura 5.10 apresenta-se a tela de atualização de um departamento selecionado.

Figura 5.9: Módulo Controle de Departamentos - Cadastro de Departamentos

UNESP/FEG-CEIE, 2006

58


Sistema Web para Controle de Processos Acadêmicos

Figura 5.10: Módulo Controle de Departamentos - Atualização de Departamentos

UNESP/FEG-CEIE, 2006

59


Sistema Web para Controle de Processos Acadêmicos

5.4 Módulo Controle de Despachos O Módulo de Controle de Despachos faz o controle dos tipos de despachos utilizados nos processos. A Figura 5.11 apresenta a tela de cadastro de despachos, onde o Código é uma sigla, de dois caracteres, da situação em que o processo pode estar, por exemplo "AS" Aguardando Solução.

Figura 5.11: Módulo Controle de Despachos - Cadastro de Despachos

O processo de exclusão de um despacho é parecido com o processo de atualização. Para a exclusão serão apresentados os despachos já cadastrados para seleção. Após a seleção, os dados serão recuperados para confirmação da exclusão, conforme apresentado na Figura 5.12. A cada operação realizada a informação é indicada na parte inferior da tela do menu, como é destacado na Figura 5.13. Este exemplo mostra que a operação de exclusão foi cancelada.

UNESP/FEG-CEIE, 2006

60


Sistema Web para Controle de Processos Acadêmicos

Figura 5.12: Tela de Confirmação de Exclusão de Despachos

Figura 5.13: Informação mostrada conforme operação realizada

UNESP/FEG-CEIE, 2006

61


Sistema Web para Controle de Processos Acadêmicos

5.5 Módulo Controle de Processos Após a conclusão dos cadastros de assuntos, departamentos e despachos, o módulo Controle de Processos poderá ser executado. O Módulo Controle de Processos permite que se faça a inclusão, alteração e exclusão de processos, como mostra a Figura 5.14.

Figura 5.14: Módulo Controle de Processos - Menu

UNESP/FEG-CEIE, 2006

62


Sistema Web para Controle de Processos Acadêmicos

Na Figura 5.15 pode-se observar a tela de cadastro de processos, onde a Sigla do Departamento é correspondente ao local onde o processo está sendo originado. No campo Departamento Origem é indicado o código numérico do departamento, já cadastrado no Módulo Controle de Departamentos enquanto o Código Assunto indica o código existente no Módulo Controle de Assuntos. A Data é informada automaticamente, podendo ser alterada conforme o caso. Ao suprimir um processo, toda a movimentação, que tenha sido efetuada através do Módulo Controle de Status dos Processos, será também excluída, como mostra a Figura 5.16.

UNESP/FEG-CEIE, 2006

63


Sistema Web para Controle de Processos Acad锚micos

Figura 5.15: M贸dulo Controle de Processos - Cadastro de Processos

UNESP/FEG-CEIE, 2006

64


Sistema Web para Controle de Processos Acadêmicos

Figura 5.16: Módulo Controle de Processos - Exclusão de Processos

5.6 Módulo Controle de Status dos Processos Após a conclusão do cadastro dos Processos, o Módulo Controle de Status dos Processos poderá ser executado. O Módulo Controle de Status dos Processos oferece funcionalidades para o envio e recebimento de processos, para atualização do status e para exclusão de status e localização dos processos como mostra a Figura 5.17. As Figuras 5.18 e 5.19 apresentam as telas referentes ao Envio e Recebimento de Processos. A partir destas telas se pode controlar a localização destes processos. O Código Despacho refere-se a atual situação do processo, sendo que essa situação poderá mudar conforme o trâmite do processo.

UNESP/FEG-CEIE, 2006

65


Sistema Web para Controle de Processos Acadêmicos

Figura 5.17: Módulo Controle de Status Processos - Menu

Na atualização do Status de um processo, ao selecionar determinado processo (c.f. Figura 5.20) os únicos campos que poderão ser alterados são o Nome do Responsável, o Código do Despacho e a Descrição do Despacho, como mostra a Figura 5.21.

UNESP/FEG-CEIE, 2006

66


Sistema Web para Controle de Processos Acad锚micos

Figura 5.18: M贸dulo Controle de Status Processos - Enviar Processo

UNESP/FEG-CEIE, 2006

67


Sistema Web para Controle de Processos Acad锚micos

Figura 5.19: M贸dulo Controle de Status Processos - Receber Processo

UNESP/FEG-CEIE, 2006

68


Sistema Web para Controle de Processos Acad锚micos

Figura 5.20: M贸dulo Controle de Status Processos - Atualizar Status

UNESP/FEG-CEIE, 2006

69


Sistema Web para Controle de Processos AcadĂŞmicos

Figura 5.21: Atualizar Status

UNESP/FEG-CEIE, 2006

70


Capítulo 6 Conclusão 6.1 Considerações Finais Neste trabalho foram apresentados conceitos básicos sobre Modelagem de Sistemas Orientados a Objetos e UML e como empregá-los no desenvolvimento de um sistema de Controle de Processos Acadêmicos, tendo como estudo de caso a Universidade de Taubaté. Através da modelagem UWE UML-based Web Engineering foram aplicados conceitos da UML voltados para o desenvolvimento de aplicações Web, iniciando pela análise de requisitos estendendo-se até o modelo de apresentação das classes aos usuários. No que diz respeito ao desenvolvimento da aplicação, utilizando as tecnologias JSP e Servlet, observa-se que a aplicação, na arquitetura J2EE, utilizando browsers como interfaces de apresentação, pode-se ter uma lógica de apresentação rica e a geração dinâmica de conteúdo HTML. Existe a vantagem da portabilidade de plataforma, podendo ser executado em outros Sistemas Operacionais além dos da Microsoft e permitir acesso nativo aos mais diversos bancos de dados, graças a tecnologia JDBC, acesso a arquivos texto, a captação de informações a partir de formulários, a captação de informações sobre o visitante e sobre o servidor entre diversas outras coisas. Uma vez terminada a implementação do sistema, pôde-se notar a importância da modelagem no desenvolvimento de uma aplicação Web, pois além de servir como base para construção do sistema, a documentação gerada facilita a manutenção ou modificação do código do sistema.


Sistema Web para Controle de Processos Acadêmicos

6.2 Oportunidades futuras Como extensão ao trabalho realizado, seria interessante abordar os frameworks atualmente disponíveis para a criação das aplicações Web, que usam o padrão MVC (Model-ViewController), como o Struts ou JSF (JavaServer Faces), as novidades da UML 2.0 ou outras extensões da UML para modelagem de sistemas Web. Considerando a possibilidade do Sistema de Controle de Processos tornar-se uma ferramenta administrativa, algumas melhorias devem ser implementadas, como tratamento dos erros, emissão de relatórios ou criação de arquivo ".pdf" com as informações e localizações dos processos, ou ainda disponibilizar na aplicação o controle de outros tipos de documentos, não somente processos, trazendo ao usuário o layout específico, com as informações correspondentes ao tipo de documento que estará sendo cadastrado.

UNESP/FEG-CEIE, 2006

72


Referências Bibliográficas [ANSI/ISO 2006]ANSI/ISO. Sql. Disponível em: <http://en.wikipedia.org/wiki/SQL>. Acesso em JANEIRO 2006. 2006. [ASP 2006]ASP. Asp. Disponível em: <http://www.w3schools.com/asp>. Acesso em JANEIRO 2006. 2006. [BOOCH 1994]BOOCH, G. Object Oriented Analysis and Design. 2 ed. [S.l.]: Benjamin Cummings, 1994. [CAVALARI 2004]CAVALARI, G. T. Modelagem e Desenvolvimento de um Sistema de HELP-DESK para a Prefeitura Municipal de Lavras-MG - Monografia. Lavras, 2004. (Ciência da Computação). Universidade Federal de Lavras. [Change-Vision 2006]CHANGE-VISION. JUDE- UML modeling tool. Disponível em: <http://jude.change-vision.com/jude-web/index.html>. Acesso em 10 Janeiro de 2006. 2006. [CORBA 2006]CORBA. Common object request broker architeture. Disponível em: <http://www.omg.org/gettingstarted/corbafaq.htm>. Acesso em JANEIRO 2006. 2006. [COSTA 2005]COSTA,

F.

JSP

e

Servlets.

Disponível

em:

<http://www.dei.esep.ipp.pt/~i020525/trabalhos/2ano-1sem-lpg2-tp1/jsp.pdf>. Acesso em DEZEMBRO 2005. 2005. [ECLIPSE 2005]ECLIPSE. Eclipse. Disponível em: <http://www.eclipse.org/>. Acesso em JUNHO 2005. 2005. [fabFORCE.net 2006]fabFORCE.net.

Dbdesigner

4.

Disponível

<http://www.fabforce.net/dbdesigner4>. Acesso em JANEIRO 2006. 2006.

em:


Sistema Web para Controle de Processos Acadêmicos

[FREIRE 2005]FREIRE, J. C. Apostila:

Servlets,

aula 05. Disponível em:

<http://ceie.feg.unesp.br/EIE2005/>. Primeiro acesso em junho de 2005. 2005. [FREIRE 2005]FREIRE, J. C. CEIE-Modelagem de Sistemas de Informação. [S.l.]: Apostila do curso de Especialização em Informática Empresarial, 2005. [HARTKE 2002]HARTKE, R. Curso de JSP - Apostila. Florianópolis, 2002. (Programa Especial de Treinamento - Ciência da Computação). Universidade Federal de Santa Catarina. [HTTP 2006]HTTP. Http. Disponível em: <http://rfc.net/rfc2616.html>. Acesso em JANEIRO 2006. 2006. [JACOBSON 1992]JACOBSON, I. Object-Oriented Software Engineering. 2 ed. [S.l.]: Addison-Wesley, 1992. [KOCH 2001]KOCH, N. P. Software engineering for adaptive hypermedia systems. Disponível em: <http://www.comp.ufla.br/ olinda/arquivosuwe.html>.Acessado em 01 de Dezembro de 2005. 2001. [KOCH 2002]KOCH, N. P. Case support for modeling web applications. Disponível em: <http://www.comp.ufla.br/ olinda/arquivosuwe.html>.Acessado em 01 de Dezembro de 2005. 2002. [KOCH 2002]KOCH, N. P. The expressive power of uml-based web engineering. Disponível em: <http://www.comp.ufla.br/ olinda/arquivosuwe.html>.Acessado em 01 de Dezembro de 2005. 2002. [MACIEL 2002]MACIEL, F. Modelagem do Catálogo e Autenticação do Direto utilizando J2EE e JAAS - Monografia. Porto Alegre, 2002. (Curso de Bacharelado em Ciência da Computação). Universidade Federal do Rio Grande do Sul. [OLIVEIRA 2001]OLIVEIRA,

A.

Apostila

servlets

JSP.

Disponível

em:

<http://www.henry.eti.br/pagina.php?IdPagina=117>. Acesso em JANEIRO 2006. 2001. UNESP/FEG-CEIE, 2006

74


Sistema Web para Controle de Processos Acadêmicos

[OMG - UML1 2005]OMG - UML1. Object LANGUAGE.

Management G roup

-

UNIFIED MODELING

Disponível em: <http://www.uml.org/>. Acesso em SETEMBRO 2005.

2005. [OMG - UML2 2006]OMG -

UNIFIED

-

MODELING

UML2.

Object

LANGUAGE

2.0.

Management

Disponível

G roup

em:

<http://www.omg.org/technology/documents/formal/uml.htm>. Acesso em MAIO 2006. 2006. [PAGLIOSA 2005]PAGLIOSA, P. A. Modelando sistemas com uml. Disponível em: <http://www.dct.ufms.br/ pagliosa/SystemAnalysis/ps2.pdf>.Acessado em 14 de Novembro de 2005. 2005. [PHP 2006]PHP. Php. Disponível em: <http://www.php.net/>. Acesso em JANEIRO 2006. 2006. [Pinheiro 2004]PINHEIRO, J. Servlets. Disponível em: <http://www.deinf.ufma.br/ mario/grad/hmidia/servlets.pdf>. Acesso em MAIO 2006. 2004. [PostgreSQL 2005]PostgreSQL. Postgresql global

D evelopment G roup.

Disponível em:

<http://www.postgresql.org/>. Acesso em SETEMBRO 2005. 2005. [PostgreSQL - CGK 2005]PostgreSQL - CGK. Comparativo postgresql. Disponível em: <http://www.cgk.com.br/downloads/doc/PostGreSQLcomparativo.pdf>. Acesso em SETEMBRO 2005. 2005. [PRESSMAN 2002]PRESSMAN, R. S. Engenharia de software. 5 ed. [S.l.]: McGrawHill, 2002. [RIVELO 2004]RIVELO, C. L. Um Sistema Web para Acompanhamento de Protocolo Monografia. Guaratinguetá, 2004. (Especialização em Informática Empresarial). Faculdade de Engenharia, Campus de Guaratinguetá, Universidade Estadual Paulista. [RUMBAUGH 1991]RUMBAUGH, J. Object Oriented Modeling and Design. 2 ed. [S.l.]: Prentice-Hall, 1991. UNESP/FEG-CEIE, 2006

75


Sistema Web para Controle de Processos Acadêmicos

[SANTOS 2005]SANTOS, B. Desenvolvimento de aplicações web na plataforma J 2 EE e IDE

eclipse. Disponível em: <http://paginas.fe.up.pt/~ei01101/ES/relatorio_final.pdf>.

Acesso em NOVEMBRO 2005. 2005. [SOMMERVILLE 2003]SOMMERVILLE, I. Engenharia de software. 6 ed. [S.l.]: Addison Wesley, 2003. [Sun - API 2006]Sun - API. Api. Disponível em: <http://tomcat.apache.org/tomcat-5.0doc/servletapi/index.html>. Acesso em JANEIRO 2006. 2006. [Sun - J2EE 2006]Sun - J2EE . Java 2 platform, enterprise edition ( J 2 EE ) overview. Disponível em: <http://java.sun.com/javaee/index.jsp>. Acesso em JANEIRO 2006. 2006. [Sun - Javabeans 2006]Sun

-

Javabeans.

Javabeans.

Disponível

em:

<http://java.sun.com/products/javabeans/faq/faq.general.html>. Acesso em JANEIRO 2006. 2006. [Sun - JSP 2005]Sun - JSP. JAVA S ERVER

PAGES

technology. Disponível em:

<http://java.sun.com/products/jsp/index.jsp>. Acesso em SETEMBRO 2005. 2005. [Sun Microsystems 2006]Sun Microsystems. J2ee ( J 2 EE ) overview - application model. Disponível em: <http://java.sun.com/j2ee/appmodel.html>. Acesso em JANEIRO 2006. 2006. [VIDAL 1995]VIDAL, A. G. Clipper 5.0. 5 ed. [S.l.]: LTC - Editora, 1995. [Wikipedia 2006]Wikipedia.

Polimorfismo.

Disponível

em:

<http://pt.wikipedia.org/wiki/>. Acesso em JANEIRO 2006. 2006. [Xpdian.com 2006]Xpdian.com. How to use the uml 2.0 for enterprise models. Disponível em: <http://www.xpdian.com/UML2.0.html>. Acesso em MAIO 2006. 2006.

UNESP/FEG-CEIE, 2006

76


Apêndice A Modelo Casos de Uso - SCPA

Figura A.1: Caso de Uso - Controle de Usuários


Sistema Web para Controle de Processos AcadĂŞmicos

Figura A.2: Caso de Uso - Controle de Ă reas

Figura A.3: Caso de Uso - Controle de Departamentos

UNESP/FEG-CEIE, 2006

78


Sistema Web para Controle de Processos AcadĂŞmicos

Figura A.4: Caso de Uso - Controle de Despachos

Figura A.5: Caso de Uso - Controle de Processos

UNESP/FEG-CEIE, 2006

79


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

80


Apêndice B Descrição dos Casos de Uso Aplicação ao Caso de Uso Login

Fluxo de Eventos para o Caso de Uso Login 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Login /Acesso no Sistema. 1.2 Pré - Condições:Para que este caso de uso seja executado o caso de uso Inserir Usuários deve ter sido efetuado; o funcionário já deve ter sido cadastrado para a utilização do sistema. 1.3 Atores Envolvidos: Usuários. 1.4 Fluxo Principal: Este caso de uso se inicia quando o usuário inicia o sistema e lhe é solicitado Login e Senha para utilização do sistema SCPA, este verifica se o login / senha são válidos (E-1); após a conferência, a tela Inicial do sistema, com os demais menus, aparecerá para posterior solicitação de serviço. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O usuário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Áreas

Fluxo de Eventos para o Caso de Uso Inserir Áreas 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Áreas no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e é solicitado, ao funcionário, a digitação do código numérico da área a ser cadastrada (E-2) e a descrição da mesma. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de cadastro de uma área já existente. A situação é informada e o caso de uso se reinicia. Fluxo de Eventos para o Caso de Uso Alterar Áreas 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Áreas no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Áreas já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Alterar Áreas, a tela com as Áreas já cadastradas, aparece. Seleciona a área, recuperando os dados a serem alterados. Assim, o funcionário poderá fazer a atualização da descrição da área. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. UNESP/FEG-CEIE, 2006

82


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Excluir Áreas 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Exclusão de Áreas no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Áreas já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir Áreas, a tela com as Áreas já cadastradas, aparece. Seleciona a área, recuperando os dados a serem excluídos. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

83


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Assuntos

Fluxo de Eventos para o Caso de Uso Inserir Assuntos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Assuntos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e é solicitado ao funcionário a digitação da sigla do assunto a ser cadastrado (E-2), bem como a descrição do mesmo. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de cadastro de um assunto já lançado. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

84


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Assuntos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Assuntos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Assuntos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E1); após a conferência, ao entrar na opção de Alterar assuntos, a tela com os assuntos já cadastrados, aparece. Seleciona o assunto, recuperando os dados a serem alterados. Assim, o funcionário poderá fazer a atualização da descrição do assunto. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

Fluxo de Eventos para o Caso de Uso Excluir Assuntos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Assuntos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Assuntos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir assuntos, a tela com os assuntos já cadastrados, aparece. Ao selecionar o assunto, os dados do mesmo aparecem na tela. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. UNESP/FEG-CEIE, 2006

85


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Departamentos

Fluxo de Eventos para o Caso de Uso Inserir Departamentos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Departamentos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e é solicitado ao funcionário a digitação do código numérico do departamento a ser cadastrado (E-2), a sigla e o nome do departamento e a área a qual ele pertence. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de cadastro de um departamento já existente. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

86


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Departamentos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Departamentos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Departamentos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Alterar Departamentos, a tela com os Departamentos já cadastrados, aparece. Seleciona o departamento, recuperando os dados a serem alterados. Ao funcionário, cabe somente a atualização da sigla e descrição do departamento e do código da área. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

87


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Excluir Departamentos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Departamentos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Departamentos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir Departamentos, a tela com os Departamentos já cadastrados, aparece. Seleciona o departamento, para verificar as informações cadastradas. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

88


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Despachos

Fluxo de Eventos para o Caso de Uso Inserir Despachos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Despachos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e o funcionário terá que digitar a sigla do despacho a ser cadastrado (E-2), bem como a descrição do mesmo. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de inserção de um despacho já cadastrado. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

89


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Despachos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Alteração de Despachos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Despachos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Alterar Despachos, a tela com os Despachos já cadastrados, aparece. Seleciona o despacho, recuperando os dados a serem alterados. O funcionário poderá somente fazer a atualização da descrição do despacho. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

Fluxo de Eventos para o Caso de Uso Excluir Despachos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para a Exclusão de Despachos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Despachos já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir Despachos, a tela com os Despachos já cadastrados, aparece. Seleciona o despacho, os dados cadastrados para o despacho aparecem na tela. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. UNESP/FEG-CEIE, 2006

90


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Tipos de Usuários

Fluxo de Eventos para o Caso de Uso Inserir Tipos de Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Tipos de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e é solicitado, ao funcionário, a digitação do código numérico do tipo a ser cadastrado (E-2) e a descrição da mesmo. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de cadastro de um tipo já existente. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

91


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Tipos de Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado para Alteração de Tipos de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Tipos de Usuários já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Alterar Tipos de Usuários, a tela com os Tipos de Usuários já cadastrados aparece. Seleciona o tipo, recuperando os dados a serem alterados. O funcionário poderá somente fazer a atualização da descrição do tipo de usuário. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

Fluxo de Eventos para o Caso de Uso Excluir Tipos de Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado para Exclusão de Tipos de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Tipos de Usuários já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir Tipos de Usuários, a tela com os Tipos de Usuários já cadastrados aparece. Seleciona o tipo, recuperando os dados deste tipo de usuário. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. UNESP/FEG-CEIE, 2006

92


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Usuários

Fluxo de Eventos para o Caso de Uso Inserir Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso. Lembrando que, o caso de uso Incluir Tipos de Usuários já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e é solicitado ao funcionário a digitação da Matricula do usuário (funcionário) a ser cadastrado (E-2), bem como Nome do usuário, Departamento ao qual o usuário pertence, Senha e Tipo de usuário, podendo ser Administrador do Sistema ou Funcionário Administrativo. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de cadastro de um usuário já cadastrado. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

93


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Tipos de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Usuários já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Alterar Usuários, a tela com os Usuários já cadastrados aparece. Seleciona o usuário, recuperando os dados a serem alterados. O funcionário poderá fazer a atualização dos dados do usuário seleciona, com exceção do número da matrícula. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

94


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Excluir Usuários 1.1 Descrição: Este caso de uso aborda o procedimento adotado no processo de Exclusão de Tipos de Usuários no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, além disso, o caso de uso Incluir Usuários já deve ter sido concluído. 1.3 Atores Envolvidos: Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário (administrador do sistema) se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, ao entrar na opção de Excluir Usuários, a tela com os Usuários já cadastrados aparece. Seleciona o usuário; as informações do usuário selecionado são visualizadas na tela. Após confirmação, do funcionário, o registro é excluído. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

95


Sistema Web para Controle de Processos Acadêmicos

Aplicação ao Caso de Uso Controle de Processos

Fluxo de Eventos para o Caso de Uso Inserir Processos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Cadastro de Processos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso e os casos de uso Inserir Departamentos, Assuntos e Despachos já devem ter sido completado anteriormente, pois o caso de uso Inserir Processos utiliza essas informações. 1.3 Atores Envolvidos: Funcionário Administrativo ou Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de cadastro aparece e o funcionário terá que digitar primeiramente a SIGLA do Departamento ao qual o Processo, a ser cadastrado, pertence (E-2); o sistema automaticamente trará a numeração para este processo, de acordo com a seqüência de processos já cadastrados e ainda a informação do ano vigente, (S-1), o Funcionário deve selecionar os seguintes campos, que são obrigatórios, Código do Departamento Origem que está originando o Processo e Código do Assunto do Processo, preencher os seguintes campos, a Data de Origem, normalmente esta será a mesma do dia do cadastro, portanto o sistema fornecerá automático, podendo ser alterada de acordo com a situação (E-3), Instituição Interessada (este campo não é obrigatório), Nome do Interessado e Observações referente ao Assunto (este campo não é obrigatório). 1.5 Sub-Fluxos: S-1: Se processo for do Departamento Normal Superior, cuja sigla é CNS, o campo Município e Turma aparecerão para que o funcionário digite essas informações, além das outras informações que devem conter no processo. 1.6 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Houve uma tentativa de inserção de uma sigla de departamento inexistente. A situação é informada e o caso de uso se reinicia. E-3: Alteração de Data Origem foi inválida, a situação é informada para que o funcionário possa corrigir a data novamente. UNESP/FEG-CEIE, 2006

96


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Alterar Processos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para Alteração de Processos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso e os casos de uso Inserir Departamentos, Assuntos, Despachos e Processos já devem ter sido completado anteriormente. 1.3 Atores Envolvidos: Funcionário Administrativo ou Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de alteração aparece com os processos já cadastrados (Informações na tela: Número do processo, Interessado e Assunto), o funcionário seleciona o processo a ser alterado, e os dados são recuperados, o funcionário poderá alterar o Código do Departamento Origem que está originando o Processo, o Código do Assunto do Processo, a Data de Origem, o sistema fornecerá automático, mas poderá ser alterada de acordo com a situação (E-2), Instituição Interessada, Nome do Interessado e Observações referente ao Assunto. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Alteração de Data Origem foi inválida, a situação é informada para que o funcionário possa corrigir a data novamente.

UNESP/FEG-CEIE, 2006

97


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Emissão de Processos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para Informar o local para onde o Processo está sendo emitido, ou seja, a Emissão dos Processos, dentro do ambiente da Universidade (Departamentos/Setores), no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, o caso de uso Inserir Processos já deve ter sido executado anteriormente. 1.3 Atores Envolvidos: Funcionário Administrativo ou Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de Controle de Processos aparece e o funcionário escolhe a opção Emissão de Processos, uma nova tela aparece onde o funcionário terá que digitar o código do processo a ser enviado (E-2), a data e hora dessa emissão serão informadas pelo próprio sistema, depois deverá ser selecionado o código do departamento destino para onde o processo está sendo enviado (Enviado Para:) e o nome do funcionário/servidor, responsável pelo recebimento do Processo. O processo que está sendo enviado receberá um código E de emitido. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Código de Processo inválido. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

98


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Recebimento de Processos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para Informar o Recebimento do Processo no Sistema, por determinado Departamento/Setor da Universidade. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, o caso de uso Inserir Processos já deve ter sido executado anteriormente (normalmente pelo departamento/setor que originou o processo, ou seja, aquele que envia) e o caso de uso Emissão de Processos já deve ter sido executado por algum departamento/setor. 1.3 Atores Envolvidos: Funcionário Administrativo ou Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de Controle de Processos aparece e o funcionário escolhe a opção Recebimento de Processos, uma nova tela aparece onde o funcionário terá que digitar o código do processo a ser recebido (E-2), selecionar o código do departamento receptor e o nome do funcionário/servidor, responsável pelo recebimento do Processo, será automaticamente informado pelo sistema, aproveitando o login do funcionário, a data e hora desse recebimento serão informadas pelo próprio sistema. O processo que está sendo recebido receberá um código R de recebido. 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login. E-2: Código de Processo inválido. A situação é informada e o caso de uso se reinicia.

UNESP/FEG-CEIE, 2006

99


Sistema Web para Controle de Processos Acadêmicos

Fluxo de Eventos para o Caso de Uso Atualizar Situação dos Processos 1.1 Descrição: Este caso de uso aborda o procedimento adotado para o Atualizar a situação dos processos no Sistema. 1.2 Pré - Condições: Para que este caso de uso seja executado o caso de uso Login deve ter sido efetuado; o funcionário já deve ter feito o login no sistema e ter tido a autorização para esse caso de uso, o caso de uso Inserir Processos já deve ter sido executado anteriormente. 1.3 Atores Envolvidos: Funcionário Administrativo ou Administrador do Sistema. 1.4 Fluxo Principal: Este caso de uso se inicia quando o funcionário se loga ao sistema SCPA e este verifica se o login/senha são válidos (E-1); após a conferência, a tela de atualização aparece e o funcionário seleciona o código do processo a ser atualizado, depois deverá ser colocada a situação atual do processo, selecionando o tipo de despacho, bem como as informações do código do departamento, o nome do funcionário responsável 1.5 Fluxos Alternativos: E-1: Login ou Senha inválido foi fornecido. O funcionário pode fornecer novamente o login e a senha ou terminar o caso de uso Login.

UNESP/FEG-CEIE, 2006

100


Apêndice C Modelo de Estrutura de Navegação SCPA

Figura C.1: Estrutura de Navegação - Visão Administrador - Parte B


Sistema Web para Controle de Processos Acadêmicos

Figura C.2: Estrutura de Navegação - Visão Administrador - Parte C

UNESP/FEG-CEIE, 2006

102


Sistema Web para Controle de Processos Acadêmicos

Figura C.3: Estrutura de Navegação - Visão Funcionário - Parte A

UNESP/FEG-CEIE, 2006

103


Sistema Web para Controle de Processos Acadêmicos

Figura C.4: Estrutura de Navegação - Visão Funcionário - Parte B

UNESP/FEG-CEIE, 2006

104


Sistema Web para Controle de Processos Acadêmicos

Figura C.5: Estrutura de Navegação - Visão Funcionário - Parte C

UNESP/FEG-CEIE, 2006

105


Sistema Web para Controle de Processos AcadĂŞmicos

UNESP/FEG-CEIE, 2006

106


Apêndice D Modelo de Apresentação - SCPA Menu Controle de Assuntos

Figura D.1: Modelo de Apresentação - Menu Assuntos


Sistema Web para Controle de Processos Acadêmicos

Menu Controle de Departamentos

Figura D.2: Modelo de Apresentação - Menu Departamentos

Menu Controle de Despachos

Figura D.3: Modelo de Apresentação - Menu Despachos

UNESP/FEG-CEIE, 2006

108


Sistema Web para Controle de Processos Acadêmicos

Menu Controle de Processos

Figura D.4: Modelo de Apresentação - Menu Processos

Menu Controle de Status dos Processos

Figura D.5: Modelo de Apresentação - Menu Status Processos

UNESP/FEG-CEIE, 2006

109


Sistema Web para Controle de Processos Acadêmicos

Menu Controle de Usuários

Figura D.6: Modelo de Apresentação - Menu Usuários

UNESP/FEG-CEIE, 2006

110


Apêndice E Diagramas de Seqüências

Controlar Usuários

Figura E.1: Diagrama de Seqüência - Incluir Usuário


Sistema Web para Controle de Processos Acadêmicos

Figura E.2: Diagrama de Seqüência - Alterar Usuário

UNESP/FEG-CEIE, 2006

112


Sistema Web para Controle de Processos Acadêmicos

Figura E.3: Diagrama de Seqüência - Excluir Usuário

UNESP/FEG-CEIE, 2006

113


Sistema Web para Controle de Processos Acadêmicos

Controlar Assuntos

Figura E.4: Diagrama de Seqüência - Incluir Assunto

UNESP/FEG-CEIE, 2006

114


Sistema Web para Controle de Processos Acadêmicos

Figura E.5: Diagrama de Seqüência - Alterar Assunto

UNESP/FEG-CEIE, 2006

115


Sistema Web para Controle de Processos Acadêmicos

Figura E.6: Diagrama de Seqüência - Excluir Assunto

UNESP/FEG-CEIE, 2006

116


Sistema Web para Controle de Processos Acadêmicos

Controlar Áreas

Figura E.7: Diagrama de Seqüência - Incluir Area

UNESP/FEG-CEIE, 2006

117


Sistema Web para Controle de Processos Acadêmicos

Figura E.8: Diagrama de Seqüência - Alterar Area

UNESP/FEG-CEIE, 2006

118


Sistema Web para Controle de Processos Acadêmicos

Figura E.9: Diagrama de Seqüência - Excluir Area

UNESP/FEG-CEIE, 2006

119


Sistema Web para Controle de Processos Acadêmicos

Controlar Departamentos

Figura E.10: Diagrama de Seqüência - Incluir Departamento

UNESP/FEG-CEIE, 2006

120


Sistema Web para Controle de Processos Acadêmicos

Figura E.11: Diagrama de Seqüência - Alterar Departamento

UNESP/FEG-CEIE, 2006

121


Sistema Web para Controle de Processos Acadêmicos

Figura E.12: Diagrama de Seqüência - Excluir Departamento

UNESP/FEG-CEIE, 2006

122


Sistema Web para Controle de Processos Acadêmicos

Controlar Despachos

Figura E.13: Diagrama de Seqüência - Incluir Despacho

UNESP/FEG-CEIE, 2006

123


Sistema Web para Controle de Processos Acadêmicos

Figura E.14: Diagrama de Seqüência - Alterar Despacho

UNESP/FEG-CEIE, 2006

124


Sistema Web para Controle de Processos Acadêmicos

Figura E.15: Diagrama de Seqüência - Excluir Despacho

UNESP/FEG-CEIE, 2006

125


Sistema Web para Controle de Processos Acadêmicos

Controlar Processos

Figura E.16: Diagrama de Seqüência - Incluir Processo

UNESP/FEG-CEIE, 2006

126


Sistema Web para Controle de Processos Acadêmicos

Figura E.17: Diagrama de Seqüência - Alterar Processo

UNESP/FEG-CEIE, 2006

127


Sistema Web para Controle de Processos Acadêmicos

Figura E.18: Diagrama de Seqüência - Excluir Processo

UNESP/FEG-CEIE, 2006

128


Sistema Web para Controle de Processos Acadêmicos

Controlar Status dos Processos

Figura E.19: Diagrama de Seqüência - Enviar Processo

Figura E.20: Diagrama de Seqüência - Receber Processo

UNESP/FEG-CEIE, 2006

129


Sistema Web para Controle de Processos Acadêmicos

Figura E.21: Diagrama de Seqüência - Atualizar Status Processo

Figura E.22: Diagrama de Seqüência - Consultar Status Processo

UNESP/FEG-CEIE, 2006

130


Apêndice F Dicionário de Dados As Figuras F.1 e F.2 apresentam o Dicionário de Dados criado para o Sistema WEB de Controle de Processos Acadêmicos. Nestas figuras são especificados todos os campos que estão presentes na base de dados do sistema.

Figura F.1: Dicionário de Dados - Parte 1


Sistema Web para Controle de Processos Acadêmicos

Figura F.2: Dicionário de Dados - Parte 2

UNESP/FEG-CEIE, 2006

132


Ceie0604