Lisboa, 18 de Janeiro de 2004

Transcrição

1 Lisboa, 18 de Janeiro de 2004 Realizado por: o Bruno Martins Nº o Cátia Chasqueira Nº o João Almeida Nº

2 Índice 1 Índice de Figuras Versões Introdução Finalidade Objectivo Estrutura Modelo de Instalação Desenho da Instalação Modelo de Implementação Diagrama de Componentes para Código fonte Diagrama de Componentes para Interface Modelo de Desenho Diagrama de Pacotes Diagrama de Classes Descrição das Classes Diagramas de Estados Interfaces Conclusão Bibliografia

3 1 Índice de Figuras Figura 1 - Diagrama de instalação do idocument... 7 Figura 2 - Diagrama de Componentes para código fonte do idocument... 9 Figura 3 - Diagrama de Componentes para interfaces do idocument Figura 4 - Diagrama de Pacotes do idocument Figura 5 - Diagrama de Classes do idocument, sem atributos ou métodos Figura 6 - Diagrama de Estados de um Documento Figura 7 - Diagrama de Estados de um Utilizador Figura 8 - Diagrama de Estados de uma Versão de Documento Figura 9 - Diagrama de Estados de uma Notificação Figura 10 - Ecrã de Criação de Tipo de Documento Figura 11 - Ecrã de Criação de Template Figura 12 - Ecrã de Digitalização de Documento Figura 13 - Ecrã de Emissão de Nota/Despacho/Parecer Figura 14 - Ecrã de Envio de Documento Figura 15 - Ecrã de Inbox de um Utilizador Figura 16 - Ecrã de Outbox de um Utilizador Figura 17 - Ecrã de Organização de Pastas de um Utilizador Figura 18 - Ecrã de Registo de um Documento Figura 19 - Ecrã de Tarefas a realizar por um Utilizador Figura 20 - Ecrã de inicio de novos Processos

4 2 Versões Versão Data Descrição /01/2004 Primeira Versão do Caderno de Desenho 4

5 3 Introdução 3.1 Finalidade Este caderno de desenho surge numa fase avançada da vida do projecto. Após as fases de levantamento de requisitos e planeamento, já existe conhecimento suficiente dos processos de negócio e do produto pretendido para se poder passar a uma nova etapa do desenvolvimento do projecto. O desenho desempenha um papel bastante importante durante para a implementação, consequentemente, é uma fase que merece, um nível profundo de detalhe. A fase de desenho e de implementação andam sempre de mãos dadas, isto é, a implementação baseia-se muito nas decisões tomadas no desenho, e o seu resultado final estará à imagem deste. Um caderno de desenho bem estruturado é sempre uma boa ferramenta de apoio à programação. Nele estão representados todos os objectos que irão guardar a informação na base de dados, bem como a interacção destes com os objectos de negócio, que contêm as regras do mesmo, e com os objectos de interface que farão a ponte para o utilizador. A metodologia de desenvolvimento adoptada, seguindo uma lógica incremental, que implica constantes revisões às decisões tomadas e à implementação, cria fortes laços entre o que é definido no caderno de desenho e o que é implementado. Facto que origina algumas alterações a decisões tomadas como certas no momento em que ficam escritas. 3.2 Objectivo O objectivo deste caderno é fornecer um documento que represente, sob a forma de documento físico, toda a estrutura codificada através de uma linguagem de programação e da integração com tecnologias existentes. Ou seja, poder-se-ão encontrar neste documento todos os componentes do projecto e suas relações. 3.3 Estrutura Os vários diagramas obedecem a uma ordem de apresentação, na qual se parte do geral para o específico. Numa primeira fase são apresentados os diagramas de arquitectura, que de um modo geral representam o sistema e, numa segunda fase, cada componente é estudado mais em pormenor. 5

