Princípios de Análise e

Projeto Orientados a
Objetos com UML

1
Um modelo é uma simplificação da realidade
que nos ajuda a entender um problema grande
e complexo que não pode ser compreendido
como um todo.
Phillipe Krutchen, 2000

2
Sistemas de Software

 Uma analogia...

Casa de
canhorro Casa Arranha-Ceús

Aumento da complexidade

3
Modelagem de sistemas

4
Complexidade
 Na construção de sistemas de software, assim
como na construção de sistemas habitacionais,
também há uma gradação de complexidade.
 A construção desses sistemas necessita de um
planejamento inicial.

5
Modelos
 De uma perspectiva mais ampla, um modelo
pode ser visto como uma representação
idealizada de um sistema a ser construído.
 Maquetes de edifícios e de aviões e plantas de
circuitos eletrônicos são apenas alguns exemplos
de modelos.

6
Razões para construção de modelos
 Gerenciamento da complexidade inerente ao
desenvolvimento de software.
 Comunicação entre as pessoas envolvidas.
 Redução dos custos no desenvolvimento.
 Predição do comportamento futuro do
sistema.

7
Diagramas
 No contexto de desenvolvimento de software,
correspondem a desenhos gráficos que
seguem algum padrão lógico.
 Esses desenhos são normalmente
denominados diagramas.
 Um diagrama é uma apresentação de uma
coleção de elementos gráficos que
possuem um significado predefinido.

8
Diagramas
 Diagramas fornecem uma representação
concisa do sistema. “uma figura vale por mil
palavras”.

 No entanto, modelos também são compostos de

informações textuais.
 Dado um modelo de uma das perspectivas de
um sistema, diz-se que o seu diagrama,
juntamente com a informação textual associada,
formam a documentação deste modelo.
9
Modelagem de Software

A modelagem de sistemas de software

consiste na utilização de notações gráficas
e textuais com o objetivo de construir modelos
que representam as partes essenciais de um
sistema, considerando-se diversas perspectivas
diferentes e complementares

10
O paradigma da orientação
a objetos
11
Paradigma?
 Um paradigma é uma forma de abordar um
problema.
 O paradigma da orientação a objetos surgiu
no fim dos anos 60.
 Hoje em dia, praticamente suplantou o
paradigma anterior, o paradigma
estruturado...

12
O Paradigma da Orientação a Objetos
 Alan Kay, um dos pais do paradigma da
orientação a objetos, formulou a chamada
analogia biológica.
 “Como seria um sistema de software que
funcionasse como um ser vivo?
 Cada “célula” interagiria com outras células
através do envio de mensagens para realizar
um objetivo comum.
 Adicionalmente, cada célula se comportaria
como uma unidade autônoma.

13
Analogia Biológica
 De uma forma mais geral, Kay pensou em
como construir um sistema de software a
partir de agentes autônomos que interagem
entre si.
 Com isso, ele estabeleceu os princípios da
orientação a objetos.

14
Princípios da Orientação a Objetos
1. Qualquer coisa é um objeto.
2. Objetos realizam tarefas através da
requisição de serviços a outros objetos.
3. Cada objeto pertence a uma determinada
classe. Uma classe agrupa objetos
similares.
4. A classe é um repositório para
comportamento associado ao objeto.
5. Classes são organizadas em hierarquias.

15
Princípios da Orientação a Objetos

 Uma analogia...

Pizzaria
16
 Orientação a Objetos

O paradigma da orientação a objetos visualiza

um sistema de software como uma coleção de
agentes interconectados chamados objetos.
Cada objeto é responsável por realizar tarefas
específicas. É através da interação entre objetos
que uma tarefa computacional é realizada.

17
Conceitos da Orientação a Objetos
 Identidade (objetos)
 Classificação (classes)
 Mensagens
 Abstração
 Encapsulamento
 Polimorfismo
 Herança

18
Objetos
 O mundo real é formado de coisas.
 Na terminologia de orientação a objetos,
estas coisas do mundo real são
denominadas objetos.
 Cada objeto tem sua própria identidade, ou
