1. Como você já fez o diagrama de casos de uso vai ficar mais fácil elaborar o diagrama de classes. Com base nos casos de uso que você definiu, você vai fazer uma lista das possíveis classes do sistema. Lembre-se que os relatórios não serão classe por si só, mas para emitir cada relatório utilizaremos diversas classes. Uma dica: se o diagrama possui um caso de uso de cadastro, é certeza de que precisará de uma classe para armazenar os dados que serão cadastrados nesse caso de uso. Seguin- do esse raciocínio teríamos as seguintes classes:
a. Paciente b. Exame c. Pedido de Exame d. Resultado de Exame e. Médicos f. Convênios g. Cidades h. UF´s i. Grupos de Exames
2. Agora, para cada uma das classes listadas, relacione os possíveis atributos de cada uma delas. A maioria desses atributos já aparece descrita no documento de requi- sitos. Nunca se esqueça de voltar ao documento de requisitos sempre que tiver dú- vidas.
a. Paciente: código, nome, endereço, CEP, cidade, UF, telefone, data de nascimen- to, RG e CPF.
b. Exame: código, descrição, valor, procedimentos, grup,o ao qual pertence o exa- me.
c. Pedido de Exame: código, nome do paciente, nome do médico, nome do convê- nio, nomes dos exames que serão realizados, data e hora da realização de cada exame, data e hora em que cada exame ficará pronto, valor de cada exame. d. Resultado de Exame: descrição do resultado (para cada exame do pedido de
exame o resultado deverá ser cadastrado).
e. Médicos: CRM, nome (como o documento de requisitos não menciona nada sobre os dados dos médicos, coloquei somente os atributos que interessam para o pedido de exame).
f. Convênios: código, nome (como o documento de requisitos não menciona nada sobre os dados dos convênios, coloquei somente os atributos que interessam para o pedido de exame).
g. Cidades: código, nome, DDD (neste caso, mesmo o documento de requisitos não mencionando nada, esses atributos devem constar em qualquer classe de
Astah e no mesmo arquivo em que já desenhamos o diagrama de casos de uso. Assim, ficaremos com os dois diagramas em um único arquivo.
4. Para cada classe desenhada no diagrama, estabelecer o seu relacionamento com as demais classes. Lembre-se dos tipos de relacionamentos que estudamos: asso- ciação (unária e binária), generalização/especialização, agregação. Releia também a explicação sobre classes associativas.
5. Depois disso, estabelecer a multiplicidade de cada relacionamento, lembrando-se de eliminar atributos que podem ser obtidos por meio do relacionamento.
6. Primeiro desenhe o seu diagrama de classes e depois compare com o meu. Veja só como ficou o meu diagrama.
1. Um pedido de exame pode estar relacionado a somente um paciente, um médico e um convênio (no diagrama não aparece a multiplicidade 1, por ser o valor default de um relacionamento).
2. Um pedido de exame pode estar relacionado a um ou a vários exames (no caso desse documento de requisitos, a 5 exames).
3. Note que os atributos: data_realizacao_exame, hora_realização_exame, data_pron- to, hora_pronto, resultado e valor estão armazenados na classe associativa que foi originada do relacionamento muitos para muitos entre Pedido de Exame e Exame. Isso se deve ao fato de que, para cada exame, esses atributos podem ser diferen- tes. Por exemplo: se o atributo DATA_PRONTO tivesse sido armazenado na classe PEDIDO_EXAME, seria possível cadastrar somente uma data em que os exames ficariam prontos. Mas, na realidade, não é isso o que acontece, ou seja, em uma lista de exames que o paciente precisa realizar pode-se ter exames que ficam prontos em 2 dias e outros que ficam prontos em 5 dias.
4. Veja que não foi criada uma classe RESULTADO_EXAME, pois como é somente uma descrição, decidiu-se armazená-la na classe associativa Exame-Pedido Exame. 5. Note também que na classe Pedido Exame não aparece o nome do paciente como
relacionamos no item 2 desse Passo a Passo. Isto porque o nome será obtido por meio do relacionamento de Pedido Exame com Paciente. Não desenhamos o atri- buto-chave de paciente na classe Pedido Exame, mas ele está lá, ou seja, por meio dele é que buscaremos o nome do paciente na classe paciente quando precisarmos. 6. Ao invés de termos utilizado o recurso da classe associativa, poderíamos ter utilizado
o relacionamento de agregação. Veja como ficaria (serão mostradas somente algu- mas classes, as demais não foram mostradas, pois ficariam iguais ao diagrama já mostrado anteriormente).
CONSIDERAÇÕES FINAIS
No decorrer desta unidade estudamos sobre a importância da modelagem de um sistema, a partir do documento de requisitos. A modelagem é a parte fundamental de todas as atividades, dentro de um processo de software, que levam à implantação de um bom software. É necessário construirmos modelos para comunicar a estrutura e o comportamento desejados do sistema, para melhor compreender o sistema que estamos elaborando (BOOCH, 2005, p. 3). Esses modelos, normalmente, são representados por meio de diagramas, em que é utilizada uma notação gráfica, que, em nosso caso, foi a UML.
A UML tem muitos tipos de diagramas, apoiando a criação de diferentes modelos de sistema, no entanto, conhecemos, nesta unidade, somente o Diagrama de Casos de Uso e o Diagrama de Classes, que são considerados por muitos autores, como os principais diagramas da UML. A UML não estabelece uma ordem pré-definida para a elaboração dos seus diversos diagramas,
porém, como o diagrama de casos de uso, é um dos diagramas mais gerais e informais da UML, normalmente a modelagem do sistema inicia-se com a elaboração desse diagrama. O diagrama de casos de uso mostra as interações entre um sistema e seu ambiente externo, determinando as funcionalidades e as características do sistema sob o ponto de vista do usuário. Conhecemos, nesta unidade, os conceitos necessários para a elaboração desse diagrama: atores, casos de uso e os possíveis relacionamentos entre estes elementos. Além disso, foi apresentado um diagrama pronto, que foi elaborado a partir do documento de requisitos para uma fábrica de colchões, mostrando como os conceitos acima podem ser aplicados em um diagrama.
Depois que o diagrama de casos de uso é elaborado fica bem mais fácil elaborar o diagrama de classes, que é o mais importante e também o mais utilizado da UML, e que define a estrutura das classes identificadas para o sistema, mostrando os atributos e métodos possuídos por cada uma das classes, e também os seus relacionamentos. Com base no mesmo documento de requisitos, o da fábrica de colchões, foi mostrado como fica o diagrama de classes referente ao mesmo.
E, para auxiliar o entendimento desses dois diagramas, foi apresentado a elaboração passo a passo de cada um deles. Para verificar se você realmente entendeu todos os conceitos, estou propondo mais um documento de requisitos nas atividades de autoestudo. Então mãos a obra!
ATIVIDADE DE AUTOESTUDO
1. Sobre relacionamento entre Casos de Uso e Atores a. Explique o relacionamento de Associação (association).
b. Explique o relacionamento de Generalização entre casos de uso (generaliza-
tion).
c. Explique o relacionamento de Extensão (extend). d. Explique o relacionamento de Inclusão (include).
3. Com base no documento de requisitos abaixo elaborar o Diagrama de Casos de Uso e o Diagrama de Classes.