Profº Henrique Vila Nova Unibratec CTD – 2º Período

Apresentação em tema: "Profº Henrique Vila Nova Unibratec CTD – 2º Período"— Transcrição da apresentação:

1 Profº Henrique Vila Nova Unibratec CTD – 2º Período
ANP Diagramas UML Profº Henrique Vila Nova Unibratec CTD – 2º Período

2 Bibliografia Booch, G., Rumbaugh, J. e Jacobson, I., The Unified Modeling language User Guide, Addison-Wesley, 1999.

3 O que é UML ?  UML é uma linguagem de modelagem, não uma metodologia (ou método). A linguagem de modelagem é a notação (principalmente gráfica) utilizada em metodologias para expressar os projetos.  Metodologia é composta de: uma linguagem de modelagem e um processo, que descreve os passos a serem seguidos na elaboração de um sistema.  A linguagem de modelagem é a parte chave para a comunicação entre as partes envolvidas em um projeto. Os participantes devem ser capazes de entender a linguagem de modelagem e não o processo utilizado no desenvolvimento do projeto.

4 Histórico  Existiam várias metodologia de modelagem OO a disposição da comunidade de desenvolvedores OO. Entre elas : Método de Booch - do Booch, Técnica de Modelagem de Objetos (OMT) - do Rumbaugh, OOSE/Objectory - do Ivar Jacobson  Estes três resolveram criar uma linguagem de modelagem unificada.  A UML reúne as melhores idéias de cada uma das metodologias. UML passou por um processo de padronização pela OMG (Object Management Group) e é agora um padrão OMG.  Os “três amigos” também desenvolveram um processo unificado, que eles chamaram de RUP (Rational Unified Process). Não é necessário utilizar RUP para usar UML

5 Vantagens de UML 1) Independência de metodologia de desenvolvimento. 2) Padrão aberto e não proprietário. 3) Aplicável a todas as fases do ciclo de desenvolvimento. 4) Independência de linguagem de implementação. 5) Integração das melhores práticas de modelagem. 6) Suporte à conceitos de alto nível. 7) Usada para modelagem de Softwares OO mas também aplicadas em sistemas mecânicos e processos em geral da organização. 8) Facilidade para visualizar, especificar, construir e documentar sistemas grandes e complexos.

6 O que é possível fazer com a UML
1) Explicitar as fronteiras do sistema e suas principais funcionalidades (casos de uso e atores); 2) Ilustrar a realização dos casos de usos (diagramas de interação); 3) Representar as estruturas estáticas do sistema (diagramas de classes). 4) Modelar o comportamento dos objetos (diagramas de transição de estados); 5) Mostrar a arquitetura física da implementação (diagramas de componentes) 6) Capturar a topologia de hardware do sistema (diagrama de implantação)

7 A notação UML  Visões - Mostram diferentes aspectos do sistema. Cada visão mostrará aspectos particulares do sistema dando enfoque a ângulos e níveis de abstrações diferentes. Visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas.  Modelo de Elementos - Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos.  Mecanismos Gerais - Inclui comentários suplementares, informações, ou semântica sobre os elementos que compõem os modelos.  Diagramas - São os gráficos que descrevem o conteúdo em uma visão. UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema.

8 Visões  Um sistema é composto por diversos aspectos: Funcional – Sua estrutura estática e suas interações dinâmicas. Não Funcional – requisitos de tempo, confiabilidade, desenvolvimento, etc. Organizacionais - organização do trabalho, mapeamento dos módulos de código, etc.  Cada visão é descrita por um número de diagramas que contém informações que dão ênfase aos aspectos particulares do sistema.  Existem em alguns casos uma certa sobreposição entre os diagramas o que significa que um destes pode fazer parte de mais de uma visão.

9 Visão Diagrama Modelo de Elementos Visões
Os diagramas que compõem as visões contém os modelos de elementos do sistema. As visões que compõem um sistema são:  Visão “Use-Case" Visão Lógica Visão de Componentes Visão de Concorrência Visão de Organização Visão Diagrama Modelo de Elementos

10 Visão “Use-Case"  Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema.  Visão central, base do desenvolvimento das outras visões do sistema.  Essa visão é montada sobre: Diagramas de Use-Case e Diagramas de Atividade (eventualmente)

11 Visão Lógica  Em contraste com a visão “use-case”, a visão lógica observa e estuda o sistema internamente.  Descreve e especifica a estrutura estática do sistema (classes, objetos, e relacionamentos) e as colaborações dinâmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funções do sistema.  A estrutura estática : Diagramas de Classes e Objetos.  A modelagem dinâmica : Diagrama de Seqüência, Colaboração e Diagramas de Estado, Atividade.

