DOCUMENTO DE ARQUITETURA –
PROJETO REDMAN
Antonio Junior
Eusyar Alves
Fernando Santos
Wagner Borges
INTRODUÇÃO
O documento de Arquitetura de Software tem
como objetivo fornecer a visão da arquitetura
existente do sistema RedMan.
 Tem como objetivo atingir o time de manutenção,
uma vez que este deverá servir como guia para a
implementação das novas features;
 Diagramas UML.

Interações e dependências entre as classes;
 Serão descritos também os módulos extras (fora da
linguagem usada por padrão pela aplicação, o java)
necessários para a execução do sistema


Descrever o ambiente necessária para sua
implantação.
FINALIDADE
Visão da arquitetura do software RedMan, de
maneira que esta deve ser compreendida da
melhor forma possível.
 O público alvo deste documento é o time de
manutenção.

Consultar o documento antes de realizar qualquer
atividade no código do projeto.
 Toda e qualquer mudança deve estar de acordo com
os termos demonstrados neste documento.
 Mudanças feitas no projeto que não representem o
conteúdo descrito no documento podem ser fator de
alteração deste mesmo

ESCOPO
Visão prévia do que deve ser alterado para se
manter determinada funcionalide;
 Estudo prévio evita que esforço seja gasto no
momento de manutenção para compreensão do
relacionamento entre este módulo e o restante do
projeto.

REFERÊNCIAS
Laranjeiras, Luis Augusto. Manutenção e
Evolução de Software - Aula 3. Universidade de
Brasília 2-2011.
 Corporation, Rational Software. Rational Unified
Process
RUP.
Copyright
1987-2001.
http://www.wthreex.com/rup/portugues/index.ht
m
 Junior, Antonio B. da Silva. de Carvalho, Eusyar
Alves. Santos, Fernando Souza. de Araujo,
Wagner Borges. Plano de Manutenção e Evolução
- Projeto RedMan. Universidade de Brasilia 22011.

REPRESENTAÇÃO DA ARQUITETURA

Para a representação da arquitetura serão
utilizados:
diagrama de classes;
 diagrama de sistema;
 diagramas de sequencia detalhados.

DIAGRAMA DE CLASSES
DIAGRAMA DE CLASSES
RedMan: Classe principal do sistema, é aqui
onde o sistema inicia e mantêm as suas funções
lógicas primárias. Funciona como uma main,
sendo nela a responsabilidade de instânciar as
classes que efetivamente farão o controle dos
aplicativos.
 HeartBeat: Classe responsável por se comunicar
com as demais aplicações RedMan em rede. Ela
funciona através de duas threads que recebem e
enviam dados para verificar se as aplicações
continuam funcionando como o esperado.
 GerPid.c: Programa em c que reconhece o Id do
processo.

DIAGRAMA DE CLASSES
AppMonitor: Classe de monitoramento de
aplicações. Nela está a lógica principal de
gerenciamento de aplicações através do RedMan.
Também é a maior classe do sistema.
 SMA: Classe que representa uma aplicação e o
seu estado.
 Log4RedManEven, Log4RedManOdd: Classe
responsável por criar logs.

DIAGRAMA DE SISTEMA
DIAGRAMA DE SEQUÊNCIA DETALHADO
VISÃO DE IMPLANTAÇÃO
VISÃO DE IMPLEMENTAÇÃO





Deve-se focar primeiramente na refatoração do
código;
Aplicando modelos e padrões de design, bem como a
divisão de pacotes e reestruturação das classes.
Uma das features a se realizar será a transferência do
módulo HeartBeat para a linguagem C.
Atualmente, o módulo apresenta outras duas classes
internas.
Ao se passar para a linguagem C, estas classes serão
divididas:


HbRec e HbSend.
De maneira nenhuma as fronteiras do software
deverão ser alteradas, mesmo quando a linguagem for
alterada.

A chamada às classes implementadas em C++ serão feitas
pela classe Java existente.
DIAGRAMA DE SEQUÊNCIA DETALHADO
TAMANHO E DESEMPENHO




O sistema deve suportar aplicações simultâneas
utilizando dois estados(ativo e stdby) para tentar
garantir que uma aplicação sempre fique em
funcionamento diante do seu nível crítico.
O sistema deve ser capaz de verificar falhas em
processos e ativar o seu par sem que haja perdas
significativas no desenvolvimento de suas atividades.
O sistema reconhecerá os processos a partir de seus
Pids sendo que não haverá erros na logística de troca
de estados das aplicações.
O sistema pode ter um desempenho baixo, visto que
utiliza informações que são passadas entre hosts em
redes corporativas que dependendo da largura de
banda da conexão utilizada para conseguir os dados
pode ocasionar atrasos.
QUALIDADE




A arquitetura definida propicia o desenvolvimento
iterativo e incremental, favorecendo a realização de
testes, da verificação e da validação durante seu
desenvolvimento.
Estará disponível em seu ambiente de origem Solaris
e também no Sistema operacional Linux Ubuntu.
Modularidade: o sistema deve ser desenvolvido em
camadas, havendo uma interface de comunicação bem
definida entre as mesmas.
Reusabilidade: a arquitetura do sistema deve ser tal
que permita a utilização de classes e componentes em
outros projetos, favorecendo o tempo de produção e a
qualidade do produto gerado.