Вы находитесь на странице: 1из 12

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

Sistema de Registro em Curso

Documento de Arquitetura de Software


Verso 1.0
Histrico da Reviso

Data 21/Maro/1999

Verso 1.0

Descrio Documento de Arquitetura de Software gerado utilizando o gabarito Rational SoDA e o modelo Rational Rose.

Autor S. Johnson

ndice

1. Introduo 2. Representao da Arquitetura 3. Objetivos e Restries da Arquitetura 4. Visualizao de Caso de Uso 5. Visualizao Lgica 6. Visualizao de Processo 7. Visualizao da Implementao 8. Tamanho e Desempenho 9. Qualidade
Documento de Arquitetura de Software Introduo
1.1 Objetivo

Este documento fornece uma viso arquitetural abrangente do sistema, usando diversas vises de arquitetura para representar diferentes aspectos do sistema. Ele pretende capturar e transmitir as decises arquiteturas significativas que foram tomadas em relao ao sistema.
1.2 Escopo

Este Documento de Arquitetura de Software fornece uma viso 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 Anlise e Design do C-Registration implementado no Rose. A maior parte das sees foi extrada do Modelo Rose utilizando SoDA e o gabarito de Documento de Arquitetura de Software.
1.3 Definies, Acrnimos e Abreviaes

Consulte o Glossrio [4].

1 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

1.4 Referncias As referncias aplicveis so:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Course Billing Interface Specification, WC93332, 1985, Wylie College Press. Course Catalog Database Specification, WC93422, 1985, Wylie College Press. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT. Course Registration System Supplementary Specification, WyIT400, V1.0, 1999, Wylie College, IT.

2. Representao da Arquitetura
Este documento apresenta a arquitetura como uma srie de visualizaes; visualizao caso de uso, visualizao lgica, visualizao do processo e visualizao da implementao. No existe uma visualizao de implementao separada descrita neste documento. Elas so visualizaes em um modelo UML (linguagem de modelagem unificada) subjacente desenvolvido utilizando o Rational Rose.

3. Objetivos e Restries da Arquitetura Existem alguns requisitos chave e restries do sistema que tm um relacionamento significativo com a arquitetura. So eles: 1. O Sistema de Catlogo de Cursos legado existente no Wylie College deve ser acessado para recuperar todas as informaes de cursos para o semestre atual. O C-Registration System deve suportar os formatos de dados e o DBMS do Sistema de Catlogo 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 Especificao da Interface de Faturamento do Curso [1]. 3. Toda a funcionalidade de estudante, professor e Secretrio deve estar disponvel nos PCs do campus local e em PCs remotos com conexes dial-up Internet. 4. O C-Registration System deve assegurar a proteo completa dos dados contra acesso no-autorizado. Todos os acessos remotos esto sujeitos a identificao do usurio 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 Viso [3] e na Especificao Complementar [15], devem ser levados em considerao medida que a arquitetura for desenvolvida. 4. Visualizao de Caso de Uso
Uma descrio da visualizao de casos de uso da arquitetura de software. A Visualizao de Caso de Uso uma entrada importante para a seleo do conjunto de cenrios e/ou casos de uso que so o foco de uma iterao. Ela descreve o conjunto de cenrios e/ou os casos de uso que representam alguma funcionalidade central e significativa. Tambm descreve o conjunto de cenrios e/ou casos de uso que possuem cobertura arquitetural substancial (que exercita vrios elementos de arquitetura) ou que enfatizam ou ilustram um determinado ponto complicado da arquitetura.

2 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

Os casos de uso do C-Registration so: - Login - Registrar em Cursos - Manter Informaes do Estudante - Manter Informaes do Professor - Selecionar Cursos a Lecionar - Submeter Notas - Visualizar Carto de Relatrio - Fechar Registro. Esses casos de uso so iniciados pelos agentes estudante, professor ou secretrio. Alm disso, ocorre a interao com agentes externos: Catlogo de Cursos e Sistema de Faturamento. 4.1 Casos de Uso Significativos para Arquitetura

Nome do Diagrama: Casos de Uso Significativos para a Arquitetura


4.1.1 Fechar Registro

Breve Descrio: Esse caso de uso permite que um Secretrio feche o processo de

3 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