12 Visão de Componentes  É uma descrição da implementação dos módulos e suas dependências.  É principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas.  Captura as informações do modelo físico de implementação, tais como arquivos de programas e sub-sistemas.

13 Visão de concorrência  Trata a divisão do sistema em processos e processadores.  Permite observar se o sistema possui execuções paralelas, e se existe gerenciamento de eventos assíncronos.  Uma vez dividido o sistema em linhas de execução de processos concorrentes (threads), esta visão de concorrência deverá mostrar como se dá a comunicação e a concorrência destas threads.  A visão de concorrência é suportada : Diagramas Dinâmicos, que são os diagramas de estado, seqüência, colaboração e atividade, Diagramas de Implementação, que são os diagramas de componente e execução.

14 Visão de Organização Mostra a organização física do sistema, os computadores, os periféricos e como eles se conectam entre si. Esta visão será executada pelos desenvolvedores, integradores e testadores, e será representada pelo diagrama de execução. Visão de Componentes Visão Lógica Visão de Use-Case Visão de Organização Visão de Concorrência

15 Modelos de Elementos  Os conceitos usados nos diagramas são chamados de modelos de elementos.  Um modelo de elemento é definido com sua semântica e possui representação gráfica que é mostrada nos diagramas da UML.  Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem que elementos podem ser mostrados em que tipos de diagramas.  Alguns exemplos de modelos de elementos são as classes, objetos, estados, pacotes e componentes. Os relacionamentos também são modelos de elementos.

16 Objeto Java : Estrutura : Maria : Turma Turma Pessoa Bono :
 Um objeto é uma entidade independente que armazena dados, encapsula serviços, troca mensagens com outros objetos e é modelado para executar as funções do sistema. Java : Estrutura : Maria : Turma Turma Pessoa Bono : Coca Cola : Luis : Produto Produto Pessoa

17 Classe  Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos (características) , operações, relacionamentos e semântica.  Todos os objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Nome da Classe Atributos da Classe Operações da Classe (Métodos)

18 Classe Atributos da Classe Operações da Classe (Métodos)  Atributos são propriedades de uma classe, que descreve um intervalo de valores que as instâncias podem apresentar. Uma classe pode ter qualquer número de atributos ou nenhum.  Operações correspondem aos processos que a classe pode realizar.

19 Estado de um Objeto  Todos os objetos possuem um estado resultante de atividades executadas pelo objeto. Este estado é determinado pelos valores dos atributos e ligações com outros objetos.  Um objeto muda de estado quando acontece algo e o fato de acontecer alguma coisa com o objeto é chamado de evento.  Através da análise da mudança de estados dos tipos de objetos de um sistema podemos prever os possíveis comportamentos dos objetos de acordo com os eventos que o mesmo possa sofrer.  Deve ser construído um Diagrama de Estados para cada classe cujos objetos apresentem algum comportamento dinâmico significante.

20 Estado de um Objeto  A modificação de estado causada por um evento é chamada transição.  Um estado tem : 1) Nome do Evento: mostra o nome do evento. Geralmente descreve o que o estado realiza. 2) Atividades: lista os eventos e ações. Dividido em três eventos : Entrar, Fazer e Sair. Exemplo de uma Conta :

21 Herança  Herança é a capacidade de uma classe definir o seu comportamento e sua estrutura aproveitando definições de outra classe, normalmente conhecida como classe base ou classe pai. Note que as subclasses herdam tudo o que a classe pai possui e acrescenta as suas características particulares.

22 Generalização Especialização Especialização e Generalização
 Através do mecanismo de herança é possível definir classes genéricas que agreguem um conjunto de definições comuns a um grande número de objetos (Generalização).  A partir destas especificações genéricas pode-se construir novas classes, mais específicas, que acrescentem novas características e comportamentos aos já existentes (Especialização). Generalização Especialização

23  A mensagem especifica O QUE deve ser feito.
Mensagens  São estímulos enviados aos objetos solicitando que alguma operação seja realizada por um dado objeto.  Nome da mensagem  Parâmetros  A mensagem especifica O QUE deve ser feito.  O comportamento de um objeto é dado pelo conjunto de mensagens que ele pode responder. Dr. Paulo : Dr. Luis : Daniel : Medico Medico Enfermeiro Diagrama de Seqüência aplicarInjecao( ) fazerCurativo( )

