Modelagem UML do Sistema de Acompanhamento a Doao de Sangue no Interior do Estado do Amazonas - SADI.

Jorlene de Souza Marques1, Fernanda Maria Ribeiro de Alencar2 Coordenadoria de Sistemas - Fundao de Hematologia e Hemoterapia do Amazonas (HEMOAM) 2 Departamento de Eletrnica e Sistemas (DES) Centro de Tecnologia e Geocincias (CTG) Universidade Federal de Pernambuco (UFPE)
1

Resumo. Este artigo apresenta a modelagem do SADI, um sistema para controlar as doaes de sangue nas Unidades de Coleta e Transfuso (UCTs) da Fundao 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 Informao, 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. A UML (Unified Modeling Language) [2] por sua vez, uma linguagem de modelagem de sistemas bastante madura e conhecida tanto no meio profissional quanto acadmico, que utiliza o paradigma orientado a objetos, permitindo a uniformizao dos modelos usados para anlise, projeto e implementao. A Fundao de Hematologia e Hemoterapia do Amazonas (HEMOAM) depende de sistemas informatizados para realizar seu trabalho de coleta, tratamento e distribuio de sangue para transfuso sangunea em todo estado do Amazonas. Sua sede situa-se em Manaus e possui tambm 47 Unidades de Coleta e Transfuso (UCTs) no interior do Estado. Modelar, com apoio da UML, um sistema para controlar as doaes de sangue nas UCTs, possibilita entender a informao, a funo, e o comportamento do sistema como um todo; tornando a tarefa de anlise de requisitos mais completa. Os requisitos so documentados, especificados e modelados, modificando assim o processo de desenvolvimento de sistemas na Fundao HEMOAM, considerado ainda imaturo. O processo atual depende fortemente dos profissionais que l se encontram e quase no possui documentao formal, sendo de difcil controle gerencial.

Introduo Atualmente, uma grande parte da populao mundial depende de sistemas informatizados para realizar suas atividades dirias. Software faz parte de nossas vidas e, embora muito j tenha sido conseguido na busca da qualidade e produtividade no desenvolvimento e manuteno 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 mtodos e tcnicas utilizados para avaliar, apoiar e melhorar as atividades de desenvolvimento e manuteno de software. A primeira contribuio importante da pesquisa na rea de processo de software o convencimento de que desenvolver software um esforo coletivo, complexo e criativo e de que a qualidade do software depende das pessoas, da organizao 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 implantao de um bom software. atravs dela que representamos de forma abstrata e simplificada um sistema real.

