IN1008 – Projeto Conceitual de BD Diagramas UML para Modelagem de Dados Por: Clarissa César Borba ccb@cin.ufpe.br Fabrício Cabral fbc@cin.ufpe.br

Roteiro Motivação Estado da Arte Introdução Diagramas Referências Diagrama de Casos de Uso Diagrama de Classes Referências

Motivação A UML foi planejada para ser uma linguagem flexível e customizável, podendo ser utilizada para vários propósitos, não só para a construção de aplicações Orientada a Objetos Permite diferentes tipos de modelagem, incluindo modelos para processos de negócio, fluxo de eventos, aplicações, arquiteturas e banco de dados Unificação de todos os modelos do sistema (aplicação e bando de dados) em torno de uma única linguagem, que pode ser compartilhada por todos os envolvidos no desenvolvimento do sistema (analistas, programadores, DBAs, etc)

Estado da Arte A UML está em contínuo desenvolvimento UML 1.1, 1.3, 1.4, 1.5, 2.0 e UML 2.1 Novas linguagens baseadas na UML estão sendo desenvolvidas, a fim de solucionar problemas específicos SysML (Systems Modeling Language)

Introdução Unified Modeling Language A UML é uma linguagem de modelagem para: Visualização Especificação Construção Documentação Comunicação A UML (Unified Modeling Language) é uma linguagem para especificação, documentação, visualização e desenvolvimento de sistemas orientados a objetos. Sintetiza os principais métodos existentes, sendo considerada uma das linguagens mais expressivas para modelagem de sistemas orientados a objetos. Por meio de seus diagramas é possível representar sistemas de softwares sob diversas perspectivas de visualização. Facilita a comunicação de todas as pessoas envolvidas no processo de desenvolvimento de um sistema - gerentes, coordenadores, analistas, designers e desenvolvedores - por apresentar um vocabulário de fácil entendimento.

Criadores da UML James Rumbaugh - Object Modeling Technique (OMT) Grady Booch - Booch Method Ivar Jacobson - Objectory (OOSE) Process

Por que os 3 autores resolveram criar a UML? Cada autor adotava idéias dos métodos dos outros, então, evoluindo juntos produziriam melhorias A unificação dos 3 métodos trariam estabilidade para o mercado Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

História Fonte: http://www.cin.ufpe.br/~if119 Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML. Fonte: http://www.cin.ufpe.br/~if119

Elementos Essenciais Elementos Estruturais Elementos Comportamentais Elementos de Agrupamento Elementos de Anotação

Elementos Estruturais São as partes estáticas de um modelo, representando elementos que são ou conceituais ou físicos. Exemplos: Classe Interface Use Cases Componente Nó Em orientação a objeto, uma classe abstrai um conjunto de objetos com características similares. Uma classe define o comportamento de seus objetos através de métodos e os estados possíveis destes objetos através de atributos. Em outros termos, uma classe descreve os serviços providos por seus objetos e quais informações eles podem armazenar.

Elementos Comportamentais São as partes dinâmicas dos modelos da UML. Exemplos: Interação - especifica um conjunto de mensagens trocadas entre objetos Máquina de Estado - especifica seqüências de estados de um objeto

Elementos de Agrupamento São as partes organizacionais dos modelos da UML. Exemplos: Pacotes - mecanismo para organização de elementos dentro de grupos

Elementos de Anotação São partes explicativas dos modelos da UML. São comentários que você aplica para descrever, iluminar e remarcar elementos no modelo. Exemplos: Nota - símbolo contendo restrições ou comentários que são melhor expressadas em textos

Diagramas São representações gráficas de um conjunto de elementos. São desenhados para visualizar um sistema de diferentes perspectivas. Exemplos: Diagramas Estruturais Diagramas Comportamentais Diagramas de Interação Structure diagrams emphasize what things must be in the system being modeled: Class diagram Composite structure diagram Deployment diagram Object diagram Package diagram Behavior diagrams emphasize what must happen in the system being modeled: Activity diagram State Machine diagram Use case diagram Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled: Communication diagram Interaction overview diagram (UML 2.0) Sequence diagram UML Timing Diagram (UML 2.0)

