A Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada Modelagem de Dados 1 A linguagem de Modelagem Unificada (UML Unified Modeling Language) é uma linguagem gráfica para comunicar especificações de projeto para software. A comunidade de desenvolvimento de software orientada a objeto criou a UML para encontrar necessidades especiais de descrição de projeto de software orientado a objeto. UML tem se tornado um padrão para o projeto de sistemas digitais em geral. Existe um número de tipos diferentes de diagramas UML servindo para vários propósitos. Os diagramas tipo classe e atividade são particularmente úteis para tratar do projeto de banco de dados. O diagrama de classe UML captura os aspectos estruturais encontramos em esquemas de banco de dados. Diagramas de atividade UML facilitam a discussão nos processos dinâmicos envolvidos no projeto de banco de dados. Diagramas de classe UML e modelos entidade-relacionamento (MER) são similares tanto em forma quanto em semântica. Os criadores da UML chamam a atenção para a influência de modelos ER nas origens dos diagramas de classe. A influência da UML tem por sua vez afetado a comunidade de banco de dados. Diagramas de classe agora aparecem frequentemente na literatura de banco de dados para descrever esquemas de banco de dados. Diagramas de atividade UML são similar em propósito aos fluxogramas. Processo são particionados em atividades competentes junto com controles de especificações de fluxo. Diagramas de classe A classe é um descritor para um conjunto de objetos que compartilham alguns atributos e/ou operações. Nós conceitualizamos classes de objetos em nossa vida todos os dias. Por exemplo, um carro tem atributos, por exemplo, um número identificador do veículo (chassis) e quilometragem. Um carro também tem operações, por exemplo, acelerar e frear. Todos os carros têm esses atributos e operações. Carros individualmente diferem nos detalhes. Um determinado carro tem um valor para o chassi e quilometragem. Carros individualmente são objetos que são instâncias da classe Carro. Classes e objetos são um meio natural de conceitualizarmos o mundo ao nosso redor. Os conceitos de classes e objetos são também os paradigmas que formam o fundamento da programação orientada a objeto. O desenvolvimento da programação orientada a objeto levou a necessidade de uma linguagem para descrever projeto orientado a objeto, ocasionando a UML. Há uma correspondência próxima entre diagramas de classe em UML e diagramas ER. Classes são análogas a entidades. Esquemas de banco de dados podem ser diagramados usando UML. É possível conceitualizar uma tabela de um banco de dados como uma classe. As colunas na tabela são os atributos, e as linhas são os objetos daquela classe. Por exemplo, nós podemos ter uma tabela chamada Carro com colunas chamadas chassi e quilometragem. Cada linha na tabela teria valores para essas colunas, representando um carro individualmente. A maior diferença entre classes e entidades é a falta de operações nas entidades. Note que o termo operação é usado aqui na UML no sentido da palavra. Stored

2 A Linguagem de Modelagem Unificada procedures, funções, triggers, e constraints são formas nomeadas de comportamentos que podem ser definidos em banco de dados; contudo, esses não são associados com o comportamento de linhas individualmente. O termo operação em UML se refere ao método inerente de classes de objetos. Esses comportamentos não são armazenados na definição das linhas dentro do banco de dados. Não há operações chamadas acelerar ou frear associadas com as linhas na sua tabela Carro. Classes podem ser mostradas com atributos e sem operações no UML, que é o uso típico para esquemas de banco de dados. Notação básica do diagrama de classe A figura acima ilustra a sintaxe UML para uma classe, mostrando ambos, atributos e operações. É possível incluir também usuário definido, chamado comportamentos, por exemplo, responsabilidades O ícone UML para uma classe é um retângulo. Quando a classes é mostrada com atributos e operações, o retângulo é subdividido em três compartimentos horizontais. O primeiro compartimento contém o nome da classe. Tipicamente, nomes de classes são substantivos. O compartimento do meio contém os nomes dos atributos. O último compartimento contém os nomes das operações, terminando com parênteses. Os parênteses podem conter argumentos para a operação. A notação de classe tem algumas variações, refletindo ênfase. Classes podem ser escritas sem o compartimento de atributos e/ou compartimento de operações. Operações são importantes no software. Se o analista de software deseja focar nas operações, a classe pode ser mostrada apenas com os compartimentos nome da classe e de operações. Mostrar operações e ocultar atributos é uma sintaxe muito comum usada por analistas de software. Analistas de banco de dados, por outro lado, geralmente não tratam com operações de classes; contudo, os atributos são de primordial importância. As necessidades do analista de banco de dados podem ser encontradas escrevendo a classe com apenas o nome da classe o mostrando os compartimentos de atributos. Ocultar operações e mostrar atributos é uma sintaxe incomum para o analista de software, mas é comum para analista de banco de dados. Por último, nos diagramas de níveis mais altos, é frequentemente desejável ilustrar os relacionamentos das classes sem tornar-se enredado nos detalhes de atributos e operações. Classes podem ser escritas com apenas o compartimento nome da classe quando é desejável simplicidade. Vários tipos de relacionamentos podem existir entre classes. Associações são um tipo de relacionamento. A forma mais genérica de associação é desenhar com uma linha conectando duas classes. Por exemplo, na figura abaixo há uma associação entre a classe Carro e a classe Motorista. Poucos tipos de associações, por exemplo, como agregação e composição, são muito comuns. UML tem símbolos designados para essas associações. Agregação indica parte de associações, onde as partes tem uma existência independente. Por

