Modelação de Dados em UML by Grupo Lidel

Distribuição

Lidel – edições técnicas, lda

Sede R. D. Estefânia, 183, R/C Dto. – 1049‐057 LISBOA Distribuição Tel: +351 213 511 448 * Fax: +351 213 522 684 Revenda: revenda@lidel.pt Exportação: depinternacional@lidel.pt Venda online: livraria@lidel.pt Lidel − edições técnicas, lda Marketing: marketing@lidel.pt

SEDE Rua D. Estefânia, 183, r/c Dto. − 1049-057 Lisboa Livraria Tel: +351 213 511 448 * Fax: +351 213 522 684 Av. Praia da Vitória, 14 – 1000‐247 LISBOA Revenda: revenda@lidel.pt Tel: +351 213 511 448 * Fax: +351 213 173 259 Exportação: depinternacional@lidel.pt livraria@lidel.pt Venda online: livraria@lidel.pt Marketing: marketing@lidel.pt Edição

LIVRARIA Av. Praia da Vitória, 14 − 1000-247 Lisboa Tel: +351 213 511 448 * Fax: +351 213 173 259 livraria@lidel.pt

FCA – Editora de Informática

Edição

Av. Praia da Vitória, 14 – 1000‐247 LISBOA Tel: +351 213 511 448 Email: fca@fca.pt FCA − Editora de Informática

Copyright © setembro 2015 Av. Praia da Vitória, 14 − 1000-247 Lisboa Tel: +351 213 511 448 FCA – Editora de Informática, Lda. Email: fca@fca.pt ISBN: 978‐972‐722‐812‐6 Capa: José M. Ferrão – Look‐Ahead Copyright © setembro de 2015

FCA − Editora de Infomática, Lda. Pré‐impressão: Tipografia Lousanense, Lda. – Lousã ISBN: 978-972-722-812-6

Impressão e acabamento: Tipografia Lousanense, Lda. – Lousã Capa: José M. Ferrão − Look-Ahead

Pré-impressão: Tipografia Lousanense, Lda. − Lousã Depósito Legal N.º

Impressão e acabamento: Tipografia Lousanense, Lda. − Lousã

Livro segundo o Novo Acordo Ortográfico Depósito Legal n.º 398004/15

Livro segundo o Novo Acordo Ortográfico

Todos os nossos livros passam por um rigoroso controlo de qualidade, no entanto, aconselhamos a consulta Todos os nossos livros passam por um rigoroso controlo de qualidade, no entanto, aconselhamos a consulta periódica periódica do nosso site (www.fca.pt) para fazer o download de eventuais correções. do nosso site (www.fca.pt) para fazer o download de eventuais correções.

Os nomes comerciais referenciados neste livro têm patente registada. Os nomes comerciais referenciados neste livro têm patente registada.

Marcas Registadas FCA – Editora Informática, Lda. – Lda. − Marcasde Registadas de FCAde – Editora de Informática.

Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em parte, parte, por qualquer processoprocesso eletrónico, mecânico, fotocópia, digitalização, sistemade de por qualquer eletrónico, mecânico, fotocópia, digitalização,gravação, gravação, sistema armazenamento e armazenamento e disponibilização disponibilizaçãodedeinformação, informação, blogue ou outros, sem prévia autorização sítiosítio Web,Web, blogue ou outros, sem prévia autorização escrita da Editora, exceto escrita da Editora, exceto o permitido pelo CDADC, em termos de cópia privada pela AGECOP – Associação o permitido pelo CDADC, em termos de cópia privada pela AGECOP − Associação para a Gestão da Cópia Privada, para a Gestão da Cópia Privada, através do das respetivas taxas. através do pagamento daspagamento respetivas taxas.

Índice Geral Índice de Figuras e Tabelas..................................................................... IX Nota dos Autores................................................................................ XV 1. Introdução........................................................................................1 1.1. Público e estrutura da obra....................................................... 3

PARTE I – Tutorial......................................................................... 5

2. Introdução ao UML através de um Exemplo..........................................7 2.1. Uma versão simplificada de um sistema de informação para um produtor de vinhos................................................................. 7 2.1.1. Descrição do problema.................................................... 7 2.1.2. Especificação dos requisitos do utilizador.............................. 9 2.1.3. Diagrama conceptual de classes em UML.............................. 12 2.1.4. Principais interfaces com o utilizador.................................. 21 Exercícios................................................................................. 26 2.2. Indo um pouco mais longe........................................................ 27 2.2.1. Descrição de alguns requisitos adicionais.............................. 27 Exercícios................................................................................. 39 2.2.2. Conversão do diagrama UML no modelo relacional correspondente........................................................................ 39 2.2.3. Perguntas a que o modelo responde e perguntas a que não responde.................................................................... 44 Exercícios................................................................................. 45

