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;
– Estabelecer a ligação entre a modelagem e a
programação de sistemas orientados a objetos.
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.
Referências na Internet
1. http://www.uml.org
2. http://www.uml-forum.com
3. http://www.rational.com
4. http://argouml.tigris.org/ (Ferramenta CASE Argo)
5. http://www.gentleware.com (Ferramenta CASE
Poseidon)
6. http://www.borland.com/together/index.ht
ml
(Ferramenta CASE Together)
1. Conceitos Fundamentais
Unidade de Aprendizado
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 Sistemas
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
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
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
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
Sistemas
• O Que é um Modelo?
– Características dos Modelos:
• Perspectivas diferentes;
• Analogia com a realidade;
• Complementaridade;
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
Sistemas
• Modelagem Orientada a Objetos
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
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
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.1. Objetivo da Modelagem de
Sistemas
• Exercício
Nº
1
2
3
Substantivos
Verbos
1.2. Orientação a Objetos
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 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 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 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 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 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 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 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 Objetos
• Classe e Objeto
1.2. Orientação a Objetos
Outra forma de desenhar a classe
Propriedades
Cliente
Nome
Idade
Funções
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 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 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 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 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 Objetos
• Herança
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 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
Cliente
será
acionada e se relacionará com as outras
partes do sistema.
Encapsulamento – acessar os
Nome
Dt_nascim
dados através dos métodos
da classe
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 Objetos
Polimorfismo
– Métodos Sobrecarregados - são os métodos
homônimos dentro de uma mesma classe.
Retângulo
Desenhar(p1,p2,p3,p4)
Desenhar(alt,larg)
Métodos na mesma classe com
assinatura diferente - Sobrecarga
Empregado
Nome
Funcao
Dt_Admissao
Empregado(nome)
Empregado(nome,funcao,dt)
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
Vendedor
comissão
ObterEmpregado( )
1.2. Orientação a Objetos
• Polimorfismo
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 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 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 Objetos
• Classe Abstrata
– E uma classe que define o comportamento e
atributos para subclasses.
– Não é instanciada diretamente.
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 << >>).
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 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
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 Sistemas
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 UML
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 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 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 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 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 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 Process
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 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 Process
• Descrição em Duas Dimensões
Concepção
Elaboração
Construção
Transição
Levantamento de Dados
Análise e Projeto
Implementação
Teste
Gerenciamento
Suporte ao Desenvolvimento
Suporte à Produção
Tempo
Iterações
2.2. Rational Unified Process
• Descrição em Duas Dimensões
As “ondas”
representam
a carga de
trabalho
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 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 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 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 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
Bloco de Construção do Aprendizado
2.3. Diagramas da UML (V 1.5)
Diagrama de
Seqüência
Diagrama de
Objetos
Diagrama de
Caso de Uso
Diagrama de
Classe
Diagrama de
Colaboração
Modelos
Diagrama de
Estado
Diagrama de
Atividade
Diagrama de
Componente
Diagrama de
Implantação
2.3. Diagramas da UML
Captura de Requisitos
Análise e Projeto
Implementação
Estados
Casos de Uso
Sequência
Distribuição
Classes
Colaboração
Atividade
(fluxo de trabalho,
casos de uso)
Componentes
Atividade
(comportamento objeto,
Algoritmo, operação)
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 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 UML
• Diagrama de
Caso de Uso
Sistema de Aluguel de Carro
Reservar Carro
Cliente
Retirar Carro
Devolver Carro
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 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 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 UML
•Diagrama
de
Seqüência
Objetos
: Cliente
Fronteira
Solicitação de Carro
: Carro
: Cliente'
: Aluguel
BuscaCarro( )
•Reservar Carro
•Curso Normal Mensage
m
Informa Reserva (data,carro)
Calcula Aluguel( )
Identificação Pessoal
VerificaHistorico( )
CadastraReserva( )
Tempo
VerificaHistorico( )
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 UML
• Diagrama de Colaboração
1: Solicitação de Carro
3: Informa Reserva (data,carro)
5: Identificação Pessoal
2: BuscaCarro( )
4: Calcula Aluguel( )
Fronteira
: Carro
: Cliente
8: CadastraReserva( )
: Aluguel
6: VerificaHistorico( )
: Cliente'
7: VerificaHistorico( )
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 UML
Diagrama de Estado – Classe Carro
Início
Fim
Na
Garagem
Vendido
Em
manutenção
Alugado
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 UML
• Diagrama de Atividade
• Reservar Carro
O losango
mostra o
desvio de
execução
Verificar Histórico
Cliente
Informações do
Aluguel
Cadastra
Reserva
Rejeição do
Cliente
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 UML
• Diagrama de Componentes
Linhas tracejadas
indicam dependência
Página ASP
Segurança.DLL
SistemaWEB.DLL
BancoGenerico.DLL
SQL Server
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 UML
• Diagrama de Implantação
Servidor de Aplicação
Página ASP
Servidor de Negócios
Segurança.DLL
SistemaWEB.DLL
BancoGenerico.DLL
Servidor de Banco de Dados
SQL Server
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
– 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.