Trabalho Modelagem De Sistemas

ROTEIRO PARA DERIVAÇÃO DO DIAGRAMA DE CLASSES

SISTEMA Biblioteca

CLASSES – Descoberta

A seguir são sugeridas quatro etapas para a aplicação desta regra.

1) Procurar (nos UCs do sistema) os ids e realçar (em amarelo). Sugestão, usar busca por “id_” e “id?_”.

2) Designar (na tabela abaixo) os objetos correspondentes que esses ids identificam.

id_empréstimo

id_aluno

id_exemplar

id_livro

id_reserva

Em princípio, deve haver uma classe no diagrama de classes (DC) para cada um desses tipos de objetos. A única coisa a verificar antes de criar essas classes é se existe pelo menos um UC gerando id para cada um desses tipos de objetos. Caso contrário, é preciso corrigir a especificação dos UCs fazendo-a cumprir essa restrição.

3) Realçar (em verde, nos UCs do sistema) os ids gerados

A tabela abaixo indica o UC onde cada id presente no sistema é gerado:

id_gerado UC onde é gerado

id_aluno --

id_exemplar UC:Cadastrar Exemplares

id_livro UC:Cadastrar Livros

4) Criar uma classe para cada tipo de objeto.

(cole aqui o DC contendo as classes do sistema)

Figura 1: Classes do Sistema Biblioteca

ASSOCIAÇÕES – Descoberta

Dois identificadores são distintos quanto não têm exatamente a mesma designação . Por exemplo, id_mesa e id_pedido são ids distintos entre si.

Três questões devem ser consideradas para se decidir pela criação ou não de uma associação:

1ª) A associação deve ser necessária em pelo menos dois UCs do sistema;

2ª) A associação não deve ser redundante (não deve já existir no DC ou ser derivável a partir de outras associações já existentes);

3ª) A associação deve ser relevante para a aplicação, ou seja, deve ter significado no domínio da aplicação.

Heurística: Para uma maior eficiência na descoberta de associações relevantes e inéditas logo de início, deve-se analisar, primeiramente, os UCs com ids em ambos os fluxos (lembre-se que, no fluxo de saída, só são considerados os ids gerados). Além disso, também ajuda considerar primeiramente os pares de ids contendo 2 ou 1 ids gerados, nesta ordem. Outra providência que pode ajudar: se um UC tem uma pré-condição que exige a execução prévia de outro UC, então ele deve ser analisado depois deste outro.

Assim que uma nova associação é identificada, deve-se também determinar a multiplicidade em cada extremo da associação e o tipo de associação (comum, agregação, composição ou generalização). Isso é importante porque as multiplicidades e o tipo de uma associação traduzem parte do seu significado, e a explicitação desse significado ajuda o analista a confirmar a corretude das respostas dadas às três questões acima colocadas.

A Tabela 1 a seguir detalha a análise de cada UC do Sistema Biblioteca, realizada durante a aplicação da Regra R2. As recomendações da heurística acima (sobre a ordem de análise dos UCs) foram seguidas.

Tabela 1: Detalhamento da aplicação da regra R2 (determinação das associações)

UC Pares de identificadores Análise sobre a criação (ou não) de associação Associação

13 id_livro id_exemplar Relevância: faz a ligação entre um livro e um exemplar. É necessário no UC: Consultar Acervo e no UC :Disparar aviso de vencimento de prazo de empréstimo. Não é redundante. É relevante

(Exemplar)Contém (Livro

5 id_aluno id_livro Relevancia: faz a ligação entre o aluno e o livro que ele reservou. É necessário no UC: Consultar Reserva e no UC : Cancelar Reserva. Não é redundante. É relevante. (Aluno)Reserva(livro)

10 id_aluno id_exemplar Relevancia: trata-se da ligação entre o aluno e o exemplar que ele pegou emprestado. É necessário no UC: Renovar empréstimo e no UC: Consultar Empréstimo. Não é redundante. É relevante. (aluno)pega emprestado(exemplar)

O DC resultante da aplicação da Regra R2 é mostrado na Figura 2 a seguir.

Figura 2: Classes e suas associações – Sistema Biblioteca

ATRIBUTOS – Descoberta e Alocação às Classes

Nesta seção são enunciadas três regras: R3a, R3b e R3c. As duas primeiras (R3a e R3b) permitem identificar, dentre os itens elementares presentes na interface informacional dos UCs, quais devem se tornar atributos das classes do sistema (ou seja, que devem ser persistidos). Já a regra R3c orienta sobre onde (em que classe) colocar o atributo.

Observação sobre a regra R3a: a aplicação desta regra a um UC do tipo Create deve considerar a possibilidade de o item ser necessário no UC (implícito) Retrieve correspondente; se este for o caso, o item deve ser persistido.

Um item elementar presente no fluxo de saída de um UC é item primário se o seu valor é estabelecido (originado) por um ator, no fluxo de entrada de algum UC. Por isso, eles também são denominados itens informados ou de entrada. Um item primário difere de um item (elementar) derivado, pois este último tem o seu valor derivado (calculado) pelo sistema a partir de outros itens elementares (primários ou derivados). Outra denominação para