Diagramas Estruturais Diagrama de Objetos Diagrama de Classes Diagrama de Componentes Diagrama de Instalação Diagrama de Pacotes Diagrama de Estrutura (UML2.0) O Diagrama de pacotes definido pela UML descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos mostrando as dependências entre estes, ou seja, pacotes podem depender de outros pacotes. Este diagrama é muito utilizado para ilustrar a arquitetura de um sistema mostrando o agrupamento de suas classes. O Diagrama de estrutura composta definido apartir da UML 2.0 da RUP destina-se à descrição dos relacionamentos entre os elementos. Utilizado para descrever a colaboração interna de classes, interfaces ou componentes para especificar uma funcionalidade.

Diagramas Comportamentais Diagrama de Caso de Uso Diagrama de Transição de Estados Diagrama de Atividade

Diagramas de Interação Diagrama de Sequência Diagrama de Interatividade Diagrama de Colaboração ou Comunicação Diagrama de Tempo (UML2.0) Diagramas de interatividade são variações de "Diagrama de atividades". Nele, sequências formam um fluxo de atividades, mostrando como elas trabalham em uma sequência de eventos. O Diagrama de tempo incluído a partir da UML 2.0 apresenta o comportamento dos objetos e sua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.

Diagramas

Diagramas de Use Case São especialmente importantes na organização e modelagem dos comportamentos de um sistema Use Case é a especificação de sequências de ações que um sistema, subsistema ou classe pode realizar, interagindo com um dos agentes O Diagrama de Caso de Uso descreve a funcionalidade proposta para o novo sistema. Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos Casos de Uso. Cada Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto. Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.

Diagramas de Use Case Solicitar Solicitar histórico do histórico Estudante Secretária <<estende>> Solicitar histórico do semestre atual Solicitar histórico de todos os semestres Solicitar histórico Verificar dependências Matricular aluno <<inclui>> Sistema de controle de pré-requisitos O Diagrama de Casos de Uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.

Diagramas de Classe Os diagramas de classes são os principais diagramas estruturais da UML Diagramas de classe mostram classes, interfaces e seus relacionamentos As classes especificam a estrutura e o comportamento dos objetos, que são instâncias de classes Diagrama de classes representa a estrutura das classes de um sistema orientado a objetos. Esse diagrama se propõe a demonstrar a estrutura das classes, com seus atributos, métodos e relações existente entre as classes do sistema orientado a objeto.

Diagramas de Classe itens representante de vendas IPessoa Cliente +confirmar() +cancelar() -calcularTotal():Currency gerarNovoCodigo: String -codigo: Integer -dataRecebido -total: Currency Pedido #creditoPermitido: Currency #nivelCredibilidade() -nome: String -endereco: String -dataPrimeiraCompra: Date -dataUltimaCompra: Date -totalComprado: Currency Cliente -quantidade: Integer -preco: Currency -emEstoque: Boolean Item de Pedido nomeContato: String telefones[1..10]: String CGC: String FAX[1..3]: String Cliente pessoa-jurídica colocarListaNegra() nome: String CPF: String numCartaoCredito Cliente pessoa-física Empregado Produto * representante de vendas IPessoa itens

Diagramas de Objetos Mostram objetos e seus relacionamentos Representam instâncias estáticas de elementos dos diagramas de classes Os diagramas de objetos são úteis para a modelagem de estruturas de dados complexas O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução. A mesma notação do diagrama de classes é utilizada com duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados.

Diagramas de Objetos * p2: Professor matricula: "205-6712-09" nome: "Jaelson Castro" p1: Professor codCurso: "IF291" descrição: "MPS" codTurma: I7 : Curso codCurso: "IF185" descrição: "AER" codTurma: I6 matricula: "219846534" nome: "Nelson Mandella" :aluno matricula: "562746134" nome: "John Major" : Aluno c1: Curso c2: Curso c3: Curso Bill Lewinsky -matrícula: String -nome: String Professor -codDisciplina: String -descrição: String -codTurma: String Curso -período: Integer Aluno [0..10] ministra [1..5] * [1..3]

Diagramas de Seqüência Mostram um conjunto de objetos, seus relacionamentos e as mensagens que podem ser enviadas entre eles Em síntese: o Diagrama de Seqüência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do sistema (Use Cases), depois, é definido como o software realizará seu papel(Seqüência de operações).

Diagramas de Seqüência Janela de entrada de pedido p: Pedido : ItemPedido :ItemEstoque preparar() * [para cada item do pedido] emEstoque := verificar() [emEstoque] remover() estoqueBaixo := verificEstoqueBaixo() :ItemRenovEstoque :ItemEntrega [estoqueBaixo] <<criar>>

