orienta o a objetos e uml parte i l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Orientação a Objetos e UML Parte I PowerPoint Presentation
Download Presentation
Orientação a Objetos e UML Parte I

Loading in 2 Seconds...

play fullscreen
1 / 90

Orientação a Objetos e UML Parte I - PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on

Orientação a Objetos e UML Parte I. Objetivos. Apresentar os conceitos fundamentais de modelagem e orientação a objetos; Apresentar os quatro diagramas principais da UML: Casos de Uso, Classes, Seqüência e Atividade;

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Orientação a Objetos e UML Parte I' - satya


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
objetivos
Objetivos
  • Apresentar os conceitos fundamentais de modelagem e orientação a objetos;
  • Apresentar os quatro diagramas principais da UML: Casos de Uso, Classes, Seqüência e Atividade;
  • Estabelecer a ligação entre a modelagem e a programação de sistemas orientados a objetos.
bibliografia
Bibliografia
  • Modelagem de Objetos Através da UML, José Davi Furlan, Editora Makron Books, 2000, ISBN 8534609241;
  • UML Guia do Usuário, Grady Booch, James Rumbaugh, Ivar Jacobson, Editora Campus, 2000, ISBN 8535205624;
  • Mastering UML com Rational Rose 2002 – Bíblia, Boggs Wendy, Michael Boggs, Editora Alta Books Ltda, 2002;
  • UML Essencial: Um breve guia para a linguagem-padrão de modelagem de objetos, Martin Fowler e Kendal Scott, Ed. Bookman, 2000.
refer ncias na internet
Referências na Internet
  • http://www.uml.org
  • http://www.uml-forum.com
  • http://www.rational.com
  • http://argouml.tigris.org/(Ferramenta CASE Argo)
  • http://www.gentleware.com(Ferramenta CASE Poseidon)
  • http://www.borland.com/together/index.html(Ferramenta CASE Together)
1 conceitos fundamentais

1. Conceitos Fundamentais

Unidade de Aprendizado

1 conceitos fundamentais6
1. Conceitos Fundamentais
  • Objetivos
    • Apresentar os conceitos envolvidos na Modelagem de Sistemas;
    • Explorar a importância e a necessidade de modelar sistemas.
    • Apresentar os conceitos fundamentais sobre Orientação a Objetos.
  • Conteúdo

1. Modelagem de Sistemas.

2. Orientação a Objetos.

1 1 objetivo da modelagem de sistemas8
1.1. Objetivo da Modelagem de Sistemas
  • A Atividade de Desenvolvimento de Sistemas
    • Objetivos da Empresa de Desenvolvimento de Software:
      • Produtos de Qualidade;
      • Atender as necessidades do cliente;
      • Preços competitivos.
    • Foco nos Clientes:
      • Centro da atenção no desenvolvimento;
      • Atender aos requisitos do usuário.
    • Viabilidade do Projeto:
      • Equilíbrio entre custos de desenvolvimento e benefícios para o cliente.
1 1 objetivo da modelagem de sistemas9
1.1. Objetivo da Modelagem de Sistemas
  • O Papel da Modelagem
    • Existem dois tipos de modelos:
      • Estrutura;
      • Comportamento;
    • Os modelos traduzem COMO as coisas serão construídas:
      • Relações entre as partes;
      • Funcionamento;
      • Disposição.
    • Os modelos traduzem o tamanho e a complexidade do sistema.
1 1 objetivo da modelagem de sistemas10
1.1. Objetivo da Modelagem de Sistemas
  • O Que é um Modelo?
    • Um modelo é uma simplificação da realidade.
    • Modelos são esquemas gráficos que representam o sistema.
    • Os modelos traduzem:
      • ESTRUTURA:
        • Organização de módulos;
        • Relacionamentos;
      • COMPORTAMENTO:
        • Dinâmica;
        • Inter-relacionamento;
        • Funcionalidade.
