An Liseeprojetodesistemasorientadosaobjetos-Notasdeaula

Análise e projeto de
sistemas com
orientação a objetos
Notas de aula
Elaboração:
Prof.: José Luiz Rodrigues Junior
jluizrj@aol.com
Ciência da computação – Análise e projeto de sistemas com orientação a objetos
5º Semestre - Professor: José Luiz Rodrigues Junior
Novembro de 11
2
Índice
1 – ORIENTAÇÃO A OBJETOS....................................................................................................3
1.1 – Alavancas da orientação a objetos.....................................................................3
1.2 – Benefícios da OO...............................................................................................3
2 – DEFINIÇÕES ....................................................................................................................5
2.1 - Objeto.................................................................................................................5
ESTADO.................................................................................................................6
COMPORTAMENTO.........................................................................................6
2.2 - Mensagem..........................................................................................................6
2.3 - Operações .........................................................................................................8
2.4 – Método ..............................................................................................................8
2.5 - Herança ............................................................................................................8
2.6 – Polimorfismo.....................................................................................................9
3 – MODELO DE OBJETOS......................................................................................................10
3.1 - Abstração.........................................................................................................10
3.2 - Encapsulamento............................................................................................10
.................................................................................................................................11
3.3 – Modularidade...................................................................................................11
3.4 – Hierarquia.......................................................................................................12
3.5 - Benefícios do modelo de objetos......................................................................12
4 – CLASSES.......................................................................................................................14
4.1 – Definição ........................................................................................................14
4.2 – Exemplos de classe:..........................................................................................14
.................................................................................................................................15
.................................................................................................................................15
................................................................................................................................15
4.3 – Classes e visões...............................................................................................15
.................................................................................................................................16
4.4 - Classes – Classificação e instanciação.............................................................17
4.5 – Classes – Generalização / Especialização........................................................17
..............................................................................................................................17
4.5.1 – Considerações............................................................................................18
4.6 - Herança.............................................................................................................18
4.7 – Composição por agregação..............................................................................19
4.8 – Composição......................................................................................................19
4.9 – Classes abstratas.............................................................................................20
4.10 – Relacionamentos ............................................................................................21
4.11 – Polimorfismo..................................................................................................21
5 – MÉTODOS PARA ANÁLISE COM ORIENTAÇÃO A OBJETOS.........................................................23
5.1 – O método BOOCH............................................................................................23
5.2 – O método OMT (Object Modeling Techinique)................................................24
5.3 – O método OOSE (Object-Oriented Software Engeneering)..............................24
6 – UML – UNIFIED MODELING LANGUAGE..........................................................................25
7 – VISÕES EM UML..........................................................................................................25
8 – DIAGRAMAS DA UML....................................................................................................27
8.1 – Diagrama de casos de uso ...............................................................................28
8.1.1 – Simbologia para diagramas de casos de uso...............................................29
..............................................................................................................................29
8.1.2 – Interações em casos de uso.........................................................................29

8.2 – Diagrama de classes.........................................................................................31
8.2.1 – Simbologia.................................................................................................31
8.2.2 – Classes e domínio do problema ................................................................32
8.2.3 – Relacionamento entre classes.....................................................................32
8.2.3.1 – Cardinalidade / Multiplicidade............................................................34
8.3 – Diagrama de sequência ...................................................................................35
8.3.1 - Simbologia..................................................................................................35
8.4 – Diagrama de colaboração................................................................................39
8.5 – Diagrama de Atividades..................................................................................39
8.5.1 - Simbologia..................................................................................................40
8.5.2 - Raias...........................................................................................................41
.................................................................................................................................41
8.6 – Diagrama de estados........................................................................................42
8.6.1 - Simbologia ................................................................................................42
8.6.2 - Evento.........................................................................................................42
.................................................................................................................................43
8.6.3 – Transição....................................................................................................44
8.7 – Diagrama de componentes ..............................................................................44
................................................................................................................................46
8.8 – Diagrama de implantação (Ou disponibilidade)..............................................47
9 – BIBLIOGRAFIA................................................................................................................48
2
1 – Orientação a objetos
O termo Orientação a Objetos significa organizar o mundo real

como uma coleção de objetos.
Dos objetos nos interessa a sua Estrutura de Dados e um
Conjunto de Operações (Métodos).
Os objetos, a sua estrutura de dados e o conjunto de operações
são selecionados de acordo com objetivos bem estabelecidos.
Ao modelar uma empresa, o analista deve identificar seus tipos
de objetos, seus eventos, as operações (métodos) que levam esses
objetos a comportar-se de uma certa forma, e as regras que governam
essas operações. Os sistemas devem ser visualizados como uma
coleção de objetos e não como um conjunto de programas.
A Orientação a Objetos não é um conceito novo. Já era utilizado,
em pelo menos três áreas, há duas décadas. Permite maior velocidade
de Desenvolvimento.
Linguagens de Programação com orientação a objetos:
Simula
Smalltalk
Objective C
C++
JAVA
1.1 – Alavancas da orientação a objetos

Evolução Tecnológica
Distribuição de Processamento
Tecnologia Cliente-Servidor
Internet
Java
Aplicações WEB
1.2 – Benefícios da OO
Reaproveitamento
Estabilidade
3
Projetista pensa em termos de comportamento dos