seja, dois objetos são distintos, mesmo que
tenham os mesmos valores para seus
atributos.
 Ex.: Objetos do mundo real (carro), objetos
visuais (tela, botão..), objetos de programa
não visuais (pilha, fila...)
19
Classes
 Seres humanos costumam agrupar os
objetos para entendê-los.
 A descrição de um grupo de objeto é
denominada classe de objetos, ou
simplesmente de classe.
 Os objetos que possuem a mesma
estrutura de dados (atributos) e o mesmo
comportamento (operações) são agrupado
em uma classe.

20
O que é uma classe?
 Uma classe é um molde para objetos. Diz-se
que um objeto é uma instância de uma
classe.

21
Classes e objetos
 Importante: uma classe é uma abstração
das características relevantes de um grupo
de coisas do mundo real.
 Na maioria das vezes, um grupo de objetos
do mundo real é muito complexo para que
todas suas características sejam
representadas em uma classe.

22
Objetos como abstrações
 Uma abstração é uma representação das
características relevantes de um conceito do
mundo real para um determinado problema.
 Carro (para uma transportadora de cargas)
 Carro (para uma fábrica de automóveis)
 Carro (para um colecionador)
 Carro (para uma empresa de kart)
 Carro (para um mecânico)

23
Classe X Objeto
 Classes são definições estáticas, que
possibilitam o entendimento de um grupo de
objetos.
 Objetos são abstrações de entidades que
existem no mundo real.
 CUIDADO: estes dois termos muitas vezes
são usados indistintamente.

24
Mensagens
 Para que um objeto realize alguma tarefa,
deve haver um estímulo enviado a este
objeto.
 Pense em um objeto como uma entidade ativa
que representa uma abstração de algo do
mundo real
 Então faz sentido dizer que tal objeto pode
responder a estímulos a ele enviados
 Assim como faz sentido dizer que seres
vivos reagem a estímulos que eles
recebem.
25
Mensagens
 Independentemente da origem do estímulo,
quando ele ocorre, diz-se que o objeto em
questão está recebendo uma mensagem.
 Uma mensagem é uma requisição enviada
de um objeto a outro para que este último
realize alguma operação.

26
Mensagens
 Objetos de um sistema trocam mensagens
 isto significa que estes objetos estão enviando
mensagens uns aos outros com o objetivo de
realizar alguma tarefa dentro do sistema no
qual eles estão inseridos.

27
Abstração
 Uma abstração é qualquer modelo que inclui
os aspectos relevantes de alguma coisa, ao
mesmo tempo em que ignora os menos
importantes.

28
Abstração
 Abstração depende do observador.

29
 Abstração na orientação a objetos
 A orientação a objetos faz uso intenso de
abstrações.
 Os princípios da orientação a objetos podem
ser vistos como aplicações do Princípio da
Abstração.
 Princípios:
 Encapsulamento
 Polimorfirmo
 Herança

30
Abstração na orientação a objetos

31
Encapsulamento
 Objetos possuem comportamento.
 O termo comportamento diz respeito a que
operações são realizadas por um objeto e
também de que modo estas operações são
executadas.

32
Encapsulamento
 O encapsulamento é uma forma de restringir o acesso
ao comportamento interno de um objeto.
 Um objeto que precise da colaboração de outro
objeto para realizar alguma tarefa simplesmente
envia uma mensagem a este último.
 Os atributos de uma classe somente são acessíveis
pelos métodos da própria classe
 Outras classes só podem acessar os atributos

através de métodos públicos.

 O encapsulamento garante que a classe seja uma
caixinha preta para o usuário; não sabe o que há
dentro do objeto, sabe apenas que ele serve e quais
os métodos disponíveis para manipulação.
33
Encapsulamento
 Na terminologia da orientação a objetos, diz-
se que um objeto possui uma interface.
 A interface de um objeto é o que ele conhece
e o que ele sabe fazer, sem descrever como
o objeto conhece ou faz.
 A interface de um objeto define os serviços
que ele pode realizar e conseqüentemente as
mensagens que ele recebe.

