Faculdade de Filosofia, Ciências e Letras de Caruaru - FAFICA Analise e Desenvolvimento de Software - ADS

Documento de Arquitetura da Aplicação
<Nome da Aplicação>

PI2 – Projeto Interdisciplinar 2 Professores: Maurício Manoel Coelho Júnior

Equipe: Nome do Aluno 1 Nome do Aluno 2

Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2.0 Nome do Aluno 3 Página 2 de 13 .

0 Este documentos de arquitetura da aplicação foi realizado pela equipe composta de graduandos em Ciência da Computação do Centro de Informática – CIn da Universidade Federal de Pernambuco – UFPE. Página 3 de 13 . ministrada em 2004.2. para ser entregue aos professores.Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. como parte das atividades da disciplina de Análise e Projeto de Sistemas.

pghms apb.0 Descrição Versão inicial do documento Versão revisada do documento Autor(es) apb. fjfbg. gamr. pghms Página 4 de 13 . fjfbg.0 2.Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. gamr.0 Histórico de Revisões Data 20/12/2004 25/02/2005 Versão 1.

...PDC........13 7.........Padrões de Projeto.......................................................................Singleton...........13 7.......2.....7 5.......0 Índice 1....9 Camada de Negócios:.................................................................................1...............................................................................Diagrama de Classes.................................Escopo.......................................................................................................Visão Geral da Arquitetura.Mapeamento de Classes de Análise................6 3........................................................................................................Objetivo.......................................................Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2.................6 2....13 Página 5 de 13 .............................................................................................................8 Camada de GUI/Comunicação:..................................................................9 Camada de Persistência......................................................................9 6......................................................................................................................13 7...................................................................................................................6 4..........................................................................................................................11 7.......Facade......3.Referências.................................................................................................

net/SSAA_DocumentoRequisitosFinalRevisado .net Página 6 de 13 .cjb. a descrição da arquitetura. Escopo Este documento deverá ser utilizado por todos os desenvolvedores durante todo o decorrer do projeto.Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. Página do SSAA http://www. Documento de análise do SSAA http://www. Nele é apresentado o mapeamento das classes de analise em elementos do projeto.net/~apb/ssaa/SSAA_DocumentoAnaliseFinal Revisado.doc 3.0 1.cjb.ssaa. Documento de requisitos do SSAA http://www.ssaa.ssaa. 2. Referências 1. implantação e pacotes e os padrões de projeto utilizados.cjb. 3. as diferentes visões desta nos diagramas de componentes. Objetivo Este documento tem como principal objetivo a definição da arquitetura do SSAA.doc 2.

0 4. conforme o padrão de projeto PDC – Persistent Data Collection. podem ser encontradas na seção 9 deste documento. Página 7 de 13 . Classes de análise Classes de projeto Fachada Data Hora TelaSubmeterDocumento TelaSubmeterDocumento ControladorSubmeterDocumento ControladorSubmeterDocumento CadastroDocumentos CadastroDocumentos IRepositorioCadastroDocumentos RepositorioCadastroDocumentosBDR Documento Documento FazerUpload SubsistemaFazerUpload ISubsistemaFazerUpload FachadaSubsistemaFazerUpload TelaCriarAreaSubmissao TelaCriarAreaSubmissao ControladorCriarAreaSubmissao ControladorCriarAreaSubmissao CadastroAreaSubmissao CadastroAreaSubmissao IRepositorioAreaSubmissao RepositorioAreaSubmissaoBDR AreaSubmissao AreaSubmissao TelaPostarMensagemSalaVirtual TelaPostarMensagemSalaVirtual ControladorSalaVirtual ControladorSalaVirtual CadastroMensagens CadastroMensagens IRepositorioCadastroMensagens RepositorioCadastroMensagensBDR SalaVirtual SalaVirtual Mensagem Mensagem Disciplina Disciplina Usuário Usuario Cada um dos cadastros (que representam coleções de entidades) foi mapeado em duas classes e uma interface.Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. Mapeamento de Classes de Análise Abaixo segue uma tabela com o mapeamento das classes de análise em elementos de projeto. Mais informações. sobre o padrão.

Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. Visão Geral da Arquitetura Nosso sistema utiliza a estruturação em camadas como ilustrado na figura abaixo: Página 8 de 13 .0 5.