PARTE II – Resolução Comentada de Problemas............................. 47 3. Aventuras Todo-o-terreno................................................................49 3.1. Descrição do problema........................................................... 49 3.2. Proposta de solução............................................................... 51 Exercícios................................................................................. 56

Modelação de Dados em UML

4. Surto de Gripe das Aves...................................................................57 4.1. Descrição do problema........................................................... 57 4.2. Resolução comentada............................................................. 58 Exercícios................................................................................. 62

5. Cursos de Formação........................................................................63 5.1. Descrição do problema........................................................... 63 5.2. Discussão das duas alternativas................................................. 64 Exercícios................................................................................. 66

6. Loja de Decoração...........................................................................67 6.1. Descrição do problema........................................................... 67 6.2. Resolução comentada............................................................. 68 Exercícios................................................................................. 72

7. Concurso de Programação................................................................75 7.1. Descrição do problema........................................................... 75 7.2. Resolução comentada............................................................. 76 Exercícios................................................................................. 83

8. Empresa de Recrutamento...............................................................85 8.1. Descrição do problema........................................................... 85 8.2. Resolução comentada............................................................. 86 Exercícios................................................................................. 87

9. Companhia de Seguros.....................................................................89 9.1. Caraterização dos clientes e dos seus endereços............................. 89 9.1.1. Descrição dos requisitos.................................................. 89 9.1.2. Resolução comentada..................................................... 90 9.2. Caraterização das apólices de seguro.......................................... 94 9.2.1. Descrição dos requisitos.................................................. 94 9.2.2. Resolução comentada..................................................... 95 9.3. Caraterização dos acidentes e das respetivas participações............... 98 9.3.1. Descrição dos requisitos.................................................. 98 9.3.2. Resolução comentada..................................................... 99 Exercícios............................................................................... 100

10. Participações em Filmes...............................................................101 10.1. Descrição do problema...................................................... 101 10.2. Resolução comentada........................................................ 101 Exercícios............................................................................. 107

11. Empresa de Outdoors..................................................................109 11.1. Descrição do problema...................................................... 109 11.2. Resolução comentada........................................................ 110 Exercícios............................................................................. 114

Índice Geral

12. Agência de Modelos.....................................................................117 12.1. Caraterização dos colaboradores.......................................... 12.1.1. Descrição dos requisitos........................................... 12.1.2. Resolução comentada.............................................. 12.2. Caraterização dos portefólios dos modelos.............................. 12.2.1. Descrição dos requisitos........................................... 12.2.2. Resolução comentada.............................................. 12.3. Caraterização de listas de preferências.................................. 12.3.1. Descrição dos requisitos........................................... 12.3.2. Resolução comentada.............................................. 12.4. Caraterização dos trabalhos fotográficos................................. 12.4.1. Descrição dos requisitos........................................... 12.4.2. Resolução comentada.............................................. Exercícios.............................................................................

117 117 118 121 121 121 123 123 123 126 126 126 127

13. Clube de Ténis.............................................................................129 13.1. Descrição do problema...................................................... 129 13.2. Resolução comentada........................................................ 130 Exercícios............................................................................. 132

14. Gestão de Cirurgias.....................................................................133

14.1. Caraterização dos cirurgiões e dos hospitais............................. 14.1.1. Descrição dos requisitos........................................... 14.1.2. Resolução comentada.............................................. 14.2. Caraterização das cirurgias................................................. 14.2.1. Descrição dos requisitos........................................... 14.2.2. Resolução comentada.............................................. 14.3. Caraterização dos materiais consumíveis................................ 14.3.1. Descrição dos requisitos........................................... 14.3.2. Resolução comentada.............................................. 14.4. Alguns requisitos adicionais do cirurgião................................. 14.4.1. Descrição dos requisitos........................................... 14.4.2. Resolução comentada.............................................. Exercícios.............................................................................

133 133 134 135 135 135 137 137 138 139 139 139 141

15. Controlo de Projetos....................................................................143 15.1. Funcionários e projetos..................................................... 15.1.1. Requisitos............................................................ 15.1.2. Resolução comentada.............................................. 15.2. Tarefas do projeto............................................................ 15.2.1. Requisitos............................................................ 15.2.2. Resolução comentada.............................................. 15.3. Tarefas previstas vs. tarefas efetivamente realizadas.................

VII

143 143 144 144 144 145 148

Modelação de Dados em UML

15.3.1. Requisitos............................................................ 15.3.2. Resolução comentada.............................................. 15.4. Tarefas genéricas............................................................. 15.4.1. Requisitos............................................................ 15.4.2. Proposta de solução................................................ Exercícios.............................................................................

148 148 150 150 150 151

16. Clínica Veterinária........................................................................153 16.1 Descrição do problema....................................................... 153 16.2 Resolução comentada......................................................... 154 Exercícios............................................................................. 159