objetos e não em detalhes de baixo nível
Construção de objetos cada vez mais complexos
Confiabilidade
Verificação de Precisão - testes
Desenvolvimento Acelerado
Integridade
Programação Facilitada
Manutenção Facilitada
Ciclo de Vida Dinâmico
Refinamento Durante a Construção
Modelagem Mais Realista
Melhor Comunicação entre Profissionais de Sistema e
Clientes
Interoperabilidade
Processamento Cliente-Servidor
Processamento Distribuído e em Paralelo
Bibliotecas de Classes Industrializadas e Corporativas
4
Análise e projeto de sistemas orientados a

objetos
2 – Definições
2.1 - Objeto
Um objeto existe no mundo real e é um elemento que podemos

manipular, acompanhar seu comportamento, criar, destruir, etc.
Existem também objetos que não encontramos no mundo real, mas que
podem ser derivados da estrutura de outros objetos do mundo real.
Todo objeto é uma entidade concreta, apesar de sua concepção ser
abstrata. Pode-se também definir um objeto da seguinte maneira:
“um objeto é uma abstração de um conjunto de coisas do

mundo real, sendo que: todas as coisas do mundo real em um
conjunto - as instâncias - têm as mesmas características. Todas
as instâncias são sujeitas e em conformidade às mesmas
regras”
“...um objeto representa uma entidade, item ou unidade
individual, identificável, sendo real ou abstrato, com regras
bem definidas no domínio do problema."
Em processamento de dados, um objeto tenta unir o que até

então era tratado de forma separada : DADOS e FUNÇÕES .
Os objetos são agrupamentos de características e ações
pertencentes a uma entidade. Suas características são representadas
através dos atributos e suas ações são representadas pelos métodos
que ela venha a possuir. O conjunto de atributos e métodos é que
compõem um objeto.
Exemplos de objetos:
Coisas tangíveis : Mesa, Cadeira, Pessoa, empresa, País,
Etc..
Incidentes : Qualquer evento ou ocorrência (Copa
do Mundo)
5
Interações : Transações (Caixa eletrônico)
Todo objeto possui três características básicas:

ESTADO
Considera-se o estado de um objeto os valores dos
atributos e o status das operações que o objeto
executou.
COMPORTAMENTO
As operações, existentes nos métodos, definem o
comportamento do objeto, que é a forma como um
objeto age e reage em termos de mudanças de
estado e respostas às operações que sabe executar.
Pode-se definir um objeto como abaixo:
IDENTIDADE
Identidade é a propriedade de um objeto que o
distingue de todos os demais objetos. Um
identificador é anexado ao objeto no momento da
sua criação e permanece com ele por toda sua
existência, sendo que nenhum outro objeto poderá
possuir identidade semelhante.
2.2 - Mensagem
Um objeto não existe isoladamente. Ele pode interagir com

outros objetos, atuando sobre estes, ou sofrendo ação dos mesmos.
Para que os objetos possam se comunicar, ou qualquer outra interface
possa se comunicar com um objeto, é necessário que exista um tipo de
protocolo para que possam se entender. Dá-se a essa comunicação o
nome de mensagem. Toda mensagem deve ser composta pelos
seguintes itens:
Identificador
Nome do objeto que será alvo da mensagem.
6
Método
Nome do método que se deseja executar no objeto
alvo.
Argumentos
Informações suplementares para que o método
possa ser excutado.
7
2.3 - Operações
Uma operação pode ser descrita como sendo um serviço

ou comportamento resultante de um procedimento algorítmico. Existe
uma diferença entre operação e método: Uma operação é algo
invocado por um objeto, enquanto método é o corpo do procedimento.
Existem quatro tipos de operações que podem ser realizadas sobre um
objeto:
Construtoras
Geração de um novo Objeto da Classe (instanciação)
Seletoras
Recuperação do conteúdo dos atributos de um Objeto, sem
alterá-los
Modificadoras
Alteração do valor dos atributos ou estado de um Objeto
Destrutoras
Eliminação de um objeto existente
2.4 – Método
Conjunto de instruções associado com a operação de uma

classe, propiciando comportamento aos objetos da Classe.
Invocado somente por meio de passagem de mensagens
por:
Objetos de outras Classes
Interface de usuário
Lógica do programa
2.5 - Herança
É o compartilhamento de atributos e operações entre

objetos situados em diferentes níveis hierárquicos. Como o
8
assunto é complexo, ele será tratado com mais

propriedade em capítulo à parte.
2.6 – Polimorfismo
Significa que diferentes tipos de objetos podem responder

a uma mesma mensagem de maneiras diferentes. Pode-se
declarar funções e procedimentos com os mesmos nomes,
enquanto suas chamadas possam a ser distintas pelos
seus parâmetros de retorno, consistindo do número dos
seus argumentos e dos seus tipos de valores de retorno.
9
3 – Modelo de objetos
Diferentes metodologias permitem diferentes abordagens para a
resolução de um problema. Em orientação a objetos, existe o conceito
de “modelo de objetos” que é composto de 4 elementos básicos:
3.1 - Abstração
Denota as características essenciais de um objeto que o
distinguem de todos os outros tipos de objetos e portanto
definem nitidamente os limites conceituais relativos à
perspectiva do observador. Descreve as características
visíveis do objeto. Tem seu foco no comportamento
observável do objeto. Não descreve, entretanto:
A sua implementação
O seu funcionamento
3.2 - Encapsulamento
É o processo de identificação dos elementos de uma
abstração que constituem sua estrutura e comportamento.
Constitui em esconder todos os detalhes de um objeto que
não contribuem para suas características essenciais.
É uma técnica utilizada para proteger informações onde o
acesso aos dados do objeto é feito através da chamada a
uma operação da sua interface.
Benefícios:
Segurança
Protege os atributos dos objetos de terem
seus valores corrompidos por outros objetos.
Independência
“Escondendo” seus atributos, um objeto
protege outros objetos de complicações de
dependência de sua estrutura interna.
10
O encapsulamento esconde os detalhes de implementação de um