registro. As ofertas de curso que no tm estudantes suficientes so canceladas. As ofertas de curso devem ter no mnimo trs estudantes nelas. O sistema de faturamento notificado para cada estudante em cada oferta de curso que no for cancelada, para que o estudante possa ser cobrado pela oferta de curso. O principal agente desse caso de uso o Secretrio. O Sistema de Faturamento um agente envolvido nesse caso de uso.
4.1.2 Login

Breve Descrio: Este caso de uso descreve como um usurio efetua login no Sistema de Registro em Curso. Os agentes que iniciam esse caso de uso so Estudante, Professor e Secretrio.
4.1.3 Manter Informaes do Professor

Breve Descrio: Esse caso de uso permite que o secretrio mantenha informaes sobre os professores no sistema de registro. Isso abrange a incluso, a modificao e a excluso de professores do sistema. O agente desse caso de uso o Secretrio.
4.1.4 Selecionar Cursos a Lecionar

Breve Descrio: Este caso de uso permite que um professor selecione as ofertas de curso (sero fornecidos cursos com data e hora especficos) no catlogo de cursos dos cursos para os quais ele/ela seja elegvel e deseje lecionar no semestre seguinte. O agente que inicia esse caso de uso o Professor. O Sistema de Catlogo de Cursos um agente no caso de uso.
4.1.5 Registrar em Cursos

Breve Descrio: Este caso de uso permite que um estudante se registre em cursos no semestre atual. O estudante tambm pode modificar ou excluir selees de cursos se forem feitas alteraes no perodo de incluso/eliminao no incio do semestre. O Sistema de Faturamento notificado de todas as atualizaes de registro. O Catlogo 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 Catlogo de Cursos um agente no caso de uso.
4.1.6 Visualizar Carto de Relatrio

Breve Descrio: Este caso de uso permite que um estudante visualize seu carto de relatrio para o semestre concludo anteriormente. O estudante o agente desse caso de uso.
4.1.7 Submeter Notas

Breve Descrio: Este caso de uso permite que um professor submeta notas de estudantes para uma ou mais classes concludas no semestre anterior. O agente nesse caso de uso o Professor.
4.1.8 Manter Informaes do Estudante

Breve Descrio: Esse caso de uso permite que o secretrio mantenha informaes sobre os estudantes no sistema de registro. Isso abrange a incluso, a modificao e a excluso de estudantes do sistema. O agente desse caso de uso o Secretrio. 5. Visualizao Lgica Uma descrio da visualizao lgica da arquitetura. Descreve as classes mais importantes, sua organizao em pacotes de servio e subsistemas e a organizao desses subsistemas em camadas. Tambm descreve as realizaes de casos de uso mais importantes como, por exemplo, os aspectos dinmicos da arquitetura. Diagramas de classe podem ser includos para ilustrar os relacionamentos entre as classes, subsistemas, pacotes e camadas significativos da arquitetura. A visualizao lgica do sistema de registro em curso composta de 3 pacotes principais: Interface com o Usurio, Servios de Negcios e Objetos de Negcios. O Pacote de Interface com o Usurio contm classes para cada um dos formulrios utilizados pelos agentes para comunicar com o Sistema. Existem classes de limite para suportar login, manuteno de planejamentos, manuteno de informaes de professores, seleo de cursos, submisso de notas, manuteno de informaes de estudantes, fechamento de registro e visualizao de cartes de relatrio. O Pacote de Servios de Negcios contm classes de controle para fazer interface com o sistema financeiro,

4 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

controlar o registro de estudantes e gerenciar a avaliao dos estudantes. O Pacote de Objetos de Negcios 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 Catlogo de Cursos.
5.1 Viso Geral da Arquitetura - Disposio em Camadas de Pacotes e Subsistemas

5.1.1 Aplicativo

camada Esta camada de aplicativo tem todas as classes de limite que representam as telas do aplicativo visualizadas pelo usurio. Essa camada depende da camada de Objetos de Processo; isso aumenta a separao do cliente da mid-tier.
5.1.2 Servios de Negcios

camada A camada de processo Servios de Negcios 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 Servios de Negcios depende da camada de Objetos de Processo; isso aumenta a separao do cliente da mid-tier.
5.1.3 Middleware

camada A camada Middleware suporta o acesso ao DBMS Relacional e ao OODBMS.