34
Encapsulamento
 Uma interface pode
ter várias formas de
implementação.
 Mas, pelo Princípio
do Encapsulamento,
a implementação de
um objeto
requisitado não
importa para um
objeto requisitante.
35
 Polimorfismo
 Do grego “muitas
formas” Homem Mulher

 É a habilidade de
objetos de classes
diferentes
responderem a
mesma mensagem
de diferentes
maneiras.
Televisor (Jogo de futebol?!)
36
Polimorfismo
 Vários comportamentos que um mesmo
método pode assumir.
 É a possibilidade de dar a um mesmo
método, por exemplo, variadas formas, de
acordo com o momento em que deseje
utilizá-lo.
 Por exemplo, a operação consultarSaldo()
pode atuar de forma diferente nas classes
ContaPoupança e ContaCorrente.

37
 Polimorfismo

 Em uma linguagem orientada a objetos, C++:

for(i = 0; i < poligonos.tamanho(); i++)

poligonos[i].desenhar();

38
 Herança
 A herança pode ser vista como um nível de
abstração acima da encontrada entre classes e
objetos.
 Na herança, classes semelhantes são
agrupadas em hierarquias.
 Cada nível de uma hierarquia pode ser visto
como um nível de abstração.
 Cada classe em um nível da hierarquia herda
as características das classes nos níveis
acima (podendo acrescentar suas próprias
características).
39
Herança
 A herança facilita o
compartilhamento
de atributos e
comportamentos
(operações) entre
classes
semelhantes.

40
Herança

41
Histórico das Linguagens O.O.
• Simula 67(introduz conceitos de classes e
objetos) [1967];
• Smalltalk 1972, 74, 76, 78, 80;
• Ada 1983 (uso militar-EUA), Eilffel 1984
(características formais), Object pascal 1986;
• C++ 1.0 1980, C++ 2.0 1989, C++ 3.0 1990
(linguagem híbrida, derivada da linguagem C);
• JAVA 1995(Linguagem puramente orientada a
objetos);
• 1995 --> Várias linguagens agregando conceitos 42

OO
Evolução histórica da
modelagem de sistemas
43
Métodos de Desenvolvimento OO
 Métodos OO começaram a aparecer entre meados
de 70 e início dos anos 80.
 Shaler & Mellor (1989 – 1990)
 CRC (Classe-Responsabilidade-Colaborador) 1989 -
Wirfs-Brock
– Designing Object-Oriented Software, Prentice-
Hall, 1990.
 Modelos OOA e OOD (1991) - Coad/Yourdon
– Análise Baseada em Objetos, Editora Campus,
1991
– Projeto Baseado em Objetos, Editora Campus,
1991
– OOAD – Object-Oriented Analysis and Design 44
 Métodos de Desenvolvimento OO
 OMT (Object Modeling Technique) (1991) – James
Rumbaugh
– Modelagem Baseada em Objetos - Editora
Campus, 1991
 BOOCH (1991) – Grady Booch
– Object-Oriented Design with Applications,
Benjamin Cummings, 1991
 OBJECTORY OOSE (1992) – Ivar Jacobson
– Object-Oriented Software Engineering, Addison-
Wesley
 Fusion (Booch, OMT, CRC, Métodos Formais) 1994 -
Colemann
45
A Linguagem de Modelagem
Unificada (UML)
46
Necessidade de um padrão
 Percebeu-se a necessidade de um padrão que
fosse aceito e utilizado amplamente, para que
qualquer sistema fosse modelado com:
 com consistência
 fácil de se comunicar com outras aplicações
 simples de ser atualizado e compreensível
 Surge a UML (Unified Modeling Language) em
1996 como a melhor candidata para ser
linguagem “unificadora” de notações.

47
UML
 Em 1997, a UML é aprovada como padrão pelo
OMG (Object Management Group) (www.omg.org).
 É uma linguagem ainda em desenvolvimento.
 Linguagem gráfica padronizada para