Modelagem de Dados 3 exemplo, um Carro pode ser parte de um Acervo de Carros. O Carro também pode existir por si próprio, independente de um Acervo de Carros. Outro aspecto distinto de agregação é que a parte pode ser compartilhada com múltiplos objetos. Por exemplo, um Carro pode pertencer a mais que um Acervo de Carro. A associação de agregação é indicada com um losango oco atado a classe que tem as partes. A figura abaixo indica que um Acervo de Carro agrega Carros. Composição é outra parte de associação, onde as partes são estritamente próprias, não compartilhadas. Por exemplo, uma Estrutura é parte de um único carro. A notação para composição é uma associação adornada com um losango preenchido de preto atado a classe que é a parte proprietária. A figura abaixo indica que uma Estrutura é parte da composição de um Carro. Generalização é outro relacionamento comum. Por exemplo, Sedan é um tipo de carro. A classe Carro é mais geral que a classe Sedan. Generalização é indicada por uma linha contínua adornada com uma ponta de flecha oca apontando para a classe mais geral. A figura abaixo mostra a generalização da classe Sedan para a classe Carro. Diagramas de classe para um projeto de banco de dados A figura abaixo ilustra construções UML para relacionamentos com vários graus de associação e multiplicidades. Esses exemplos são paralelos ao modelo ER.

4 A Linguagem de Modelagem Unificada Associações entre classes podem ser reflexiva, binária, ou n-ária. Associação reflexiva é um termo que nós carregamos do modelo ER. Não é um termo definido em UML, embora valha à pena discutir. Associação reflexiva relata uma classe para si mesma. A associação abaixo significa que um Funcionário no papel de gerente é associado com muitos Funcionários gerenciados. O papel das classes no relacionamento pode ser indicado no fim do relacionamento. O número de objetos envolvidos no relacionamento, se refere como multiplicidade, pode também ser especificado no final do relacionamento. Um asterisco indica que muitos objetos fazem parte da associação no final do relacionamento. As multiplicidades da associação reflexiva no exemplo abaixo indica que um Funcionário está associado com um gerente, e um gerente está associado com muitos Funcionários gerendiados. Uma associação binária é um relacionamento entre duas classes. Por exemplo, uma Divisão tem muitos Departamentos. Note o losango preto na Divisão finaliza o relacionamento. O losango inteiriço é um adereço a associação que indica composição. A Divisão é composta de Departamentos. O relacionamento ternário na figura abaixo é um exemplo de uma associação n- ária uma associação que relaciona três ou mais classes. Todas as classes coparticipativas na associação são conectadas a um losango vazado. Papéis e/ou multiplicidades são opcionalmente indicadas no final da associação n-ária. Cada final da associação ternária no exemplo abaixo é marcado com um asterisco, significando muitos. O significado de cada multiplicidade é isolado das outras multiplicidades. Dada uma classe, se você tem exatamente um objeto de muitas outras classes na associação, a multiplicidade é o número de objetos associados a determinada classe. Um Funcionário trabalhando em um Projeto atribuído utiliza muitas Habilidades. Um Funcionário utiliza uma Habilidade para muitos Projetos atribuídos. Uma Habilidade utilizada em um Projeto é realizada por muitos Funcionários. Os próximos três diagramas de classe na figura abaixo mostram várias combinações de multiplicidades. A associação um-para-um ilustrada especifica que cada Departamento está associado com exatamente um Funcionário atuando no papel de gerente, e cada gerente está associado com exatamente um Departamento. O diagrama com associação uma-para-muitos significa que cada Departamento tem muitos Funcionários, e cada Funcionário pertence a exatamente um Departamento. O exemplo muito-para-muitos na figura abaixo significa que cada Funcionário associa-se com muitos Projetos, e cada Projeto associa-se com muitos Funcionários. Esse exemplo também ilustra o uso de uma associação de classe. Se uma associação tem