Anexo – Guia de Referência Rápida da Linguagem UML para a Modelação Conceptual de Classes...........................................................161 Bibliografia........................................................................................169 Índice Remissivo................................................................................171

VIII

Nota dos Autores A nossa experiência de mais de vinte anos a aprender, ensinar e avaliar processos de modelação de problemas de conhecimento fez-nos sentir a falta desta obra. Desenvolver um sistema interativo para gerir informação, normalmente suportado numa base de dados relacional, requer um trabalho conceptual prévio discutido entre os parceiros do projeto. Cada caso é um caso, e num contexto organizacional complexo, em mudança contínua, existem sempre muitas soluções para um problema, dependendo de muitos pressupostos.

Modelar um problema requer a compreensão de múltiplos aspetos. Para se ser objetivo tem de se usar uma linguagem precisa, com um significado matematicamente rigoroso. Para a solução ser eficaz e eficiente, a modelação tem de usar um método de engenharia que considere os recursos disponíveis, o contexto e o horizonte de utilização. Para o sistema ter sucesso, é necessária também a arte de considerar todos os restantes aspetos difíceis de definir mas que se adquirem com a prática e talvez com o estudo de exemplos. Esta obra apresenta diversos problemas, e para cada um deles inclui diferentes exemplos de construção de soluções possíveis, acompanhadas de uma discussão detalhada. Todos os exemplos apresentados foram sendo validados e aperfeiçoados com estudantes de diversos cursos, incluindo Engenharia e Gestão Industrial, Engenharia Mecânica e Engenharia Informática e Computação na Faculdade de Engenharia da Universidade do Porto (FEUP). Regista-se, desde já, o nosso agradecimento a todos esses estudantes com quem fomos aprendendo e que nos permitiram preparar este trabalho.

Modelação de Dados em UML

A primeira parte deste livro inclui uma breve introdução ao UML e às regras de como transformar um modelo conceptual numa estrutura relacional para construir uma base de dados. A segunda parte inclui a discussão de 16 problemas que vão sendo resolvidos com propostas de soluções alternativas, mais ou menos complexas. Finalmente, gostaríamos de agradecer a todos os colegas que ao longo dos últimos anos nos acompanharam no ensino dos vários cursos na FEUP, como assistentes ou monitores, em particular a António Nunes, João Mourinho, Luís Certo e Ricardo Castro. Um agradecimento especial ao Thiago Sobral pela sua ajuda na revisão do texto final. Aqui ficam também os nossos votos de que esta obra contribua para um melhor processo de aprendizagem na preparação dos modelos conceptuais que vão servir de base ao desenvolvimento de sistemas de informação. Desde já agradecemos os vossos comentários. José Luís Moura Borges Teresa Galvão Dias João Falcão e Cunha FEUP, 30 de julho de 2015

XVI

1. Introdução Atualmente, grande parte dos quadros superiores depara‑se, mais cedo ou mais tarde, com questões sobre a organização da informação recolhida e mantida nos sistemas de informação da sua empresa. É comum ocorrerem situações em que não há total acordo ou compreensão entre os diferentes interlocutores, sobre os requisitos de informação relevantes para o negócio ou sobre a forma como os sistemas de informação os poderão representar. Também, aquando da especificação de sistemas de informação, surgem dificuldades de comunicação entre os interlocutores, que compreendem o negócio, e os responsáveis pela definição dos requisitos do sistema.

A modelação de dados é uma componente importante na caraterização dos sistemas de informação. É nesta fase que se discutem os principais conceitos que caraterizam o negócio, as suas particularidades e o modo como se relacionam entre si. No processo de conceção de um sistema é, por um lado, fundamental envolver os clientes, os analistas e os responsáveis pela sua implementação. Por outro lado, é importante ter uma linguagem formal para representar os conceitos discutidos. De facto, a utilização de uma linguagem formal de modelação permite a caraterização de um sistema por forma a desafiar os seus limites, assim como identificar exceções e mal entendidos. Por exemplo, se considerarmos a conceção de uma base de dados para uma faculdade, o conceito de turma parece, à partida, natural para os diferentes intervenientes. No entanto, podemos ter diferentes interpretações deste conceito. Podemos considerar que uma turma é formada no contexto de uma disciplina particular (a turma 3 da disciplina de Sistemas de Informação), ou no contexto de um ano de um curso em particular (a turma 3 do 2.o ano do curso de Engenharia Mecânica). Enquanto, no pri-

Modelação de Dados em UML