24 Interfaces  As interfaces são estritamente modelos de comportamento.  As interfaces não podem ser instanciadas pois não produzem objetos.  A relação existente entre as classes que implementam uma Interface e a Interface é uma relação do tipo “implementa os métodos de”. Não precisa ter significado semântico. Relação “implementa os métodos de”

25 Mecanismos Gerais - Ornamentos e Notas
 Especificação de multiplicidade de relacionamentos são ornamentos. Também é um ornamento separar tipo de uma instância da classe.  Nem tudo pode ser definido em uma linguagem de modelagem. Para permitir adicionar informações a um modelo, UML provê a capacidade de adicionar Notas.  Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informação

26 Diagramas  Em UML os modelos são desenvolvidos a partir de blocos tais como: classes, interfaces, colaborações, dependências, generalizações, associações, etc. Os diagramas são os meios utilizados para visualização de blocos de construção.  Os diagramas utilizados pela UML são compostos por nove tipos: Diagramas de Casos de Uso Diagramas de Classes Diagramas de Objetos Diagramas de Estado Diagramas de Atividade Diagramas de Seqüência Diagramas de Colaboração Diagramas de Componentes Diagramas de Execução

27 Diagramas  O modelo funcional Diagramas de Casos de Uso  O modelo estático Diagramas de Classes e Diagramas de Objetos  O modelo dinâmico Diagramas: de Estado, Sequencia, Colaboração Atividade  Arquitetura Física do Sistema Diagramas de Componentes e Diagrama de Execução

28 Diagramas de Casos de Uso
 Este tipo de diagrama ilustra um conjunto de casos de uso para um sistema, os atores e a relação entre os atores e os casos de usos.  O modelo de caso de uso consiste de atores e casos de uso. Sistema de Matricula Sistema Bancário ator Caso de uso ator Casos de uso

29 Atores  Atores representam usuários ou sistemas que interagem com o sistema modelado.  Um ator é um tipo (uma classe), não uma instância.  Um ator se comunica com o sistema através de mensagens, embora estas mensagens não estejam especificadas.  Um ator pode ser: primário: usa funções principais do sistema secundário: usa as funções que mantém o sistema (gerenciamento) ativo: inicia um caso de uso passivo: nunca inicia, mas apenas participa do caso de uso

30 Casos de Uso  Casos de Uso são cenários que o sistema percorre em resposta ao estímulo de um ator.  Casos de Uso são descritos por um texto contendo: Objetivo do Caso de Uso e Como o caso de Uso é iniciado O fluxo de mensagens entre atores e casos de uso Fluxo alternativo (execuções alternativas) Como o caso de uso termina e retorna um valor para o ator  Três tipos de relacionamentos entre os casos de uso: Inclusão: quando deseja evitar a repetição de ações Generalização: acrescenta comportamento a casos de usos base Extensão: acrescenta comportamento a casos de usos base, explicando os pontos de extensão

31 Diagramas de Casos de Uso
 Diagramas de Caso de Uso determinam as funções que deverão ser suportadas pelo sistema modelado.  Os diagramas dão uma visão geral mas as descrições dos casos de uso são tipicamente textuais.  Não existe preocupação com implementação de cada uma das funções pois o propósito é determinar somente a funcionalidade que será oferecida.  Ferramenta útil na captura de requisitos e no planejamento. Esta captura é uma das tarefas básicas necessárias para construção do sistema.

32 Diagramas de Casos de Uso
Sistema de Matricula <<extend>> Matricular Aluno Matricular Aluno Aluno Transferido Pontos de Extensão: Nota no teste FaculdadeAnterior Matricular Alunos Novos

33 Diagramas de Casos de Uso
Sistema Bancário

34 Diagramas de Classes  Descreve as classes do sistema, seus atributos, operações e relacionamentos. Representa a visão estática do sistema.  Um sistema pode possuir alguns diagramas de classes. Neste caso, uma classe pode participar em vários diagramas.  Existem três perspectivas para projetar diagramas. Conceitual : Representa os conceitos do mundo real. Sem preocupação quanto aos aspectos de implementação. Especificação: Aspetos de interface, não de implementação. Implementação: Temos realmente as classes e as definições de implementação.

35 Relacionamento entre Classes
1) Associação  Associações e ligações são os mecanismos para estabelecer relacionamentos entre objetos e classes. Uma associação descreve um conjunto de ligações potenciais.  Alguns atributos dizem respeito a associações e não a classes. Estes se transformam em classes de Associação.