representação de objetos, classes, diagramas,
etc...;
 Criada por 3 grandes desenvolvedores (os “três
amigos”)
 James Rumbaugh (OMT)
 Ivar Jacobson (OOSE, Objectory)
Grady Booch (Booch Method)
48

 Última versão da UML, Set 2001
Histórico UML 1.4

UML 1.3
Aceitação OMG, Nov de 1997

Interação
Submissão final para a OMG, Set de 97 UML 1.1
com a
comunidade Primeira submissão para a OMG, Jan de 97 UML 1.0

UML 0.9

Unified Method 0.8

Outros métodos Método de Booch OMT OOSE

49
Características da UML
 UML é...
 uma linguagem visual que utiliza conceitos da OO.
 independente de linguagem de programação.
 independente de processo de desenvolvimento.
 UML não é...
 uma linguagem programação nem metodologia.
 um processo de desenvolvimento de software.
 UML é uma linguagem de modelagem para:
 Visualização
 Especificação
 Construção
 Documentação
 Comunicação
50
Diagramas da UML
 Um processo de desenvolvimento que utilize a
UML como linguagem de modelagem envolve
a criação de diversos documentos.
 podem ser textuais ou gráficos.
 são denominados artefatos de software.
 São os artefatos que compõem as visões do
sistema.

 Os artefatos gráficos produzidos durante o

desenvolvimento de um sistema de software
são definidos através da utilização dos
diagramas da UML.
51
Diagramas da UML

52
 Visão Estática
Diagramas Visão Dinâmica

Seqüência Classe Caso de Uso

Colaboração
Objeto

Modelos
Estado
Componente

Implantação
Atividade
53
Visões
 Modelar um sistema complexo exige que
criemos um conjunto de visões do modelo
 As visões UML podem ser divididas em três
grupos:
 Estrutural
 Comportamental
 Arquitetural

54
Visões
 Estrutural
 Diagrama de Classes
 Diagrama de Objetos
 Comportamental
 Diagrama de Casos de Uso
 Diagrama de Seqüência
 Diagrama de Colaboração
 Diagrama de Estados
 Diagrama de Atividades
55
Visões
 Arquitetural
 Diagrama de Componentes
 Diagrama de Implantação

56
Visão Estrutural
 Diagrama de Classes
 Dá uma visão estática do sistema
 Exibe um conjunto de classes, interfaces e
seus relacionamentos
 As classes especificam a estrutura e o
comportamento dos objetos (que são
instâncias de classes)

57
 Diagrama de Classe

Cliente

1
possui

0..*
refere a Veículo Alugado
Contrato de Aluguel
0..1
0..*
possui Tipos de Veículos
1

Companhia de Caminhão Carro Sport Carro de Passeio

Aluguel de Veículos

58
Visão Estrutural
 Diagrama de Objetos
 Exibe uma cenário estático
 Traz um conjunto de objetos e seus
relacionamentos
 Representam instâncias estáticas de
elementos dos diagramas de classes

59
 Diagrama de Objetos

Marcelo: Cliente
Nome =: "MarceloTurine"
Idade = 28
CPF = 94168912-24

2478: Contrato de Aluguel 2479: Contrato de Aluguel

Num_Contrato = 2478 Num_Contrato = 2479
Veículo ="Corsa" Veículo = " Santana"
60
Visão Comportamental
 Diagrama de Casos de Uso
 Organiza e modela o comportamento do
sistema
 Mostra um conjunto de atores e casos de uso
Movimentar <<include>>
Gerar Histórico
Conta Corrente

Consultar Aplicar em
Conta Corrente Pré Fixados

Cliente 61
Visão Comportamental
 Diagrama de Seqüência
 Diagrama de interação que enfatiza o
ordenamento das mensagens
 Diagrama de Colaboração
 Diagrama de interação que enfatiza a
organização estrutural dos objetos que trocam
mensagens

62
Diagrama de Seqüência
: Computador : Servidor de : Impressora : Fila
Impressão

Imprimir (arquivo) [Impressora Livre]

Imprimir (arquivo)

[Impressora Ocupada]
Imprimir (arquivo)

63
Diagrama de Colaboração