meiro caso, um aluno deverá inscrever‑se numa turma para cada disciplina que pretenda frequentar, no segundo caso, ao inscrever‑se numa turma, ficaria automaticamente associado a todas as disciplinas dessa turma. Assim, na especificação de um sistema de informação é necessário verificar se os diferentes interlocutores partilham a mesma interpretação dos diversos conceitos. Para isso, é fundamental que os quadros superiores das empresas compreendam os princípios da modelação de dados e que conheçam uma linguagem que lhes permita representar de forma precisa a sua interpretação do problema, garantindo assim que uma correta interpretação do seu negócio é transmitida aos responsáveis pela implementação do sistema de informação. O UML é uma linguagem de modelação visual para a especificação de sistemas de software. Esta linguagem surgiu de um esforço de unificação de um conjunto de linguagens que existiam na década de 90, sendo atualmente considerado um standard (http://www.uml.org/). Um dos seus componentes é o diagrama de classes que pode ser utilizado para descrever a estrutura de organização de informação de um sistema. Embora a notação do diagrama de classes em UML possa ser resumida em poucas páginas (ver Anexo), e seja de compreensão relativamente simples, a sua correta utilização exige reflexão e maturidade por forma a compreender as implicações de diferentes opções de modelação. De facto, a especificação da linguagem de modelação de classes em UML define, de forma clara, a sintaxe dos diagramas mas não apresenta uma definição precisa da sua semântica. Este livro surge na sequência de mais de uma década de ensino de disciplinas de Sistemas de Informação a alunos de vários cursos da Faculdade de Engenharia da Universidade do Porto (FEUP), além da experiência de diversas colaborações com empresas e organizações na especificação e desenho de sistemas de informação. No ensino de como estruturar a informação para ser armazenada numa base de dados são transmitidos os conceitos de modelação. Nesse contexto, verificamos que, embora a compreensão da notação de uma linguagem de modelação de dados, como o diagrama de classes em UML, seja relativamente rápida, a aprendizagem da sua correta utilização é um processo complexo que exige reflexão para compreender as implicações das diferentes opções de modelação. Costumamos, ainda, deparar‑nos com dificuldades na análise de modelos alternativos e na compreensão das implicações resultantes das diferentes opções. Ao longo do livro, procuraremos apresentar e discutir diferentes

Introdução

opções de modelação, assim como as possíveis consequências no modelo relacional resultante. Este livro foca‑se, assim, na discussão semântica de diagramas de classes, utilizando o UML, em particular.

1.1. PÚBLICO E ESTRUTURA DA OBRA Este livro foi escrito no pressuposto de que o leitor tem conhecimentos básicos do que é uma base de dados relacional e dos principais conceitos associados como, por exemplo, os conceitos de tabela e de chave primária. Noções de chave estrangeira e de integridade referencial, embora não sejam fundamentais, ajudam à compreensão de algumas das discussões. Este livro é dirigido a todos aqueles que procuram compreender a modelação de dados, nomeadamente, estudantes e profissionais envolvidos na discussão de requisitos de sistemas de informação a implementar. Está organizado em duas partes. A Parte I ajuda a compreender o processo de modelação através de uma introdução, sob a forma de um tutorial, em que a interpretação dos requisitos de um problema vai sendo discutida, assim como a forma de os representar. A Parte II apresenta um conjunto de problemas que podem ser lidos de forma independente.

Foi identificado um conjunto de tópicos de modelação que se pretendem abordar e que estão relacionados com questões frequentemente levantadas durante a aprendizagem. De forma a facilitar a sua identificação, as questões foram organizadas numa matriz que indica os problemas nos quais cada uma das questões é abordada de forma mais profunda (ver Tabela 1.1). São também utilizadas notas de margem para indicar os parágrafos em que as questões são discutidas. O índice remissivo, no final do livro, permite uma forma alternativa de localizar as páginas onde são discutidas estas questões de modelação. Os problemas foram ordenados de forma a que as questões mais simples e frequentes fossem abordadas em primeiro lugar, seguindo‑se progressivamente as questões mais complexas. No final de cada problema são apresentados alguns exercícios que procuram explorar algumas questões em aberto ou tópicos mais avançados. Finalmente, no Anexo é apresentado um sumário da notação para os diagramas de classes em UML, assim como a respetiva conversão para o modelo relacional.

Modelação de Dados em UML

15. Controlo projetos

16. Clínica veterinária

14. Gestão cirurgias

13. Clube ténis

12. Agência modelos

11. Empresa outdoors

10. Participações filmes

9. Companhia seguros

8. Empresa recrutamento

7. Concurso programação

6. Loja decoração

5. Cursos formação

4. Surto gripe das aves

3. Aventuras todo-o-terreno

2. Introdução UML

Capítulos

Atributos atributo derivado atributo ou classe

x x

atributos paralelos

Associações agregação associação binária

associação ternária

associação unária

associação ordenada

x x

associações mutuamente exclusivas

atributo de associação

classe de associação

generalização

multiplicidade

composição

x x

Diversos 3 binárias vs. 1 ternária

associação dependente do tempo

x x

associação redundante

associações paralelas

x x

até que ponto normalizar

generalização excessiva

guardar histórico

hierarquias

interpretação de n:m

item e descrição de item limitações do modelo de classes previsto vs. realizado

x x

Tabela 1.1 – Organização das principais questões de modelação abordadas no livro e dos problemas em que estas são discutidas de forma mais profunda

2. Introdução ao UML através de um Exemplo Este capítulo apresenta uma introdução à utilização da linguagem de modelação conceptual de classes UML (Unified Modeling Language) através de um exemplo que consiste na especificação de um sistema de informa ção para auxiliar a gestão do negócio de um produtor de vinhos. O capítulo está organizado em duas partes: a Secção 2.1 explora uma versão simplificada do sistema e a Secção 2.2 discute um conjunto de requisitos e funcionalidades mais complexas.

2.1. UMA VERSÃO SIMPLIFICADA DE UM SISTEMA DE INFORMAÇÃO PARA UM PRODUTOR DE VINHOS

2.1.1. DESCRIÇÃO DO PROBLEMA Um produtor de vinhos de mesa pretende implementar um sistema de informação que lhe permita gerir a informação associada à produção dos seus vinhos. Atualmente, a empresa possui quatro propriedades agrícolas, estando em estudo a possibilidade de adquirir mais uma ou duas propriedades num futuro próximo. De cada propriedade, é necessário registar o nome pela qual é conhecida, a região vinícola que integra (por exemplo, se é no Douro ou no Alentejo), a área total em hectares (ha), o endereço, o número de telefone e o email. É ainda necessário registar a distância

Modelação de Dados em UML

e o respetivo tempo médio de viagem entre as propriedades mais importantes. Em cada uma das propriedades existem diversas vinhas. Cada vinha é caraterizada por uma designação, pela sua área útil de plantação, pelo tipo de solo (pode, por exemplo, ser de xisto ou de granito), pela sua exposição predominante (por exemplo, se está orientada a sul ou a nascente), a sua situação predominante (por exemplo, se é uma encosta acentuada, em socalcos, ou uma encosta suave), a altitude média, o ano em que foi plantada e um indicador da quantidade esperada (em pipas) de produção num ano normal. É ainda importante saber quais as castas (o tipo de uva) que estão plantadas em cada uma das vinhas. De referir que, enquanto nas vinhas adquiridas recentemente se optou por plantar uma única casta, algumas das vinhas mais antigas produzem uvas de mais de uma casta. Apesar disso, para cada vinha sabe‑se o número de pés plantados de cada uma das castas, sendo importante registar essa informação. Cada casta é caraterizada pela sua designação corrente (por exemplo, Touriga Nacional ou Tinta Roriz), uma descrição textual das suas caraterísticas, a cor (tinta ou branca) e a indicação se é uma casta de baixa, média ou elevada produtividade (sabe‑se, por exemplo, que a Touriga Nacional é uma casta de baixa produtividade, enquanto que a Tinta Roriz é de elevada produtividade). A atividade principal da empresa é a produção de vinhos. De cada vinho produzido importa saber a marca sob a qual é comercializado, o seu teor alcoólico, o número médio de meses de estágio em madeira, o preço de referência, o número médio de garrafas produzidas anualmente, a sua designação oficial (por exemplo, se é um VQPRD1 ou um DOC2) e o tipo de vinho (por exemplo, se é um vinho tinto, um vinho branco ou um espumante). É também importante registar uma descrição das principais caraterísticas de cada vinho comercializado. Em geral, um vinho está associado apenas a uma das propriedades, mas está atualmente em estudo um vinho que poderá vir a ser produzido com uvas provenientes de mais do que uma propriedade. É ainda importante saber, para cada vinho, quais as castas que o compõem e as percentagens correspondentes. 1 2

Vinho de Qualidade Produzido em Região Determinada. Denominação de Origem Controlada.

Introdução ao UML através de um Exemplo

2.2. INDO UM POUCO MAIS LONGE 2.2.1. DESCRIÇÃO DE ALGUNS REQUISITOS ADICIONAIS

Vamos agora considerar um conjunto de requisitos adicionais para o sistema de informação. O conceito de marca, tal como representado na Figura 2.9, corresponde a uma interpretação do negócio que é estática no tempo. De facto, o teor alcoólico, o número de garrafas produzidas, o número de meses em estágio, o preço de referência e a percentagem de cada variedade de uvas que compõem um determinado vinho são caraterísticas que podem variar para os diferentes anos de colheita. Será por isso importante prever o registo da informação que permita caraterizar o historial dos vinhos produzidos de uma determinada marca. Para representar este tipo de informação, que terá de ser definida anualmente, será necessário introduzir uma classe que represente o conceito de colheita. Vamos, por isso, considerar que uma colheita é caraterizada pelo ano a que corresponde, por uma data de início e de fim da vindima e por uma classificação de um a cinco que diz respeito à quantidade e à qualidade da produção obtida nesse ano. Será também interessante permitir a introdução de um breve texto que represente um comentário sobre o ano agrícola a que a colheita diz respeito. Um outro requisito para esta versão estendida do sistema é a manutenção de informação relativa ao pessoal. Sobre cada funcionário é importante saber o seu nome, data de nascimento, email, número de telemóvel, endereço de residência, data de contratação e vencimento mensal. De referir que há dois tipos de funcionários: os enólogos e os membros do pessoal permanente. Um elemento do pessoal permanente trabalha em exclusividade para a empresa, está associado a uma propriedade e tem uma categoria (por exemplo, gerente agrícola ou comercial). Tem ainda uma extensão telefónica associada. Por sua vez, os enólogos estão ligados à empresa mas não em regime de exclusividade, sendo por isso necessário registar a percentagem de dedicação relativa ao contrato. Além disso, os enólogos são responsáveis pelas marcas produzidas, havendo casos em que há mais de um enólogo responsável por uma determinada marca. Por último, vamos considerar o requisito que permite registar qual o elemento do pessoal permanente responsável pela vindima em cada uma das

Modelação de Dados em UML

propriedades, isto é, em cada colheita é indicado o elemento do pessoal permanente que fica responsável pela vindima de cada propriedade.

2.2.1.1. REDEFINIÇÃO DA MARCA COMO CONCEITO INTEMPORAL E INTRODUÇÃO DO CONCEITO DE COLHEITA

associação ternária, atributo de associação

Tal como é representado na Figura 2.15, a classe Marca passa agora a ter como atributos apenas aqueles que são invariáveis ao longo dos anos, passando o teorAlcoólico, o numGarrafas, o mesesEstágio e o preçoReferência a ser representados como atributos da associação entre as classes Marca e Colheita. Além disso, embora seja de esperar que uma marca mantenha as suas caraterísticas essenciais de ano para ano, é natural que a percentagem utilizada de cada tipo de uvas varie ao longo dos anos. Essa variação pode ser justificada por oscilações tanto na qualidade como na quantidade produzida de cada tipo de uva nos diferentes anos. Assim, uma vez incluída a classe Colheita, torna‑se necessário recorrer a uma associação ternária para representar a percentagem utilizada de cada casta numa determinada marca em cada colheita. Casta -... * -...

* Marca -marca -caraterís cas -tara

produzida

Colheita -ano -dataInícioVindima -dataFimVindima -classificaçãoQuan dade -classificaçãoQualidade -comentários

-teorAlcoólico -numGarrafas -mesesEstágio -preçoReferência

Figura 2.15 – Caraterização das classes relacionadas com o conceito de colheita

4. Surto de Gripe das Aves O principal objeto deste capítulo é ilustrar como é possível, a partir de uma descrição de um problema, ter diferentes opções e pressupostos que condicionam a solução. É apresentada uma descrição de um problema e uma proposta de solução, sendo discutidos os pressupostos e algumas alternativas possíveis.

4.1. DESCRIÇÃO DO PROBLEMA

Um observatório de saúde pública pretende implementar um sistema de informação que lhe permita acompanhar a evolução de um surto de gripe das aves. Uma importante fonte de informação sobre uma crise de gripe das aves são os ofícios e os comunicados oficiais emitidos por organismos responsáveis como, por exemplo, um comunicado do gabinete do Ministério da Agricultura. Assim, o sistema deverá manter um registo dos organismos responsáveis, sendo cada organismo caraterizado pela sua designação, nome do principal contacto, endereço, telefone, URL do site e uma descrição. O observatório deverá disponibilizar uma lista de contactos para o público em geral. Sobre cada contacto deverá ser disponibilizado o nome ou designação, o telefone, o email, a designação da respetiva especialidade (se, por exemplo, fornece informação sobre a prevenção ou sobre os diferentes vírus) e uma descrição. No caso de o contacto ser de um dos organismos referenciados, essa informação deverá ser incluída na base de dados. Note que um organismo pode ter mais do que um contacto para informação ao público.

Modelação de Dados em UML

Deverá também ser mantido um registo de todos os ofícios emitidos por cada organismo, sendo cada ofício caraterizado por um título, a data de divulgação, uma breve descrição, o URL do ficheiro correspondente e o formato do mesmo. Um ofício pode dizer respeito a uma ou mais espécies, sendo importante registar as espécies a que o ofício diz respeito. Será necessário ainda manter no sistema a informação que diz respeito às diferentes estirpes do vírus. Sobre cada estirpe é necessário saber a designação, uma descrição dos sintomas, a data em que foi identificada a estirpe, se a estirpe é contagiosa para os animais e se é contagiosa para os humanos. Além disso, é necessário saber quais são os medicamentos disponíveis para combater as diferentes estirpes do vírus da gripe das aves. Sobre cada medicamento é necessário saber a sua designação, o nome do laboratório que o disponibiliza, se é uma vacina ou um medicamento para tratamento e quais as estirpes a que se destina. O grau de eficácia de um medicamento para uma determinada estirpe deverá ser classificado de um a cinco. É necessário manter uma lista das espécies avícolas mais importantes, sendo cada espécie caraterizada por um nome, a indicação se é uma espécie doméstica ou selvagem e a indicação se se trata de uma espécie migratória. É também necessário manter um registo de propriedade de espécies avícolas. Assim, cada proprietário deverá ser caraterizado pelo nome, NIC (número de identificação civil, que corresponde ao número de BI mais o dígito de controlo, ou ao número do cartão de cidadão), endereço, telefone e email. Cada proprietário deverá indicar o número de aves de cada espécie que possui, se as aves estão em capoeira ou ao ar livre, e a data mais recente em que as aves de cada espécie foram declaradas. Finalmente, o sistema deverá manter um registo histórico dos casos detetados de cada estirpe em cada país, sendo fundamental saber a data e o número de aves de cada espécie afetada.

4.2. RESOLUÇÃO COMENTADA A Figura 4.1 apresenta uma proposta de solução para o problema proposto. Temos a classe Organismo e a classe Contacto, relacionadas com uma associação de n:1 com multiplicidade (0..1), uma vez que está implícito

13. Clube de Ténis Este problema aborda a diferença entre agregação e composição. Frequentemente, a escolha entre as duas alternativas está relacionada com a interpretação semântica dos conceitos envolvidos. A resolução deste problema apresenta e discute as duas alternativas de forma agnóstica, dado que a descrição do problema é suficientemente aberta para ambas as interpretações.

13.1. DESCRIÇÃO DO PROBLEMA A direção de um clube de ténis verificou a necessidade de implementar um sistema de informação com o objetivo de facilitar a gestão dos resultados dos torneios de ténis aí realizados. Sabendo que um encontro de ténis é composto por sets, e que cada set é formado por um conjunto de jogos, pretende‑se saber o resultado e duração de cada set referente a um dado encontro. Para cada set de um dado encontro pretende‑se guardar o resultado de cada um dos seus jogos. De um dado encontro interessa ainda saber qual a sua data de realização, em que court se realizou, quem foi o árbitro, quem foram os juízes de linha e as suas respetivas posições (linha de fundo, linha de serviço, etc.). Pretende‑se ainda saber qual o nome e a idade de cada jogador, árbitro e juiz de linha, e também a posição no Ranking ATP de cada um dos jogadores. Relativamente aos courts interessa saber a lotação máxima de cada um. No início de cada encontro realiza‑se um sorteio entre os jogadores/pares. O vencedor do sorteio pode decidir se escolhe o campo ou se escolhe ser servidor no primeiro jogo. É importante armazenar o resultado do sorteio, pois a escolha do serviço do primeiro jogo poderá determinar a forma como os resultados são guardados e apresentados.

129

Modelação de Dados em UML

13.2. RESOLUÇÃO COMENTADA

associação binária, multiplicidade

A resolução deste problema centra‑se no conceito de encontro, que corresponde a uma partida de ténis realizada entre dois (encontro de singulares) ou quatro (encontro de pares) jogadores. Esta restrição, conhecida de antemão e rígida neste desporto, é caraterizada pela associação binária entre a classe Jogador e a classe Encontro. Embora seja uma associação de n:m, a extremidade do lado da classe Jogador está assinalada com os valores 2 e 4, indicando que um jogo apenas pode ter dois ou quatro jogadores. O resultado do sorteio inicial, que decide qual o jogador a realizar o primeiro serviço ou a escolher o lado do campo onde o encontro se inicia, é caraterizado através de dois atributos na associação binária entre as classes Encontro e Jogador. Dado que um juiz de linha, em cada encontro, pode colocar‑se numa posição diferente, a posição é um atributo da associação binária entre a classe Encontro e a classe Juiz. Por último, cada encontro pode ser definido como sendo composto por um conjunto de sets, os quais, por sua vez, são compostos por jogos. O resultado de cada set é calculado a partir dos resultados dos jogos. Assim, cada jogo pertence a um set, o qual, por sua vez, pertence a um encontro. A esta interpretação corresponde o modelo apresentado na Figura 13.1. Árbitro -nome -dataNascimento

-campo -serviço tem

Court -designação -lotação 1

Set -designação -resultado -duração

* realiza-se

composto

par cipa

2;4

Encontro -data

1 composto *

Jogador -nome -dataNascimento -rankingATP Juiz -nome -dataNascimento

1 -posição

Jogo -designação -resultado

Figura 13.1 – Solução proposta para o problema Clube de Ténis

130

Clube de Ténis

O conceito de composição expresso nas associações binárias entre as classes Jogo e Set e entre as classes Set e Encontro permite caraterizar esta relação entre os conceitos. A propriedade fundamental de uma composição é que, quando eliminamos um objeto da classe Encontro (ou uma linha da tabela correspondente), devemos também eliminar todos os sets e todos os jogos desse encontro (na realidade, todos os objetos relacionados com esse encontro na classe Set e ainda todos os objetos relacionados com cada um desses sets na classe Jogo). Podemos, no entanto, apresentar uma interpretação alternativa. Mantendo‑se o conceito de encontro como uma partida de ténis entre dois ou quatro jogadores, podemos considerar que cada encontro é formado por um conjunto de sets abstratos (1.o set, 2.o set, etc.). Por sua vez, cada jogo pode ser interpretado como um jogo genérico que ocorre em qualquer set de um encontro (por exemplo, o terceiro jogo do 2.o set ou o segundo jogo do 1.o set). Assim, só conseguimos saber o resultado de um jogo concreto, realizado no âmbito de um encontro, quando o associamos ao set e ao encontro. A representação mais adequada para esta interpretação encontra‑se apresentada no modelo da Figura 13.2. -campo -serviço

* *

tem

2;4

par cipa

realiza-se

Set -designação -resultado -duração

Jogador -nome -dataNascimento -rankingATP

* *

Encontro -data

tem

Court -designação -lotação

Árbitro -nome -dataNascimento

-resultado *

Jogo -designação -resultado

Juiz -nome -dataNascimento

-posição

Figura 13.2 – Solução alternativa proposta para o problema Clube de Ténis

131

composição

Modelação de Dados em UML

agregação

A utilização do conceito de jogo genérico pode ser justificada pela necessidade de produzir estatísticas relacionadas com os encontros. Será mais simples, usando esta interpretação alternativa, analisar o histórico do desempenho dos jogadores (por exemplo, quais os resultados mais comuns de um dado jogador ao fim dos dois primeiros sets ou quais os resultados no fim do terceiro jogo). Neste modelo, a associação binária entre Encontro e Set é uma agregação em vez de uma composição. Embora um encontro seja formado por vários sets, um set genérico (por exemplo, o 2.º set) ocorre em vários encontros. O modelo da Figura 13.1 é mais simples e natural e o modelo relacional correspondente bastante direto. O modelo da Figura 13.2, além de mais abstrato e menos intuitivo, irá ser um pouco mais complexo, já que irá exigir uma chave primária tripla resultante da associação ternária.

EXERCÍCIOS 1) A opção de utilizar atributos na associação entre as classes Jogador e Encontro para indicar o resultado do sorteio é discutível. Num encontro de singulares (apenas dois jogadores) poderá ser uma boa opção, mas, no caso de um encontro de pares, os atributos da associação são redundantes para o outro jogador da mesma equipa. Que alterações poderiam ser introduzidas no modelo por forma a garantir que o resultado do sorteio seja armazenado corretamente mas sem introdução de redundância? 2) Na descrição do problema não é referido o sexo dos jogadores. Contudo, no ténis os encontros são separados por género, exceto nos pares mistos. Será possível acrescentar ao modelo este tipo de requisitos? Como o poderia fazer sem acrescentar complexidade desnecessária?