Modelagem de Dados 5 atributos, esses são escritos em uma classe que é ligada a associação com uma linha tracejada. A associação de classe chamada Atribuição_Trabalho na figura abaixo contém duas associações de atributos chamados atribuição_tarefa e data_início. A associação e a classe juntas formam uma associação de classe. Multiplicidade pode ser um intervalo de inteiros, escrito com os valores mínimo e máximo separados por dois períodos. O asterisco por si leva o mesmo significado como o intervalo [0..*]. Também, se os valores mínimos e máximos são o mesmo número, então a multiplicidade pode ser escrita como um único número. Por exemplo, [1..1] significa o mesmo que [1]. Existência opcional pode ser especificada usando um zero. O [0..1] na existência opcional do exemplo na figura abaixo significa que um Funcionário no papel de gerente é associada ou não com um Departamento (exemplo, administração superior). Existência obrigatória é especificado sempre que uma multiplicidade começa com um inteiro positivo. O exemplo de existência obrigatória abaixo significa que um Funcionário é ocupante de exatamente um Escritório. Um na extremidade da associação pode indicar existência obrigatória, enquanto a outra extremidade pode ser existência opcional. Esse é o caso no exemplo, onde um Escritório pode ter qualquer número de ocupante, inclusive zero. Generalização é outro tipo de relacionamento. Uma superclasse é uma generalização de uma subclasse. Especialização é o relacionamento oposto da generalização. Uma subclasse é uma especialização da superclasse. O relacionamento de generalização no UML é escrito com uma seta vazada apontando da subclasse para a superclasse generalizada. A figura abaixo mostra quatro subclasses: Gerente, Engenheiro, Técnico e Secretária. Essas quatro subclasses são todas especializações da superclasse mais geral, Funcionário onde, Gerentes, Engenheiros, Técnicos e Secretárias são tipos de Funcionários.

6 A Linguagem de Modelagem Unificada Note que os quatro relacionamentos compartilham uma ponta de seta comum. Semanticamente, esses são ainda quatro relacionamentos separados. O compartilhamento da ponta da seta é permissível em UML, para melhorar a clareza dos diagramas. O exemplo abaixo ilustra que a classe pode agir como uma subclasse em um relacionamento e uma superclasse em outro relacionamento. A classe chamada Individual é uma generalização das classes Funcionário e Cliente. As classes Funcionário e Cliente são por sua vez superclasses da classe FunCli. Uma classe pode ser uma subclasse em mais que uma relacionamento de generalização. O significado no exemplo onde um objeto FunCli é ambos um Funcionário e um Cliente. Você pode ocasionalmente verificar que UML não produz um símbolo padrão para o que você está tentando comunicar. UML incorpora alguma extensibilidade para acomodar necessidades do usuário, como uma observação. Uma observação em UML é escrita como um retângulo com a ponta virada no canto superior direito. A observação pode anexar ao(s) elemento(s) pertinente(s) com uma linha pontilhada. Escreva brevemente em uma observação o que você deseja transmitir. O diagrama na figura acima ilustra uma observação, que descreve as classes Funcionário e Cliente como Completa enumeração de subclasses. A diferença entre composição e agregação é algumas vezes esquisito para os novatos na UML. A figura abaixo mostra um exemplo de cada, para ajudar na clareza. O diagrama de cima significa que um Programa e Documentação Eletrônica ambos contribuem para a composição de um Produto de Software. A composição significa que as partes não existem sem o Produto de Software (não há software pirata no seu mundo ideal). O diagrama de baixo especifica que um Professor e um LivroTexto são partes do Curso, mas eles também existem separadamente. Se um curso é cancelado, o Professor e o LivroTexto continuam a existir.