36 Relacionamento entre Classes
1) Associação  Embora associações sejam bidirecionais por padrão, é freqüentemente desejável limitar sua “navegação” em uma única direção. Se a navegação for limitada, uma seta é adicionada para indicar a direção na qual a associação pode ser percorrida.  Uma associação recursiva representa uma associação entre objetos da mesma classe.

37 Relacionamento entre Classes
1) Associação Associações qualificadas são usadas com associações de um para vários (1..*) ou vários para vários (*..*). O “qualificador” (identificador da associação qualificada) especifica como um determinado objeto no final da associação "n" é identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associação. O qualificador permite reduzir a multiplicidade da associação para 1.  O identificador é desenhado como uma pequena caixa no final da associação junto à classe de onde a navegação deve ser feita.  

38 2) Agregação  Uma agregação é um relacionamento do tipo “parte de”, nos quais objetos representando os componentes são associados com objetos representando uma montagem.  Agregação é uma forma de associação com alguma semântica adicional. É transitiva (se A é parte de B e B parte de C, então A é parte de C)  Agregação Compartilhada é um tipo especial de agregação que ocorre quando uma das classes é uma parte, ou está contida na outra, mas esta parte pode estar contida na outra várias vezes em um mesmo momento.

39 3) Composição  É uma forma mais forte de agregação. Na composição, o objeto parte pode pertencer somente a um todo e espera-se que as partes vivam e morram com o todo.  Se o objeto da classe que contém for destruído, as classes da composição serão destruídas juntamente. JTextField JTextArea JButton Formulario JComboBox

40 4) Dependência  Forma mais fraca de relacionamento, onde uma classe (o cliente) depende de outra classe (o servidor) para um serviço específico.  Uma mudança no elemento independente irá afetar o modelo dependente.  Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento.

41 4) Dependência  Existe um relacionamento de dependência entre duas classes quando: um objeto da classe servidora é passado como parâmetro de um método da classe cliente ou, um objeto da classe servidora é declarado localmente em um método da classe cliente ou, um objeto global da classe servidora é acessado pela classe.  Um dos objetivos do desenvolvimento é manter as dependências ao mínimo.  Manter a interface das classes evita problemas de dependências.

42 Diagramas de Classes Sistema Bancário Agregações Generalização Associação bidirecional Classe de Associação

43 Diagramas de Objetos  O diagrama de Objetos fazem a modelagem de instâncias de itens contidos em diagramas de classes.  Mostra um conjunto de objetos e seus relacionamentos em um determinado ponto do tempo.  É uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas.  Envolve a modelagem do sistema em um determinado ponto.  Pode-se considerar o diagrama de objetos como um diagrama de colaboração sem mensagens.

44 Diagramas de Objetos

45 de Diagramas de Interação
 Diagramas de interação descrevem como os casos de uso são realizados através das interações entre objetos.  Dinâmica do sistema : forma pela qual os objetos se comunicam no sistema e alteram seus estados durante o tempo de vida do sistema.  A comunicação entre um conjunto de objetos, com o propósito de executar alguma função, é chamada interação. Pode ser descrita pelos: Diagramas de Seqüência Diagramas de Colaboração Diagramas de Atividades  Além destes diagramas, o modelo dinâmico pode ser descrito com auxílio dos Diagramas de Estado. Também chamados de Diagramas de Interação

46 Diagramas de Estado  Mostra todos os estados possíveis nos quais objetos de uma certa classe podem se encontrar e mostra quais os eventos que provocam mudanças entre estes estados.  Não são escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um número de estados conhecidos.  É um complemento para a descrição das classes.  Os estados representam as condições dos objetos em um determinado momento. Os eventos representam incidentes que causam a mudança de um estado para outro. As linhas de transição descrevem o movimento de um estado para o outro.

47 Diagramas de Estado Condição de Guarda Estado Argumentos Evento
Ação de Transição Atividade

48 Diagramas de Atividades
 Diagramas de atividades capturam ações e seus resultados, com foco no trabalho executado na implementação de uma operação (método) e suas atividades numa instância de um objeto.  É uma variação do diagrama de estado onde todos os estados têm uma ação interna e nenhuma transição tem um evento de entrada.  Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada, sem ser necessário especificar eventos como no diagrama de estados.  Representa o que acontece mas não quem faz. Não diz que classe é responsável por cada atividade. Através do uso de divisores (Swimlanes) podemos separar as atividades de acordo com as classes responsáveis.

49 Diagramas de Atividades
 Decisões e condições, como execução paralela, também podem ser mostrados neste diagrama.  Mostra o fluxo seqüencial das atividades. Atividade Condição de Guarda Desvio

50 Diagramas de Atividades
Separação (execuções em paralelo) Junção (junta as execuções em paralelo)

