Universidade de Passo Fundo Instituto de Ciências Exatas e Geociências Pós s em Desenvolvimento de Software (Unified Modeling Language) Prof. Cristiano Roberto Cervi O problema O grande problema do desenvolvimento de sistemas utilizando a orientação a objetos nas Fases de análise de requisitos Análise de sistemas Design Não existe uma notação padronizada e realmente eficaz que abranja qualquer tipo de aplicação que se deseje 2 O problema Cada simbologia existente possui seus próprios conceitos, gráficos e terminologias, resultando numa grande confusão Especialmente para aqueles que querem utilizar a orientação a objetos não só sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajudá-los a construir e manter sistemas cada vez mais eficazes Modelagem Por que fazer a modelagem? Construímos modelos para compreender melhor o sistema que estamos desenvolvendo O que é um modelo? Um modelo é uma simplificação da realidade São esquemas gráficos que representam o sistema 3 4 Modelagem Como fazer a modelagem? A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida Cada modelo poderá ser expresso em diferentes níveis de precisão Modelagem Como fazer a modelagem? Os melhores modelos estão relacionados à realidade Nenhum modelo único é suficiente Deve-se usar um conjunto de modelos independentes 5 6 1
Modelando com a A é o sucessor de um conjunto de métodos de análise e projeto orientados a objetos A é um modelo de linguagem, não um método A é uma linguagem-padrão para a elaboração da estrutura de projetos de software Modelando com a Um método pressupõe um modelo de linguagem e um processo O modelo de linguagem é a notação que o método usa para descrever o projeto O processo são os passos que devem ser seguidos para se construir o projeto O modelo de linguagem corresponde ao ponto principal da comunicação Se uma pessoa quer conversar sobre o projeto, com outra pessoa, é através do modelo de linguagem que elas se entendem Nessa hora, o processo não é utilizado 7 8 Modelando com a A define uma notação e um meta-modelo A notação são todos os elementos de representação gráfica vistos no modelo (retângulos, setas, o texto, etc.) É a sintaxe do modelo de linguagem Um meta-modelo é um diagrama que define de maneira mais rigorosa a notação Modelando com a A pode ser empregada para Visualização Especificação Construção Documentação de artefatos Que façam uso de sistemas complexos de software 9 é uma linguagem de modelagem e não uma metodologia 10 História A teve seu início na década de 90 quando três metodologias foram unificadas, OMT, Booch e OOSE OMT (Object Modeling Technique) James Rumbaugh Booch Grady Booch OOSE (Object-Oriented Software Engineering) Ivar Jacobson História OMT Técnica de Modelagem de Objetos É um método desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava O método é especialmente voltado para o teste dos modelos, baseado nas especificações da análise de requisitos do sistema 11 12 2
História Booch Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas O Método de Booch trazia uma simbologia complexa de ser desenhada a mão História OOSE/Objectory Os métodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson O método OOSE é a visão de Jacobson de um método orientado a objetos O Objectory é usado para a construção de sistemas tão diversos quanto eles forem Ambos os métodos são baseados na utilização de use cases (casos de uso), que definem os requisitos iniciais do sistema, vistos por um ator externo 13 14 História Cada um destes métodos possui Sua própria notação Seus próprios símbolos para representar modelos orientado a objetos Processos Que atividades são desenvolvidas em diferentes partes do desenvolvimento Ferramentas As ferramentas CASE (Computer Aided Software Engineering) que suportam cada uma destas notações e processos 15 História Diante desta diversidade de conceitos, os três amigos decidiram criar uma linguagem de modelagem unificada Grady Booch Ivar Jacobson James Rumbaugh Disponibilizaram inúmeras versões preliminares da para a comunidade de desenvolvedores As respostas incrementaram muitas novas idéias que melhoraram ainda mais a linguagem 16 História (Evolução) Feedback Público Aprovado em out/97 Submissão à OMG set/97 Submissão à OMG jan/97 96 95 De 2000 a 2003 foi produzida a 2.0 e a OMG a adotou como padrão no início de 2005 Introdução A é usada no desenvolvimento dos mais diversos tipos de sistemas Abrange sempre qualquer característica de um sistema em um de seus diagramas É aplicada em diferentes fases do desenvolvimento de um sistema Desde a especificação da análise de requisitos até a finalização com a fase de testes 17 18 3
Introdução O objetivo da é descrever qualquer tipo de sistema Em termos de diagramas orientado a objetos Naturalmente, o uso mais comum é para criar modelos de sistemas de software Mas a também é usada para representar sistemas mecânicos sem nenhum software Utilização Sistemas de Informação Sistemas Técnicos Sistemas de Tempo Real Integrados Sistemas Distribuídos 19 20 Utilização A é Uma linguagem Uma notação Não tem uma regra para sua utilização Permite que o desenvolvedor/analista/gerente use os diagramas como bem entender, dependendo do sistema que pretende desenvolver Diagramas O modo para descrever os vários aspectos de modelagem para a é através da notação definida pelos seus vários tipos de diagramas Um diagrama é Uma apresentação gráfica de uma coleção de elementos de modelo Frequentemente mostrado como um gráfico conectado de arcos (relacionamentos) e vértices (outros elementos do modelo) 21 22 Diagramas até a 1.4 1.Diagrama de casos de uso 2.Diagrama de atividades 3.Diagrama de classes 4.Diagrama de sequência 5.Diagrama de colaboração 6.Diagrama de estados 7.Diagrama de objetos 8.Diagrama de componentes 9.Diagrama de implantação 23 Diagramas da 2.0 1.Diagrama de casos de uso 2.Diagrama de atividades 3.Diagrama de classes 4.Diagrama de sequência 5.Diagrama de estados 6.Diagrama de comunicação (antigo Diagrama de colaboração) 7.Diagrama de objetos 8.Diagrama de componentes 9.Diagrama de implantação 10.Diagrama de pacotes 11.Diagrama de estruturas compostas 12.Diagrama de temporização 13.Diagrama de visão geral de interação 24 4
Diagramas Para dar início a construção de qualquer diagrama da, primeiro deve-se conhecer a sua notação ou seja A forma de representação Sua semântica Diagrama de casos de uso É o diagrama mais importante da construção de software orientado a objetos Os casos de uso são, talvez, o único instrumento que acompanha um software do seu início até a sua conclusão O limite de um caso de uso é uma decisão pessoal e só com experiência de sua utilização é que se aprende a distinguir um caso de uso de outro 25 26 Diagrama de casos de uso Descreve o que um sistema deve fazer ou o que um sistema já está fazendo É construído através de um processo iterativo durante discussões entre os desenvolvedores do sistema e os usuários As discussões conduzem a uma especificação de requisitos sobre os quais, o sistema deve ser projetado e desenvolvido Diagrama de casos de uso Na modelagem de casos de uso, o sistema é visto como uma caixa-preta que fornece uma funcionalidade através de atividades O modo como o sistema implementa os casos de uso, não é relevante nesse ponto do trabalho, tornando o caso de uso uma técnica mais para a análise do que para o projeto Uma das grandes vantagens é a documentação da análise dos requisitos do sistema 27 28 Diagrama de casos de uso Um caso de uso deve ser muito bem detalhado, mas sem ser longo demais para ser lido A objetividade não deve sacrificar a compreensão e a composição do detalhe Em análise OO, quando utiliza-se o conceito de abstração, divide-se um problema em partes e essas partes são os casos de uso Quando se aborda o detalhamento dos casos de uso tem-se a análise de suas tarefas, atividades ou aquilo que ele irá desempenhar no âmbito do sistema Diagrama de casos de uso A extração de um caso de uso pode ser feita ou por observação ou por entrevista A observação somente é possível em casos onde a atividade é repetitiva, realizadas por um operador ou por uma máquina A entrevista somente é possível entre humanos e é a forma mais utilizada na extração dos casos de uso de um sistema 29 30 5
Diagrama de casos de uso A aprovação de um caso de uso deve ser feita pelo cliente que está contratando o serviço Antes de mostrar os casos de uso ao cliente, mostre para um colega/gerente de projetos Se ele compreender o que foi descrito sem questionamento, o trabalho está bom Se ele questionar alguma coisa, fique esperto, veja o que pode ter saído errado e submeta a uma nova apreciação Lembre que se fizer isso estará ganhando tempo ao invés de perder Diagrama de casos de uso (princípios) Decide e descreve os requisitos funcionais do sistema, resultando em um acordo entre o usuário e o desenvolvedor do sistema Fornece uma descrição clara e consistente da funcionalidade do sistema O que o sistema faz Serve de orientação para as próximas fases Demonstra a interação do sistema com agentes externos 31 32 Diagrama de casos de uso (composição) É composto de quatro elementos básicos Ator Caso de uso Interação Sistema Diagrama de casos de uso (visualização) Abrir conta corrente Cadastrar cliente Abrir conta poupança Fechar conta corrente Fechar conta poupança Cadastrar agência Remover cliente 33 Remover agência 34 Diagrama de casos de uso (sistema) Significa um sistema de software, um negócio ou uma máquina Como parte da modelagem, os limites do sistema desenvolvido são definidos A fase de definição dos limites e responsabilidades de um sistema nem sempre é um processo fácil, pois nem sempre é óbvio quais tarefas são melhor automatizadas pelo sistema e quais tarefas são melhor tratadas manualmente ou por outros sistemas Diagrama de casos de uso (atores) Um ator é alguém ou algo que interage com o sistema É quem ou o quê usa o sistema A interação com o sistema significa que o ator envia ou recebe mensagens para/do sistema, ou troca informações com o sistema Um ator pode ser um departamento, um profissional, uma máquina, etc. 35 36 6
Diagrama de casos de uso (atores) O ator se comunica com o sistema pelo envio e recebimento de mensagens, de forma similar aos métodos usados na programação orientada a objetos Para identificar atores, estabelece-se quais objetos estão interessados no uso e interação com o sistema A partir desta lista, é possível levantar a posição do ator em relação ao sistema tentando identificar os requisitos do ator e de quais casos de uso o ator necessita Diagrama de casos de uso (atores) Quando observa-se os usuários de um sistema, não deve-se considerar somente os indivíduos que estão sentados na frente do computador O usuário do sistema pode ser qualquer pessoa ou coisa que interage direta ou indiretamente com o sistema e usa os serviços disponíveis pelo sistema 37 38 Diagrama de casos de uso (como encontrar atores) Algumas perguntas podem ser feitas para auxiliar na identificação dos atores quem usa as funções principais do sistema? quem necessita suporte do sistema para realizar suas tarefas diariamente? quem se responsabiliza pela manutenção, administração e conservação do funcionamento do sistema? quais são os dispositivos de hardware necessários? quem ou o quê se interessa pelos resultados produzidos pelo sistema? Diagrama de casos de uso Representa uma funcionalidade completa como percebida por um ator É definido como um conjunto de seqüências de ações de um sistema que rende um resultado observável por um ator 39 40 Diagrama de casos de uso (como encontrar) Para cada ator identificado se faz as seguintes perguntas quais funções o ator requisita do sistema? e o quê o ator necessita fazer? o ator necessita ler, criar, destruir, modificar ou armazenar algum tipo de informação no sistema? o ator deve ser notificado sobre eventos realizados pelo sistema ou o ator necessita notificar ao sistema quando algo ocorre? pode o trabalho do ator ser simplificado ou ser feito com melhor eficiência através de novas funções? o quê o sistema necessita de entrada e de saída? Diagrama de casos de uso (relacionamento) Extensão Inclusão Generalização 41 42 7
Diagrama de casos de uso (relacionamento) Extensão Diagrama de casos de uso (relacionamento) Inclusão Atendente Cadastrar venda << Extend >> Emitir nota Atendente Cadastrar venda Cadastrar serviço << Include >> << Include >> Emitir Nota O desenho informa que a emissão da nota pode ser chamada diretamente do cadastro da venda, mas esta é uma ação que pode ocorrer ou não O caso de uso que estende tem uma relação de dependência com o caso de uso estendido (seta tracejada), ou seja, o Emitir nota só pode ser executado se Cadastrar venda for executado antes 43 Utilizado para demonstrar que um caso de uso pode ser utilizado por vários outros casos de uso, quando este representa uma atividade comum a mais casos de uso Apresenta uma relação de dependência, ou seja, se Cadastrar Venda e Cadastrar Serviço forem executados, Realizar Pagamento obrigatoriamente será executado O caso de uso Realizar pagamento pode ser chamado por Cadastrar venda ou por Cadastrar serviço 44 Diagrama de casos de uso (relacionamento) Generalização Diagrama de casos de uso (visualização) <<extend>> Atendente Receber pagamento Atendente Realizar locação <<include>> Pagar locação Receber Pagamento em dinheiro Receber Pagamento em cheque Receber Pagamento em cartão Cadastrar clientes Cliente Avisar cliente de filme já assistido <<extend>> Receber pagamento em dinheiro, Receber pagamento em cheque e Receber pagamento em cartão são especializações do caso de uso Receber Pagamento 45 Cadastrar autorizados 46 Diagrama de casos de uso Possibilidades de relacionamentos Caso de uso e caso de uso Ator e ator Caso de uso e ator Comunicação X Extensão X Inclusão X Generalização X X Diagrama de atividades É utilizado para criar boas descrições de casos de uso É a especificação de um caso de uso Se equivalente a um algoritmo Sequência de passos para demonstrar alguma coisa Dificilmente haverá um diagrama de atividades para todos os casos de uso de um sistema 47 48 8
Diagrama de atividades Utiliza-se para os casos de uso em cenários mais complexos Onde o negócio a ser modelado é de difícil compreensão Um caso de uso interpretado ou escrito de maneira equivocada gerará um diagrama de atividades igualmente equivocado Ao escrever o diagrama de atividades pode ser necessário retornar ao caso de uso para reescrevê-lo Diagrama de atividades (composição) Representa uma atividade Representa passagens de uma atividade para outra Representa uma decisão Representa o ponto de entrada de um processo Representa o ponto de saída de um processo Sincronização com Fork Uma atividade é dividida em mais de uma 49 Sincronização com Join Mais de uma atividade foram unidas em uma 50 Diagrama de atividades (visualização 1) Inicio Diagrama de atividades (visualização 2) Cliente entrega o filme ao atendente [Se já viu e não quer locar novamente] O cliente se dirije ao balcao e entrega o filme ao atendente Atendente verifica se o cliente já locou aquele filme [Se não viu] [Se já viu] [Se já viu e quer locar novamente] Atendente registra filme como devolvido Atendente verifica se o filme está pago Atendente verifica pendência financeira [Se há pendência] [Se não há pendência] Registrar mídia como locada [ Se sim ] Finaliza [Se acertar pendência] Acertar pendência [ Se não ] Registrar locação como paga [Se pagar] [Se não pagar] Regis trar loc ação como não paga Pagar locação 51 [Se não acertar pendência] 52 Finaliza locação 2 Diagrama de atividades (visualização 3) Diagrama de Classes Classe (notação) Calcular valor total [se valor >= 100] Solicitar aprovação [se valor < 100] [ se aprovado] Efetuar compra Pessoa nome data_nascimento endereco get_data_nasc ( ) set_data_nasc ( ) informar_idade ( ) Nome Atributos Métodos [ se não aprovado] 53 Essa notação não foi definida pela 54 9
Classe É similar a uma tabela no modelo relacional somente até o ponto onde representa uma coleção de dados armazenados com um tema em comum Diagrama de classes É uma estrutura lógica estática, mostrando uma coleção de elementos declarativos de modelo como as classes seus tipos seus atributos seus métodos seus relacionamentos 55 56 Diagrama de classes Como localizar classes? Na funcionalidade especificada através dos casos de uso Os substantivos indicam candidatos à classes e objetos Os adjetivos desses substantivos indicam os atributos Os verbos representando as ações desses substantivos indicam os métodos Diagrama de classes (visualização) Pessoa Nome : String Endereco : String Telefone : String CPF : String cadastrarpessoa() atualizarpessoa() excluirpessoa() Venda Numero : Integer Data : Date ValorTotal : Currency ItensVenda Quantidade : Integer Produto Descricao : String Estoque : Integer Preco : Currency Professor Titulacao : String Estudante Naturalidade : String Funcionario Cargo : String 57 calcularsalario() calcularsalario() 58 Relacionamentos entre classes As classes não coexistem isoladamente em uma aplicação Os relacionamentos existentes entre classes podem ser Herança Generalização/Especialização Agregação Agregação por Composição Associação Herança Define que uma classe é uma especialização de outra classe Exemplo As classes Pessoa, Estudante, Funcionário e Professor Estudante, Funcionário e Professor são um tipo de pessoa Pessoa (generalização) Estudante, Funcionário e Professor (especialização, particularização) Dica É um, É um tipo de 59 60 10
Herança (papéis das classes) Superclasse Representa a generalização Subclasse Representa a especialização/particularização Exemplo Relacionamento de herança entre as classes Pessoa e Estudante, Funcionário e Professor Pessoa: superclasse de Estudante, Funcionário e Professor Estudante, Funcionário e Professor: subclasse de Pessoa Herança (vantagens) Economia de descrição Facilidade de gerenciamento da estrutura Reutilização 61 62 Herança (exemplo) Pessoa matricula nome endereco informar_nome ( ) Superclasse Herança (significado) Atributos da superclasse são herdados pela subclasse Pessoa possui o atributo nome Em consequência, estudante, funcionário e professor também possuem o atributo nome Todos os atributos da superclasse são herdados pela subclasse Todos os métodos da superclasse são herdados pela subclasse Estudante Funcionario Professor Subclasses 63 64 Herança (características) A superclasse implementa atributos e métodos genéricos que servem para todas as subclasses e estas, implementam atributos e métodos específicos ao seu contexto Este tipo de relacionamento é um dos pontos chaves do paradigma de orientação a objetos, pois contempla a propriedade de reuso de software Herança (características) A generalização é um relacionamento entre classes e não entre objetos, ou seja Cada instanciação de um objeto da subclasse gera uma estrutura composta por atributos e métodos públicos da superclasse acrescidos dos atributos e métodos da subclasse 65 66 11
Herança Múltipla Quando uma subclasse herda atributos ou métodos de duas ou mais superclasses É um tipo de relacionamento que pode apresentar problemas se não for bem utilizado Colisão de nomes provindos de atributos da superclasse Colisão de métodos provindos das superclasses Java e Smalltalk não implementam Eifell e C++ implementam 67 Herança Múltipla (exemplo) Automóvel numportas dirhidraulica dirigir ( ) Subclasse e Superclasse Veículo marca modelo ano dirigir ( ) Anfíbio dirigir ( ) Barco tamanho tipomotor dirigir ( ) Superclasse Subclasse Subclasse e Superclasse 68 Herança Múltipla (como evitar) Em Java existem duas saídas para o problema da herança múltipla A primeira é aumentar o número de classes e isso é feito em 50% dos casos (MEDEIROS, 2004) A segunda é a utilização de Interfaces Interfaces Utilizada em Java para contornar a falta da herança múltipla Não é uma classe Não possui atributos É um arquivo que define valores constantes e operações que outra classe deve implementar 69 70 Interfaces Define somente as operações, sem os métodos Não podem ser instanciadas (não tem objetos) Só podem ser Public e Abstract Não podem ser Private e Protected Se não forem declaradas como Public e Abstract, serão automaticamente transformados desse maneira 71 Interfaces (exemplo) Superclasse Automóvel numportas dirhidraulica dirigir (int ( ) x) Subclasse/Superclasse Veículo marca modelo ano dirigir (int x) Anfíbio dirigir (int x) Barco tamanho tipomotor dirigir (int x) <<Interface>> Barco dirigir (double x) Subclasse Métodos com assinaturas diferentes 72 12
Agregação Relação que pode ocorrer entre duas classes Caracteriza uma relação todo-parte Exemplo Relação entre as classes Carro e Roda Um Carro possui rodas Agregação (papéis das classes) Classe todo ou agregada É a classe resultante da agregação Classe parte É a classe cujas instâncias formam a agregação Exemplo entre as classes Carro e Roda Classe Carro: todo ou agregada Classe Roda: parte 73 74 Agregação (exemplo) Carro Roda Agregação (significado) A classe todo existe, independentemente da classe parte (e vice-versa) Não existe uma ligação forte entre as duas classes Objetos da classe todo são independentes da classe parte O objeto parte pode estar em mais de 1 objeto todo Classe todo Classe parte 75 76 Agregação (como encontrar) Dica Consiste em, Contém, É parte de Perguntas é uma relação todo-parte? um objeto vive sem o outro? Em uma relação entre as classes X e Y X tem um ou mais Y? Y é parte de X? Agregação por Composição Ocorre quando tem-se uma situação semelhante à da agregação entre duas partes Ambas as classes vivem unidas, de forma dependente, ou seja, existe uma ligação forte entre as duas A parte pode compor apenas 1 todo em um determinado instante do tempo 77 78 13
Agregação por Composição O todo é responsável pela vida de suas partes (criação e destruição) A parte não tem vida independente do todo Os objetos da classe parte são dependentes, em termos de vida, da classe todo Os objetos da classe parte não podem continuar vivendo quando o todo é destruído Agregação por Composição (exemplo) Venda Parcela Classe todo Classe parte 79 80 Agregação por Composição (como encontrar) Dica Consiste em, Contém, É parte de Perguntas é uma relação todo-parte? um objeto vive sem o outro? Não tem sentido os objetos parte continuarem existindo sem o objeto todo Agregação x Composição (diferença) Agregação Os objetos parte podem estar em mais de 1 objeto todo Os objetos parte continuam existindo se o objeto todo não mais existir Composição Os objetos parte podem compor apenas 1 objeto todo em um determinado instante do tempo Os objetos parte só existem se o objeto todo existir 81 82 Agregação e Composição (exemplo 1) Agregação e Composição (exemplo 2) Venda Parcela Empresa Equipe de Projeto Itens da Venda Produto Empregado -A A venda possui parcelas e itens. Se excluir a venda, são excluídos também m seus itens e suas parcelas -Uma empresa é composta por empregados e equipes. Se excluir a empresa, o empregado egado e a equipe -Os itens da venda são formados por produtos, mas se excluir um item i o produto continua existindo 83 são excluídos juntos 84 -Uma equipe é formada por empregados. Se excluir uma equipe, os empregados continuam existindo 14
Associação É uma relacionamento entre classes que não pode ser caracterizado como herança, nem como agregação e nem como composição Não apresenta significado preciso Mais comum em aplicações voltadas para comércio e serviços Associação (exemplo) Cliente Cidade 85 86 Como saber qual relacionamento deve ser utilizado? Pense se existe herança Existem atributos ou métodos sendo aproveitados por outras classes? A subclasse é do tipo da superclasse? Sim: Isso é herança Não: Existe todo-parte? Sim: A parte vive sem o todo? Sim: Isso é agregação Não: Isso é uma composição Não: Isso é associação Diagrama de classes (multiplicidade) Define quantos objetos participam do relacionamento É o número de instâncias de uma classe relacionada a uma instância de outra classe 87 88 Diagrama de classes (multiplicidade) Possibilidades 0..1 0..* * 1..1 1 1..* 1..6 Zero ou um Zero ou muitos Muitos (mesmo que zero ou muitos) Um e somente um Um e somente um Um ou muitos Não especificada No mínimo 1 e no máximo 6 89 Diagrama de classes (navegabilidade) Define que a instância de uma classe pode navegar à instâncias de outras classes e vice-versa Uma seta é ligada entre duas classes para indicar o caminho de navegação entre elas Representa que o objeto de uma classe contém um apontador para o objeto da outra classe Sentido da navegação: de Pessoa para Cidade Uma Pessoa busca a cidade A Pessoa tem a responsabilidade de informar a qual cidade pertence 90 15
Diagrama de classes (navegabilidade) Possibilidades Diagrama de sequência Modela a seqüência de eventos e a interação de mensagens existentes em uma transação do sistema Uma interação é uma especificação comportamental que inclui uma sequência de trocas de mensagens entre um conjunto de objetos dentro de um contexto para realizar um propósito específico, tal como a realização de um caso de uso 91 92 Diagrama de sequência A partir de uma linha do tempo, o diagrama mostra a ativação de mensagens entre objetos Os objetos são desenhados como linhas verticais, as mensagens como linhas horizontais e a sequência de mensagem é lida de cima para baixo na página : Locacao Objeto Diagrama de sequência O objeto é desenhado como um retângulo ao topo de uma linha vertical tracejada, projetada para baixo Essa linha vertical é chamada de linha de vida do objeto e representa o ciclo de vida de um objeto durante uma interação Cada mensagem é representada por uma linha com seta dirigida horizontalmente entre as linhas de vida de dois objetos [Devolver filme] Mensagem 93 94 Diagrama de sequência (visualização) Diagrama de sequência (visualização) : Cliente : Atendente : Locacao : ItensLocacao : Usuário inserepedido( ) Pedido:Pedido Itens: Itens Pedido Produto: Produto insereitens( ) [Busca Locação] buscaproduto( ) verificaitem( ) [Devolver filme] 95 96 16
Diagrama de estados Diagrama de estados capturam os ciclos de vida de objetos Eles distinguem os estados que um objeto pode ter e quais os eventos (mensagem recebida, tempo, erros e condições verdadeiras) afetam esses estados ao mesmo tempo Um diagrama de estado existe para todas as classes que possuem, claramente, estados identificáveis e comportamentos complexos Cada classe possui, somente, um diagrama de estados Diagrama de estados Todos objetos tem um estado O estado é o resultado de atividades anteriores realizadas pelo objeto, e é tipicamente determinada por valores de seus atributos Uma classe pode possuir um atributo específico para indicar o estado (forma explícita), como pode o estado ser determinado por valores de atributos normais no objeto (forma implícita) 97 98 Diagrama de estados Exemplos de estados de objetos O pedido (objeto) é atendido (estado) O carro (objeto) está andando (estado) A máquina (objeto) está parada (estado) Diagrama de estados Um objeto muda de estado quando alguma coisa acontece, o que é chamado de evento Há duas dimensões de dinamicidade Interação: descreve o comportamento externo do objeto e como ele interage com outros objetos Por exemplo: enviando mensagens Mudança de estado interno: descreve como os objetos tem alteração de estados através de eventos internos 99 100 Diagrama de estados (representação) Diagramas de estado podem ter um ponto de início e vários pontos de encerramento Cada estado é representado, no diagrama, através de um retângulo com as bordas arredondadas Diagrama de estados (representação) Chegar no térreo No Térreo subir (andar) Chegar no andar Subindo V subir (andar) Indo para o térreo Descendo Chegar no andar Parado descer (andar) tempo de espera 101 102 17
Diagrama de estados (representação) Diagrama de estados (representação) Vazia Preparar(Erva/Bomba) Esvaziar Preparada Seca Pode quebar (descartar) Encher Pode quebar (descartar) Limpar Cheia Encher Tomar(Erva Boa) Tomar(Erva Lavada) Limpar Disponível (molhada/vazia) Erva Lavada Limpar 103 104 Diagrama de comunicação Diagramas de sequência e comunicação expressam informações semelhantes mas as apresentam de modo diferente As associações mostram os objetos atuais e como eles estão inter-relacionados Como o diagrama de seqüência, o diagrama de comunicação pode ser usado para ilustrar a execução de uma operação ou a execução de um caso de uso Diagrama de comunicação (visualização) : Computador : Servidor de Impressão 1: Imprimir (arq) [Impressora Ocupada] 1.2: Armazenar (arq) [Impressora Livre] 1.1: Imprimir (arq) : Fila : Impressora 105 106 Diagrama de objetos O diagrama de objetos é uma variação do diagrama de classes A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes Sua finalidade é descrever um conjunto de objetos existentes em algum momento da execução do software, como uma espécie de fotografia do tempo de execução Diagrama de objetos (visualização) Midia 1:Itens Locacao DataPrevDevol DataDevol Valor = 11/03/2009 = 11/03/2009 = 4,00 Locacao 1:Locacao Número Data ValorPago ValorTotal Pago = 125 = 10/03/2009 = 8,00 = 8,00 = S Midia 2:Itens Locacao DataPrevDevol DataDevol Valor = 11/03/2009 = 11/03/2009 = 4,00 107 108 18
Diagrama de componentes O diagrama de componente mostra a organização e as dependências existentes entre um conjunto de componentes É um dos dois tipos de diagramas disponíveis para modelagem de aspectos físicos de sistemas orientados a objetos São tipicamente os arquivos implementados no ambiente de desenvolvimento Diagrama de componentes Um componente é qualquer arquivo que contenha uma parte necessária ao software Se um software necessita de uma página HTML para ser executado ou de um arquivo.txt, estes arquivos são um componente Um componente não necessariamente é um arquivo executável, como um.exe 109 110 Diagrama de componentes É usado quando se deseja Mostrar o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução Descrever os componentes de software e suas dependências entre si Diagrama de componentes (visualização) Produtos Financeiro Aplicação Vendas Arquivo Inicialização 111 112 Diagrama de implantação É o diagrama com a visão mais física da Também chamado de Diagrama de Execução É um diagrama que mostra a configuração dos nós de processamento em tempo de execução e os componentes que neles existem É a última descrição física da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade Os nós significam objetos físicos que fazem parte do sistema, onde um ou mais módulos do sistema será executado, pode ser uma máquina cliente numa LAN, uma máquina servidora, uma impressora, um roteador etc Um nó é mostrado como uma figura que apresenta visão tridimensional como um cubo 113 Diagrama de implantação (visualização) Impressora 1 1 Cliente 1 Servidor 20 1 1 1 1 Leitor de cartao Scanner 114 19
Diagrama de pacotes Pacote é um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados Classes, componentes, implantação, casos de uso Pode representar um módulo do sistema, um subsistema, ou simplesmente uma pasta para organização das informações do modelo Este diagrama é utilizado normalmente em sistemas de maior complexidade Diagrama de pacotes (visualização) Pacote 1 Classe1 Classe2 Classe3 Classe4 Pacote 3 Pacote 2 Classe1 Classe2 Classe1 Classe2 115 116 Diagrama de estruturas compostas Representa a colaboração entre classes, objetos ou interfaces para realizar uma tarefa Diagrama de temporização (ou de Tempo) Utilizado para mostrar a interação entre objetos em determinado ponto do tempo É a fusão do diagrama de seqüência e de estado Apresenta o comportamento dos objetos e sua interação em uma escala de tempo O estado dos objetos em relação ao tempo e as mensagens que modificam esse estado Elaborar edital de concurso Divulgar edital e abrir inscrições Aplicar prova de seleção Avaliar provas Publicar resultados 117 {05/01..30/01} {01/02..31/03} {10/04 14:00.. 10/04 18:00} {12/04..30/04} {03/05} 118 Diagrama de visão geral de interação Mostra uma interação entre os diagramas de sequência e atividades Pesquisar Livros <<control>> controlador [Registrar Item] [Verdadeiro] [Livro não encontrado] [Adicionar livro] Itens: Carrinho 119 Vantagens & Desvantagens da Perdas Maior trabalho na modelagem Mais tempo gasto Ganhos Menos trabalho na construção A solução está pronta Menos tempo gasto Os problemas são encontrados em tempo hábil para sua solução As dúvidas são sanadas mais cedo e são levantadas na sua totalidade 120 20
Referências DEBONI, J. E. Z. Modelagem Orientada a Objetos com a. 1ª ed., Futura, 2003 FURLAN, J. D. Modelagem de Objetos Através da : The Unified Modeling Language. 1ª ed., Makron Books, 1998 GUEDES, GT. A. G. Uma Abordagem Prática. 2ª ed., Novatec, 2006 MEDEIROS, E. S. Desenvolvendo Software com 2.0: Definitivo. 1ª ed., Makron Books, 2004 PRESSMAN, R. Engenharia de Software. 6ª ed., McGraw-Hill, 2006 SILVA, R. P. Notas de aula da disciplina de Engenharia de Software. PPGCC/UFSC SILVA, R. P. 2 em Modelagem Orientada a Objetos. 1ª ed., Visual Books, 2007 SOMMERVILLE, I. Engenharia de Software. 8ª ed., Pearson Education, 2007 121 21