1 1 objetivo da modelagem de sistemas11
1.1. Objetivo da Modelagem de Sistemas
  • O Que é um Modelo?
    • Construímos modelos para:
      • Visualizar o sistema como ele é ou como desejamos que ele seja;
      • Dominar a complexidade e entender o sistema;
      • Delimitar o escopo de um problema;
      • Comunicação entre equipe;
      • Ajudar a planejar as soluções;
      • Guiar o desenvolvimento do sistema.
1 1 objetivo da modelagem de sistemas12
1.1. Objetivo da Modelagem de Sistemas
  • O Que é um Modelo?
    • Características dos Modelos:
      • Perspectivas diferentes;
      • Analogia com a realidade;
      • Complementaridade;
1 1 objetivo da modelagem de sistemas13
1.1. Objetivo da Modelagem de Sistemas
  • Modelagem Orientada a Objetos
    • Tradicional:
      • Foco do desenvolvimento nos processos;
    • Orientada a Objetos:
      • Foco do desenvolvimento nas entidades que participam dos processos.
    • Entidades do mundo real:
      • Pessoas - Funcionário, Vendedor, Professor, Aluno.
      • Lugares - Sala, Estoque, Estante, Prateleira.
      • Fatos - Conta-Corrente, Matrícula, Pedido de Compra, Apólice de Seguro.
      • Coisas - Livro, Caminhão, Fita VHS, Computador.
1 1 objetivo da modelagem de sistemas14
1.1. Objetivo da Modelagem de Sistemas
  • Modelagem Orientada a Objetos
1 1 objetivo da modelagem de sistemas15
1.1. Objetivo da Modelagem de Sistemas
  • Modelagem Orientada a Objetos - Benefícios
    • Benefícios Técnicos:
      • Reusabilidade;
      • Extensibilidade e manutenção;
      • Aumento da qualidade;
    • Benefícios Econômicos:
      • Apoio ao planejamento;
      • Reaproveitamento de esforços.
1 1 objetivo da modelagem de sistemas16
1.1. Objetivo da Modelagem de Sistemas
  • Modelagem Orientada a Objetos - Definições
    • James Rumbaugh

Uma nova maneira de pensar os problemas, utilizando modelos organizados a partir de conceitos do mundo real.

O componente fundamental é o objeto, que combina estrutura e comportamento em uma única entidade.

1 1 objetivo da modelagem de sistemas17
1.1. Objetivo da Modelagem de Sistemas
  • Modelagem Orientada a Objetos - Definições
    • Grady Booch

Leia a especificação do software que você quer criar.

Sublinhe os verbos se quiser uma codificação procedural ou os substantivos se visar a um programa orientado a objetos.

1 2 orienta o a objetos20
1.2. Orientação a Objetos
  • Analogia Orientada a Objetos
    • Imagine que você recebeu como herança, um grande terreno.
    • Esse terreno é identificado por um número.
1 2 orienta o a objetos21
1.2. Orientação a Objetos
  • Analogia Orientada a Objetos
    • Você contrata um arquiteto a fim de projetar uma casa.
    • O arquiteto faz várias perguntas sobre a casa, a sua forma, estilo e funcionalidade.
    • O arquiteto trabalha algum tempo no projeto da casa e entrega as plantas para que você possa construir.
1 2 orienta o a objetos22
1.2. Orientação a Objetos
  • Analogia Orientada a Objetos
    • Você contrata uma construtora para erguer a casa.
    • A construtora leva algum tempo e termina o serviço.
    • Existe alguma casa no terreno? Sim, a casa ocupa espaço no terreno.
1 2 orienta o a objetos23
1.2. Orientação a Objetos
  • Processador e Memória
    • A memória é dividida em partes referenciadas por endereços.
    • Existem partes da memória que estão ocupadas e outras livres.
    • Dentro de um programa, podemos alocar espaço na memória e construir objetos.
    • Esses objetos são acessados através de um endereço de memória ou de uma referência ao endereço.