Metodologia O objetivo deste trabalho adquirir conhecimentos para mudar o processo de desenvolvimento de software na Fundao 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 prprio de desenvolvimento, baseado no Rational Unified Process mas no to detalhado, para o desenvolvimento do sistema. Como o foco do trabalho a modelagem do sistema, o processo criado se limita as etapas de anlise e projeto do sistema utilizando a UML. Resultados Levantamento das necessidades O controle de doaes de sangue na sede da Fundao HEMOAM informatizado. A instituio conta com um sistema, o SAD, Sistema de Acompanhamento a Doao de sangue. Porm o controle de doaes de sangue nas Unidades de Coleta e Transfuso (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 distribuio so realizados nas prprias UCTs, com exceo dos exames de sorologia, e todas essas informaes anotadas em livros. Os exames sorolgicos das unidades do interior UCTs - so realizados na sede, e seus resultados so enviados por fax, para as mesmas, no interior do Estado. As bolsas, coletadas no interior, so fracionadas e ficam aguardando a realizao da sorologia para serem liberadas ou no. Quando os resultados dos exames sorolgicos chegam as UCTs que as bolsas de sangue so liberadas para transfuso. 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 no estar informatizado so: i. identificao do doador ilegvel - as fichas que acompanham as amostras de sangue so escritas manualmente; dados incompletos no chegam do interior todas as informaes necessrias;

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 Doaes de sangue no Interior que tem por objetivo automatizar o controle das doaes de sangue nas UCTs no interior do Estado do Amazonas; eliminando o controle manual destas informaes e trocando dados com o sistema SAD atravs da Internet. Esse sistema incluir dados de cadastro do doador; cadastro de triagens; cadastro de doao com informaes de numerao da bolsa de sangue e os exames realizados no sangue do doador com seus respectivos laudos. Processo de desenvolvimento adotado Inicialmente a idia era adotar o Rational Unified Process (RUP) [2], mas, aps 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 prprio. Este processo possui definio de atividades, responsabilidades, artefatos de entrada e sada, e ferramentas que sero utilizadas; d nfase na criao e manuteno de modelos da UML. Nosso processo utiliza as etapas de: anlise, projeto, implementao, verificao e validao, implantao e manuteno. Cada etapa estruturada com um conjunto de atividades. Neste artigo descreveremos apenas as etapas de anlise e projeto, sucintamente, pois o foco do trabalho foi inicialmente apenas modelar o sistema SADI utilizando a UML. Na etapa de Anlise as atividades realizadas do ciclo de desenvolvimento foram: levantamento das necessidades; estudo de viabilidade geral; modelagem de negcios e modelagem do domnio do problema. Na etapa de projeto as atividades foram: decises de projeto; modelagem comportamental e modelagem arquitetural. No levantamento das necessidades, etapa de anlise, foram realizados dois tipos de entrevistas individuais: internas (usurios) e externas (gerentes do setor). Posteriormente foi realizada reunio com usurios e gerentes para validar os requisitos extrados individualmente. Em seguida realizamos laboratrios em cada setor participante do processo para estudarmos as atividades e os documentos relacionados. E ento, elaboramos o escopo do sistema. A UML no determina uma ordem predefinida dos diagramas a serem modelados. Esta ordem determinada pela preferncia do

ii.

iii. estatstica dos dados dificultada devido os dados no estarem informatizados;

desenvolvedor e/ou processo que esteja sendo usado. Alguns desenvolvedores iniciam a modelagem do sistema pela criao 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 anlise foram: modelo de negcios e modelo do domnio do problema. No modelo de negcios foram identificados os casos de uso e elaborado o diagrama de casos de uso. No modelo do domnio 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 sequncia, digrama de classe com as operaes, diagrama de estado e diagrama de atividades. No modelo arquitetural os diagramas elaborados foram: diagrama de componente e diagrama de implantao. Etapa de anlise No incio da modelagem de negcios realizamos a anlise dos requisitos coletados no levantamento das necessidades e especificamos esses requisitos atravs dos casos de uso, atores e cenrios. Processos e requisitos de negcio foram descobertos e expressos em casos de uso. Na compreenso dos requisitos conhecemos os processos do domnio e os fatores externos que participam desses processos. A identificao do negcio do sistema comeou 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 cenrios principais. A partir dos cenrios principais, identificamos e descrevemos os cenrios alternativos. Vale ressaltar que apenas nos preocupamos em escrever os casos de uso desta forma (formato alto nvel). No nos preocupamos em categoriz-los (primrios, secundrios ou opcionais) segundo alguns autores [4]. Durante a descrio percebermos a necessidade de cenrios comuns a outros casos de uso. Ento foram descobertos os casos de uso de incluso. Da mesma forma, casos de uso muito extensos, seja quanto ao cenrio principal ou quanto aos cenrios alternativos, foram divididos em casos de extenso. A preocupao com a escrita de casos de uso mais crticos, influentes e de maior risco, seja no formato essencial expandido, ou em outro formato[4], no faz parte do escopo deste trabalho.

A partir dos diagramas de caso de uso e dos cenrios principal e alternativo validamos novamente o negcio do sistema com nossos usurios, atravs de reunio. A figura 1 exemplifica um dos diagramas de caso de uso que foram criados para modelar o sistema SADI.

<<extend>> Cadastrar novo doador

Consultar doador Recepcionista

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 atravs de uma extenso 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 no possui cadastro, porque para se cadastrar um novo doador obrigatoriamente necessrio uma consulta anterior. Extenso entre casos de uso indica que um deles ter seu procedimento acrescido, em um ponto de extenso, de outro caso de uso, identificado como base. A seguir temos os cenrios principal e alternativo do caso de uso consultar doador. Ator: recepcionista Cenrio 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 impresso da ficha. Cenrio Alternativo Doador no cadastrado 1A. O recepcionista verifica no Sistema, pelo nome e data do nascimento, se o doador j possui cadastro. Caso negativo, o usurio cadastra novo doador. Doador inapto

4A. O Sistema informa que o doador est inapto. A inaptido pode ser por prazo insuficiente ou por problemas na doao anterior. A seguir temos o cenrio principal do caso de uso cadastrar novo doador. Ator: recepcionista Cenrio 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 no 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 me, endereo, bairro, cep, cidade, estado, telefone, data de cadastro. 5. O recepcionista solicita impresso da ficha. Em seguida, passamos para modelagem do domnio do problema; identificamos as classes do domnio 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 anlise e passamos para a etapa de projeto. Neste artigo no iremos mostrar o exemplo do diagrama de classe elaborado por se tratar de um diagrama grande e no haver espao. Etapa de projeto Nesta etapa os diagramas criados na etapa de anlise continuam vlidos, porm so revisados. Novos diagramas so modelados refletindo requisitos de implementao. A primeira atividade a tomada de decises de projeto, onde so elaborados documentos com definio do tipo de banco de dados a ser utilizado no projeto do sistema, a linguagem de programao que ser utilizada para implementar as decises modeladas, os mecanismos de acesso a atributos, a plataforma de implantao, nmero mximo de usurios que podero acessar o sistema simultaneamente, as interfaces com o usurios, entre outros requisitos. Na modelagem comportamental descrito o comportamento do sistema. As interaes entre os objetos so mostradas, os estados nos quais um objeto pode estar, que operaes ele pode realizar. Para operaes complexas, so mostradas as aes e atividades que as compem. 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 anlise. O estudo do fluxo da informao com base no escopo realizado e ento o diagrama de atividades elaborado. Este fluxo ser validado com os usurios do sistema por meio de reunio(es) onde o diagrama elaborado ser

discutido. A seguir ser modelada a interao entre os objetos. Cada caso de uso encontrado gerar um diagrama de seqncia para cada cenrio principal. Para os cenrios alternativos optamos explic-los por meio de notas. Durante a criao dos diagramas de seqncia as operaes das classes so descobertas. Ento o diagrama de classes completado com essas operaes descobertas. De posse do diagrama de classes com as operaes, o analista de sistemas parte para modelar o comportamento de objetos que possuem comportamento dinmico. Alm do diagrama de classes com as operaes, utilizamos o escopo do sistema para elaborar os diagramas de estados.

: Recepcionista

: Tela_doador

: Doador

informa (nome, data nascimento) verifica se existe cadastro

lista dados lista nome e data nascimento seleciona nome da lista

se doador nao cadastrado, cadastra novo doador

mostra dados. Doador apto

se doador inapto, informa que nao pode doar.

solicita impressao da ficha

Figura 2 diagrama de seqncia: consultar doador Para cada caso de uso criado haver um diagrama de seqncia que representar os cenrios principal e alternativo quando houver. Como exemplo, segue o diagrama de seqncia consultar doador, mostrado na figura 2; este diagrama inicia com o envio de informaes (nome e data de nascimento) pela recepcionista. Somente aps essas informaes terem sido enviadas, iniciamos a comunicao com os objetos. Ao chamar o mtodo verifica cadastro do objeto Doador este se encarrega de validar as informaes passadas e listar os dados para o objeto Tela doador. Este objeto passar os dados (nome e data de nascimento).Caso o doador no esteja cadastrado haver uma opo de cadastro. Caso contrrio a recepcionista selecionar o nome

na lista e o objeto Tela doador mostrar os outros dados; inclusive a informao se o doador est apto ou no. Caso o doador seja inapto o sistema no permitir a impresso da ficha. Caso contrrio a recepcionista pode solicitar a impresso. As notas, no diagrama de seqncia consultar doador, representam o cenrio alternativo. Caso o doador no seja cadastrado uma opo de cadastro ser apresentada. Caso o doador seja inapto o sistema no permitir a impresso da ficha para doao. Em seguida, os diagramas de estado sero criados para documentar os estados dos objetos que tenham comportamentos dinmicos significante. Um diagrama de estado mostra o ciclo de vida de uma classe, os eventos que causaro a transio de um estado para outro, e as aes que resultaro em mudanas 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 explicao.

Figura 4 Diagrama de estado: situao da bolsa e seus produtos Para entender a explicao dos diagramas de estado do SADI necessria a seguinte observao: 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 situao do doador. Inicialmente, aps o cadastro na recepo o doador torna-se apto a ser triado, se ele for aprovado estar apto a doar sangue, caso contrrio receber estado de inapto temporrio, ento poder passar por consulta mdica ou no, dependendo do seu motivo de inaptido. Quando o doador est apto a doar, ele faz a doao e seu estado muda para aguardando resultado at que seus exames laboratoriais estejam concludos. O doador recebe o resultado de seus exames e caso esteja tudo normal, passa para o estado de inapto temporrio at que seu prazo de inaptido 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 doao anterior e ele encaminhado para uma consulta mdica. Dependendo de seu problema, o mdico pode liberar ou no o doador para novas doaes 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 situao aptido da classe doador guarda os estados do doador. Quando o doador inapto, por qualquer motivo, este motivo ser guardado na classe motivo de inaptido. O diagrama de estado, mostrado na Figura 4, representa a situao da bolsa de sangue colhida na doao e seus vrios produtos, at o momento em que, esses produtos gerados a partir da bolsa, saem do Hemoam. Inicialmente, a bolsa de sangue, aps 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 intercorrncia aquele produto que est sendo gerado desprezado e fica com o estado de produto desprezado. Os exames laboratoriais so realizados (imuno e sorologia) e lanadas condutas para bolsa. Quando a conduta da bolsa liberada seus produtos so liberados para Rotulagem seu estado produto liberado. Se a conduta for desprezar o produto desprezado e fica com o estado de produto desprezado. Aps a

Bolsa coletada houve intercorrncia bolsa fracionada

Produto gerado

conduta bolsa[ desprezar ]

Produto desprezado

produto[ no ok ] conduta bolsa[ liberar ] Produto sendo verificado Produto liberado validade_venceu

devolvido rotulado/vai para estoque produto[ ok ]

Produto estocado

sai do Hemoam

Produto distribudo

Figura 3 Diagrama de estado: situao doador

no aprovado[ problema grave ] Apto a ser triado prazo inaptido encerrado aprovado[ ok ] Apto a doar medico[ libera para nova doao ] recebe resultado[ resultado ok ] Inapto definitivo medico diagnostica[ problema grave ] Inapto temporario

no aprovado[ pouco problema ]

doa Aguardando resultado

recebe resultado[ problema no resultado ] encaminhar medico[ pouco problema ] Com problemas na doao anterior encaminhar medico[ problema grave ]

rotulagem o produto estocado e fica com o estado de produto estocado. Uma vez estocado, o produto pode ser distribudo ou desprezado se seu prazo de validade vencer. Quando o produto distribudo, existe a possibilidade dele retornar, se isso acontecer ele ficara no estado de produto sendo verificado e aps a verificao 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 atravs do diagrama de atividades. O diagrama de atividades elaborado para o SADI tambm no ser mostrado neste artigo por falta de espao. Na modelagem arquitetural, que finaliza a etapa de projeto, descrita a arquitetura fsica do sistema. Seu foco o mapeamento da estrutura lgica de classes para uma arquitetura fsica em termos de componentes e ns de processamento. A arquitetura fsica descrever a decomposio detalhada do hardware e do software que comporo a implementao do sistema. Sempre que novas classes e operaes forem descobertas, os diagramas de casos de uso sero revisados. Os diagramas de componentes e implantao elaborados tambm no sero mostrados por falta de espao. Com estas atividades a etapa de projeto est concluda. As prximas etapas: implementao, verificao e validao, implantao e manuteno no fazem parte do escopo deste trabalho. Concluses 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 Fundao HEMOAM, entre elas a facilidade e agilidade do processo da doao de sangue no interior do estado do Amazonas, eliminando os problemas existentes. A escolha pela utilizao da UML como linguagem de modelagem deu-se pelo fato de ser independente de linguagem de programao e de processo de desenvolvimento. Nosso trabalho teve nfase na criao e manuteno de modelos para que as informaes do sistema pudessem ser visualizadas, especificadas, capturadas instantaneamente e controladas eletronicamente melhorando a comunicao entre a equipe de desenvolvimento e a coordenadoria de sistemas. A modelagem nos permitiu, ainda, documentar as

decises que foram tomadas ao longo das fases de anlise e projeto do sistema, mantendo estas decises atualizadas e introduzindo modificaes na documentao gerada. Uma limitao do trabalho , at o momento, que no houve reuso das classes modeladas, pois como dissemos, o trabalho ainda encontra-se nas etapas iniciais do processo (anlise e projeto). uma expectativa nossa, mas no sabemos se ir ocorrer realmente. Deixamos para trabalhos futuros a implementao das demais etapas e a reviso 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 implantao so etapas que dependem de questes oramentrias. Referncias [1] ROCHA, A.R.C.; MALDONADO, J.C.; WEBER, K.C. Qualidade de Software teoria e prtica. So Paulo: Prentice Hall, 2001. [2] RUMBAUGH, J.; BOOCH, G.; JACOBSON, I. UML guia do usurio. Rio de Janeiro: Editora Campus ltda, 2000. [3] MELO, A. C. Desenvolvendo aplicaes com UML. Rio de Janeiro: Brasport, 2002. [4] LARMAN, C. Utilizando UML e padres: uma introduo anlise 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. Formao acadmica/titulao: Mestrado profissionalizante em Engenharia Eltrica. Universidade Federal de Pernambuco, UFPE Pernambuco Brasil. Endereo 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 Endereo residencial: Rua rondonia, bloco 18-D apto 28, Conj. Eldorado Chapada 69050530 Manaus, AM Brasil, Telefone: (92) 6423263 E-mail: jorlene@ig.com.br