objeto
3.3 – Modularidade
A modularidade consiste na divisão do sistema em

componentes individuais fazendo com que o problema
apresente maior clareza e compreensão, além de
identificar os limites do sistema e dos seus programas.
Uma outra definição de modularidade é :
11
“Modularidade é a propriedade de um sistema de ser

decomposto em um conjunto de módulos coesivos e
relacionalmente desprendidos.”
3.4 – Hierarquia
Um grupo de abstrações frequentemente forma uma
hierarquia e com a identificação dessas hierarquias no
projeto, pode-se simplificar o entendimento do problema.
Pode-se definir hierarquia como segue:
“Hierarquia é uma graduação ou ordenamento de

abstrações “
3.5 - Benefícios do modelo de objetos

É adequado para sistemas que pretendem evoluir com o
tempo, pois sua estrutura permite que se mude a
implementação interna de um objeto sem ter que mudar
todo o código que se situa acima deste.
É um modelo maleável, o que permite a inserção de novas
características.
12
Princípios como “esconder informações” e “modularidade”

permitem facilidade em sistemas que possuem
manutenção constante.
13
4 – Classes
4.1 – Definição
Todos os objetos estão armazenados em estruturas que

identificam os seus atributos e os seus métodos.
Analogamente às tabelas, dos bancos de dados relacionais,
onde os comandos DDL (Em SQL) permitem a criação de
sua estrutura, as classes, em orientação a objetos,
propiciam a montagem da estrutura dos objetos que a
comporão.
As classes são estruturas genéricas de onde os objetos
podem derivar. Cada objeto é uma linha de vida à parte e
cada um possui um estado específico, sendo que cada
objeto é diferente do outro (Em seu conteúdo e estado)
mesmo que a sua interface seja a mesma.
“Uma classe é um grupo de objetos que compartilham

uma estrutura comum e um comportamento comum”
4.2 – Exemplos de classe:

Existem vários tipos de objetos, portanto existem vários
tipos de classes:
14
Graficamente, podemos representar uma classe da

seguinte forma:
CONTA
CONTA Classe
Titular
Titular
Número
Número
Saldo Atributos
Saldo
Depósito( )
Saque( ) Métodos
Transferância( )
- Todos os objetos são instâncias de uma classe.

- Classe é o que se projeta e programa
- Objeto é o que se cria durante o processamento
4.3 – Classes e visões
A interface de uma classe provê a visão externa, e

portanto, enfatiza a abstração enquanto esconde sua
estrutura e segredos de seu comportamento.
A implementação de uma classe é sua visão interna, que

