Modelagem UML do Sistema SADI

Prévia do material em texto

Modelagem UML do Sistema de Acompanhamento a Doação de Sangue no
Interior do Estado do Amazonas - SADI. 
Jorlene de Souza Marques1, Fernanda Maria Ribeiro de Alencar2
1Coordenadoria de Sistemas - Fundação de Hematologia e Hemoterapia do Amazonas
(HEMOAM)
2Departamento de Eletrônica e Sistemas (DES) – Centro de Tecnologia e Geociências (CTG)
– Universidade Federal de Pernambuco (UFPE)
Resumo. Este artigo apresenta a modelagem do SADI, um sistema para controlar as doações de sangue nas
Unidades de Coleta e Transfusão (UCTs) da Fundação HEMOAM. Unidades essas situadas no interior do
Estado do Amazonas. Para a modelagem do sistema foi considerada a Linguagem de Modelagem Unificada da
OMG - UML (Unified Modeling Language). 
Palavras-chave. Sistemas de Informação, Modelagem, Linguagem UML.
Abstract. This article presents the modeling of SADI, a system to control donations of blood in the units of
collection and transfusion (UCTs) of the Foundation HEMOAM. Units situated in the interior of the state of
Amazon. For the modeling of the system the Language of Modeling Unified of OMG - UML (Unified Modeling
Language) was considered.
Key-words :Information System, Modeling, UML Language.
Introdução
Atualmente, uma grande parte da população
mundial depende de sistemas informatizados para
realizar suas atividades diárias. Software faz parte de
nossas vidas e, embora muito já tenha sido
conseguido na busca da qualidade e produtividade no
desenvolvimento e manutenção de software nos
últimos 30 anos, muito resta para ser feito. 
A qualidade de produtos de software, entretanto,
está fortemente relacionada à qualidade do processo
de software. A pesquisa em processo de software trata
dos métodos e técnicas utilizados para avaliar, apoiar
e melhorar as atividades de desenvolvimento e
manutenção de software. A primeira contribuição
importante da pesquisa na área de processo de
software é o convencimento de que desenvolver
software é um esforço coletivo, complexo e criativo e
de que a qualidade do software depende das pessoas,
da organização e dos procedimentos usados em seu
desenvolvimento [1].
Rumbaugh, Booch, e Jacobson [2], afirmam: “A
modelagem é a parte central de todas as atividades
que levam à implantação de um bom software”. É
através dela que representamos de forma abstrata e
simplificada um sistema real.
A UML (Unified Modeling Language) [2] por
sua vez, é uma linguagem de modelagem de
sistemas bastante madura e conhecida tanto no
meio profissional quanto acadêmico, que utiliza o
paradigma orientado a objetos, permitindo a
uniformização dos modelos usados para análise,
projeto e implementação.
A Fundação de Hematologia e Hemoterapia
do Amazonas (HEMOAM) depende de sistemas
informatizados para realizar seu trabalho de coleta,
tratamento e distribuição de sangue para
transfusão sanguínea em todo estado do
Amazonas. Sua sede situa-se em Manaus e
possui também 47 Unidades de Coleta e
Transfusão (UCTs) no interior do Estado.
Modelar, com apoio da UML, um sistema
para controlar as doações de sangue nas UCTs,
possibilita entender a informação, a função, e o
comportamento do sistema como um todo;
tornando a tarefa de análise de requisitos mais
completa. Os requisitos são documentados,
especificados e modelados, modificando assim o
processo de desenvolvimento de sistemas na
Fundação HEMOAM, considerado ainda imaturo.
O processo atual depende fortemente dos
profissionais que lá se encontram e quase não
possui documentação formal, sendo de difícil
controle gerencial.
Metodologia
O objetivo deste trabalho é adquirir
conhecimentos para mudar o processo de
desenvolvimento de software na Fundação HEMOAM
e adotar uma metodologia de desenvolvimento de
software para que suas atividades sejam controladas e
documentadas. Assim a metodologia adotada foi a de
fazer o levantamento das necessidades do sistema
SADI e criar um processo próprio de
desenvolvimento, baseado no Rational Unified
Process mas não tão detalhado, para o
desenvolvimento do sistema. Como o foco do trabalho
é a modelagem do sistema, o processo criado se
limita as etapas de análise e projeto do sistema
utilizando a UML.
Resultados
Levantamento das necessidades 
O controle de doações de sangue na sede da
Fundação HEMOAM é informatizado. A instituição
conta com um sistema, o SAD, Sistema de
Acompanhamento a Doação de sangue. Porém o
controle de doações de sangue nas Unidades de
Coleta e Transfusão (UCTs) no interior do Estado do
Amazonas, é manual. 
O cadastro do doador; a triagem; a coleta do
sangue; os exames de imunohematologia; o
fracionamento e a distribuição são realizados nas
próprias UCTs, com exceção dos exames de
sorologia, e todas essas informações anotadas em
livros. 
Os exames sorológicos das unidades do interior
– UCTs - são realizados na sede, e seus resultados
são enviados por fax, para as mesmas, no interior do
Estado. 
As bolsas, coletadas no interior, são fracionadas
e ficam aguardando a realização da sorologia para
serem liberadas ou não. Quando os resultados dos
exames sorológicos chegam as UCTs é que as
bolsas de sangue são liberadas para transfusão. Este
processo gera alguns problemas, entre eles a demora
na entrega dos resultados de exames para o doador
de sangue do interior. 
Os problemas gerados por este processo ainda
não estar informatizado são: 
i. identificação do doador ilegível - as fichas que
acompanham as amostras de sangue são escritas
manualmente;
ii. dados incompletos – não chegam do interior todas
as informações necessárias;
iii. estatística dos dados dificultada – devido os dados
não estarem informatizados;
iv. atraso no recebimento dos resultados de
exames pelo doador – chega a ser de até dois
meses para algumas unidades;
Nesse contexto, apresentamos o SADI –
Sistema Acompanhamento das Doações de
sangue no Interior – que tem por objetivo
automatizar o controle das doações de sangue nas
UCTs no interior do Estado do Amazonas;
eliminando o controle manual destas informações
e trocando dados com o sistema SAD através da
Internet. Esse sistema incluirá dados de cadastro
do doador; cadastro de triagens; cadastro de
doação com informações de numeração da bolsa
de sangue e os exames realizados no sangue do
doador com seus respectivos laudos. 
Processo de desenvolvimento adotado 
Inicialmente a idéia era adotar o Rational
Unified Process (RUP) [2], mas, após estudá-lo,
percebemos que nos facilitaria ter um processo
mais simples, com etapas bem definidas, e que
nos possibilitasse gerenciar estas atividades.
Diante disso, resolvemos apenas nos basear no
RUP criando um processo próprio. Este processo
possui definição de atividades, responsabilidades,
artefatos de entrada e saída, e ferramentas que
serão utilizadas; dá ênfase na criação e
manutenção de modelos da UML.
Nosso processo utiliza as etapas de:
análise, projeto, implementação, verificação e
validação, implantação e manutenção. Cada etapa
é estruturada com um conjunto de atividades.
Neste artigo descreveremos apenas as etapas de
análise e projeto, sucintamente, pois o foco do
trabalho foi inicialmente apenas modelar o sistema
SADI utilizando a UML.
Na etapa de Análise as atividades realizadas
do ciclo de desenvolvimento foram: levantamento
das necessidades; estudo de viabilidade geral;
modelagem de negócios e modelagem do domínio
do problema. Na etapa de projeto as atividades
foram: decisões de projeto; modelagem
comportamental e modelagem arquitetural.
No levantamento das necessidades, etapa
de análise, foram realizados dois tipos de
entrevistas individuais: internas (usuários) e
externas (gerentes do setor). Posteriormente foi
realizadareunião com usuários e gerentes para
validar os requisitos extraídos individualmente. Em
seguida realizamos laboratórios em cada setor
participante do processo para estudarmos as
atividades e os documentos relacionados. E então,
elaboramos o escopo do sistema.
A UML não determina uma ordem
predefinida dos diagramas a serem modelados.
Esta ordem é determinada pela preferência do
desenvolvedor e/ou processo que esteja sendo
usado. Alguns desenvolvedores iniciam a modelagem
do sistema pela criação das classes, outros pelos
casos de uso. No processo de desenvolvimento do
SADI iniciamos a modelagem a partir dos casos de
uso.
Modelagem do SADI
Os modelos criados na etapa de análise foram:
modelo de negócios e modelo do domínio do
problema. No modelo de negócios foram identificados
os casos de uso e elaborado o diagrama de casos de
uso. No modelo do domínio do problema foi elaborado
o diagrama de classes com seus atributos e
relacionamentos.
Na etapa de projeto os modelos criados foram:
modelo comportamental e modelo arquitetural. No
modelo comportamental os diagramas elaborados
foram: diagrama de sequência, digrama de classe
com as operações, diagrama de estado e diagrama de
atividades. No modelo arquitetural os diagramas
elaborados foram: diagrama de componente e
diagrama de implantação.
Etapa de análise
No início da modelagem de negócios realizamos
a análise dos requisitos coletados no levantamento
das necessidades e especificamos esses requisitos
através dos casos de uso, atores e cenários.
Processos e requisitos de negócio foram descobertos
e expressos em casos de uso. Na compreensão dos
requisitos conhecemos os processos do domínio e os
fatores externos que participam desses processos. A
identificação do negócio do sistema começou a partir
do escopo do sistema e nos possibilitou produzir uma
lista de casos de uso. 
Uma vez identificados os casos de uso [3], nos
concentramos em descrever os cenários principais. A
partir dos cenários principais, identificamos e
descrevemos os cenários alternativos. Vale ressaltar
que apenas nos preocupamos em escrever os casos
de uso desta forma (formato alto nível). Não nos
preocupamos em categorizá-los (primários,
secundários ou opcionais) segundo alguns autores [4].
Durante a descrição percebermos a necessidade de
cenários comuns a outros casos de uso. Então foram
descobertos os casos de uso de inclusão. Da mesma
forma, casos de uso muito extensos, seja quanto ao
cenário principal ou quanto aos cenários alternativos,
foram divididos em casos de extensão. A preocupação
com a escrita de casos de uso mais críticos, influentes
e de maior risco, seja no formato essencial expandido,
ou em outro formato[4], não faz parte do escopo deste
trabalho. 
A partir dos diagramas de caso de uso e dos
cenários principal e alternativo validamos
novamente o negócio do sistema com nossos
usuários, através de reunião. 
A figura 1 exemplifica um dos diagramas de
caso de uso que foram criados para modelar o
sistema SADI.
Figura 1 – casos de uso: consultar doador
e cadastrar novo doador
A Figura 1 mostra o ator recepcionista
associado ao diagrama de caso de uso consultar
doador que é o caso de uso base e possui seu
procedimento acrescido através de uma extensão
do caso de uso cadastrar novo doador. Neste caso
o processo de consulta é extendido para um
cadastro quando em sua pesquisa é descoberto
que um determinado doador ainda não possui
cadastro, porque para se cadastrar um novo
doador obrigatoriamente é necessário uma
consulta anterior.
Extensão entre casos de uso indica que um
deles terá seu procedimento acrescido, em um
ponto de extensão, de outro caso de uso,
identificado como base.
A seguir temos os cenários principal e
alternativo do caso de uso consultar doador.
Ator: recepcionista
Cenário Principal
1. O recepcionista verifica no Sistema, pelo
nome e data do nascimento, se o doador já possui
cadastro.
2. O Sistema retorna uma lista com nomes e
data do nascimento.
3. O recepcionista seleciona nome da lista.
4. O Sistema mostra dados e doador apto.
5. O recepcionista solicita impressão da
ficha.
Cenário Alternativo
Doador não cadastrado
1A. O recepcionista verifica no Sistema, pelo
nome e data do nascimento, se o doador já possui
cadastro. Caso negativo, o usuário cadastra novo
doador.
Doador inapto
Recepcionista
Consultar doador
<<extend>> Cadastrar novo doador
4A. O Sistema informa que o doador está
inapto. A inaptidão pode ser por prazo insuficiente ou
por problemas na doação anterior. 
A seguir temos o cenário principal do caso de
uso cadastrar novo doador.
Ator: recepcionista
Cenário Principal
1. O recepcionista verifica no Sistema, pelo
nome e data do nascimento, se o doador já possui
cadastro.
2. O Sistema retorna uma lista com nomes. O
nome não está na lista.
3. O recepcionista realiza cadastro do doador,
informando os dados: nome, data do nascimento,
naturalidade, nacionalidade, estado civil, sexo,
identidade, cpf, nome do pai, nome da mãe, endereço,
bairro, cep, cidade, estado, telefone, data de cadastro.
5. O recepcionista solicita impressão da ficha.
Em seguida, passamos para modelagem do
domínio do problema; identificamos as classes do
domínio do problema e seus atributos a partir dos
diagramas de caso de uso. Uma lista das classes
encontradas, e seus atributos, foi criada, e a partir dela
o diagrama de classes com os atributos e
relacionamentos. Neste momento finalizamos a etapa
de análise e passamos para a etapa de projeto.
Neste artigo não iremos mostrar o exemplo do
diagrama de classe elaborado por se tratar de um
diagrama grande e não haver espaço.
Etapa de projeto
Nesta etapa os diagramas criados na etapa de
análise continuam válidos, porém são revisados.
Novos diagramas são modelados refletindo requisitos
de implementação. 
A primeira atividade é a tomada de decisões de
projeto, onde são elaborados documentos com
definição do tipo de banco de dados a ser utilizado no
projeto do sistema, a linguagem de programação que
será utilizada para implementar as decisões
modeladas, os mecanismos de acesso a atributos, a
plataforma de implantação, número máximo de
usuários que poderão acessar o sistema
simultaneamente, as interfaces com o usuários, entre
outros requisitos. 
Na modelagem comportamental é descrito o
comportamento do sistema. As interações entre os
objetos são mostradas, os estados nos quais um
objeto pode estar, que operações ele pode realizar.
Para operações complexas, são mostradas as ações e
atividades que as compõem. Na verdade, a
modelagem comportamental do sistema inicia a partir
da lista de casos de uso e do escopo do sistema,
ambos, elaborados na etapa de análise. O estudo do
fluxo da informação com base no escopo é realizado e
então o diagrama de atividades é elaborado. Este fluxo
será validado com os usuários do sistema por meio de
reunião(ões) onde o diagrama elaborado será
discutido. A seguir será modelada a interação
entre os objetos. Cada caso de uso encontrado
gerará um diagrama de seqüência para cada
cenário principal. Para os cenários alternativos
optamos explicá-los por meio de notas. Durante a
criação dos diagramas de seqüência as operações
das classes são descobertas. Então o diagrama de
classes é completado com essas operações
descobertas. De posse do diagrama de classes
com as operações, o analista de sistemas parte
para modelar o comportamento de objetos que
possuem comportamento dinâmico. Além do
diagrama de classes com as operações, utilizamos
o escopo do sistema para elaborar os diagramas
de estados.
Figura 2 – diagrama de seqüência: consultar
doador
Para cada caso de uso criado haverá um
diagrama de seqüência que representaráos
cenários principal e alternativo quando houver.
Como exemplo, segue o diagrama de seqüência
consultar doador, mostrado na figura 2; este
diagrama inicia com o envio de informações (nome
e data de nascimento) pela recepcionista.
Somente após essas informações terem sido
enviadas, iniciamos a comunicação com os
objetos. Ao chamar o método verifica cadastro do
objeto Doador este se encarrega de validar as
informações passadas e listar os dados para o
objeto Tela doador. Este objeto passará os dados
(nome e data de nascimento).Caso o doador não
esteja cadastrado haverá uma opção de cadastro.
Caso contrário a recepcionista selecionará o nome
 : Recepcionista
 : Tela_doador : Doador