6 4 Modelo de Instalação O modelo de instalação faz parte de um conjunto de especificidades do desenho que pretendem dar resposta a um conjunto de requisitos do sistema. Para além de construir o produto, é fundamental estabelecer o ambiente sobre o qual assentará. Com o intuito de dar resposta a essas necessidades, foi elaborado nesta secção o diagrama de instalação referente ao idocument. Nele constam o hardware e software indispensáveis ao sistema, bem como a forma como estas diferentes entidades irão comunicar. No modelo do idocument é possível encontrar três grandes módulos: o primeiro corresponde às bases do sistema (servidor HTTP, SharePoint Portal Server 2003, Servidor Ultimus, Active Directory e Base de Dados SQL Server), as quais requerem máquinas potentes que possam dar resposta aos pedidos dos utilizadores. A escolha dos servidores, tanto ao nível das características como da quantidade, irá ter uma grande influência na performance do sistema. o segundo está relacionado com os periféricos que permitem a recepção e envio de documentos. Para que um sistema desta natureza funcione, é necessário garantir que um documento possa dar entrada no sistema, independentemente do meio de envio. Para além do e do servidor de fax, é crucial definir um terminal de digitalização que permita fazer face à quantidade de pedidos de digitalização da organização. por fim, são estabelecidas as estações de trabalho dos colaboradores. A estação de trabalho será contituida por um PC, que fundamentalmente possua acesso à rede e permita a navegação por páginas web, e também por uma ligação a uma ou váias impressoras. 6

7 4.1 Desenho da Instalação Figura 1 - Diagrama de instalação do idocument 7

8 5 Modelo de Implementação O modelo de implementação traduz a forma como será estruturado o código do idocument. A modularização, para além de significar um boa estrutura e organização do código, também facilita o processo de desenvolvimento e de possíveis integraçãos. O objectivo é dividir o código do idocument por diversos pacotes de funções, seguindo uma critério de funcionalidade. Cada um desses módulos é independente dos outros, em termos funcionais, no entanto cada um desempenha um conjunto especifico de funções e no todo representam as funcionalidades totais do idocument. Alguns destes módulos, tais como Gestão de Utilizadores ou mesmo Autenticação, já são fornecidos pelo SharePoint Portal Server 2003, o que contribui em muito para a qualidade de performance do sistema. O módulo relativo ao motor de Workflow também já desempenha um conjunto de funcionalidades que contribuem para a integração entre os dois sistemas idocument e Ultimus. Outro dos objectivos alcançados com os diagramas de componentes, é definir o conjunto de interfaces bem como o a navegabilidade entre as principais páginas. Este documento já permite ao cliente obter uma ideia fidedigna do que constituirá o seu produto. 8

9 5.1 Diagrama de Componentes para Código fonte Figura 2 - Diagrama de Componentes para código fonte do idocument 9

10 5.2 Diagrama de Componentes para Interface My Site Inbox idocument OutBox Enviar Fax Pastas Enviar Digitalizar Imprimir Registar Versionar Criar Template Enviar Notificação Administração Log de Sistema Criar Grupos Pesquisar Criar Tipo Figura 3 - Diagrama de Componentes para interfaces do idocument 10

11 6 Modelo de Desenho Do modelo de desenho faz parte toda a informação relativa à implementação do produto. O todo do sistema que é o idocument, foi dividido em sete subsistemas que, apesar de estarem todos ligados entre eles, dependem uns dos outros, o que vem facilitar em muito o trabalho do analista de desenho, bem como dos programadores. O diagrama de classes é outro dos diagramas deste modelo de desenho. Esta versão do documento uma primeira versão do diagrama de classes, a qual está susceptível de alterações decorrentes, quer da redefinição dos requisitos, quer das funcionalidades já disponibilizadas pelo SharePoint. Esse diagrama não representa atributos ou métodos das classes, deixando-se esse complemento para a segunda versão do documento. As classes representam tabelas na base de dados, nas quais será guardada toda a informação relativa a um documento e aos seus intervenientes. As classes agora definidas podem ser alteradas, conforme as funções disnibilizadas pelo SharePoint. Informação sobre cada classe e relação entre elas podem ser encontradas no ponto 6.3 Descrição das Classes. 11

