sábado, 13 de junho de 2009

Mapa do Site

Este foi o mapa do site para o Sistema PrEDoc que nós elaboramos.

sexta-feira, 5 de junho de 2009

Diagrama de Atividades

Construímos 2 Diagramas de Atividades que representam as principais funções do nosso sistema.

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.

Apresentação

Este blog é pré-requisito na avaliação da disciplina Modelagem de Sistemas de Informação, do Mestrado em Informática na UNIRIO.

Aqui serão apresentadas as soluções encontradas pelo grupo para as atividades propostas na disciplina, relacionadas ao estudo de desenvolvimento de um sistema.