sexta-feira, 29 de maio de 2009

Diagrama de Seqüência

Nosso grupo compreendeu que para fins de estudos deveríamos abordar um Diagrama de Seqüência que apresentasse o Caso de Uso mais complexo e mais importante para o nosso sistema. Construímos portanto um Diagrama de Seqüência referente ao Caso de Uso Manter Tramitação, que representa a capacidade de workflow de nosso sistema.

sexta-feira, 22 de maio de 2009

Diagrama de Máquina de Estados

Nosso sistema não possuirá um comportamento em seus objetos que representem grande destaque para utilização de um Diagrama de Máquina de Estados. A exemplo disto, apresentamos os DMT's dos objetos mais relevantes do sistema e com suas respectivas mudanças de estado.

sexta-feira, 8 de maio de 2009

Diagrama de Classes

Considerando a estrutura MVC, definimos as classes Modelo no nosso Diagrama de Classes. Os métodos foram omitidos pois consideramos que nestas classes existiram somente métodos dos tipos get e set.

terça-feira, 14 de abril de 2009

Documento de Visão

1. OBJETIVO

Este documento de visão define a descrição dos problemas e o detalhamento dos envolvidos no Sistema Protocolo Eletrônico de Documentos (PrEDoc).

2. Visão Geral do Problema

A circulação interna de documentos impressos sempre foi um grande problema para os Órgãos do Governo. A cada entrada de documento, um processo é montado, sendo registrado o assunto e os dados do executor. Caso um novo documento seja necessário, ele deverá ser anexado no processo e assim por diante. Os custos operacionais de eventuais perdas de documentos e/ou processos nas tramitações entre departamentos é um fator de grande impacto no orçamento, devendo ser minimizado ao máximo ou eliminado, se possível.

O excesso de papel também é um fato a ser considerado. O manuseio do papel entre os departamentos acarreta problemas com fungos, ácaros, cupim, excesso de peso para carregamento e armazenamento de grandes volumes, dentre outros.

A necessidade de organizar e integrar o controle na tramitação destes processos, facilitando a visualização rápida de sua trajetória e sua localização em qualquer parte da organização, além da redução dos custos são os objetivos a serem alcançados.

3. Atores/Executores
















FUNÇÃO/PAPELDESCRIÇÃOÓRGÃO
AdministradorResponsável pela gestão dos cadastros básicos do sistema, como cadastro de usuário, assuntos, órgãos e departamentos.Órgão Governamental
FuncionárioResponsável cadastrar os processos e sua tramitação no sistema.Órgão Governamental


4. Visão Geral da Solução Proposta

O sistema proposto deve automatizar, controlar e acompanhar os processos eletronicamente de forma rápida e organizada. Através de um histórico de providências tomadas, esta solução deve trazer funcionalidades que permitem acompanhar o fluxo dos processos entre os departamentos desde a sua origem até seu destino final, permitindo a sua localização imediata dentro da organização.

Adicionalmente, o produto proposto permitirá que somente funcionários previamente cadastrados acessem o sistema, além de possibilitar que um administrador faça o gerenciamento de cadastros básicos, tais como: usuário, assuntos dos processos, órgãos e departamentos.

5.Requisitos de Negócio

a. Funcionais
  • Cadastrar os dados dos funcionários;
  • Emitir relatórios gerenciais sobre os funcionários;
  • Cadastrar os assuntos relativos aos documentos;
  • Cadastrar os departamentos do Órgão Governamental;
  • Cadastrar outros Órgãos Governamentais;
  • Cadastrar os processos que vão conter os documentos;
  • Cadastrar o trâmite de documentos entre os departamentos
  • Visualizar o trâmite de documentos entre os departamentos

b. Inversos
  • Não foram identificados requisitos de negócio inversos.

c. Não Funcionais
  • O sistema tem como proposta a rapidez e a facilidade de uso, buscando respeito aos preceitos de usabilidade e acessibilidade.
  • O sistema deve ser baseado na plataforma Web

6. Restrições

Não foram identificadas restrições específicas para o sistema.

sexta-feira, 3 de abril de 2009

Modelagem de Negócio

Vislumbrando o Sistema PrEDoc, visualizamos a seguinte modelagem de negócio.

sexta-feira, 27 de março de 2009

Modelo de Casos de Uso

Como primeira atividade de nosso estudo, o Sistema PrEDoc teve seus Casos de Uso modelados:
(concordando com alguns comentários em nosso blog, alteramos no Modelo de Casos de Uso)


Caso de Uso: Manter Usuários
Ator Principal:
Administrador