Diagramas de Colaboração Mostram um conjunto de objetos, seus relacionamentos e as mensagens que enfatizam a organização dos objetos que trocam mensagens Um Diagrama de colaboração é definido pelo UML (Unified Modeling Language). O Diagrama de Colaboração exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. O diagrama de sequência e colaboração são isomórficos.

Diagramas de Colaboração

Diagramas de Estados Mostram uma máquina contendo estados, transições, eventos e atividades Estes diagramas são usados para modelar o comportamento de objetos (com comportamento complexo) Nestes diagramas são modelados os estados em que um objeto pode estar e os eventos que fazem o objeto passar de um estado para outro Em engenharia de software e eletrônica digital, um diagrama de transição de estados é uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Com isso, o objeto pode passar de um estado A (estado inicial) para um estado B (estado final) através de uma transição.

Diagramas de Estados

Diagramas de Atividades São um caso especial dos Diagramas de Estados, com a maioria das transições resultantes do término das atividades Mostram o fluxo entre atividades (ações não-atômicas) São semelhantes aos antigos fluxogramas São muito usados para modelar atividades concorrentes O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada (UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processo computacional. Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

Diagramas de Atividades Procurar bebida [achou café] H Pessoa [sem café] [sem Coca] [achou Coca] Pegar lata de Coca Beber Adicionar água à máquina Colocar café no filtro Colocar filtro na máquina Ligar máquina Filtrar café Pegar xícara Colocar café na

Diagramas de Componentes Mostram componentes e os relacionamentos entre eles São usados para modelar o aspecto físico de um sistema Exemplos de componentes são documentos, executáveis e tabelas de bancos de dados Diagrama de componentes da UML ilustra como as classes deverão se encontrar organizadas através da noção de componentes de trabalho. Por exemplo, pode-se explicitar, para cada componente, qual das classes que ele representa. É utilizado para: Modelar os componentes do código-fonte, do código executável do software. Destacar a função de cada módulo para facilitar a sua reutilização. Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

Diagramas de Componentes FormCadastro.html Cadastro.exe Principal.html FormEntrada.html Autenticacao.exe <<link>> Banco Usuários Senhas

Diagramas de Implantação São usados para modelar o ambiente em que o sistema será executado São compostos por nós e relacionamentos de comunicação Um nó pode ser um computador, uma rede, um disco rígido, um sensor, etc. O Diagrama de instalação é definido pela Linguagem de Modelagem Unificada, descreve os componentes de hardware e software e sua interação com outros elementos de suporte ao processamento.

Diagramas de Implantação servidorWeb Autenticação.exe Cadastro.exe servidorDeArquivos FormCadastro.html Principal.html FormEntrada.html servidorBancoDeDados SGBD O SGBD a ser utilizado ainda não foi escolhido. PC - G309 Nestscape Communicator 5.0

Ferramentas JUDE Rational Rose Borland Together http://jude.change-vision.com Rational Rose http://www-306.ibm.com/software/rational Borland Together http://www.borland.com/us/products/together Poseidon (baseada no ArgoUML) http://www.gentleware.com MagicDraw UML http://www.magicdraw.com

Diagramas de Use Cases

Origem Ivar Jacobson Alistair Cockburn Uma das técnicas mais populares para um processo mais rápido e eficiente de levantamento e validação de requisitos de sistemas de software é a utilização de Casos de Uso para descrever claramente todos os requisitos de um dado sistema, esta técnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE, visando identificar os requisitos de um sistema. Foi aprimorada por várias outras personalidades do campo, como por exemplo, Alistair Cockburn. Posteriormente foi incorporado à linguagem UML, que define um diagrama para representar graficamente os casos de uso e seus relacionamentos (Diagrama de classes).

Caso de Uso Caso de uso (use case) é uma técnica empregada para especificar o comportamento que se espera do sistema. Casos de uso possibilitam que desenvolvedores obtenham uma compreensão comum do sistema, junto aos usuários e especialistas do domínio. Mostram apenas o que o sistema faz, e não como. Descrevem o que acontece dentro do sistema. Capturam o comportamento pretendido para um sistema, sem a necessidade de especificar como esse comportamento será implementado. Ajudam muito na comunicação entre clientes e desenvolvedores.

Caso de Uso Cada caso de uso descreve uma funcionalidade requerida do sistema. Um caso de uso é uma descrição de um conjunto de seqüência de ações, incluindo variações, que um sistema executa a partir da interação de coisas externas ao sistema. Casos de uso podem incluir seqüências alternativas, ou sequências excepcionais (de erro) Cada chamado 'caso de uso descreve um cenário de possivel interação com um utilizador ou um outro sistema. Devem ser o mais claros possivel para que todos os eventuais leitores de diferentes campos e backgrounds possam entendê-los de igual modo. Devendo-se assim evitar termos técnicos ou obscuros que possam possivelmente dificultar a compreensão inequivoca da funcionalidade descrita. Cada caso de uso deve descrever somente uma funcionalidade ou objectivo do sistema. É então comum, para sistemas minimamente complexos, serem necessários bastantes casos de uso para uma correcta e completamente descrição de todas as funcionalidades requeridas pelo sistema.

Estudo de Caso Uma universidade X deseja informatizar a sua biblioteca. Em conversas com o usuário, as seguintes características foram levantadas: Alunos e professores podem ter acesso ao acervo da biblioteca Usuários devem ser cadastrados antes que possam ter acesso ao acervo

Estudo de Caso O acervo da biblioteca é constituído por títulos e periódicos Apenas títulos podem ser emprestados aos usuários, sendo os periódicos mantidos apenas para consulta O atraso na devolução de títulos implica na cobrança de multa sobre cada dia de atraso O usuário pode também reservar títulos emprestados

Estudo de Caso Documentos para o acervo da biblioteca são adquiridos através de compra ou de doação Professores podem solicitar a compra de novos títulos ou periódicos para o acervo Periodicamente, auditorias são realizadas para que o extravio de títulos possa ser averiguado.

Casos de Uso Notação Nome do caso de uso

Exemplo Casos de Uso Realizar reserva Cadastrar cliente Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua atividade inequivocamente, para tal são usualmente utilizadas as formas verbais ativas.

Atores Um caso de uso envolve a interação de atores com o sistema. Um ator é uma entidade externa ao sistema que, de alguma maneira, interage com ele. Um ator, tipicamente, estimula o sistema com eventos de entrada ou recebe algo dele. um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quando interagem com esses casos de uso. Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o sistema. Qualquer coisa que possui interface com o sistema em desenvolvimento; São sempre externos ao sistema

Atores Atores não são, necessariamente, pessoas. Atores podem ser outros sistemas ou hardware externo que interage com o sistema.

Atores Notação Nome do ator

Atores Exemplo Aluno

Atores Exemplo generalização Usuário Professor Aluno

Atores Atores podem ser conectados a casos de uso apenas por associação (uma linha que une o ator ao caso de uso). Uma associação entre um ator e um caso de uso indica que o ator e o caso de uso comunicam-se, cada um, possivelmente, enviando e recendo mensagens.

Identificando Atores Para identificar atores, pergunte: Quem usa o sistema? Que outros sistemas usam este sistema? Quem obtém informação deste sistema? Quem fornece informação para o sistema? Alguma coisa acontece automaticamente neste sistema? Quem dá suporte e mantém o sistema? Onde o sistema será utilizado na empresa?

Identificando Casos de Uso Para identificar casos de uso, o seguinte método pode ser utilizado: Identifique os atores relacionados a um sistema Para cada ator, identifique os processos que eles iniciam ou dos quais eles participam.

Identificando Casos de Uso Para identificar casos de uso, pergunte: Para que o ator usará o sistema? O ator irá criar, armazenar, modificar, excluir ou consultar dados no sistema? O ator necessitará informar o sistema sobre eventos externos ou mudanças? O ator deverá ser informado sobre certas ocorrências no sistema?

Diagrama de Casos de Uso Um Diagrama de Casos de Uso exibe um conjunto de casos de uso para um sistema, os atores e a relação entre os atores e os casos de uso. A finalidade do diagrama é apresentar um tipo de diagrama de contexto, através do qual pode-se, rapidamente, compreender quais são os atores do sistema e as maneiras principais segundo eles o utilizam. Servem para facilitar o entendimento de um sistema mostrando a sua “visão externa”. A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o ator não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade. Devendo as interações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de interação simplifica a descrição dos requisitos evita falsas suposições sobre como a funcionalidade será implementada no sistema. O Diagrama de Casos de Uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.

Diagrama de Casos de Uso Registrar devolução Consultar acervo Cadastrar documento Usuário Realizar Reserva Realizar auditoria Bibliotecário Solicitar Compra de Documentos Cadastrar usuário Aluno Professor Emprestar título

Diagrama de Casos de Uso A seta usada nas associações indica a direção do início da comunicação entre os elementos do diagrama. Consultar acervo Usuário Bibliotecário Se a seta sai do ator para o caso de uso, isso significa que foi o ator quem iniciou a interação. Em interações onde existe uma resposta ou retorno de valores, não é preciso indicar isso com outra seta em sentido contrário. Associações ondea navegabilidade (sentido da seta) não está definida, indicam interações em ambos os sentidos.

Um engano com Casos de Uso Um engano comum com casos de uso é representar como casos de uso passos individuais, operações ou transações. Um caso de uso é uma descrição completa de um processo relativamente grande, que inclui, geralmente, muitos passos ou transações.

Um engano com Casos de Uso Exemplo Calcular multa Representação incorreta de um caso de uso

Categorizando Casos de Uso Os casos de uso devem ser categorizados, de acordo com sua importância: Casos de uso essenciais: representam processos comuns principais. Ex: Realizar empréstimo Casos de uso desejáveis: representam processos menos importantes ou raros. Ex: Realizar auditoria, Solicitar compra de documentos Casos de uso opcionais: representam processos que podem ou não ser considerados

Estrutura de um Caso de Uso Cabeçalho Nome Atores Descrição breve Tipo Fluxo de eventos normal Fluxo de eventos alternativos Requisitos não funcionais

Cabeçalho de um Caso de Uso Cada descrição de caso de uso deve possuir um cabeçalho, no seguinte formato: Caso de uso Nome do caso de uso Atores Lista de atores Visão geral Descrição breve Tipo (essencial, desejável, opcional)

Descrição breve de um Caso de Uso A descrição breve deve conter o objetivo do caso de uso. Exemplos: Emprestar título Possibilita o empréstimo de títulos solicitados pelo usuário. Cadastrar acervo Provê facilidades para criar, modificar e apagar informações de títulos e periódicos que fazem parte do acervo da biblioteca.

Corpo de um Caso de Uso O corpo do caso de uso (fluxo de eventos) deve conter a descrição detalhada dos eventos trocados entre os atores e o sistema. As duas partes principais do fluxo de eventos são: fluxo de eventos básico (normal) e fluxo de eventos excepcionais ou alternativos.

Corpo de um Caso de Uso O fluxo de eventos básico descreve o que acontece normalmente quando o caso de uso é executado. O fluxo de eventos alternativos descreve o comportamento de caráter opcional ou excepcional em relação ao comportamento normal.

Corpo de um Caso de Uso É importante descrever: como e quando o caso de uso inicia e finaliza quando o caso de uso interage com os atores quais os objetos trocados na interação os fluxos de eventos alternativos ou excepcionais

Descrevendo Casos de Uso Exemplo - Caso de uso Realizar empréstimo Caso de uso Realizar empréstimo Atores Usuário (iniciador), Bibliotecário Visão geral Possibilita o empréstimo de títulos solicitados pelo cliente Tipo essencial

Descrevendo Casos de Uso Exemplo - Caso de uso Realizar empréstimo Fluxo de eventos básico: 1. O caso de uso inicia quando o usuário deseja realizar o empréstimo de um título. 2. O bibliotecário digita o código do título e a matrícula do usuário. 3. O sistema verifica se o usuário está cadastrado. 4. O sistema verifica se não há reservas para o título. 5. O sistema realiza o empréstimo, guardando a data e a hora em que a operação foi realizada e o caso de uso finaliza.

Descrevendo Casos de Uso Continuação do exemplo Fluxo de eventos excepcional: No passo 3, se o usuário ainda não tiver sido cadastrado na biblioteca, o sistema não permite que o empréstimo seja realizado. Requisitos não funcionais: 1. A operação de empréstimo deve retornar o resultado da efetivação do empréstimo em, no máximo, 30 segundos.

Descrevendo Casos de Uso Os casos de uso podem ser descritos com variáveis graus de detalhe, bem como de comprometimentos a decisões de projeto, ou seja, o mesmo caso de uso pode ser escrito em diferentes formatos, com diferentes níveis de detalhes.

Relacionamentos entre casos de uso Há dois tipos possíveis de relacionamentos entre casos de uso: inclui e estende.

Relacionamentos entre casos de uso O relacionamento inclui deve ser utilizado quando um conjunto de passos do fluxo de eventos se repete para vários casos de uso. O comportamento comum a vários casos de uso é colocado em um caso de uso à parte, chamado caso de uso de inclusão. O caso de uso de inclusão é, em geral, abstrato, ou seja, não pode ser instanciado.

Relacionamentos entre casos de uso Exemplo: Registrar devolução Emprestar título Validar usuário Bibliotecário <<include>>

Relacionamentos entre casos de uso Exemplo - Caso de uso Realizar Empréstimo Fluxo de eventos básico: 1. O caso de uso inicia quando o usuário deseja realizar o empréstimo de um título. 2. O bibliotecário digita o código do título e a matrícula do usuário. 3. Inclui Validar Usuário. 4. O sistema verifica se não há reservas para o título. 5. O sistema realiza o empréstimo, guardando a data e a hora em que a operação foi realizada e o caso de uso finaliza.

Relacionamentos entre casos de uso O relacionamento estende representa comportamento que é opcional, ou seja, que só é executado sob determinadas condições. O uso do relacionamento estende permite separar comportamento obrigatório do comportamento opcional. Em certos casos, o caso de uso de extensão pode ter um comportamento independente do caso de uso base.

Relacionamentos entre casos de uso Exemplo: Emprestar título Cadastrar usuário Bibliotecário <<extend>>

Relacionamentos entre casos de uso Exemplo - Caso de uso Realizar empréstimo Fluxo de eventos básico: 1. O caso de uso inicia quando o usuário deseja realizar o empréstimo de um título. 2. O bibliotecário digita o código do título e a matrícula do usuário. 3. O sistema verifica se o usuário está cadastrado. 4. O sistema verifica se não há reservas para o título. 5. O sistema realiza o empréstimo, guardando a data e a hora em que a operação foi realizada e o caso de uso finaliza.

Relacionamentos entre casos de uso Continuação do exemplo Fluxo de eventos excepcional: No passo 3, se o cliente ainda não tiver sido cadastrado na biblioteca, estende Cadastrar Usuário.

Organização dos casos de uso em pacotes Quando o caso de uso se torna muito extenso, recomenda-se particioná-lo em pacotes. Um pacote é um agrupamento de elementos que têm uma forte coesão. Recomenda-se manter em um mesmo pacote os casos de uso que dizem respeito ao mesmo assunto e que têm relacionamentos (inclui e estende). Algumas maneiras de agrupar casos de uso em pacotes são: casos de uso que interagem com o mesmo ator; casos de uso com funcionalidades correlatas; casos de uso envolvidos com um deterninado processo;

Sistema de Controle Bibliotecário Organização dos casos de uso em pacotes Sistema de Controle Bibliotecário Aquisição de Documentos Catalogação Para facilitar a visão geral do sistema é usual agregar casos de uso similares em pacotes e criar diagramas que ilustrem essa agregação e qual a interação com outros sistemas ou utilizadores do sistema. Controle de Circulação

Limitações Os casos de uso são excelentes para capturar os requisitos funcionais de um sistema, entretanto, tem as seguintes limitações: Não facilitam muito o levantamento dos requisitos não funcionais do sistema. A sua correta interpretação requer sempre um processo de aprendizagem e ambientação, por parte tanto dos utilizadores quanto dos programadores.

Um exemplo do mundo real Empresa: TRE/PE Sistema: Sistema de Monitoramento do Plano de Ação Objetivo: facilitar o gerenciamento e o acompanhamento das informações relativas ao Plano de Ações das Unidades, observando as vinculações orçamentárias e os prazos programados.

Diagrama de Classes

Diagramas UML para Design de BDs Descrição Casos de Uso É um modelo das funcionalidades do sistema e o ambiente que suporta os processos do negócio. Este modelo serve como um contrato entre o cliente e os desenvolvedores. Interação Os Diagramas de Interação correspondem aos Diagramas de Seqüência e Colaboração, que mostram a interação dos objetos com o sistema. Eles podem ser usados para entender consultas que irão afetar o banco de dados e também ajudam a construir indíces baseados na informação modelada. Atividade Mostram o fluxo de um processo. Eles podem ser usados para mostrar alguma visão de alto nível do negócio e como ele funciona. Gráfico de Estados Captura o comportamento dinâmico do sistema ou objetos dentro do sistema. Classe São modelos lógicos que mostram a estrutura básica do sistema. Banco de Dados Descreve a estrutura do banco de dados, incluindo tabelas, colunas, constraints e etc. Componente Mostra o armazenamento físico do banco de dados, incluindo o SGBD, tablespaces e partições. Eles também podem incluir aplicações e as interfaces usadas por elas para acessar o banco de dados. Deployment Mostra a configuração do hardware que está sendo usado pelo banco de dados e aplicações.

Diagrama de Classes Mapeamento entre Modelos Utilização de estereótipos para identificar os elementos Apenas classes e atributos persistentes serão mapeados Ex.: Um atributo chamado valor_do_pedido, que é um campo calculado (somatório do valor de todos os produtos de um pedido) não seria necessário ser armazenado no banco de dados UML Banco de Dados Estereótipo Classe Tabela <<Table>> Atributo Coluna <<Column>>, <<PK>>, <<FK>> Tipos Tipos de Dados - Associações Relacionamentos <<Identifying>>, <<Non-identifying>>

Diagramas de Classes (2) Mapeamento de Classes para Tabelas 1:1, 1:N e N:N Associações N:N devem ser quebradas em relacionamentos 1:N, através de uma tabela de associação Mapeamento entre subtipos de classes Uma tabela por classe Uma tabela por classe concreta Uma tabela por hierarquia

Diagrama de Classes (3) Uma Tabela por Classe <<Tabela>> Cliente PK codigo : INTEGER nome : VARCHAR(30) telefone : VARCHAR(15) tipo: CHAR(1) <<Tabela>> ClienteFisico PK/FK codigo : INTEGER cpf : VARCHAR(10) data_nasc : DATE <<Tabela>> ClienteJurídico PK/FK codigo : INTEGER cnpj : VARCHAR(15)

Diagrama de Classes (4) Uma Tabela por Classe Concreta ClienteFísico PK codigo : INTEGER nome : VARCHAR(30) telefone : VARCHAR(15) cpf : VARCHAR(10) data_nasc : DATE <<Tabela>> ClienteJurídico PK codigo : INTEGER nome : VARCHAR(30) telefone : VARCHAR(15) cnpj : VARCHAR(15)

<<Tabela>> Diagrama de Classes (5) Uma Tabela por Hierarquia <<Tabela>> Cliente PK codigo : INTEGER nome : VARCHAR(30) telefone : VARCHAR(15) cpf : VARCHAR(10) cnpj : VARCHAR(15) data_nasc : DATE tipo: CHAR(1)

Tipo de Dados Padrão ANSI SQL 92 Diagrama de Classes (6) Tipos de Atributos Tipo Genérico Tipo de Dados Padrão ANSI SQL 92 Descrição Boolean Bit Verdadeiro (T) ou Falso (F) Currency Decimal Números reais com até 15 dígitos do lado esquerdo do ponto decimal e 4 dígitos do lado direito Date Data e Hora Double Double Precision Números reais com 15-16 dígitos de precisão Integer Números inteiros acimda de 4 dígitos de precisão Long Números inteiros acima de 10 dígitos de precisão Single Números reais acima de 7 dígitos de precisão String Varchar / Char Ilimitado número de caracteres

Diagrama de Classes (7) Elementos

Diagrama de Classes (8) Demonstração de um Exemplo utilizando o JUDE

Diagrama de Classes (9) Demonstração de um Exemplo utilizando o JUDE

Referências The Unified Modelling Language User Guide (Grady Booch) The Unified Modelling Language Reference Manual (James Rumbaugh) The Unified Software Development Process (Ivar Jacobson) UML Distilled (Martin Fowler) http://pt.wikipedia.org/wiki/UML http://pt.wikipedia.org/wiki/Casos_de_Uso Database Design for Smarties (Robert J. Muller) Apostila da Qualiti Software Processes

Referências Naiburg, E., Maksumchuk, R. UML for Database Design, Addsison Wesley, 2001 Guedes, G. UML – Uma Abordagem Prática, Novatec, 2003

Dúvidas?

IN1008 – Projeto Conceitual de BD Diagramas UML para Modelagem de Dados Por: Clarissa César Borba ccb@cin.ufpe.br Fabrício Cabral fbc@cin.ufpe.br