5.1.4 Reutilizao Base

O pacote Reutilizao Base inclui classes para suportar funes de lista e padres.

6. Visualizao do Processo
Uma descrio da visualizao do processo da arquitetura. Descreve as tarefas (processos e encadeamentos) envolvidas na execuo do sistema, suas interaes e configuraes. Tambm descreve a alocao de objetos e

5 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

classes para tarefas. O Modelo de Processo ilustra as classes de registro em curso organizadas como processos executveis. Existem processos para suportar o registro de estudantes, funes de professores, fechamento de registro e acesso ao Sistema Financeiro e ao Sistema de Catlogo de Cursos externos. 6.1 Processos

Nome do Diagrama: Processos


6.1.1 CourseCatalogSystemAccess

Esse processo gerencia o acesso ao Sistema de Catlogo de Cursos legado. Ele pode ser compartilhado por vrios usurios 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, so utilizados para recuperar itens de forma assncrona do sistema legado. Mecanismos de Anlise: - Interface Legada Rastreabilidade de Requisitos: - Restries de Design: O sistema deve integrar-se ao sistema legado existente (banco de dados do catlogo de cursos).

6.1.2 CourseCatalog

6 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

O catlogo 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 padro Gamma). Ela funciona para certificar-se de que o CourseCatalogSystem possa ser acessado pela interface ICourseCatalog para o subsistema.

6.1.3 CourseRegistrationProcess

H uma instncia desse processo para cada estudante que est atualmente se registrando em cursos.

6.1.4 RegistrationController

Isso suporta o caso de uso, permitindo que um estudante se registre em cursos no semestre atual. O estudante tambm pode modificar ou excluir selees de cursos se forem feitas alteraes no perodo de incluso/eliminao no incio do semestre. Mecanismos de Anlise: - Distribuio

6.1.5 StudentApplication

Gerencia a funcionalidade do estudante, incluindo o processamento da interface com o usurio e a coordenao com os processos de negcios. H uma instncia desse processo para cada estudante que est atualmente se registrando em cursos.

6.1.6 MainStudentForm

Controla a interface do aplicativo do estudante. Controla a famlia de formulrios utilizada pelo Estudante.

6.1.7 BillingSystemAccess

Esse processo se comunica com o Sistema Financeiro (Faturamento) externo para iniciar o faturamento de estudantes.

6.1.8 CloseRegistrationProcess

O processo Fechar Registro iniciado no final do perodo de tempo de registro. Esse processo se comunica com o processo que controla o acesso ao Sistema Financeiro.

6.1.9 BillingSystem

O Sistema Financeiro suporta a submisso de contas de estudantes para os cursos em que o estudante se registrou no semestre atual. Mecanismos de Anlise: - Interface Legada

6.1.10 CloseRegistrationController

O Controlador de Fechamento de Registro controla o acesso ao Sistema Financeiro.

7 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

Mecanismos de Anlise: - Distribuio

6.2 Processo para o Design de Elementos

Nome do Diagrama: Processo para o Design de Elementos


6.2.1 CourseCache

O encadeamento Cache do Curso utilizado para recuperar itens de forma assncrona a partir do Sistema de Catlogo de Cursos legado.
6.2.2 OfferingCache

O encadeamento OfferingCache utilizado para recuperar itens de forma assncrona a partir do Sistema de Catlogo de Cursos legado.

6.2.3 Curso

Uma classe oferecida pela universidade. Mecanismos de Anlise: - Persistncia - Interface Legada

8 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

6.2.4 CourseOffering

Uma oferta especfica para um curso, incluindo dias da semana e horrios. Mecanismos de Anlise: - Persistncia - Interface Legada

6.3 Modelo de Processo para o Design de Dependncias de Modelo

Nome do Diagrama: Modelo de Processo para o Design de Dependncias de Modelo

6.4 Processos para a Implementao

9 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

Nome do Diagrama: Processos para a Implementao 6.4.1 Remote

* 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 mtodos especificados em uma interface remota esto disponveis remotamente. * As classes de implementao podem implementar qualquer quantidade de interfaces remotas e pode estender outras classes de implementao remotas.
6.4.2 Runnable

