Artigo Engenharia de Software 12 - UML – Diagrama de Classes

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (4)  (0)

Artigo da Revista Engenharia de Software edição 12.

Esse artigo faz parte da revista Engenharia de Software 12 edição especial. Clique aqui para ler todos os artigos desta edição

Projeto

UML – Diagrama de Classes

Encontrando classes e desenhando seu diagrama – Parte I

 

De que se trata o artigo:

Este artigo tem por objetivo apresentar as regras para se modelar um diagrama de classes, partindo da análise prática dos requisitos de um estudo de caso.

Para que serve:

Fornecer aos desenvolvedores ou estudantes da área de sistemas uma linha de entendimento com o intuito de orientá-los a modelar seus diagramas de classes.

Em que situação o tema é útil:

Para quem ainda não modelou classes, ou para quem tem experiência e quer revisar a sintaxe permitida nesse tipo de diagrama.

 

Neste artigo, faremos uso de um pequeno estudo de caso para entendermos como é feita a modelagem de um diagrama de classes, aproveitando esse passo a passo para a apresentação das regras desse diagrama.

Nessa primeira parte mostraremos como extrair classes de uma lista de requisitos ou de um caso de uso; demonstraremos as notações para representarmos uma classe, seus atributos e operações, e falaremos do relacionamento de associação.

No próximo artigo, veremos como refinar um diagrama de classes, apresentando informações relevantes como escopo, restrições, os relacionamentos de generalização e agregação, além de algumas classes especiais como classe de enumeração, abstrata e de associação.

Encontrando as classes

A tarefa de encontrar classes entre um conjunto de requisitos requer questionamento e investigação. O caminho mais usual para essa tarefa é a de se encontrar as classes a partir dos cenários de casos de uso. Contudo, podemos partir também dos requisitos ainda brutos (não modelados em casos de uso), para obter uma primeira versão das classes que o sistema acolherá. Normalmente, essa segunda opção é realizada em sistemas de maior porte para se obter uma idéia macro de sua dimensão, antes que o trabalho duro tenha início; ou em sistemas de menor porte, para se ter a idéia precisa de seu tamanho.

Em virtude de espaço, não iremos relacionar aqui todos os cenários dos casos de uso de nosso estudo de caso para extrairmos as classes a partir deles. Mas aproveitando a simplicidade de nosso exemplo, faremos a lista de classes a partir do levantamento de requisitos apresentado no Quadro 1.

 

Sistema de Consultas Médicas

 

Dr. Monteiro contratou uma empresa para informatizar seu consultório.

Dr. Monteiro é pediatra e atende através de plano de saúde ou particular. As consultas na agenda serão marcadas pela secretária, e ocorrem de meia em meia hora, em horários distintos a cada dia da semana. Só são permitidos dois encaixes por dia. Caso o paciente seja novo, deve-se registrar apenas o nome da criança, do responsável, telefone de contato e tipo de plano.

Para cada paciente é preciso manter: nome da criança, nome dos pais, data de nascimento, endereço completo (incluindo uf), telefone residencial e celular (indicando a quem pertence), sexo, prontuário de cada consulta, histórico de peso e altura. O receituário deve ser emitido pelo sistema com as prescrições, nome e CRM do médico.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?