O administrador consulta o sistema verificando se o usuário já está cadastrado. Caso não esteja cadastrado, ele cadastra o usuário, informando seus dados pessoais e selecionando em qual órgão e departamento está alocado. Caso o usuário já esteja cadastrado, o administrador atualiza seus dados, ou substitui a alocação do usuário. A exclusão do usuário é lógica, ou seja, o administrador altera a situação para inativo, preservando seus dados para futuras consultas de histórico de tramitações.


Caso de Uso:
Relatórios de Usuários
Ator Principal: Administrador

O administrador consulta o sistema informando a situação dos usuários (ativo ou inativo) que deseja no relatório. O sistema retorna uma relação com todos os usuários que atendam a situação informada, transcrevendo seus dados pessoais, o órgão e o departamento onde estão alocados.


Caso de Uso: Manter Departamentos
Ator Principal: Administrador

O administrador consulta o sistema verificando se o departamento já está cadastrado. Caso ele não esteja cadastrado, o administrador cadastra o departamento, informando seus dados e alocando-o a um órgão. Caso o departamento já esteja cadastrado, o administrador atualiza seus dados. A exclusão do departamento é lógica, ou seja, o administrador altera a situação para inativo, preservando seus dados para futuras consultas de histórico de tramitações.


Caso de Uso: Manter Órgãos
Ator Principal: Administrador

O administrador consulta o sistema verificando se o órgão já está cadastrado. Caso ele não esteja cadastrado, o administrador cadastra o órgão, informando seus dados. Caso o órgão já esteja cadastrado, o usuário atualiza seus dados. A exclusão do órgão é lógica, ou seja, o administrador altera a situação para inativo, preservando seus dados para futuras consultas de histórico de tramitações.


Caso de Uso: Manter Processos
Ator Principal: Usuário

Caso o processo não esteja cadastrado no sistema, o usuário cadastra-o, informando seus dados de identificação, órgão origem, departamento origem e o assunto. Após o cadastro, o sistema fornece um código seqüencial e imprime uma etiqueta com este código. Caso o documento já esteja cadastrado, o usuário atualiza seus dados de identificação.


Caso de Uso: Manter Tramitação
Ator Principal: Usuário

O usuário informa o código do processo que receberá uma tramitação. O usuário cadastra uma nova tramitação, informando o órgão e o departamento de destino. Caso seja a última tramitação, o sistema deverá alterar a situação do processo para arquivado.


Caso de Uso: Manter Assuntos
Ator Principal: Administrador

O administrador consulta o sistema verificando se o assunto já está cadastrado. Caso ele não esteja cadastrado, o administrador cadastra o assunto, informando seus dados. Caso o assunto já esteja cadastrado, o administrador atualiza seus dados. A exclusão do assunto é lógica, ou seja, o administrador altera a situação para inativo, preservando seus dados para futuras consultas de histórico de tramitações


Caso de Uso: Relatórios de tramitação de processos
Ator Principal: Usuário

O usuário consulta o sistema informando um período, número do processo, assunto, órgão origem, órgão destino, departamento origem ou departamento destino. O sistema retorna uma relação com o(s) processos(s) que atendam a situação informada, transcrevendo seus dados de identificação, as tramitações cadastradas para o documento, os usuários que receberam o documento e links para visualização da imagem do documento e de seus anexos (se existirem).


quarta-feira, 18 de março de 2009

Sistema a ser estudado - Protocolo Eletrônico

Como proposta de estudo, modelaremos um sistema que terá como finalidade protocolar e monitorar documentos recebidos em uma empresa fictícia.

O Sistema foi denominado como Protocolo Eletrônico de Documentos (PrEDoc).

As vantagens esperadas com esse sistema:
  • evitar a circulação de documentos (impressos) entre os departamentos de uma empresa, diminuindo com isso o consumo de papel;
  • criar um histórico de providências tomadas relacionadas a um documento origem;
  • agilizar a tramitação das medidas tomadas entre departamentos.
Até o início deste estudo haviam sido identificados 2 sistemas com características semelhantes ao PrEDoc:
  • SICOP (Sistema Único de Controle de Protocolo): sistema adotado pela Prefeitura da Cidade do Rio de Janeiro para gerenciar todos os documentos que circulam entre os Órgãos municipais.
  • SCP2 (Sistema de Controle de Processos e Protocolos): sistema elaborado pela APOENA Soluções em Software Livre Ltda., que permite o controle de documentos que são encaminhados a uma empresa, tanto internos como externos.
O diferencial do PrEDoc com relação aos sistemas até o momento identificados reside principalmente nos seguintes pontos:
  • O PrEDoc é um sistema com uma visão acadêmica, que implica na preocupação de abordagens em concordância com as diretrizes da Orientação a Objeto e um emprego correto da UML;
  • O PrEDoc tem como proposta a rapidez e a facilidade de uso, buscando respeito aos preceitos de usabilidade e acessibilidade.