1 2 orienta o a objetos24
1.2. Orientação a Objetos
  • Classe
    • Conceito de Classe:
      • As plantas da casa representam a classe.
      • É a partir da classe que se constrói um objeto na memória.
      • É a definição da forma e funcionalidade de alguma coisa.
    • Responsabilidade da Classe:
      • É o que a classe “sabe” e o que ela “faz”.
      • O que a classe “sabe” são as propriedades ou seus atributos.
      • O que a classe “faz” são os seus métodos ou funções.
1 2 orienta o a objetos25
1.2. Orientação a Objetos
  • Exemplo
    • Vamos imaginar que em um sistema exista a classe Aluno.
    • O que Aluno sabe?
      • Seu nome,
      • Seu endereço,
      • Seu número de matrícula etc.
    • O que o Aluno faz?
      • Se matricula em um Curso,
      • Tranca a matricula,
      • Tem Avaliações etc.
1 2 orienta o a objetos26
1.2. Orientação a Objetos
  • Tipos de Classes
    • Classes de Interface:
      • Botões,
      • Listas,
      • Checkboxes,
      • Scrollbars etc.
    • Classes de Negócio:
      • Cliente,
      • Pedido,
      • Item de Pedido,
      • Produto etc.
    • Classes de Controle:
      • Data,
      • Conexão com Banco de Dados,
      • Gerenciador de Impressão,
      • Leitura e Gravação de Arquivos etc.
1 2 orienta o a objetos27
1.2. Orientação a Objetos
  • Objeto
    • Quando alocamos espaço na memória e usamos o construtor de uma classe, um objeto é criado.
    • Um objeto não interfere em outro.
    • Instância é sinônimo de objeto.
    • Instanciar significa criar um objeto a partir de uma classe.
1 2 orienta o a objetos29

Propriedades

Cliente

Criar()

Nome

Idade

Destruir()

Funções

1.2. Orientação a Objetos

Outra forma de desenhar a classe

1 2 orienta o a objetos30
1.2. Orientação a Objetos
  • Propriedade
    • As propriedades são os dados que guardam as características e o estado dos objetos criados a partir da classe.
    • É o que a classe “sabe”.
    • O relógio digital tem as propriedades “hora” e “minuto”.
1 2 orienta o a objetos31
1.2. Orientação a Objetos
  • Método
    • O termo método representa as funcionalidades inerentes à classe.
    • É o que a classe “faz”.
    • Para alterar o mostrador do relógio digital não podemos simplesmente exibir um número qualquer.
    • Existe um “método” para fazer isso.
1 2 orienta o a objetos32
1.2. Orientação a Objetos
  • Método Construtor e Destrutor
    • A função do método construtor é inicializar um objeto na memória.
      • Através dele é possível que o objeto na memória tenha valores iniciais.
      • Esse método é usado, por exemplo, para construir a tela da aplicação e abrir a conexão com o banco de dados.
    • O método destrutor permite “fechar” o ciclo de vida do objeto, dando condições de finalização ao programador.
1 2 orienta o a objetos33
1.2. Orientação a Objetos
  • Assinatura
    • É a chamada de um método. Identifica um método pelo nome, a quantidade e tipos dos argumentos passados por parâmetros.
    • Um método é reconhecido pelo seu nome e seus parâmetros

CancelarAssinatura(codAssinante)

AlterarPagamento(codAssinante, novaDataPagamento)

1 2 orienta o a objetos34
1.2. Orientação a Objetos
  • Herança
    • Relacionamento de generalização e especialização entre classes.
    • Permite ao programador criar uma nova classe “estendendo” uma classe anterior.
    • A herança define uma hierarquia onde o conceito mais genérico fica sobre o conceito mais específico.
1 2 orienta o a objetos36
1.2. Orientação a Objetos
  • Encapsulamento
      • A Classe é um “pacote”, contendo dados e operações;
      • O objeto é referenciado como um módulo único;
      • É a proteção dos dados internos da classe;
      • Os dados só podem ser acessados sob determinadas condições.
      • É implementado através da “Visibilidade” mais restrita.
