Lisboa, 18 de Janeiro de 2004
Realizado por:
o Bruno Martins Nº 17206 o Cátia Chasqueira Nº 17211
Índice
1 Índice de Figuras ... 3 2 Versões ... 4 3 Introdução... 5 3.1 Finalidade ... 5 3.2 Objectivo ... 5 3.3 Estrutura ... 5 4 Modelo de Instalação... 6 4.1 Desenho da Instalação ... 7 5 Modelo de Implementação ... 85.1 Diagrama de Componentes para Código fonte... 9
5.2 Diagrama de Componentes para Interface... 10
6 Modelo de Desenho... 11
6.1 Diagrama de Pacotes ... 12
6.2 Diagrama de Classes... 13
6.3 Descrição das Classes... 14
6.4 Diagramas de Estados... 17
6.5 Interfaces ... 21
7 Conclusão ... 27
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... 10
Figura 4 - Diagrama de Pacotes do iDocument... 12
Figura 5 - Diagrama de Classes do iDocument, sem atributos ou métodos ... 13
Figura 6 - Diagrama de Estados de um Documento... 18
Figura 7 - Diagrama de Estados de um Utilizador ... 19
Figura 8 - Diagrama de Estados de uma Versão de Documento... 19
Figura 9 - Diagrama de Estados de uma Notificação ... 20
Figura 10 - Ecrã de Criação de Tipo de Documento ... 21
Figura 11 - Ecrã de Criação de Template... 22
Figura 12 - Ecrã de Digitalização de Documento... 22
Figura 13 - Ecrã de Emissão de Nota/Despacho/Parecer ... 23
Figura 14 - Ecrã de Envio de Documento ... 23
Figura 15 - Ecrã de Inbox de um Utilizador... 24
Figura 16 - Ecrã de Outbox de um Utilizador ... 24
Figura 17 - Ecrã de Organização de Pastas de um Utilizador ... 25
Figura 18 - Ecrã de Registo de um Documento... 25
Figura 19 - Ecrã de Tarefas a realizar por um Utilizador... 26
2 Versões
Versão Data Descrição
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.
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 email 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.
4.1 Desenho da Instalação
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.
5.1 Diagrama de Componentes para Código fonte
5.2 Diagrama de Componentes para Interface
My Site Inbox iDocument OutBox
Pastas
Digitalizar
Registar
Administração Log de Sistema
Criar Grupos Criar Tipo Enviar Notificação Versionar Pesquisar Enviar Email Imprimir Enviar Fax Criar Template
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
6.1 Diagrama de Pacotes
6.3 Descrição das Classes
DocumentoElemento 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.
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).
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, email, 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.
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.
[entrou no sistema]
Cheked-Out Activo
Arquivado Registo Básico
[sistema preenche os atributos básicos do documento]
[utilizador preenche atributos detalhados]
Registo Detalhado [utilizador preenche atributos
detalhados]
[utilizador tem posse do documento]
Check In
Figura 7 - Diagrama de Estados de um Utilizador
Nova
Vista
Encaminhada
[utilizador ainda nao deu seguimento à notificação]
Com limite temporal Sem limite temporal Com limite excedido [passou o prazo de
encaminhamento] Por Encaminhar
6.5 Interfaces
Este ponto do caderno pretende ser uma evolução à secção 3.1.2. 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 11 - Ecrã de Criação de Template
Figura 13 - Ecrã de Emissão de Nota/Despacho/Parecer
Figura 15 - Ecrã de Inbox de um Utilizador
Figura 17 - Ecrã de Organização de Pastas de um Utilizador
Figura 19 - Ecrã de Tarefas a realizar por um Utilizador
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.
8 Bibliografia
[1] O’Neill, Henrique; Nunes, Mauro; Fundamental de UML, FCA – Editora de Informática, 2001. [2] Site Modeling Style
http://www.modelingstyle.info/
[3] Microsoft SharePoint Portal Server 2003 Overview http://www.microsoft.com/sharepoint
[4] Ultimus – Motor de Workflow http://www.ultimus.com/