132

Anexo – Guia de Referência Rápida da Linguagem UML para a Modelação Conceptual de Classes

Funcionário

trabalha para

-colaborador

-empregador

t_funcionario funcionario_id

Empresa

t_empresa ...

empresa_id

...

Figura A.3 – Associação binária de 1:n e as tabelas correspondentes no modelo relacional. O nome da associação trabalha para é indicado para guiar a leitura da mesma, sendo muitas vezes omitido quando a leitura é óbvia. O papel das classes da associação (colaborador e empregador) apenas é indicado quando considerado fundamental para a leitura do diagrama

Funcionário

* -colaborador

t_funcionario funcionario_id

trabalha para

-empregador

t_empresa ...

Empresa

empresa_id

t_funcionario_empresa funcionario_id

...

empresa_id

Figura A.4 – Associação binária de n:m e as tabelas do modelo relacional correspondente

Funcionário

t_funcionario funcionario_id

gostava de trabalhar

t_empresa ...

empresa_id

* {ordered}

Empresa

t_funcionario_empresa ...

funcionario_id

empresa_id

ordem

Figura A.5 – Representação de uma associação ordenada e uma forma possível de a converter no modelo relacional. Alternativamente, pode optar‑se por omitir o atributo da associação e deixar a implementação da ordenação para uma fase posterior da conceção do sistema. A ordenação também pode ser indicada através de um atributo de associação (ver Figura A.7)

163