Modelagem de Dados 7 A figura abaixo ilustra outro exemplo de um relacionamento n-ário. O relacionamento n-ário pode ser clarificado por especificar papéis próximos às classes participantes. Um Aluno é inscrito em um curso, associado com uma dada localização de Sala e um Dia programado e Hora de encontro. O conceito de uma chave primária surge no contexto do projeto de banco de dados. Frequentemente, cada linha de uma tabela é unicamente identificada por valores contidos em uma ou mais colunas designadas como a chave primária. Objetos em software não são tipicamente identificados dessa maneira. Como um resultado, UML não tem um ícone representando uma chave primária. Contudo, UML é extensivo. O significado de um elemento em UML pode ser estendido com um estereótipo. Estereótipos são retratados com uma palavra ou frase de uma linguagem natural curta, incluso entre aspas: «e». Nós tomamos vantagem dessa extensibilidade, usar um estereótipo «pk» para designar atributos de chave primária. A figura abaixo ilustra o mecanismo do estereótipo. O atributo chassi é especificado como a chave primária para Carros. Isso significa que um dado CHASSI identifica um Carro específico.

8 A Linguagem de Modelagem Unificada Exemplo da indústria de música Grandes esquemas de banco de dados podem ser apresentados com elevado número de diagramas. Detalhes podem ser irrompidos em diagramas adicionais. A meta global é apresentar idéias de forma clara, e maneira organizada. UML oferece variações de notação e um mecanismo organizacional. Você verá algumas vezes que já múltiplas maneiras de representar o mesmo assunto em UML. As decisões que você estabelece com consideração para sua representação dependem em parte do seu propósito para um dado diagrama. As figuras abaixo ilustram algumas das possibilidades com um exemplo tirado da indústria de música. Pacotes podem ser usados para organizar classes dentro de grupos. Pacotes podem também serem agrupados dentro de pacotes. O objetivo de usar pacotes é fazer o projeto global de um sistema mais compreensível. Um uso para pacotes é representar um esquema. Você pode então mostrar múltiplos esquemas conciso. Outro uso para pacotes é agrupar classes relacionadas junto com um esquema, e apresentar o esquema claramente. Dado um conjunto de classes, diferentes pessoas podem conceituar diferentes grupos. A divisão é uma decisão de projeto, sem respostas certas ou erradas. Qualquer que sejam as decisões tomadas, o resultado poderia aumentar a legibilidade. A notação para um pacote é um ícone de pasta, e os conteúdos de um pacote podem ser opcionalmente mostrados no corpo da pasta. Se os conteúdos são mostrados, então o nome do pacote é colocado na guia. Se os conteúdos são omitidos, então o nome do pacote é mostrado no corpo do ícone. Se a proposta é ilustrar os relacionamentos dos pacotes, e as classes não são importantes no momento, então é melhor ilustrar com os conteúdos omitidos. A figura abaixo ilusta a notação com o exemplo da indústria da música no nível mais alto. Música é criado e colocado na Mídia. A Mídia é então distribuída. Há uma associação entre a Música e a Mídia, e entre a Mídia e Distribuição. A indústria da música é ilustrada na figura abaixo com as classes listadas. O pacote Música contém as classes que são responsáveis por criar a música. Exemplos de Grupos são os Beatles e Bangles. Sarah McLachlan e Sting são Artistas. Grupos e Artistas estão envolvidos na criação da música. O pacote Mídia contém classes que fisicamente possuem os registros da música. O pacote Distribuição contem classes que trazem a mídia até você.