1 2 orienta o a objetos37
1.2. Orientação a Objetos
  • Encapsulamento
    • Um sistema não deve depender da sua implementação interna e sim de sua interface com o mundo exterior.
    • A interface de uma classe é a forma pela qual ela será acionada e se relacionará com as outras partes do sistema.

Cliente

Encapsulamento – acessar os

dados através dos métodos

da classe

BuscarCliente()

Nome

Dt_nascim

ListarCliente()

ExcluirCliente()

CadCliente()

1 2 orienta o a objetos38
1.2. Orientação a Objetos
  • Polimorfismo
    • Vários comportamentos que uma mesma operação pode assumir.
    • Polimorfismo (muitas formas) é a capacidade de um programa orientado a objetos distinguir, dentre métodos homônimos, qual deverá ser executado.
1 2 orienta o a objetos39

Empregado

Retângulo

Nome

Funcao

Dt_Admissao

Desenhar(p1,p2,p3,p4)

Desenhar(alt,larg)

Empregado(nome)

Empregado(nome,funcao,dt)

Métodos na mesma classe com assinatura diferente - Sobrecarga

1.2. Orientação a Objetos

Polimorfismo

  • Métodos Sobrecarregados - são os métodos homônimos dentro de uma mesma classe.
1 2 orienta o a objetos40

Vendedor

comissão

ObterEmpregado( )

1.2. Orientação a Objetos
  • Polimorfismo
      • Métodos Sobrescritos - são métodos homônimos em uma relação de herança.

Empregado

nome

ObterEmpregado( )

Métodos com a mesma assinatura em uma herança - Sobrescrita

1 2 orienta o a objetos42
1.2. Orientação a Objetos
  • Modularidade
    • É a separação dos serviços em um conjunto de módulos que guardam independência de compilação e execução.
    • A modularidade leva a uma separação entre a interface do sistema e o código que vai executar os serviços.
    • Otimiza o processo de manutenção de código.
1 2 orienta o a objetos43
1.2. Orientação a Objetos
  • Persistência
    • É o tempo total que um objeto permanece na memória (auxiliar ou principal).
    • Os objetos de negócio devem ser persistentes.
    • É comum a utilização de bancos de dados para tornar os objetos persistentes.
1 2 orienta o a objetos44
1.2. Orientação a Objetos
  • Abstração
    • É a ocultação de certos aspectos de implementação.
    • O objetivo é diminuir a complexidade, focando um problema por vez.
1 2 orienta o a objetos45
1.2. Orientação a Objetos
  • Classe Abstrata
    • E uma classe que define o comportamento e atributos para subclasses.
    • Não é instanciada diretamente.
1 2 orienta o a objetos46
1.2. Orientação a Objetos
  • Estereótipo
    • Os estereótipossão extensões de elementos do modelo. Podem ser usados para denotar especializações significativas de classes.
    • Os atores, por exemplo, são tratados pelas ferramentas de modelagem como classes estereotipadas.
    • Os estereótipos podem ser indicados através de ícones próprios, ou incluindo-se o nome do estereótipo em aspas francesas (os caracteres « », representados nos desenhos por << >>).
1 2 orienta o a objetos47
1.2. Orientação a Objetos
  • Estereótipo
    • Estereótipos são usados para criar especializações da UML em relação a determinadas áreas de modelagem.
    • Ivar Jacobson propõe a divisão das classes do Modelo de Análise de acordo com estereótipos, que foram incorporados ao padrão oficial da UML. Esses estereótipos podem ser representados por textos ou ícones. São eles: Entidades (tabelas), Fronteiras (telas) e de Controle (conexão com banco, gerenciador de impressão,...).
1 2 orienta o a objetos48
1.2. Orientação a Objetos
  • Exercício
  • Identifique as propriedades e métodos das classes listadas.
