Exemplo: Documento de Arquitetura de Software

Transcrição

1 Sistema de Registro em Curso Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 21/Março/ Documento de Arquitetura de Software gerado utilizando o gabarito Rational SoDA e o modelo Rational Rose. S. Johnson Índice 1. Introdução 2. Representação da Arquitetura 3. Objetivos e Restrições da Arquitetura 4. Visualização de Caso de Uso 5. Visualização Lógica 6. Visualização de Processo 7. Visualização da Implementação 8. Tamanho e Desempenho 9. Qualidade Documento de Arquitetura de Software Introdução 1.1 Objetivo 1.2 Escopo Este documento fornece uma visão arquitetural abrangente do sistema, usando diversas visões de arquitetura para representar diferentes aspectos do sistema. Ele pretende capturar e transmitir as decisões arquiteturas significativas que foram tomadas em relação ao sistema. Este Documento de Arquitetura de Software fornece uma visão geral de arquitetura do C-Registration System. O C- Registration System está sendo desenvolvido pelo Wylie College para suportar o registro on-line em cursos. Este Documento foi gerado diretamente a partir do Modelo de Análise e Design do C-Registration implementado no Rose. A maior parte das seções foi extraída do Modelo Rose utilizando SoDA e o gabarito de Documento de Arquitetura de Software. Página 1 de 14

2 1.3 Definições, Acrônimos e Abreviações 1.4 Referências Consulte o Glossário [4]. As referências aplicáveis são: 1. Course Billing Interface Specification, WC93332, 1985, Wylie College Press. 2. Course Catalog Database Specification, WC93422, 1985, Wylie College Press. 3. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT. 4. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT. 5. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT. 6. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT. 7. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT. 8. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT. 9. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT. 10. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT. 11. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT. 12. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT. 13. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT. 14. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT. 15. Course Registration System Supplementary Specification, WyIT400, V1.0, 1999, Wylie College, IT. 2. Representação da Arquitetura Este documento apresenta a arquitetura como uma série de visualizações; visualização caso de uso, visualização lógica, visualização do processo e visualização da implementação. Não existe uma visualização de implementação separada descrita neste documento. Elas são visualizações em um modelo UML (linguagem de modelagem unificada) subjacente desenvolvido utilizando o Rational Rose. 3. Objetivos e Restrições da Arquitetura Existem alguns requisitos chave e restrições do sistema que têm um relacionamento significativo com a arquitetura. São eles: 1. O Sistema de Catálogo de Cursos legado existente no Wylie College deve ser acessado para recuperar todas as informações de cursos para o semestre atual. O C-Registration System deve suportar os formatos de dados e o DBMS do Sistema de Catálogo de Cursos legado [2]. 2. O Sistema Financeiro legado existente no Wylie College deve receber uma interface para suportar o faturamento dos estudantes. Essa interface está definida na Especificação da Interface de Faturamento do Curso [1]. 3. Toda a funcionalidade de estudante, professor e Secretário deve estar disponível nos PCs do campus local e em PCs remotos com conexões dial-up à Internet. 4. O C-Registration System deve assegurar a proteção completa dos dados contra acesso não-autorizado. Todos os acessos remotos estão sujeitos a identificação do usuário e controle de senha. 5. O C-Registration System será implementado como um sistema cliente/servidor. A parte cliente reside em PCs e a parte servidor deve operar no Servidor UNIX do Wylie College. [3] 6. Todos os requisitos de desempenho e carga, conforme estipulados no Documento de Visão [3] e na Especificação Complementar [15], devem ser levados em consideração à medida que a arquitetura for desenvolvida. 4. Visualização de Caso de Uso Uma descrição da visualização de casos de uso da arquitetura de software. A Visualização de Caso de Uso é uma Página 2 de 14

3 entrada importante para a seleção do conjunto de cenários e/ou casos de uso que são o foco de uma iteração. Ela descreve o conjunto de cenários e/ou os casos de uso que representam alguma funcionalidade central e significativa. Também descreve o conjunto de cenários e/ou casos de uso que possuem cobertura arquitetural substancial (que exercita vários elementos de arquitetura) ou que enfatizam ou ilustram um determinado ponto complicado da arquitetura. Os casos de uso do C-Registration são: - Login - Registrar em Cursos - Manter Informações do Estudante - Manter Informações do Professor - Selecionar Cursos a Lecionar - Submeter Notas - Visualizar Cartão de Relatório - Fechar Registro. Esses casos de uso são iniciados pelos agentes estudante, professor ou secretário. Além disso, ocorre a interação com agentes externos: Catálogo de Cursos e Sistema de Faturamento. 4.1 Casos de Uso Significativos para Arquitetura Página 3 de 14