Modelagem de Dados 9 O conteúdo de um pacote pode ser expandido em maiores detalhes. Os relacionamentos das classes dentro do pacote Música são ilustrados na figura abaixo. Um Grupo é uma agregação de dois ou mais Artistas. Como indicada pela multiplicidade entre Artista e Grupo [0..*], um Artista pode ou não estar em um Grupo, e pode estar em mais que um Grupo. Compositor, Cantor e Músicos são tipos diferentes de Artistas. Uma Canção está associada com um ou mais Compositores. Uma Canção pode não ter um Cantor, ou qualquer número de Cantores. Uma Canção pode ter qualquer número de Capitulações. Uma Capitulação é associada com exatamente uma Canção. Uma Capitulação está associada com Músicos e Instrumentos. Uma dada combinação de Músico-Instrumento está associada com qualquer número de Capitulações. Uma combinação específica Capitualação-Músico pode ser associada com qualquer número de Instrumentos. Uma dada combinação Capitulação-Instrumento está associada com qualquer número de Músicos. Um sistema pode ser entendido mais facilmente por mudança de foco para cada pacote por vez. Nós voltamos nossa atenção agora para as classes e relacionamentos no pacote Mídia, mostrado na figura abaixo. As classes associadas dos pacotes de Música e Distribuição também são mostrados, detalhando como o pacote Mídia está relacionado com outros dois pacotes. A Mídia da Musica está associada com as classes Grupo e Artista, que estão contidos no pacote Música (mostrado acima). A Mídia da Música está associada também com as classes Editor, Estúdio e Produtor, que estão contidos no pacote Distribuição (já mostrado). Álbuns e CDs são tipos de Mídia de Música. Álbuns e CDs são compostos de Faixas. Faixas são associadas com Capitulação.

10 A Linguagem de Modelagem Unificada Exercícios 1. Complete os desenhos abaixo que representam os relacionamentos indicados: FORNECEDOR PRODUTO FORNECEDOR (N) : N PRODUTO (fornece) DEPARTAMENTO FUNCIONÁRIO DEPARTAMENTO 1 : N FUNCIONÁRIO (aloca) ROTATIVA TIPO PAPEL ROTATIVA (N) : N TIPO PAPEL (imprime) 2. A partir das indicações dos relacionamentos, construa o desenho do modelo de dados indicando o nome dos relacionamentos no desenho: ALUNO (N) : N DISCIPLINA (cursa) DISCIPLINA N : 1 PROFESSOR (é_ministrada) ALUNO N : 1 CURSO (está_inscrito) DISCIPLINA (N) : (N) LIVRO (utiliza) 3. O acervo iconográfico é composto de ícones de diferentes tipos, tais como fotos, slides, cromos, negativos. Os ícones são identificados recebendo um código único, portanto não há dois ícones com o mesmo código, e são classificados por assunto tais como ecologia, esporte, astronomia, trânsito, gastronomia, etc. Um ícone nunca pode ser classificado em dois assuntos, somente em um, sempre é escolhido um assunto preferencial. O analista de sistemas responsável pelo desenvolvimento do modelo de dados encontrou três entidades: ASSUNTO para retratar as classificações possíveis de um ícone: ecologia, trânsito, etc.; ÍCONE para retratar cada um dos ícones identificados: ícone 1.115, ícone 1876, etc.; TIPO ÍCONE para retratar o tipo de ícone: slide, cromo, etc. a) A partir dessas considerações desenhe o modelo de dados que retrate a realidade descrita. b) Desenhe a seguir os relacionamentos do modelo que você criou. 4. O funcionário está dedicado a um departamento, tem vários ou nenhum dependente, pode ou não autorizar a assinatura de um contrato e é, algumas vezes, responsável por um bem patrimonial da organização. Um contrato pode ser autorizado por mais de um funcionário, porém todo bem patrimonial só pode ter um responsável. a) Quais as entidades encontradas na situação acima? b) Construa o provável modelo de dados que retrate esta realidade. c) Indique as entidades onde deverão estar os atributos abaixo: ATRIBUTO ENTIDADE id_bem_patrimonial nm_departamento dt_inicio_validade_contrato cd_matricula_funcionario

Bibliografia Database Modeling and Design: Logical Design Toby Teorey, Sam Lightstone, Tom Nadeau, H. V. Jagadish USA: Elsevier, 2011 Modelagem de Dados 11