informa (nome, data nascimento)
verifica se existe cadastro
lista dados
lista nome e data nascimento
seleciona nome da lista
mostra dados. Doador apto
solicita impressao da ficha
se doador nao 
cadastrado, 
cadastra novo 
doador
se doador inapto, 
informa que nao pode 
doar.
na lista e o objeto Tela doador mostrará os outros
dados; inclusive a informação se o doador está apto
ou não. Caso o doador seja inapto o sistema não
permitirá a impressão da ficha. Caso contrário a
recepcionista pode solicitar a impressão. As notas, no
diagrama de seqüência consultar doador, representam
o cenário alternativo. Caso o doador não seja
cadastrado uma opção de cadastro será apresentada.
Caso o doador seja inapto o sistema não permitirá a
impressão da ficha para doação.
Em seguida, os diagramas de estado serão
criados para documentar os estados dos objetos que
tenham comportamentos dinâmicos significante. Um
diagrama de estado mostra o ciclo de vida de uma
classe, os eventos que causarão a transição de um
estado para outro, e as ações que resultarão em
mudanças de estado.
Em nosso estudo de caso existem dois objetos
que possuem comportamento interessante, o objeto
doador e o objeto produto gerado. Para esses objetos
projetamos o diagrama de estado. Figuras 3 e 4. Em
seguida a elas segue explicação.
Figura 3 – Diagrama de estado: situação doador
Figura 4 – Diagrama de estado: situação da
bolsa e seus produtos
Para entender a explicação dos diagramas
de estado do SADI é necessária a seguinte
observação: o doador doa seu sangue. O sangue
é coletado em uma bolsa. Esta bolsa é fracionada
e o sangue nela contido é separado gerando
produtos. 
O diagrama de estado da classe doador,
Figura 3, representa a situação do doador.
Inicialmente, após o cadastro na recepção o
doador torna-se apto a ser triado, se ele for
aprovado estará apto a doar sangue, caso
contrário receberá estado de inapto temporário,
então poderá passar por consulta médica ou não,
dependendo do seu motivo de inaptidão. Quando o
doador está apto a doar, ele faz a doação e seu
estado muda para aguardando resultado até que
seus exames laboratoriais estejam concluídos. O
doador recebe o resultado de seus exames e caso
esteja tudo normal, passa para o estado de inapto
temporário até que seu prazo de inaptidão se
encerre e ele possa doar novamente (3 meses
para mulheres e 2 meses para homens). Se der
alguma anormalidade no resultado de seus
exames, o doador passa a ter o estado de com
problemas na doação anterior e ele é
encaminhado para uma consulta médica.
Dependendo de seu problema, o médico pode
liberar ou não o doador para novas doações apto a
ser triado, deixá-lo inapto temporario ou inapto
definitivo. O estado de inapto definitivo
impossibilita o doador de doar sangue novamente.
O atributo situação aptidão da classe doador
guarda os estados do doador. Quando o doador é
inapto, por qualquer motivo, este motivo será
guardado na classe motivo de inaptidão.
O diagrama de estado, mostrado na Figura
4, representa a situação da bolsa de sangue
colhida na doação e seus vários produtos, até o
momento em que, esses produtos gerados a partir
da bolsa, saem do Hemoam. 
Inicialmente, a bolsa de sangue, após a
coleta, fica com o estado de bolsa coletada. Em
seguida, a bolsa é encaminhada ao setor de
Fracionamento onde é fracionada em alguns
produtos. Cada produto gerado a partir da bolsa
fica com estado de produto gerado. Se no ato de
fracionar a bolsa de sangue acontecer alguma
intercorrência aquele produto que está sendo
gerado é desprezado e fica com o estado de
produto desprezado. Os exames laboratoriais são
realizados (imuno e sorologia) e lançadas
condutas para bolsa. Quando a conduta da bolsa é
liberada seus produtos são liberados para
Rotulagem seu estado é produto liberado. Se a
conduta for desprezar o produto é desprezado e
fica com o estado de produto desprezado. Após a
Apto a ser 
triado
Apto a 
doar
Aguardando 
resultado
doa
Com problemas na 
doação anterior
recebe resultado[ problema no resultado ]
Inapto 
temporario
recebe resultado[ resultado ok ]
Inapto 
definitivo
aprovado[ ok ]
não aprovado[ pouco problema ]
não aprovado[ problema grave ]
prazo inaptidão encerrado
medico diagnostica[ problema grave ]
encaminhar medico[ pouco problema ]
encaminhar medico[ problema grave ]
medico[ libera para nova doação ]
Bolsa 
coletada
Produto 
gerado
bolsa fracionada
Produto 
liberado
Produto 
desprezado
conduta bolsa[ liberar ]
conduta bolsa[ desprezar ]
houve intercorrência
Produto 
estocado
Produto 
distribuído
Produto sendo 
verificado
é rotulado/vai para estoque
sai do Hemoam
validade_venceu
devolvido
produto[ ok ]
produto[ não ok ]
rotulagem o produto é estocado e fica com o estado
de produto estocado. Uma vez estocado, o produto
pode ser distribuído ou desprezado se seu prazo de
validade vencer. Quando o produto é distribuído,
existe a possibilidade dele retornar, se isso acontecer
ele ficara no estado de produto sendo verificado e
após a verificação ele poderá ser estocado novamente
ou ser desprezado.
Os estados do objeto doador ocorrem
concorrentemente aos estados do objeto produto
gerado. Quando o resultado dos exames do doador
ficam prontos, o produto gerado muda do estado de
gerado, para liberado (resultado sem problema) ou
desprezado (problema no resultado), dependendo do
resultado do exame do doador. Por serem objetos
distintos os diagramas de estados foram criados
separados. Eles poderiam ser melhor observados
através do diagrama de atividades. 
O diagrama de atividades elaborado para o
SADI também não será mostrado neste artigo por falta
de espaço.
Na modelagem arquitetural, que finaliza a etapa
de projeto, é descrita a arquitetura física do sistema.
Seu foco é o mapeamento da estrutura lógica de
classes para uma arquitetura física em termos de
componentes e nós de processamento. A arquitetura
física descreverá a decomposição detalhada do
hardware e do software que comporão a
implementação do sistema. Sempre que novas
classes e operações forem descobertas, os diagramas
de casos de uso serão revisados. Os diagramas de
componentes e implantação elaborados também não
serão mostrados por falta de espaço.
Com estas atividades a etapa de projeto está
concluída. As próximas etapas: implementação,
verificação e validação, implantação e manutenção
não fazem parte do escopo deste trabalho.
Conclusões
O desenvolvimento desse trabalho foi realizado
com ênfase na modelagem do sistema SADI. A
proposta inicial foi modelar um sistema que atendesse
às necessidades das UCTs da Fundação HEMOAM,
entre elas a facilidade e agilidade do processo da
doação de sangue no interior do estado do Amazonas,
eliminando os problemas existentes. 
A escolha pela utilização da UML como
linguagem de modelagem deu-se pelo fato de ser
independente de linguagem de programação e de
processo de desenvolvimento. Nosso trabalho teve
ênfasena criação e manutenção de modelos para que
as informações do sistema pudessem ser
visualizadas, especificadas, capturadas
instantaneamente e controladas eletronicamente
melhorando a comunicação entre a equipe de
desenvolvimento e a coordenadoria de sistemas. A
modelagem nos permitiu, ainda, documentar as
decisões que foram tomadas ao longo das fases
de análise e projeto do sistema, mantendo estas
decisões atualizadas e introduzindo modificações
na documentação gerada.
Uma limitação do trabalho é, até o
momento, que não houve reuso das classes
modeladas, pois como dissemos, o trabalho ainda
encontra-se nas etapas iniciais do processo
(análise e projeto). É uma expectativa nossa, mas
não sabemos se irá ocorrer realmente. Deixamos
para trabalhos futuros a implementação das
demais etapas e a revisão do processo de
desenvolvimento criado.
O sistema SADI tem a proposta de eliminar
o controle manual feito nas UCTs e trocar dados
com o sistema que existe na capital. Seu
desenvolvimento e implantação são etapas que
dependem de questões orçamentárias. 
Referências
[1] ROCHA, A.R.C.; MALDONADO, J.C.;
WEBER, K.C. Qualidade de
Software – teoria e prática. São
Paulo: Prentice Hall, 2001.
[2] RUMBAUGH, J.; BOOCH, G.;
JACOBSON, I. UML – guia do
usuário. Rio de Janeiro: Editora
Campus ltda, 2000.
[3] MELO, A. C. Desenvolvendo
aplicações com UML. Rio de
Janeiro: Brasport, 2002.
[4] LARMAN, C. Utilizando UML e
padrões: uma introdução à
análise e ao projeto orientados a
objetos. Trad. Luiz A. Meirelles
Salgado. Porto Alegre: Bookman,
2000.
Contato
Autor: Jorlene de Souza Marques
Nascimento: 11/12/1969, Manaus/AM –
Brasil.
Formação acadêmica/titulação: Mestrado
profissionalizante em Engenharia Elétrica.
Universidade Federal de Pernambuco, UFPE –
Pernambuco – Brasil.
Endereço profissional: Av. Constantino Nery,
3240 Bloco E, 3o. Andar, sala CPD – Chapada -
69050002 Manaus, AM – Brasil, Telefone: (92)
6564020 ramal 207 fax (92)6562066 E-mail:
jorlene@hemoam.org.br
Endereço residencial: Rua rondonia, bloco
18-D apto 28, Conj. Eldorado – Chapada –
69050530 Manaus, AM – Brasil, Telefone: (92)
6423263 E-mail: jorlene@ig.com.br