4 Nome do Diagrama: Casos de Uso Significativos para a Arquitetura Fechar Registro Breve Descrição: Esse caso de uso permite que um Secretário feche o processo de registro. As ofertas de curso que não têm estudantes suficientes são canceladas. As ofertas de curso devem ter no mínimo três estudantes nelas. O sistema de faturamento é notificado para cada estudante em cada oferta de curso que não for cancelada, para que o estudante possa ser cobrado pela oferta de curso. O principal agente desse caso de uso é o Secretário. O Sistema de Faturamento é um agente envolvido nesse caso de uso Login Manter Informações do Professor Breve Descrição: Este caso de uso descreve como um usuário efetua login no Sistema de Registro em Curso. Os agentes que iniciam esse caso de uso são Estudante, Professor e Secretário. Página 4 de 14

5 4.1.4 Selecionar Cursos a Lecionar Registrar em Cursos Visualizar Cartão de Relatório Submeter Notas Manter Informações do Estudante Breve Descrição: Esse caso de uso permite que o secretário mantenha informações sobre os professores no sistema de registro. Isso abrange a inclusão, a modificação e a exclusão de professores do sistema. O agente desse caso de uso é o Secretário. Breve Descrição: Este caso de uso permite que um professor selecione as ofertas de curso (serão fornecidos cursos com data e hora específicos) no catálogo de cursos dos cursos para os quais ele/ela seja elegível e deseje lecionar no semestre seguinte. O agente que inicia esse caso de uso é o Professor. O Sistema de Catálogo de Cursos é um agente no caso de uso. Breve Descrição: Este caso de uso permite que um estudante se registre em cursos no semestre atual. O estudante também pode modificar ou excluir seleções de cursos se forem feitas alterações no período de inclusão/eliminação no início do semestre. O Sistema de Faturamento é notificado de todas as atualizações de registro. O Catálogo de Cursos fornece uma lista de todas as ofertas de curso para o semestre atual. O agente principal desse caso de uso é o estudante. O Sistema de Catálogo de Cursos é um agente no caso de uso. Breve Descrição: Este caso de uso permite que um estudante visualize seu cartão de relatório para o semestre concluído anteriormente. O estudante é o agente desse caso de uso. Breve Descrição: Este caso de uso permite que um professor submeta notas de estudantes para uma ou mais classes concluídas no semestre anterior. O agente nesse caso de uso é o Professor. Breve Descrição: Esse caso de uso permite que o secretário mantenha informações sobre os estudantes no sistema de registro. Isso abrange a inclusão, a modificação e a exclusão de estudantes do sistema. O agente desse caso de uso é o Secretário. 5. Visualização Lógica Uma descrição da visualização lógica da arquitetura. Descreve as classes mais importantes, sua organização em pacotes de serviço e subsistemas e a organização desses subsistemas em camadas. Também descreve as realizações de casos de uso mais importantes como, por exemplo, os aspectos dinâmicos da arquitetura. Diagramas de classe podem ser incluídos para ilustrar os relacionamentos entre as classes, subsistemas, pacotes e camadas significativos da arquitetura. A visualização lógica do sistema de registro em curso é composta de 3 pacotes principais: Interface com o Usuário, Serviços de Negócios e Objetos de Negócios. O Pacote de Interface com o Usuário contém classes para cada um dos formulários utilizados pelos agentes para comunicar com o Sistema. Existem classes de limite para suportar login, manutenção de planejamentos, manutenção de informações de professores, seleção de cursos, submissão de notas, manutenção de informações de estudantes, fechamento de registro e visualização de cartões de relatório. O Pacote de Serviços de Negócios contém classes de controle para fazer interface com o sistema financeiro, controlar o registro de estudantes e gerenciar a avaliação dos estudantes. O Pacote de Objetos de Negócios inclui classes de entidade para os artefatos da universidade (isto é, oferta de curso, planejamento) e classes de limite para a interface com o Sistema de Catálogo de Cursos. 5.1 Visão Geral da Arquitetura - Disposição em Camadas de Pacotes e Subsistemas Página 5 de 14

6 5.1.1 Aplicativo camada Esta camada de aplicativo tem todas as classes de limite que representam as telas do aplicativo visualizadas pelo usuário. Essa camada depende da camada de Objetos de Processo; isso aumenta a separação do cliente da mid-tier Serviços de Negócios camada A camada de processo Serviços de Negócios tem todas as classes de controlador que representam os gerenciadores de caso de uso que direcionam o comportamento do aplicativo. Essa camada representa a divisa cliente para mid-tier. A camada Serviços de Negócios depende da camada de Objetos de Processo; isso aumenta a separação do cliente da mid-tier Middleware camada A camada Middleware suporta o acesso ao DBMS Relacional e ao OODBMS Reutilização Base O pacote Reutilização Base inclui classes para suportar funções de lista e padrões. 6. Visualização do Processo Uma descrição da visualização do processo da arquitetura. Descreve as tarefas (processos e encadeamentos) envolvidas na execução do sistema, suas interações e configurações. Também descreve a alocação de objetos e Página 6 de 14