12 6.1 Diagrama de Pacotes Figura 4 - Diagrama de Pacotes do idocument 12

13 6.2 Diagrama de Classes Figura 5 - Diagrama de Classes do idocument, sem atributos ou métodos 13

14 6.3 Descrição das Classes Documento Elemento essencial do sistema. Um documento representa o núcleo da informação a gerir. Template Serve de base à criação de Documentos. O Template é um tipo específico de Documento. Trata-se de um ficheiro em formato Word com um conjunto de especificações a seguir por quem cria um documento a partir do template. Existe também um conjunto de variáveis para preencher, que servem para personalizar o documento criado, que poderão ou não estar ligadas aos Atributos de um Documento. Versão de Documento Corresponde a uma das formas de um mesmo documento. Uma nova versão é criada quando os ficheiros que compõem o núcleo do documento sofrem alguma alteração no âmbito do sistema (são acrescentados ficheiros, retirados ou renovados), ou quando a estrutura de um Template é alterada. Ficheiro Pode ter qualquer tipo de formato digital (Word, Excel, imagem, etc). Um conjunto de ficheiros (um ou mais) corresponde ao núcleo de um documento. Não podem sofrer alterações após a entrada no sistema, um utilizador apenas interfere com a informação acessória ao documento (quando há um versionamento, os ficheiros deixam de estar activos, mas continuam no sistema associados à versão antiga). Pacote Conjunto de ficheiros de imagem depois da digitalização e antes de serem reconhecidos como documentos independentes. Um pacote tem mais de um documento, e cada documento pode ter vários ficheiros. Tem que passar por um processo de aglomeração de ficheiros em documentos passíveis de registo no idocument. Tipo de Documento Meio de categorização dos Documentos. Cada documento registado no idocument tem um Tipo. Versão do Tipo Um Tipo de Documento pode ser alterado durante a execução do idocument. A Versão do Tipo garante que Documentos já registados com um determinado Tipo continuarão a ter as mesmas características, acontecendo que as modificações estão presentes apenas para novos registos. Atributo Um Tipo de documento tem vários atributos. São preenchidos no momento de registo de um Documento, automaticamente pelo sistema ou manualmente pelo Colaborador. Permitem que um Documento seja distinguido de outros do mesmo Tipo. Atributo no Documento Os atributos criados para um Tipo de Documento são preenchidos nesta tabela no momento do Registo de um novo Documento. 14

15 Variável Unidade de informação a preencher no acto de criação de um Documento a partir de um template, para facilitar a personalização de um template. São criadas e posicionadas no momento da criação do template, e preenchidas no momento da criação de um documento a partir desse template. Esta Variável pode estar associada a um ou mais Atributos do Tipo de Documento. Estado Um Tipo de Documento tem um conjunto de Estados. Esta tabela tem todos os estados existentes no sistema. Estado do Tipo Os Estados de um determinado Tipo de Documento são definidos no Estado do Tipo, associando a tabela Tipo de Documento com a tabela Estado. Grupo Um ou mais utilizadores com um conjunto idêntico de características (Grupo Funcional). Permissão Grup Doc A cada Documento que associado a um Grupo, o Grupo adquire as permissões por defeito do Tipo de Documento, no entanto essas permissões podem ser modificadas. Utilizador Individuo que tem uma área de trabalho no sistema idocument. Permissão Util Doc Relativamente a um Documento específico, um utilizador pode ter mais ou menos tipos de permissão. Permissão Grup Util Característica de acesso a funcionalidades do sistema. Dentro de um Grupo diferentes Utilizadores podem ter diferentes permissões. Permissão Util do Grup no Doc Permissões especificas de um Utilizador, enquanto membro de um Grupo, relativamente a um Documento especifico. Permissão Grup Tipo Permissões definidas por defeito no momento de criação do Tipo de Documento. Permissão Util Tipo Permissões especificas de um Utilizador, enquanto membro de um Grupo, relativamente a um Tipo de Documento. Pasta Funciona como um directório. No conjunto das pastas de um utilizador formam uma árvore de directórios, contendo os documentos que o utilizador quer organizados nesse sistema (os documentos continuam apenas numa localização do sistema, estes directórios apenas contêm links para eles). 15