: Computador
[Impressora Ocupada] : Fila
1.2: Armazenar (arq)

1: Imprimir ( arq)

[Impressora Livre]
: Servidor de 1.1: Imprimir (arq) : Impressora
Impressão

64
Visão Comportamental
 Diagrama de Estados
 Enfatiza o comportamento de um objeto de
acordo com um conjunto de eventos
 Mostra uma máquina contendo estados,
transições, eventos e atividades
 Nestes diagramas são modelados tanto os
estados pelos quais um objeto pode passar
como os eventos provocam mudanças de
estado
 Usados para modelar o comportamento de
objetos (com comportamento complexo)
65
Diagrama de Estados

No Térreo subir (andar) Subindo

Chegar no térreo
Chegar no andar subir (andar)

Indo para o
térreo
Descendo Chegar no andar Parado

descer (andar)

tempo de espera
66
Visão Comportamental
 Diagrama de Atividades
 Enfatiza o fluxo de uma atividade a outra no
sistema
 São semelhantes aos antigos fluxogramas
 Muito usados para modelar atividades
concorrentes

67
Visão Arquitetural
 Diagrama de Componentes
 Ilustra a implementação estática do sistema
 Mostra um conjunto de componentes e seus
relacionamentos
 Exemplos de componentes são documentos,
executáveis e tabelas de bancos de dados

68
Diagrama de Componentes

Gerenciador de Gráficos Gerenciador de

Comunicação Banco de
Dados
Comm.dll Graficos.dll Db.dll

Aplicação

App.exe

69
Visão Arquitetural
 Diagrama de Implantação
 Modela o ambiente em que o sistema será
executado, ou seja, seus aspectos físicos:
 São compostos por nós e relacionamentos de
comunicação
 Um nó pode ser um computador, uma rede,
etc

70
Diagrama de Implantação

ClienteA :
Pentium 200 <<TCP/IP>>
MMX
Servidor de Servidor de
Aplicação : SQL <<TCP/IP>> Banco de
HP/UX Dados :
ClienteB : ORACLE
Pentium 200
<<TCP/IP>>
MMX

71
Visões da UML
 mostram diferentes aspectos do sistema que
está sendo modelado
 não é um gráfico, mas uma abstração
 servem de ligação entre a linguagem de
modelagem e o método de desenvolvimento
 A UML prevê 5 visões do software
 Cada visão possui diferentes diagramas que
podem descrevê-la
 Cada diagrama possui diferentes elementos
para representar informação

72
Visões da UML

Visão de Visão de
Projeto Implementação
Visão de
Casos de Uso
Visão de Visão de
Processos Implantação

73
Visão de Casos de Uso
 Descreve as funcionalidades do sistema que
são externamente observáveis.
 Não há preocupação de descrever como
cada processo é internamente.
 Seu conteúdo é base do desenvolvimento
das outras visões do sistema.
 Diagramas utilizados:
 Diagramas de Casos de Uso
 Diagramas de Atividades
74
Visão de Projeto
 Descreve como a funcionalidade do sistema será
implementada.
 especifica a estrutura estática do sistema e define
as colaborações dinâmicas
 propriedades como persistência, interfaces e

as estruturas de classes, a interação entre os

objetos na execução do sistema
 Estrutura Estática
 Diagramas de Classes e de Objetos

 Modelagem Dinâmica
 Diagramas de Estados, Seqüência,

Colaboração e Atividades.
75
Visão de Processos
 Trata a divisão do sistema em processos e
processadores.
 Aborda aspectos de concorrência e
sincronização do sistema.
 deverá mostrar como se dá a comunicação e
a concorrência entre as threads.
 Diagramas:
 Diagramas de estado, seqüência, colaboração
e atividade, e pelos diagramas de
implementação.

76
Visão de Implementação
 É uma descrição da implementação dos
módulos e suas dependências.
 É principalmente executado por
desenvolvedores
 Diagramas
 Diagrama de Componentes.

77
Visão de Implantaçã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
 Diagramas:
 Diagrama de Execução ou Implantação

78