51 Diagramas de Seqüência
 Mostra a colaboração dinâmica entre os vários objetos de um sistema.  Tipicamente, captura o comportamento de um único caso de uso.  A partir deste diagrama podemos perceber a seqüência de mensagens enviadas entre os objetos.  Descrição : Consiste em um número de objetos mostrado em linhas verticais. O tempo é visualizado no sentido vertical de cima para baixo e as mensagens enviadas por cada objeto são simbolizadas por setas.

52 Caso de Uso Cadastrar Cliente
Diagramas de Seqüência Caso de Uso Cadastrar Cliente

53 Caso de Uso Retirar Valor Conta
Diagramas de Seqüência Caso de Uso Retirar Valor Conta

54 Diagramas de Colaboração
 Um diagrama de colaboração mostra de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entre os objetos.  Além de mostrar a troca de mensagens entre os objetos, percebe-se também os objetos com os seus relacionamentos.  Se a ênfase do diagrama for o decorrer do tempo: diagrama de seqüência Se a ênfase for o contexto do sistema: diagrama de colaboração.    As setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens nomeadas mostram a ordem em que as mensagens são enviadas.

55 Caso de Uso Adicionar Valor Conta
Diagramas de Colaboração Caso de Uso Adicionar Valor Conta

56 <Conta Corrente>
Diagramas de Colaboração Caso de Uso Criar Conta <Conta Corrente>

57 Diagramas de Componentes
 Diagramas de Componentes são usados para modelar os aspectos físicos de um sistema. Descreve os componentes de software e suas dependências, representando a estrutura do código gerado.  Componentes são a implementação, na arquitetura física, dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos).  Um componente, tipicamente, é uma versão física de elementos lógicos, como classes e interfaces. Pode ser utilizado para representar bibliotecas, objetos COM, Java Beans, código fonte, esquemas de banco de dados, etc.   Componentes podem ser executadas em nós (processadores, dispositivos, etc.)

58 Diagramas de Componentes
 Um diagrama de componentes mostra apenas componentes como tipos. A dependência entre componentes é mostrada por uma linha tracejada, simbolizando que um componente precisa do outro.  O diagrama de componentes é composto por : Componentes. Pacotes de componentes - representa os grupos de componentes relacionados. Interfaces - define os métodos visíveis de uma classe ou componente. Relacionamento de dependência - Exibe quando um componente usa serviços de outro componente.

59 Diagramas de Componentes
Nível de Interface PackageGuiBanco Formulario FormularioCad Operacoes astramento <<Application>> Nível de Négocios Banco PackageNegóciosBanco <<object>> <<object>> ContaCorre Cliente nte Nível de Dados PackageAcessoDadosBanco DataAcess Object

60 Diagramas de Implantação (Utilização/Execução)
 Diagrama de Implentação mostra as relações físicas entre componentes de software e hardware no sistema implementado.  É composto de: 1) Componentes de software 2) Nós, objetos físicos que fazem parte do sistema, tais como máquinas servidoras, máquinas clientes em uma LAN, impressoras, roteadores. 3) Conexões entre nós e componentes que, juntos, compõem toda a arquitetura física do sistema.  Mostra a arquitetura do sistema em tempo de execução composta de seus processadores, dispositivos e componentes de software.

61 Diagramas de Implantação (Utilização/Execução)

62 Resumo A Arquitetura Lógica de um sistema contém a lógica da aplicação. Em UML os diagramas usados para descrever a arquitetura lógica são: Os Diagramas de Casos de uso representam uma visão externa do sistema. Os Diagramas de Classes mostram a estrutura estática do sistema. O Diagrama de Objetos as instâncias dos objetos e seus relacionamentos em um dado momento. Diagramas de interação descrevem como os casos de uso são realizados através das interações entre objetos. Se a ênfase desejada for o decorrer do tempo usa-se Diagrama de Sequência. Se a ênfase for o contexto do sistema usa-se o Diagrama de Colaboração.  

63 Resumo O Diagrama de Estado mostra os estados possíveis de objetos de uma certa classe e os eventos que provocam tais mudanças. O Diagrama de Atividades descreve a sequencia de atividades, com suporte para comportamento condicional e paralelo. A Arquitetura Física de um sistema apresenta uma descrição dos componentes de software e hardware. Em UML os diagramas usados para descrever a arquitetura física são: O Diagrama de Componentes contém os componentes de software. O Diagrama de Implantação mostra a arquitetura em tempo de execução, ou seja, os computadores, dispositivos etc.