16 Log Mecanismo de histórico. Esta tabela guarda toda a informação sobre o que se passa no sistema, com precisão de data e hora, baseando-se no binómio utilizador + documento, ou seja, interessa saber quem realizou a acção e sobre que documento ela foi realizada. Notificação Sempre que o sistema regista uma alteração relativamente a um Documento, o conjunto de Utilizadores associados ao Documento são notificados. As Notificações também são usadas como correio interno. Entrada É um tipo especifico de Notificação. Corresponde às Notificações recebidas, as quais têm estados associados. Saida São o outro tipo de Notificações. Este tipo corresponde às mensagens enviadas internamente para outros Utilizadores. Estado da Notificação Relativamente às Notificações de Entrada, importa guardar informação, como meio de organização, se a Notificação já foi ou não vista. Visibilidade É uma forma de gestão dos Documentos, que permite um Utilizador definir se o Documento é Privado, Público ou Restrito. Origem Classe que guarda informação acerca da criação/registo de um Documento, tal como o tipo de entrada (fax, , digitalização), e também guarda referência para o Criador do Documento e para o Remetente, caso exista. Contacto Externo Lista de Contactos Externos à organização. Anexo A cada Documento podem estar anexados Notas, Despachos ou Pareceres, sendo que a estes dois últimos tipos de anexo, está sempre associada uma Notificação. Esta informação é única ao binómio Utilizador/Documento. Nota A qualquer Documento que um Utilizador tenha acesso, o mesmo pode colocar Notas tal como procede com um documento tradicional. A esta Nota só o Utilizador é que tem acesso. Despacho/Parecer São o outro tipo de Anexo. A este tipo específico de Anexo encontra-se sempre associada uma Notificação. Normalmente é enviado um despacho a colaboradores de um nível hierárquico inferior, e um Parecer a um colaborador de nível hierárquico superior. Estes Despachos/Pareceres são visíveis a todos os destinatários da Notificação. 16

17 6.4 Diagramas de Estados Neste ponto, os diagramas de estados pretendem representar comportamentos que algumas classes do sistema podem adoptar, neste caso as que assumem comportamentos mais vincados. A disposição de um conjunto de factores, que não passam de valores do sistema, pode activar determinado estado de uma classe, que muito certamente irá condicionar o comportamento desta. No idocument foram definidos quatro conjuntos de estados, com as seguintes particularidades: Estados de Documento: sendo o Documento a peça fulcral de todo o sistema, existe associada a esta classe um conjunto de factores que influenciam as acções do sistema. Factores como o registo no sistema e acesso ao documento são demasiado sensiveis, que acabam, em parte, por levar à definição de estados para esta classe. Estados de Utilizador: um utilizador, a partir do momento em que é inserido no sistema, passa a estar disponível para desempenhar um conjunto de funções próprias da sua categoria profissional. No entanto, e como todos os utilizadores necessitam de descanço, foi definido um estado no qual, durante o espaço de tempo em que o colaborador esteja ausente da organização, a sua lista de trabalho é endereçada para outro colaborador Estados de Versão de Documento: Sempre que uma nova versão é criada para um documento, essa fica no estado activa e a anterior passa para o estado passada. Desta forma é possível garantir a manutenção de versões antigas e que a actual esteja sempre disponível. Estados de Notificação: Funcionando as notificações como correio interno, nomeadamente correio de envio de documento no seio da organização, o recurso a estados para o controlo das acções efectuadas por um colaborador sobre um documento permite retirar conclusões muito importantes sobre o desempenho de um determinado colaborador. 17