□ Disciplina – representa as disciplinas da universidade. como a validação e verificação. o Fachada – Representa a classe de controle do sistema. o Coleções de Negócio – Representam os conjuntos das classes básicas. as coleções de negócio e a fachada. essas telas serão apresentadas via browser. • Camada de Negócios: É nesta camada que estão implementas todas as funcionalidades do sistema. o Classes básicas – Representam o mapeamento das entidades identificadas na modelagem. As principais classes básicas do sistema são: □ Usuario – representa os visitantes do SSAA que têm seu acesso restrito através de identificação única e pessoal. As classes que compõem esta camada são responsáveis pela Página 9 de 13 .Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. Todas as funcionalidades do sistema só podem ser acessadas pela Fachada. □ Documento – representa os documentos(arquivos) cadastrado no sistema. A camada de comunicação entra em contato com o resto do sistema utilizando os serviços que estão disponíveis na fachada. □ Mensagem – representa a mensagem postada na sala virtual. Nela estão contidas as classes básicas.0 • Camada de GUI/Comunicação: Esta camada representa as telas do sistema que interagem com os usuários e fazem a comunicação com a fachada(Servidor). Através destas classes que os elementos são pesquisados e inseridos no sistema. • Camada de Persistência Esta camada permite o armazenamento e a recuperação dos dados. □ SalaVirtual – representa a sala virtual do sistema. Contém as regras do negócio.

0 inclusão.Data: 25/02/05 <Nome do Projeto> Documento de Requisitos Versão: 2. modificação e pesquisa dos dados. As coleções de negócio fazem uso destas classes para realizar suas operações de inclusão e pesquisa. Página 10 de 13 .

6.n FachadaSubsitemaFazerUpload 1 1 Fachada 1 ISubsistemaFazerUpload 1 1 ControladorSubmeterDocumentos anexarArquivo() submeterDocumento() 1 1 1 ControladorCriarAreaSubmissao criarAreaSubmissao() 1 1 1 ControladorSalaVirtual postarMensagem() atualizarTelaUsuarios() 1 <<entity>> Usuario (from us uario) TelaCriarAreaSubmissao criarAreaSubmissao() 0...n TelaPostarMensagemSalaVirtual postarMensagem() 0..n 1 1 1 CadastroDocumentos insereDocumento() Documento titulo descricao Usuario AreaSumissao arquivo 1 1 CadastroAreasSubmissao inserirAreaSubmissao() existeAreaSubmissao() 1 AreaSubmissao titulo descricao data Disciplina Usuario 1 CadastroMensagens inserirMensagem() <<entity>> Usuario (from us uar io) SalaVirtual registrarMensagem() getUsuarios() 1 Data (from util) <<entity>> Disciplina (from disc iplina) 1 1 1 Mensagem nomeUsuario msg data hora Hora (from util) IRepositorioDocumento <<entity>> Usuario <<entity>> AreaSubmissao IRepositorioAreaSubmissao Data (from util) IRepositorioMensagens RepositorioDocumentos RepositorioAreaSubmissaoBDR RepositorioMensagensBDR . Diagrama de Classes TelaSubmeterDocumento anexarArquivo() submeterDocumento() 0.

. portanto. Singleton Assegura que a classe terá uma única instância e provê um ponto único de acesso a ela. foram analisados alguns padrões de projeto e selecionados aqueles que poderiam ser satisfatoriamente aplicados. que representa o conjunto de serviços oferecidos.1. e que dispõe do conjunto de dados que será compartilhado entre os usuários.7. acessível a partir de um único ponto específico.3. 7. Padrões de Projeto Os padrões de projeto possibilitam a reutilização de técnicas comprovadas com o objetivo de atender requisitos técnicos relacionados ao projeto de um sistema. PDC Conforme descrito na seção 4. dentro da classe Fachada. isolando os diversos componentes do sistema. em conjunto com uma interface para isolá-la do Cadastro. 7. para limitar a sua instância.2. Isto é importante por que é a Fachada que serve de ponto de acesso a todos os serviços oferecidos pelo SSAA. Para o SSAA. O SSAA implementa a Fachada como um ponto de acesso único para as funcionalidades. O padrão Singleton é usado. Facade O padrão de projeto Facade oferece um ponto centralizado e unificado para um conjunto de interfaces em um subsistema ou do sistema como um todo. o PDC – Persistent Data Collection – é um padrão de projeto que destrincha cada coleção persistente de dados em duas classes e uma interface: uma classe Cadastro da coleção propriamente dita (e diretamente ligada à classe Cadastro da análise) e uma classe Repositório que implementa uma forma de persistência física específica. 7.