7 6.1 Processos classes para tarefas. O Modelo de Processo ilustra as classes de registro em curso organizadas como processos executáveis. Existem processos para suportar o registro de estudantes, funções de professores, fechamento de registro e acesso ao Sistema Financeiro e ao Sistema de Catálogo de Cursos externos CourseCatalogSystemAccess Nome do Diagrama: Processos Esse processo gerencia o acesso ao Sistema de Catálogo de Cursos legado. Ele pode ser compartilhado por vários usuários que se registram em cursos. Isso permite uma cache de ofertas e cursos recuperados recentemente para aprimorar o desempenho. Os encadeamentos separados no processo CourseCatalog, CourseCache e OfferingCache, são utilizados para recuperar itens de forma assíncrona do sistema legado. Mecanismos de Análise: - Interface Legada Rastreabilidade de Requisitos: Página 7 de 14

8 - Restrições de Design: O sistema deve integrar-se ao sistema legado existente (banco de dados do catálogo de cursos) CourseCatalog O catálogo integral de todos os cursos e ofertas de curso oferecidas pela universidade, incluindo aquelas de semestres anteriores. Essa classe age como um adaptador (consulte o padrão Gamma). Ela funciona para certificar-se de que o CourseCatalogSystem possa ser acessado pela interface ICourseCatalog para o subsistema CourseRegistrationProcess Há uma instância desse processo para cada estudante que está atualmente se registrando em cursos RegistrationController Isso suporta o caso de uso, permitindo que um estudante se registre em cursos no semestre atual. O estudante também pode modificar ou excluir seleções de cursos se forem feitas alterações no período de inclusão/eliminação no início do semestre. Mecanismos de Análise: - Distribuição StudentApplication Gerencia a funcionalidade do estudante, incluindo o processamento da interface com o usuário e a coordenação com os processos de negócios. Há uma instância desse processo para cada estudante que está atualmente se registrando em cursos MainStudentForm Controla a interface do aplicativo do estudante. Controla a família de formulários utilizada pelo Estudante BillingSystemAccess Esse processo se comunica com o Sistema Financeiro (Faturamento) externo para iniciar o faturamento de estudantes CloseRegistrationProcess O processo Fechar Registro é iniciado no final do período de tempo de registro. Esse processo se comunica com o processo que controla o acesso ao Sistema Financeiro BillingSystem O Sistema Financeiro suporta a submissão de contas de estudantes para os cursos em que o estudante se registrou no semestre atual. Página 8 de 14

9 Mecanismos de Análise: - Interface Legada CloseRegistrationController O Controlador de Fechamento de Registro controla o acesso ao Sistema Financeiro. Mecanismos de Análise: - Distribuição 6.2 Processo para o Design de Elementos CourseCache Nome do Diagrama: Processo para o Design de Elementos O encadeamento Cache do Curso é utilizado para recuperar itens de forma assíncrona a partir do Sistema de Catálogo de Cursos legado OfferingCache Página 9 de 14

10 O encadeamento OfferingCache é utilizado para recuperar itens de forma assíncrona a partir do Sistema de Catálogo de Cursos legado Curso Uma classe oferecida pela universidade. Mecanismos de Análise: - Persistência - Interface Legada CourseOffering Uma oferta específica para um curso, incluindo dias da semana e horários. Mecanismos de Análise: - Persistência - Interface Legada 6.3 Modelo de Processo para o Design de Dependências de Modelo Página 10 de 14

11 Nome do Diagrama: Modelo de Processo para o Design de Dependências de Modelo 6.4 Processos para a Implementação Página 11 de 14

12 Nome do Diagrama: Processos para a Implementação Remote Runnable Thread * A interface Remote serve para identificar todos os objetos remotos. Qualquer objeto que seja do tipo remoto deve implementar direta ou indiretamente essa interface. Apenas os métodos especificados em uma interface remota estão disponíveis remotamente. * As classes de implementação podem implementar qualquer quantidade de interfaces remotas e pode estender outras classes de implementação remotas. * A interface Runnable deve ser implementada por qualquer classe cujas instâncias serão executadas por um encadeamento. A classe deve definir um método sem argumentos denominado run. * Essa interface é destinada a fornecer um protocolo comum para objetos que desejam executar código enquanto estão ativos. Por exemplo, Runnable é implementado pela classe Thread. * Estar ativo simplesmente significa que um encadeamento foi iniciado e ainda não foi parado. * Um thread é um encadeamento de execução em um programa. A Java Virtual Machine Página 12 de 14