1 2 conclus o da ua 1
1.2. Conclusão da UA 1
  • A Orientação a Objetos é uma TECNOLOGIA que envolve desde a concepção do sistema e da sua modelagem até a implementação utilizando linguagens orientadas a objetos.
2 a uml e o processo de desenvolvimento de sistemas51
2. A UML e o Processo de Desenvolvimento de Sistemas
  • Objetivos
    • Apresentar as origens da UML e suas versões;
    • Mostrar os diagramas da linguagem e os seus principais conceitos;
    • Relacionar como ocorre o processo de desenvolvimento iterativo e incremental.
  • Conteúdo

1. Origens da UML;

2. Versionamento da UML;

3. Diagramas da UML;

4. Rational Unified Process;

2 1 origens da uml53
2.1. Origens da UML
  • O Que é UML?
    • A Unified Modeling Language nasceu (1994) da junção de vários métodos (Booch, OOSE e OMT), por isso se chama unificada.
    • A UML é uma linguagem para especificar, visualizar, construir e documentar os artefatos de software.
    • Padrão OMG (UML 1.1 – 1997)
    • Contribui para as melhores práticas de engenharia de software, pois é uma linguagem visual.
2 1 origens da uml54
2.1. Origens da UML
  • Definição em Três Partes
    • Primeiro: a UML funde os conceitos de Grady Booch, James Rumbaugh e Ivar Jacobson.
2 1 origens da uml55
2.1. Origens da UML
  • Definição em Três Partes
    • Segundo, a UML é genérica e flexível.
    • Se aplica a uma diversidade de sistemas.
2 1 origens da uml56
2.1. Origens da UML
  • Definição em Três Partes
    • Terceiro, a UML tem como foco uma linguagem de modelagem padronizada e não se preocupa com a metodologia de desenvolvimento.
    • Método = Linguagem (UML) + Processo (RUP)
2 1 origens da uml57
2.1. Origens da UML
  • Versionamento da Linguagem
    • Atualmente na versão 1.5, em atualização para a 2.0, novidades:
      • XMI,
      • Comunication Diagram,
      • Composite Structure Diagram,
      • Interaction Overview Diagram,
      • Timming Diagram