* A interface Runnable deve ser implementada por qualquer classe cujas instncias sero executadas por um encadeamento. A classe deve definir um mtodo sem argumentos denominado run. * Essa interface destinada a fornecer um protocolo comum para objetos que desejam executar cdigo enquanto esto ativos. Por exemplo, Runnable implementado pela classe Thread. * Estar ativo simplesmente significa que um encadeamento foi iniciado e ainda no foi parado.
6.4.3 Thread

* Um thread um encadeamento de execuo em um programa. A Java Virtual Machine permite que um aplicativo tenha vrios encadeamentos de execuo simultaneamente. * Cada encadeamento tem uma prioridade. Os encadeamentos com maior prioridade so executados em preferncia aos encadeamentos com menor prioridade. Cada encadeamento tambm pode ou no ser marcado como um daemon. Quando o cdigo

10 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

em execuo 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. Visualizao da Implementao Uma descrio da visualizao da implementao da arquitetura que descreve os diversos ns fsicos para as mais tpicas configuraes de plataforma. Tambm descreve a alocao de tarefas (a partir da Visualizao do Processo) para os ns fsicos. Esta seo organizada por configurao de rede fsica; cada configurao ilustrada por um diagrama de implementao, seguido de um mapeamento dos processos para cada processador.

Nome do Diagrama: Visualizao da Implementao


7.1 PC Desktop Externo

Os estudantes se registram em cursos utilizando PCs desktop externos conectados ao Servidor da Universidade via dial-up Internet.
7.2 PC Desktop

Os estudantes se registram em cursos utilizando PCs Desktop locais conectados diretamente ao Servidor da Universidade via LAN. Esses PCs locais tambm so utilizados pelos professores para selecionar cursos e submeter notas de estudantes. O Secretrio utiliza esses PCs locais para manter informaes sobre estudantes e professores.
7.3 Servidor de Registro

O Servidor de Registro o Servidor UNIX principal do campus. Todas as faculdades e estudantes tm acesso ao Servidor pela LAN do campus.
7.4 Catlogo de Cursos

O Sistema de Catlogo de Cursos um sistema legado que contm o catlogo de cursos completo. O acesso a ele est disponvel pelo Servidor da Universidade e pela LAN.
7.5 Sistema de Faturamento

O Sistema de Faturamento (tambm denominado o Sistema Financeiro) um sistema legado que gera as contas

11 de 12

11/09/2012 16:08

Exemplo: Documento de Arquitetura de Software

http://www.rrochas.com.br/processo/arquitetura/sadoc_v1.htm

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 Especificao Complementar [15]: 1. O sistema deve suportar at 2.000 usurios simultneos utilizando o banco de dados central ao mesmo tempo e at 500 usurios simultneos utilizando os servidores locais a qualquer momento. 2. O sistema fornecer acesso ao banco de dados do catlogo de cursos legado com um tempo de espera de at 10 segundos. 3. O sistema deve ser capaz de concluir 80% de todas as transaes em 2 minutos. 4. A parte cliente deve requerer menos de 20 MB de espao em disco e 32 MB de RAM. A arquitetura selecionada suporta os requisitos de dimensionamento e velocidade pela implementao 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 necessrios requisitos mnimos de disco e memria na parte cliente do PC. 9. Qualidade A arquitetura de software suporta os requisitos de qualidade, conforme estipulado na Especificao Complementar [15]: 1. A interface com o usurio de desktop deve estar em conformidade com o Windows 95/98. 2. A interface com o usurio do C-Registration System dever ser projetada para facilidade de utilizao e dever ser apropriada para uma comunidade de usurios experiente com computadores, sem treinamento adicional no Sistema. 3. Cada recurso do C-Registration System deve ter ajuda on-line interna para o usurio. A Ajuda On-line deve incluir instrues passo a passo sobre a utilizao do Sistema. A Ajuda On-line deve incluir definies para termos e acrnimos. 4. O C-Registration System deve estar disponvel 24 horas por dia, 7 dias por semana. No deve haver mais que 4% de tempo de inatividade. 5. O Tempo Mdio 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 fcil acesso a upgrades do sistema.

Copyright (c) IBM Corp. 1987, 2004. Todos os direitos reservados.

Exemplo da Web do Projeto de Registro em Curso Verso 2001.03

12 de 12

11/09/2012 16:08

Вам также может понравиться