engloba os segredos de seu comportamento.
A interface de uma classe divide-se em:
Pública (Representada pelo símbolo “+”)
Uma declaração que forma parte da interface
de uma classe e é visível para todos os
clientes que são habilitados para isto;
Protegida (Representada pelo símbolo “#”
15

de uma classe, mas não é visível para
quaisquer outras classes, exceto suas
subclasses;
Privada (Representada pelo símbolo “-”)
de uma classe, mas não é visível para
quaisquer outras classes.
16
4.4 - Classes – Classificação e instanciação
Classificação
É a operação que divide em uma ou mais categorias
(classes) indivíduos dentro de um domínio;
Instanciação
É a operação que evidencia um indivíduo (Objeto)
que pertence a uma categoria.
São operações opostas. Quando se une vários
indivíduos em uma categoria, é uma classificação,
mas quando se pega um único indivíduo da
categoria, é uma instanciação.
4.5 – Classes – Generalização / Especialização

Generalização
Ato de definir-se uma Classe (supertipo) que irá
conter as características e o comportamento que
outras Classes possuem em comum;
Especialização
Ato de definir-se uma Classe que além de herdar as
características e o comportamento do Supertipo
ainda possui outras características que são sua
especialidade (somente ela tem) e, portanto, os
demais subtipos não possuem
17
E
G s
e p
n e
e c
r i
a a
l l
i i
z z
a a
ç ç
ã ã
o o
4.5.1 – Considerações
Uma Classe derivada herda a estrutura de dados e
métodos de sua classe “base”, mas pode
seletivamente:
- adicionar novos métodos;
- estender a estrutura de dados;
- redefinir a implementação de métodos
já existentes.
Uma Classe “base” propicia a funcionalidade que é
comum a todas as suas classes derivadas, enquanto
que uma classe derivada proporciona a
funcionalidade adicional que especializa seu
comportamento.
A Generalização é uma noção conceitual. Herança é
a implementação de uma generalização.
4.6 - Herança
Herança é o compartilhamento de atributos e operações
entre classes com base em um relacionamento
hierárquico. Cada subclasse herda todas as propriedades
da superclasse e acrescenta suas próprias e exclusivas
características, permitindo assim, a reutilização de
especificações comuns.
18
4.7 – Composição por agregação
Propriedade de uma Classe formar suas instâncias a partir

da reunião das características e do comportamento de
outras instâncias da mesma Classe ou de Classes
diferentes, sendo que os componentes têm existência
independente em relação ao composto, ou seja, a
eliminação do composto não afeta a existência dos
elementos que o criaram.
É uma associação entre um objeto e outros objetos que
fizerem parte dele.
PEDIDO
PRODUTO CLIENTE
Se A agrega B então B é parte de A; mas seus tempos de

vida são independentes.
4.8 – Composição
Propriedade de uma Classe formar suas instâncias a partir
da reunião das características e do comportamento de
outras instâncias da mesma Classe ou de Classes
diferentes, sendo que os componentes não têm existência
indepedente em relação ao composto, ou seja, a
eliminação do composto afeta a existência dos elementos
que o criaram.
19
LÂMPADA
BASE BULBO FILAMENTO
Se A é composto de B então A controla o tempo de

vida de B.
4.9 – Classes abstratas
São Classes utilizadas apenas para organizar a estrutura,

já que ela não será instanciada. Ela define um conjunto
mínimo de atributos e métodos virtuais, que deverão ser
implementados pelas SubClasses.
Uma Classe abstrata sugere uma técnica de “design” e
muitas vezes aumenta a clareza da modelagem.
CLASSE
ALUNO ABSTRATA
CLASSES
GRADUAÇÃO CONCRETAS PÓS
Uma Classe Abstrata é uma classe que:

Provê organização;
Não possui instâncias;
Possui uma ou mais operações abstratas;
Possui subclasses que implementam estas
operações.
Uma operação abstrata só determina a existência de
um comportamento não definindo uma
implementação.
20
4.10 – Relacionamentos
Um relacionamento modela uma conexão física ou

conceitual entre objetos. Os relacionamentos são sempre
bidirecionais e permitem uma visualização do número de
objetos que podem ser associados.
Todo relacionamento deve possuir um verbo que o
identifica.
1
CLIENTE FAZ * PEDIDO
Relacionamentos possíveis:
1 PARTICIPA 1
GERENTE PROJETO EXATAMENTE 1
1 PARTICIPA 0...1
EMPREGADO PROJETO OPCIONAL 0 OU 1
1 ALOCA 1...* OPCIONAL 1 OU

DEPTO. EMPREGADO
MUITOS
1
CLIENTE FAZ * PEDIDO
MAIOR OU IGUAL A
ZERO
1 EMPRESTA 0...5 NUMÉRICAMENTE

ALUNO LIVRO
ESPECIFICADO
4.11 – Polimorfismo
Pode-se declarar funções e procedimentos com os mesmos
nomes, enquanto suas chamadas possam a ser distintas
pelos seus parâmetros de retorno, consistindo do número
dos seus argumentos e dos seus tipos de valores de
retorno.
No contexto OO, Polimorfismo significa que diferentes tipos
de Objetos podem responder a uma mesma mensagem de
maneiras diferentes.
21
Aplicação financeira
CalcularSaldo(...)
Renda fixa Poupança
CalcularSaldo(...) CalcularSaldo(...)
Pode-se declarar funções e procedimentos com os mesmos

nomes, enquanto suas chamadas possam a ser distintas
pelos seus parâmetros de retorno, consistindo do número
dos seus argumentos e dos seus tipos de valores de
retorno.
22
5 – Métodos para análise com orientação a

objetos
A Análise Orientada a Objeto remonta a década de 80, com modelos

que estendiam o Modelo Entidade Relacionamento.
Do crescimento dos métodos de BOOCH e OMT, independentemente, e
o reconhecimento pela classe usuária mundial, nasceu uma tentativa de
padronização dos métodos de AOO, por Grady Booch e James Rumbaugh -
criação da Rational Corporation (1994). Ivar Jacobson juntou-se a equipe em
1995, integrando seu método OOSE.
Receberam, então, a incumbência de c
riar uma linguagem de modelagem unificada que tratasse assuntos de escala
inerentes a sistemas complexos e de missão crítica, que se tornasse poderosa
o suficiente para modelar qualquer tipo de aplicação, de tempo real, cliente
servidor, ou outros tipos de software padrão.
5.1 – O método BOOCH
O método de BOOCH consistia no emprego de técnicas de

desenho orientado a objeto, apesar de ter sido estendido
para contemplar também a AOO.
Descreve um objeto como sendo um modelo do mundo
real que consiste de dados e habilidades para o tratamento
desses dados.
Argumenta que o desenho estruturado funciona bem com
linguagem de programação estruturada, e que o enfoque
estruturado direciona a concentração dos esforços na
lógica do módulo, dando pouca ênfase no uso dos dados.
O desenho orientado a objeto é organizado via abstrações
algoritmicas de forma parecida à programação orientada a
objeto.
Estreita relação entre desenho e programação permite
tomar decisões de negócio antes da criação do código.
23
5.2 – O método OMT (Object Modeling

Techinique)
Desenvolvido pela GE Corporation, conhecido como

Técnica de Modelagem de Objetos. Baseado na
modelagem semântica dos dados, derivado dos modelos
estruturados. Suporta conceitos como:
Atributos e Relacionamentos;
Composição, Agregação e Herança.
O seu ponto forte é a notação utilizada e o enfoque
relativamente conservador.
Um problema, em sua estrutura, é a falta de notação para
representar a passagem de mensagens entre objetos.
5.3 – O método OOSE (Object-Oriented Software

Engeneering)
Foco em Casos de Uso e a categorização de pessoas e

equipamentos.
Técnica baseada em modelos de requerimento e análise
que consistem em:
Conjunto de Casos de Uso;
Modelo de domínio do problema e
Interface do sistema.
O seu ponto forte é o método Objectory, que tem sido
adaptado para a engenharia de negócio.
Notação simplista usada para objetos de domínio.
24
6 – UML – Unified Modeling Language
A UML não é uma metodologia, é uma linguagem de modelagem

bem definida, expressiva, poderosa e aberta.
Aprovada pela OMG Object Management Group em 1997
A UML pode ser usada para:
Mostrar as fronteiras de um sistema e suas principais funções
(Atores e Casos de Uso);
- Ilustrar a realização de Casos de Uso com Diagramas de
Interação;
- Representar a estrutura estática de um sistema utilizando
Diagramas de Classe;
- Modelar o comportamento de objetos com Diagramas de
Transição de Estado;
- Revelar a arquitetura de implementação física com Diagramas
de Componente e de Implantação;
- Estender sua funcionalidade através de estereótipos.
7 – Visões em UML
As visões são usadas em UML para descrever os diferentes

aspectos do sistema sendo modelado. Uma visão é uma abstração do
sistema, formada por um conjunto de diagramas. A partir de um
conjunto de visões se chega a uma descrição completa do sistema a ser
construído.
Tipos de visões em UML:
Visão de Casos de Uso - mostra a funcionalidade do
sistema do ponto de vista externo. Casos de uso podem
ser descritos textualmente através de uma descrição do
Fluxo de Eventos e/ou visualmente através dos Diagramas
de Casos de Uso.
25
Visão Lógica - A visão lógica tem por objetivo descrever

como a funcionalidade do sistema será obtida. A visão de
casos de uso descreve o sistema do ponto de vista do
mundo externo ao sistema. A visão lógica descreve o
sistema do ponto de vista interno.
descreve a organização do sistema, seus módulos

principais, como eles se relacionam e suas
funcionalidades. A visão lógica envolve a estrutura estática
do sistema (módulos, classes, objetos e relacionamentos) e
também os aspectos dinâmicos (manifestados através de
mensagens entre objetos, eventos externos, etc). A
estrutura estática é descrita através de diagramas de
classes. O
modelamento dinâmico é feito através de diagramas de
sequência, diagramas de colaboração e diagramas de
estado.
Visão de Componentes - descreve a arquitetura física do
sistema, em termos de componentes de software
26
8 – Diagramas da UML
Para que as visões possam ser visualizadas graficamente, a UML

dispõe de vários tipos de diagramas :
1. Diagramas de casos de uso (casos + atores + relações)

2. Diagramas de seqüência (detalhamento - fase projeto)
3. Diagramas de colaboração (troca de mensagens entre
objetos)
4. Diagramas de classes (classes + responsabilidades --
atributos, relacionamentos, métodos, cenários)
5. Diagrama de atividades (ordenamento dos casos de uso)
6. Diagramas de estados (ciclos de vida, comportamentos)
7. Diagrama de componentes (grupo de objetos divididos em
nodos físicos)
·Visão de Implantação – mostra a alocação dos componentes de

software no equipamento alvo.
27
8.1 – Diagrama de casos de uso
A modelagem de um diagrama de casos de uso é uma

técnica usada para descrever e definir os requisitos
funcionais de um sistema. Eles são escritos em termos de
atores externos, casos de uso e o sistema modelado. Os
atores representam o papel de uma entidade externa ao
sistema como um usuário, um hardware, ou outro sistema
que interage com o sistema modelado. Os atores iniciam a
comunicação com o sistema através dos casos de uso,
onde o caso de uso representa uma sequência de ações
executadas pelo sistema e recebe do ator, que lhe utiliza,
dados tangíveis de um tipo ou formato já conhecido, e o
valor de resposta da execução de um caso de uso
(conteúdo) também já é de um tipo conhecido, tudo isso é
definido juntamente com o caso de uso através de texto de
documentação.
O objetivo final do sistema é oferecer a funcionalidade
descrita pelos casos de uso. Sendo assim, a visão dos
casos de uso é importante também na validação do
sistema.
Exemplo:
SISTEMA DE VENDAS
Dados do cliente para

Dados do pesquisa
atendimento EFETUAR
VENDA
Dados da
autorização
Operador de caixa Adm. Cartões
28
8.1.1 – Simbologia para diagramas de casos de uso
Caso de uso
ATOR
COMUNICAÇÃO
Rótulo
Interação bidirecional
Rótulo
Interação Unirecional
RELAÇÕES
<< USES >>
Uses - Passos comuns
<< EXTENDS >> Extends - Passos
Extends adicionais
- Passos adicionais
Generalização / Especialização
8.1.2 – Interações em casos de uso
Comunicação: um Ator comunica-se com o Caso de Uso.

Extensão: demonstra como o comportamento definido
para o primeiro caso pode ser inserido no comportamento
definido para o segundo. Sugere a existência de casos
adicionais e alternativos.
Generalização: um caso de uso é uma especialização de
outro, e herda características.
Uso ou inclusão: ocorre quando surge a divisão de um
caso de uso mais complexo, que inclui outros mais
simples, e a identificação de passos comuns, que podem
ser reutilizados por outros casos de uso.
O tipo de generalização <<uses>> é usado para

descrever o comportamento comum entre dois ou mais
Casos de uso.
29
O tipo de generalização <<extends>> é usado

para expressar comportamento opcional por um Caso de
uso.
30
8.2 – Diagrama de classes
No modelamento orientado a objetos, classes, objetos e

seus relacionamentos constitnuem os principais elementos
de modelamento.
Uma classe é a descrição de um conjunto de objetos
semelhantes – os objetos constituem instâncias de uma
classe.
Uma classe descreve as propriedades e o comportamento
dos objetos que ela define.
O diagrama de classes demonstra a estrutura estática das
classes de um sistema onde estas representam as "coisas"
que são gerenciadas pela aplicação modelada.
Classes podem se relacionar com outras através de
diversas maneiras:
- Associação (conectadas entre si).
- Composição (Uma classe é criada a partir de
outras classes existindo uma relação de
dependência entre elas).
- Composição por agregação ( Uma classe é criada
a partir de outras classes não existindo,
entretanto, uma relação de dependência entre
elas).
- Especialização / Generalização (Uma classe é
uma especialização de outra classe).
8.2.1 – Simbologia
31
CLASSE
NOME
ATRIBUTOS
MÉTODOS
Verbo
ASSOCIAÇÃO
GENERALIZAÇÃO / ESPECIALIZAÇÃO
COMPOSIÇÃO POR AGREGAÇÃO
COMPOSIÇÃO
8.2.2 – Classes e domínio do problema

Ao se modelar um sistema através de objetos é
natural que apareçam classes que descrevem conceitos e
situações no domínio do problema. Por exemplo, ao se
modelar um sistema de administração escolar, são usadas
classes como estudante, curso, currículo, professor e
matrícula, entre outras. Baseando-se em objetos e partindo
de classes no domínio do problema é possível se construir
sistemas que conseguem evoluir junto com os requisitos:
mesmo que os requisitos evoluam e que seja necessário
adicionar novas funcionalidades, o domínio do problema
(em geral) continua sendo o mesmo.
8.2.3 – Relacionamento entre classes

Num sistema, as classes podem ter diversos tipos de
relacionamentos entre si. Uma associação é o tipo mais
comum desses relacionamentos.
Uma associação é uma “conexão” bidirecional entre duas
classes.
Classes
Elementos de um relacionamento:
Relacionamento
Prédio Apartamento
1 possui
*
32
Cardinalidade
33
8.2.3.1 – Cardinalidade / Multiplicidade
A cardinalidade permite restringir o número

de elementos que podem se relacionar.
Cardinalidades possíveis:
N Exatamente N
0...1 0 ou 1
N...M Entre N e M (Incluindo os extremos)
* Zero ou Muitos
1... 1 ou muitos
*
Exemplo: supondo que país e cidade são classes

num sistema, um país está associado a uma cidade
que é a sua capital.
PAÍS CIDADE
Tem capital
É capital de
No relacionamento entre duas classes, cada

uma desempenha um papel específico. Esse papel,
sempre que possível, deve ser explicitado no
modelo. No exemplo anterior,
No exemplo anterior, Tem capital corresponde ao
papel da classe Pais e É capital de corresponde ao
papel da Cidade no mesmo relacionamento.
34
ALUNO DISCIPLINA
1 Está matriculado em 1...*
Exemplo: num sistema de administração escolar, um

aluno pode se inscrever em zero ou várias
disciplinas.
8.3 – Diagrama de sequência

Um diagrama de seqüência mostra os objetos participando
de uma interação arranjada em uma seqüência de tempo.
Uma interação é o comportametno que compreende um
conjunto de mensagens trocadas entre um conjunto de objetos
em determinado contexto para a realização de um propósito.
Interação = troca de mensagens entre objetos p/ realizar
alguma atividade.
O mais importante aspecto deste diagrama é que a partir

dele percebe-se a sequência de mensagens enviadas entre os
objetos.
Uma mensagem é a especificação de uma comunicação
entre objetos, a qual contém informações relacionadas ao que se
espera resultar dessa atividade.
8.3.1 - Simbologia
35
UM OBJETO:
OBJETO
XXXXXXXX
COMUNICAÇÃO
ESTEREÓTIPO
LINHA DE
VIDA
Um diagrama de seqüência tem duas dimensões:

A vertical que representa o tempo, e
A horizontal, que representa os diferentes objetos.
Um objeto é mostrado com uma linha pontilhada vertical
chamada de "linha da vida". A linha da vida representa a
existência do objeto em um tempo determinado.
As mensagens podem ser divididas em:
Simples= não descreve detalhes da mensagem por
não ser importante neste momento ou por não se
saber os pormenores da comunicação.
Síncrona = mensagem para chamada de operação,
a próxima mensagem só é executada quando esta
for concluída.
Assíncrona=serve para envio de mensagem sem
nenhuma espera, ou seja, a próxima mensagem
pode ser executada antes que esta termine.
Notação:
SIMPLES SÍNCRONA ASSÍNCRONA
36
Se o objeto é criado ou destruído durante o período de tempo

mostrado no diagrama, então a linha da vida começa e pára no
ponto apropriado; caso contrário ela vai desde o início até o fim
do diagrama.
Se o objeto é criado durante o diagrama, então a
mensagem que o cria é desenhada com a ponta da seta para o
símbolo de objeto.
Se o objeto é destruído durante o diagrama, então sua
destruição é marcada por um "X", ou na mensagem que causa a
destruição ou na mensagem final retornada pelo objeto
destruído.
37
Exemplo de diagrama de seqüência:
c:C liente :Agente p : Ass istente de

Viagem Planejamento
< <create>>
definir_Itinerário(i)
estabelecer_rota( )
rota
notificar( )
Os diagramas de seqüência podem ser usados de forma

genérica e como uma instância.
A forma genérica descreve todas as possíveis alternativas
em um cenário.
Um cenário é uma descrição de um evento específico.
Existem duas possibilidades de cenário:
Cenário primário: Que descreve as ações do evento
sem qualquer alusão a problemas que podem
ocorrer durante o processamento.
Cenário secundário: Que descreve uma situação que
não se aplica às regras do cenário primário.
Ex.: Um cenário de abertura de uma conta bancária

deveria descrever: uma abertura de conta bem sucedida, uma
abertura de conta não concedida por falta de crédito do cliente e
uma abertura de conta com um depósito imediato na conta.
Um diagrama de seqüência instanciado deveria mostrar somente
uma destas possibilidades.
38
8.4 – Diagrama de colaboração
O diagrama de colaboração não mostra o tempo como

uma dimensão separada, então a seqüência de mensagens deve
ser determinada usando-se números em seqüência.
Os diagramas de colaboração mostram os relacionamentos
entre os objetos.
Pode-se escolher entre utilizar o diagrama de colaboração
ou o diagrama de seqüência.
Se a ênfase do diagrama for o decorrer do tempo, é melhor
escolher o diagrama de seqüência.
Se a ênfase for o contexto do sistema, é melhor dar
prioridade ao diagrama de colaboração.
Exemplo:
8.5 – Diagrama de Atividades
São usados em situações onde todos ou a maioria dos

eventos representam a conclusão das ações geradas
internamente (isto é, fluxo de controle procedimental).
Normalmente descreve etapas seqüenciais (e possivelmente
concorrentes) em um processo computacional. Geralmente
utiliza-se esse tipo de diagrama para modelar fluxo de trabalho e
operações, no entanto é possível utilizá-lo também para modelar
o fluxo do sistema como um todo.
39
8.5.1 - Simbologia
INÍCIO DO DIAGRAMA
FIM DO DIAGRAMA
ATIVIDADE
DECISÃO
CONECTOR (MESMA
PÁGINA)
Exemplo de diagrama de atividade:
Selecionar local
Contratar arquiteto
Desenvolver plano
Orçar plano
Rejeitado
Aceito
Executar trabalho em outros

Executar trabalho no local
setores
Construir edifício
40
O exemplo de diagrama acima, mostra uma bifurcação. Quando

são modelados fluxos de trabalho em processos de negócios,
geralmente ocorrem fluxos concorrentes.
Nesses casos utiliza-se uma barra para a bifurcação e a união dos

fluxos paralelos de controle.
8.5.2 - Raias
Esse recurso é útil na modelagem de fluxo de
trabalho pois possibilita particionar em grupos os estados. Cada
grupo é chamado de raia sem semântica profunda, exceto por
representar alguma entidade do mundo real.
Num diagrama com raias, cada atividade pertence
exclusivamente a uma raia, mas as transições poderão cruzar as
raias.
Exemplo:
41
8.6 – Diagrama de estados

Um diagrama de estado representa o ciclo de vida de um
objeto. Para isso ele mostra os estados que um objeto pode ter e
como os eventos afetam estes estados.
Podem ser considerados eventos o recebimento de uma
mensagem, uma condição que se tornou verdadeira ou a
passagem de um período de tempo designado após um
determinado evento.
O objeto emite uma resposta a um estímulo(evento)
recebido.
Um estado é uma condição durante a vida de um objeto ou
uma interação durante a qual ele:
- Satisfaz alguma condição,
- Executa alguma ação,
- Espera algum evento.
8.6.1 - Simbologia
INÍCIO DO DIAGRAMA
FIM DO DIAGRAMA
ESTADO
DECISÃO
CONECTOR (MESMA
PÁGINA)
CONECTOR (PÁGINA
ANTERIOR/PRÓXIMA)
8.6.2 - Evento
Um evento é uma ocorrência que pode disparar uma

transição do estado. Cada nome de evento pode aparecer
no máximo uma vez em um único estado.
42
43
8.6.3 – Transição
Uma transição é representada por uma seta sólida
de um estado para outro, rotulada por uma cadeia de
transição.
Exemplo de diagrama de estados:
cancelamento de pedido solicitado
Cancelando Pedido
pedido enviado alteração de pedido solicitada
Registrando Pedido Alterando Pedido

pedido
cancelado
pedido requisitado
pedido para análise
requisitado
para análise
pedido será cancelado
Analisando Pedido
pedido para aprovação
pedido já pode ser
atendido Aprovando Pedido
pedido não pode ser

atendido no momento pedido será atendido
pedido atendido
Colocando pedido em pendência Atendendo pedido
8.7 – Diagrama de componentes

Componentes modelam coisas físicas que podem residir
em um nó, como: executáveis, bibliotecas, tabelas, arquivos e
documentos.
Um nó é um objeto físico que representa um recurso
computacional.
Nós geralmente incluem computadores com processadores, e
dispositivos, como impressoras, leitoras de cartão, dispositivos
de comunicação, etc.
Assim como na análise, para a implementação de um
software é necessário estabelecer qual a modelagem física do
sistema executável.
44
Um diagrama de componentes mostra as dependências

entre componentes de software, incluindo componentes de
código fonte, componentes de código binário e componentes
executáveis.
É um grafo de componentes conectado por relacionamentos de
dependência.
45
Exemplos:
Modelagem de uma aplicação:
Modelagem de um banco de dados físico:
<<Database>>
escola.db
<<Table>> <<Table>>
curso aluno
<<Table>> <<Table>> <<Table>>
departamento professor escola
46
8.8 – Diagrama de implantação (Ou

disponibilidade)
Os diagramas de implantação são utilizados para a

modelagem da visão estática de funcionamento de um sistema.
Essa visão é direcionada para a distribuição, entrega e instalação
das partes que formam o sistema físico.
São utilizados para visualizar, especificar e documentar
sistemas embutidos, cliente/servidor e distribuídos. Envolvem a
topologia do sistema, descrevendo a estrutura de hardware.
Esses diagramas mostram a configuração de nós de
processamento em tempo de execução e os componentes que
neles existem.
Componentes que não existem em tempo de execução não

aparecem nestes diagramas.
São diagramas úteis também para a engenharia reversa.
Exemplos de diagrama de componentes:
<<console>>
terminal
<<Ethernet>>
<<server>>
servidor
<<console>>
terminal
<<Conexão serial>>
<<console>>
Os servidores nacionais podem
terminal <<console>> ser alcançados um pelo outro
terminal por meio da rede privada da
empresa.
<<console>>
terminal
<<server>>
servidor
internet nacional
<<server>>
servidor
regional
47 servidor
de login
<<server>>
<<server>>
servidor
servidor
regional
regional
9 – Bibliografia
MODELAGEM DE OBJETOS ATRAVÉS DA UML

Furlan, José Davi
Makron Books
UML ESSENCIAL Um Breve Guia para a linguagem-padrão de
modelagem de objetos
Fowler, Martin e Scott, Kendall
Bookman
APPLYING UML AND PATTERNS
An Introduction to Object-Oriented Analysis and Design
Larman, Craig
UML TOOLKIT
Eriksson, Hans-Erik and Penker, Magnus
FUNDAMENTOS DO DESENHO ORIENTADO A OBJETOS COM UML
Page-Jones, Meilir
Makron books
48

An Liseeprojetodesistemasorientadosaobjetos-Notasdeaula

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

An Liseeprojetodesistemasorientadosaobjetos-Notasdeaula

Transféré par

Droits d'auteur :

Formats disponibles

Análise e projeto de

5º Semestre - Professor: José Luiz Rodrigues Junior

5º Semestre - Professor: José Luiz Rodrigues Junior

8.1.2 – Interações em casos de uso.........................................................................29

5º Semestre - Professor: José Luiz Rodrigues Junior

O termo Orientação a Objetos significa organizar o mundo real

1.1 – Alavancas da orientação a objetos

5º Semestre - Professor: José Luiz Rodrigues Junior

Projetista pensa em termos de comportamento dos

5º Semestre - Professor: José Luiz Rodrigues Junior

Análise e projeto de sistemas orientados a

Um objeto existe no mundo real e é um elemento que podemos

“um objeto é uma abstração de um conjunto de coisas do

Em processamento de dados, um objeto tenta unir o que até

5º Semestre - Professor: José Luiz Rodrigues Junior

Interações : Transações (Caixa eletrônico)

Todo objeto possui três características básicas:

Um objeto não existe isoladamente. Ele pode interagir com

5º Semestre - Professor: José Luiz Rodrigues Junior

5º Semestre - Professor: José Luiz Rodrigues Junior

Uma operação pode ser descrita como sendo um serviço

Conjunto de instruções associado com a operação de uma

É o compartilhamento de atributos e operações entre

5º Semestre - Professor: José Luiz Rodrigues Junior

assunto é complexo, ele será tratado com mais

Significa que diferentes tipos de objetos podem responder

5º Semestre - Professor: José Luiz Rodrigues Junior

5º Semestre - Professor: José Luiz Rodrigues Junior

O encapsulamento esconde os detalhes de implementação de um

A modularidade consiste na divisão do sistema em

5º Semestre - Professor: José Luiz Rodrigues Junior

“Modularidade é a propriedade de um sistema de ser

“Hierarquia é uma graduação ou ordenamento de

3.5 - Benefícios do modelo de objetos

5º Semestre - Professor: José Luiz Rodrigues Junior

Princípios como “esconder informações” e “modularidade”

5º Semestre - Professor: José Luiz Rodrigues Junior

Todos os objetos estão armazenados em estruturas que

“Uma classe é um grupo de objetos que compartilham

4.2 – Exemplos de classe:

5º Semestre - Professor: José Luiz Rodrigues Junior

Graficamente, podemos representar uma classe da

- Todos os objetos são instâncias de uma classe.

4.3 – Classes e visões

A interface de uma classe provê a visão externa, e

A implementação de uma classe é sua visão interna, que

5º Semestre - Professor: José Luiz Rodrigues Junior

Uma declaração que forma parte da interface

5º Semestre - Professor: José Luiz Rodrigues Junior

4.4 - Classes – Classificação e instanciação

4.5 – Classes – Generalização / Especialização

5º Semestre - Professor: José Luiz Rodrigues Junior

5º Semestre - Professor: José Luiz Rodrigues Junior

4.7 – Composição por agregação

Propriedade de uma Classe formar suas instâncias a partir

Se A agrega B então B é parte de A; mas seus tempos de

5º Semestre - Professor: José Luiz Rodrigues Junior

BASE BULBO FILAMENTO

Se A é composto de B então A controla o tempo de

4.9 – Classes abstratas

São Classes utilizadas apenas para organizar a estrutura,

Uma Classe Abstrata é uma classe que:

5º Semestre - Professor: José Luiz Rodrigues Junior