(http://www.agilemodeling.com)

2 1 origens da uml58
2.1. Origens da UML
  • Certificação em UML
    • Provas para UML Professional:
      • Iniciante (Class Diagrams, Activity diagrams, Interaction Diagrams, Use Case Diagrams, Miscellaneous basic notions)
      • Intermediária (Composite Structure Diagrams, Component diagrams, Action Model, Activity Diagrams, Interaction Diagrams, State Machines, Deployment diagrams)
      • Avançada (Class Diagrams, Composite Structure diagrams, Component diagrams, Action Model, Activity Diagrams, Deployment diagrams, State Machine Diagrams, Miscellaneous Advanced Constructs and Diagramming, Language Architecture, Object Constraint Language)
2 2 rational unified process60
2.2. Rational Unified Process
  • Processo de Desenvolvimento
    • O processo de desenvolvimento é composto por diversas fases;
    • Em cada fase precisamos executar diversas atividades.
    • Esse esforço tem como alvo principal a construção de um sistema de qualidade.
2 2 rational unified process61
2.2. Rational Unified Process
  • Origens
    • O RUP foi desenvolvido originalmente na Suécia por Ivar Jacobson, sendo batizado, na ocasião da sua concepção, de Objectory.
    • Trata-se de um processo iterativo e incremental e indica o uso da UML.
    • O RUP é um framework.
2 2 rational unified process62

Concepção

Concepção

Concepção

Elaboração

Elaboração

Elaboração

Construção

Construção

Construção

Transição

Transição

Transição

Levantamento de Dados

Levantamento de Dados

Levantamento de Dados

Análise e Projeto

Análise e Projeto

Análise e Projeto

Implementação

Implementação

Implementação

Teste

Teste

Teste

Gerenciamento

Gerenciamento

Gerenciamento

Suporte ao Desenvolvimento

Suporte ao Desenvolvimento

Suporte ao Desenvolvimento

Suporte à Produção

Suporte à Produção

Suporte à Produção

2.2. Rational Unified Process
  • Descrição em Duas Dimensões

Tempo

Iterações

2 2 rational unified process63
2.2. Rational Unified Process
  • Descrição em Duas Dimensões

As “ondas” representam a carga de trabalho

2 2 rational unified process64
2.2. Rational Unified Process
  • Fase de Concepção
    • Na fase de concepção é estabelecido o contexto de negócio para o sistema e delimitado o escopo do projeto.
    • O contexto de negócio inclui também um critério de sucesso, ponderado em função de recursos e tempo.
    • Devemos elaborar um cronograma básico de execução com as principais fases e datas de entrega.
    • Nessa fase o sistema é descrito através de um texto sumário, resumindo o que é o sistema, e de um diagrama de Caso de Uso geral, contendo os atores e as suas principais funcionalidades.
2 2 rational unified process65
2.2. Rational Unified Process
  • Fase de Elaboração
    • Consiste de uma análise mais refinada do sistema a ser construído, juntamente com um plano detalhado de trabalho a ser feito.
    • Elaboração de um projeto completo, com o detalhamento de interações e estrutura do sistema.
    • Construir um protótipo que teste a arquitetura escolhida.
    • Nessa fase os Casos de Uso são completamente detalhados, são elaborados todos os diagramas de classes identificadas, são feitos protótipos das telas e o projeto lógico do banco de dados é elaborado.
2 2 rational unified process66
2.2. Rational Unified Process
  • Fase de Construção
    • Trabalhamos sobre o protótipo da fase anterior adicionando novas funcionalidades e refinando as funcionalidades pré-existentes.
    • O gerente do projeto define várias versões que devem ser liberadas a cada ciclo.
    • A cada ciclo é necessário rever os requisitos de cada parte da aplicação.
    • Nessa fase os módulos do sistema são implementados e refinados em ciclos (iterações). O projeto físico do banco de dados é implementado.
2 2 rational unified process67
2.2. Rational Unified Process
  • Fase de Transição
    • Nessa fase o software pode ser instalado em ambiente de produção para que os clientes possam trabalhar com ele - versão beta.
    • A medida em que testes são executados e melhorias são implementadas é produzida a versão final do produto.
    • Nessa fase, além da versão beta e do produto final, são produzidos os manuais e componentes de distribuição do software.
2 2 rational unified process68
2.2. Rational Unified Process
  • Exercício
    • Que documentos e produtos são obtidos a partir de cada fase do RUP?
      • Concepção:
      • Elaboração:
      • Construção:
      • Transição:
2 3 diagramas da uml

2.3. Diagramas da UML

Bloco de Construção do Aprendizado

2 3 diagramas da uml v 1 5
2.3. Diagramas da UML (V 1.5)

Diagrama de

Objetos

Diagrama de

Caso de Uso

Diagrama de

Seqüência

...

...

Diagrama de

Classe

Diagrama de

Colaboração

Modelos

Diagrama de

Componente

Diagrama de

Estado

Diagrama de

Atividade

Diagrama de

Implantação

2 3 diagramas da uml71
2.3. Diagramas da UML

Captura de Requisitos

Análise e Projeto

Implementação

Estados

Casos de Uso

Distribuição

Sequência

Classes

Colaboração

Componentes

Atividade

(fluxo de trabalho,

casos de uso)

Atividade

(comportamento objeto,

Algoritmo, operação)

2 3 diagramas da uml72
2.3. Diagramas da UML
  • Cenário de uma Aplicação
    • Este cenário apresenta os oito tipos de diagramas UML na modelagem de um sistema de software para uma locadora de veículos.
2 3 diagramas da uml73
2.3. Diagramas da UML
  • Diagrama de Caso de Uso
    • Especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo muito claro a atingir.
      • O cliente faz a reserva de um carro;
      • O cliente retira o carro;
      • O cliente devolve o veículo.
2 3 diagramas da uml75
2.3. Diagramas da UML
  • Diagrama de Classe
    • A próxima tarefa é a classificação dos objetos envolvidos neste processo e a relação de uns com os outros.
    • Diagramas de classe mostram a estrutura geral do sistema e também as suas propriedades relacionais e de comportamento.
      • Cliente;
      • Mecânica;
      • Locação.
2 3 diagramas da uml76
2.3. Diagramas da UML
  • Diagrama de Classe

Os diagramas são complementares !

Se o sistema controlar todas essas informações teremos alteração no Diag. Caso de Uso anterior

2 3 diagramas da uml77
2.3. Diagramas da UML
  • Diagrama de Seqüência
    • Mostra uma interação organizada em forma de uma seqüência, dentro de um determinado período de tempo.
    • Os participantes são apresentados dentro do contexto das mensagens que transitam entre eles.
    • O diagrama de seqüência é um diagrama de interação.
2 3 diagramas da uml78
2.3. Diagramas da UML

Objetos

  • Diagrama de Seqüência
  • Reservar Carro
  • Curso Normal

Mensagem

Tempo

2 3 diagramas da uml79
2.3. Diagramas da UML
  • Diagrama de Colaboração
    • Mostra como um grupo de objetos num caso de uso interage com os demais.
    • Cada mensagem é numerada para documentar a ordem na qual ela ocorre.
    • O diagrama de colaboração também é um diagrama de interação.
2 3 diagramas da uml80
2.3. Diagramas da UML
  • Diagrama de Colaboração
2 3 diagramas da uml81
2.3. Diagramas da UML
  • Diagrama de Estado
    • Mapeia diferentes estados em que se encontram os objetos, e desencadeia eventos que levam os objetos a se encontrarem em determinado estado em um dado momento.
2 3 diagramas da uml82

Início

Fim

Na

Vendido

Garagem

Alugado

Em

manutenção

2.3. Diagramas da UML

Diagrama de Estado – Classe Carro

2 3 diagramas da uml83
2.3. Diagramas da UML
  • Diagrama de Atividade
    • Apresenta a lógica que ocorre em resposta a ações desencadeadas internamente.
    • Se reporta a uma determinada classe ou caso de uso.
2 3 diagramas da uml84
2.3. Diagramas da UML
  • Diagrama de Atividade
  • Reservar Carro

O losango mostra o desvio de execução

2 3 diagramas da uml85
2.3. Diagramas da UML
  • Diagrama de Componentes
    • Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema.
2 3 diagramas da uml86
2.3. Diagramas da UML
  • Diagrama de Componentes

Linhas tracejadas indicam dependência

2 3 diagramas da uml87
2.3. Diagramas da UML
  • Diagrama de Implantação
    • Mostra como estão configurados o hardware e o software dentro de um determinado sistema.
2 3 diagramas da uml88
2.3. Diagramas da UML
  • Diagrama de Implantação
2 3 diagramas da uml89
2.3. Diagramas da UML
  • Exercício
    • Divida os diagramas vistos nessa seção em três grupos:
    • Visão dos Requisitos do Sistema:
    • Visão da Estrutura do Sistema:
    • Visão da Dinâmica do Sistema:
    • Visão do Funcionamento das “Partes Físicas” do Sistema:
conclus o da ua 2
Conclusão da UA 2
  • A UML não tem uma metodologia embutida, permitindo que o desenvolvedor use os diagramas como bem entender.
  • Cada diagrama da UML mostra uma “visão” do sistema. Nenhum diagrama permite ter a idéia do sistema por inteiro.
  • O RUP é uma proposta de metodologia de desenvolvimento de sistemas que usa a UML como notação.