18 [entrou no sistema] Activo [sistema preenche os atributos básicos do documento] [utilizador tem posse do documento] Registo Básico [utilizador preenche atributos detalhados] Cheked-Out [utilizador preenche atributos detalhados] Registo Detalhado Check In Arquivado Figura 6 - Diagrama de Estados de um Documento 18

19 Figura 7 - Diagrama de Estados de um Utilizador Figura 8 - Diagrama de Estados de uma Versão de Documento 19

20 Nova Vista [utilizador ainda nao deu seguimento à notificação] Por Encaminhar [passou o prazo de encaminhamento] Com limite temporal Sem limite temporal Com limite excedido Encaminhada Figura 9 - Diagrama de Estados de uma Notificação 20

21 6.5 Interfaces Este ponto do caderno pretende ser uma evolução à secção Esboço para a interface com o Utilizador do Caderno de Requisitos do projecto idocument. Os ecrãs estão agora mais realistas e completos, e permitem que, no momento da implementação, o processo de criação de interfaces seja contituido maioritariamente por drag & drop, sem necessidade de paragens longas para definição de formulários. Muitas das funções serão construídas recorrendo a Web Parts, possibilitando deste modo que a organização do ecrã seja da responsabilidade do utilizador, para além de outras vantagens inerentes a esta técnica. As Web Parts são facilmente identificadas pela barra azul/cinzenta que se encontra na parte superior de cada função. Relativamente aos ecrãs do idocument, há a realçar a separação visual dos diferentes ambientes de trabalho, ainda que estejam fortemente integrados: gestão documental e gestão de processos. Existe uma zona que é comum tanto às aplicações idocument e Ultimus como também ao SharePoint Portal Server, apesar de, existirem alguma diferenças para este último em termos de funcionalidades. Este espaço comum de trabalho apresenta alguns dados informativos, tais como o número de notificações novas e o número de processos novos, nos casos em que o ultimus está instalado, o nome do utilizador, para além de funções de procura dentro no idocument. Figura 10 - Ecrã de Criação de Tipo de Documento 21

22 Figura 11 - Ecrã de Criação de Template Figura 12 - Ecrã de Digitalização de Documento 22

23 Figura 13 - Ecrã de Emissão de Nota/Despacho/Parecer Figura 14 - Ecrã de Envio de Documento 23

24 Figura 15 - Ecrã de Inbox de um Utilizador Figura 16 - Ecrã de Outbox de um Utilizador 24

25 Figura 17 - Ecrã de Organização de Pastas de um Utilizador Figura 18 - Ecrã de Registo de um Documento 25

26 Figura 19 - Ecrã de Tarefas a realizar por um Utilizador Figura 20 - Ecrã de inicio de novos Processos 26

27 7 Conclusão Este caderno de desenho, sendo o último de uma série de três cadernos entregues no momento anterior ao inicio da codificação da solução, vem finalizar um período com a duração de cerca de três meses, desenrolado no âmbito da cadeira de Projecto de IGE. Ao longo do período referenciado foram efectuadas reuniões com os coordenadores, que desempenharam papéis de clientes e de críticos, nas quais foram fornecidas todas as informações acerca da solução a construir a melhor forma de o fazer. Da elaboração deste projecto, os autores ficam cada vez mais com a imagem de que o projecto deve ser encarado como um todo, e que só atribuindo o mesmo esforço a todas as fases, este poderá originar um resultado positivo. A fase de desenho sofrerá certamente algumas iterações, resultando possivelmente numa nova versão deste documento. No entanto, considera-se que a corrente versão consegue responder às questões mais importantes e aos pormenores delicados do desenho do sistema idocument, constituindo-se como uma ferramenta fundamental para a fase de implementação, que se iniciará em breve. 27

28 8 Bibliografia [1] O Neill, Henrique; Nunes, Mauro; Fundamental de UML, FCA Editora de Informática, [2] Site Modeling Style [3] Microsoft SharePoint Portal Server 2003 Overview [4] Ultimus Motor de Workflow 28