Orienta

1
Orientação a Objetos e UMLParte I
2
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.

3
Bibliografia

1. Modelagem de Objetos Através da UML, José Davi
   Furlan, Editora Makron Books, 2000, ISBN
   8534609241
2. UML Guia do Usuário, Grady Booch, James Rumbaugh,
   Ivar Jacobson, Editora Campus, 2000, ISBN
   8535205624
3. Mastering UML com Rational Rose 2002 Bíblia,
   Boggs Wendy, Michael Boggs, Editora Alta Books
   Ltda, 2002
4. UML Essencial Um breve guia para a
   linguagem-padrão de modelagem de objetos, Martin
   Fowler e Kendal Scott, Ed. Bookman, 2000.

4
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)

5
1. Conceitos Fundamentais
Unidade de Aprendizado
6
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.

7
1.1. Objetivo da Modelagem de Sistemas
8
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.

9
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.

10
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.

11
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.

12
1.1. Objetivo da Modelagem de Sistemas

• O Que é um Modelo?
• Características dos Modelos
• Perspectivas diferentes
• Analogia com a realidade
• Complementaridade

13
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.

14
1.1. Objetivo da Modelagem de Sistemas

• Modelagem Orientada a Objetos

15
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.

16
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.

17
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.

18
1.1. Objetivo da Modelagem de Sistemas

• Exercício

Nº Substantivos Verbos
1
2
3
19
1.2. Orientação a Objetos
20
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.

21
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.

22
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.

23
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.

24
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.

25
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.

26
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.

27
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.

28
1.2. Orientação a Objetos

• Classe e Objeto

29
1.2. Orientação a Objetos
Outra forma de desenhar a classe
30
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.

31
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.

32
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.

33
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)

34
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.

35
1.2. Orientação a Objetos

• Herança

36
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.

37
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()
38
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.

39
1.2. Orientação a Objetos

• Polimorfismo
• Métodos Sobrecarregados - são os métodos
  homônimos dentro de uma mesma classe.

40
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
41
1.2. Orientação a Objetos

• Polimorfismo

42
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.

43
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.

44
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.

45
1.2. Orientação a Objetos

• Classe Abstrata
• E uma classe que define o comportamento e
  atributos para subclasses.
• Não é instanciada diretamente.

46
1.2. Orientação a Objetos

• Estereótipo
• Os estereótipos sã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 ltlt gtgt).

47
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,...).

48
1.2. Orientação a Objetos

• Exercício
• Identifique as propriedades e métodos das classes
  listadas.

Nº Nome da Classe Propriedades Métodos
1 Professor Nome, Endereço, Telefone, Disciplina Lançar Notas, Fornecer Nome, Requisitar lista de Alunos
2 Aluno
3 Filme
49
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.

50
2. A UML e o Processo de Desenvolvimento de
Sistemas
51
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

52
2.1. Origens da UML
53
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.

54
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.

55
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.

56
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)

57
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)

58
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)

59
2.2. Rational Unified Process
60
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.

61
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.

62
2.2. Rational Unified Process

• Descrição em Duas Dimensões

Tempo
Iterações
63
2.2. Rational Unified Process

• Descrição em Duas Dimensões

As ondas representam a carga de trabalho
64
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.

65
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.

66
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.

67
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.

68
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

69
2.3. Diagramas da UML
Bloco de Construção do Aprendizado
70
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
71
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)
72
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.

73
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.

74
2.3. Diagramas da UML

• Diagrama de Caso de Uso

75
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.

76
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

77
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.

78
2.3. Diagramas da UML
Objetos

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

Mensagem
Tempo
79
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.

80
2.3. Diagramas da UML

• Diagrama de Colaboração

81
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.

82
2.3. Diagramas da UML
Diagrama de Estado Classe Carro
83
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.

84
2.3. Diagramas da UML

• Diagrama de Atividade
• Reservar Carro

O losango mostra o desvio de execução
85
2.3. Diagramas da UML

• Diagrama de Componentes
• Mostra como os diferentes subsistemas de software
  formam a estrutura total de um sistema.

86
2.3. Diagramas da UML

• Diagrama de Componentes

Linhas tracejadas indicam dependência
87
2.3. Diagramas da UML

• Diagrama de Implantação
• Mostra como estão configurados o hardware e o
  software dentro de um determinado sistema.

88
2.3. Diagramas da UML

• Diagrama de Implantação

89
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

90
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.