13 permite que um aplicativo tenha vários encadeamentos de execução simultaneamente. * Cada encadeamento tem uma prioridade. Os encadeamentos com maior prioridade são executados em preferência aos encadeamentos com menor prioridade. Cada encadeamento também pode ou não ser marcado como um daemon. Quando o código em execução em algum encadeamento cria um novo objeto Thread, o novo encadeamento tem sua prioridade inicialmente definida como sendo igual a prioridade do encadeamento que a criou e será um encadeamento daemon se e somente se o encadeamento criador for um daemon. 7. Visualização da Implementação Uma descrição da visualização da implementação da arquitetura que descreve os diversos nós físicos para as mais típicas configurações de plataforma. Também descreve a alocação de tarefas (a partir da Visualização do Processo) para os nós físicos. Esta seção é organizada por configuração de rede física; cada configuração é ilustrada por um diagrama de implementação, seguido de um mapeamento dos processos para cada processador. Nome do Diagrama: Visualização da Implementação 7.1 PC Desktop Externo 7.2 PC Desktop 7.3 Servidor de Registro Os estudantes se registram em cursos utilizando PCs desktop externos conectados ao Servidor da Universidade via dial-up à Internet. Os estudantes se registram em cursos utilizando PCs Desktop locais conectados diretamente ao Servidor da Universidade via LAN. Esses PCs locais também são utilizados pelos professores para selecionar cursos e submeter notas de estudantes. O Secretário utiliza esses PCs locais para manter informações sobre estudantes e professores. O Servidor de Registro é o Servidor UNIX principal do campus. Todas as faculdades e estudantes têm Página 13 de 14

14 7.4 Catálogo de Cursos 7.5 Sistema de Faturamento acesso ao Servidor pela LAN do campus. O Sistema de Catálogo de Cursos é um sistema legado que contém o catálogo de cursos completo. O acesso a ele está disponível pelo Servidor da Universidade e pela LAN. O Sistema de Faturamento (também denominado o Sistema Financeiro) é um sistema legado que gera as contas de estudantes a cada semestre. 8. Tamanho e Desempenho A arquitetura de software escolhida suporta os principais requisitos de qualidade e prazo, conforme estipulado na Especificação Complementar [15]: 1. O sistema deve suportar até usuários simultâneos utilizando o banco de dados central ao mesmo tempo e até 500 usuários simultâneos utilizando os servidores locais a qualquer momento. 2. O sistema fornecerá acesso ao banco de dados do catálogo de cursos legado com um tempo de espera de até 10 segundos. 3. O sistema deve ser capaz de concluir 80% de todas as transações em 2 minutos. 4. A parte cliente deve requerer menos de 20 MB de espaço em disco e 32 MB de RAM. A arquitetura selecionada suporta os requisitos de dimensionamento e velocidade pela implementação de uma arquitetura cliente/servidor. A parte cliente é implementada em PCs locais no campus ou em PCs dial-up remotos. Os componentes foram projetados para assegurar que sejam necessários requisitos mínimos de disco e memória na parte cliente do PC. 9. Qualidade A arquitetura de software suporta os requisitos de qualidade, conforme estipulado na Especificação Complementar [15]: 1. A interface com o usuário de desktop deve estar em conformidade com o Windows 95/ A interface com o usuário do C-Registration System deverá ser projetada para facilidade de utilização e deverá ser apropriada para uma comunidade de usuários experiente com computadores, sem treinamento adicional no Sistema. 3. Cada recurso do C-Registration System deve ter ajuda on-line interna para o usuário. A Ajuda On-line deve incluir instruções passo a passo sobre a utilização do Sistema. A Ajuda On-line deve incluir definições para termos e acrônimos. 4. O C-Registration System deve estar disponível 24 horas por dia, 7 dias por semana. Não deve haver mais que 4% de tempo de inatividade. 5. O Tempo Médio Entre Falhas deve exceder 300 horas. 6. Os upgrades para a parte cliente PC do C-Registration devem poder ser transferidos por download do Servidor UNIX pela Internet. Esse recurso permite que os estudantes tenha fácil acesso a upgrades do sistema. Copyright (c) IBM Corp. 1987, Todos os direitos reservados. Exemplo da Web do Projeto de Registro em Curso Versão Página 14 de 14