02 Aula Conceitos Gerais UML

Prévia do material em texto

Análise de sistemas orientado a objetos
Aula 02
Conceitos básicos da orientação a objetos
2
Objetivos:
� Entender o significado de objetos e classes;
� Definir abstração
� Definir atributos e operações
� Conhecer mecanismos de herança e polimorfismo
� Exemplificar encapsulamento
Introdução
3
Antes de começarmos a desenvolver orientado a objetos, é preciso,
começar a pensar orientado a objetos
4
Mas o que é um objeto?
5
Portanto, objetos são coisas do mundo real, como pessoas, animais etc,
que descobrimos estudando suas características (atributos), como altura,
tamanho, cor e seu comportamento (ações), como falar, dormir, andar.
Além de objetos animados, essa observação inclui também objetos
inanimados, como por exemplo: uma bola de futebol, que possui
atributos, como diâmetro, cor, peso e ações como rolar, encher chutar etc.
Conceito 02…
O que é abstração?
6
Suponha um conjunto formado pelos seguintes objetos: calculadora,
caminhão, impressora, pessoas. Se por exemplo, o propósito fosse
desenvolver um sistema de transporte, os demais objetos estariam
descartados.
Conceito 02…
O que é abstração?
7
A tarefa do analista, portanto, é estudar e observar a realidade e, usando
o processo intelectual de abstração, representar esses objetos em um
modelo dentro de um contexto, denominado domínio da aplicação
Classes
8
Uma Classe é a definição dos atributos e funções de um tipo de objetos;
ela descreve um conjunto de objetos individuais em qualquer contexto.
Ela é obtida pela classificação de objetos com a mesma estrutura de
dados e o mesmo comportamento.
Nome da classe
Atributos da classe
Funções da classe
Classes
9
Cada objeto (do mundo real) pertencente a uma classe e é denominado
instancia da classe. Assim por exemplo em um dado momento, José,
Antônio, João etc. podem ser instanciadas da classe Cliente, uma vez
que possuem atributos comuns (nome, data de nascimento, endereço
etc) e comportamentos (andar, deitar, trabalhar etc). A classe Cliente nada
mais é que um modelo para a criação de objetos em determinado
sistema.
Atributos
10
Os atributos, são recursos de uma classe ou qualquer outro elemento que
represente propriedades ou elementos de dados. Em algumas
linguagens, os atributos são denominados variável de instancia de
classe ou membro de dado.
Eles possuem algumas características importantes, como visibilidade
(escopo), nome, tipo de dado e valor inicial.
A visibilidade de um atributo pode ser:
Atributos
11
A visibilidade de um atributo pode ser:
� Publica: o atributo é acessível (pode ser enxergado) por outras classes
– a visibilidade pública é representada no modelo por um sinal de
adição (+).
� Privada : atributo é acessível somente pela própria classe e suas
subclasses – é representada no modelo por um sinal de subtração (-).
� Protegida: o atributo é acessível somente pela própria classe e suas
subclasses – é representada no modelo pelo símbolo de sustenido (#).
� De pacote: o atributo de uma classe é acessível somente pelas
classes do pacote que a contém – é representada no modelo pelo til
(~) e disponível apenas em algumas linguagens, como java.
Operações
12
Os objetos interagem e comunicam-se por meio de mensagens, que
identificam os métodos a serem executados, no objeto receptor.
Para invocar um método de um objeto, enviar-se uma mensagem para
ele especificando o nome do objeto, o método a ser executado e a lista
de argumentos requeridos. Após a execução, o objeto pode ou não
retornar um valor como resposta a mensagem recebida.
Herança
13
Usando o mecanismo de herança, podemos definir classes de veículos
especificas.
A classe Pessoa é denominada superclasse (classe mãe) e as classes
PessoaFisica, PessoaJuridica e Funcionário são denominadas
subclasses (classes filhas ou derivadas) .
Assim, uma subclasse herda atributos e comportamento de sua classe
imediatamente superior – a superclasse e também possui atributos e
operações específicos dela mesma.
14
Polimorfismo
15
Polimorfismo: é o principio pelo qual classes derivadas de uma mesma
superclasse, podem invocar operações que tem a mesma assinatura,
mas comportamentos diferentes em cada subclasse, produzindo
diferentes resultados, dependendo de como cada objeto implementa a
operação.
Em outra palavras, é a capacidade de objetos diferentes possuírem
operações com o mesmo nome e a mesma lista de argumentos, mas que
executam tarefas diferentes
16
ANIMAL
CAO GATO GALINHA
Encapsulamento
17
Os atributos estão encapsulamento, isto é, envolvidos por código de
forma que só é visível na operação em que foi criado. Isso também vale
para as operações, quando algumas delas são visíveis apenas pelo
próprio objeto.
18
public class Conta {
public int numero;
public String nome;
private double saldo;
public void depositar (double v) {
saldo += v;
}
public void retirar (double v) {
if (v <= saldo) saldo -= v;
else System.out.println("Saldo insuficiente");
}
public double getSaldo () {
return saldo;
}
}
Análise e Projeto Orientados a Objeto
com UML e Padrões
Parte I 
Análise, Projeto, e Processo
19
Aplicando UML, Padrões e APOO
Objetivo 
» Desenvolver habilidades práticas na utilização da TO 
para a criação de sistemas de software bem 
projetados, robustos, e modificáveis
Linguagens OO são um primeiro passo necessário mas 
insuficiente
Outros recursos importantes 
» processo de desenvolvimento
» padrões
» UML
Ilustrados na prática através de um estudo de caso 
detalhado
O que é Análise e Projeto?
Análise — “o quê”
Investigação do problema e 
dos requisitos
Requisitos
Casos de uso
Restrições
Vocabulário
Projeto — “como”
Descrição de uma solução lógica
Objetos
Arquitetura
Instalação & Operação
Interface do usuário
Conflito de Terminologias
Termos “Análise” e “Projeto” não são fixos, mas 
usados ao longo de um contínuo
Significados variam de metodologia para 
metodologia
Distinção é útil na prática, mas debater definições 
rígidas não é construtivo 
Mais orientado
a análise
Mais orientado 
a projeto
O que é APOO?
Na essência, considerar um problema e uma
solução dentro da perspectiva de objetos,
coisas ou conceitos.
O que é AOO?
» Investigação dos objetos de domínio e seus 
relacionamentos
� Descritos no Modelo de Objetos de Domínio
O que é POO?
» Elaboração de uma solução lógica em termos de 
componentes de software e suas colaborações e 
responsabilidades
� Descritos em Diagramas de Classes e Diagramas de 
Interação
Representação de um Conceito na APOO
Ex.: O conceito “Livro” em um sistema de biblioteca
Conceito
de domínio
public class Livro
{
public void imprimir();
private String titulo;
}
Representação
no código
Livro
título
Representação
na análise
Livro
título
Representação
no projeto
imprimir()
Uma Analogia — Organizando os 
Negócios de uma Empresa 
Documentos
AssociadosAPOOAnalogia
Casos de usoAnálise de requisitosQuais são os processos de 
negócio?
Modelo conceitualAnálise do domínioQuais são os papeis dos 
empregados?
Diagramas de classes de 
projeto, diagramas de 
colaboração
Atribuição de 
responsabilidades, projeto 
das interações
Quem é responsável por o 
quê? Como eles 
interagem?
Um Exemplo — Jogo de Dados
Objetivo: ganha o jogo, o jogador que rolar dois 
dados e tirar sete
Modelagem na APOO
» Casos de uso
� Descrições narrativas de processos do domínio no formato 
de prosa estruturada
� Ex.: 
Caso de uso:
Atores:
Descrição:
Jogar
Jogador
Este caso de uso começa quando
o jogador rola os dados.Se o total
dos dados for sete, o jogador ganha;
do contrário, ele perde.
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.)
» Modelo conceitual
� Conceitos, atributos, e associações que são considerados 
importantes no domínio da aplicação
� Ex.:
» Um modelo conceitual descreve conceitos do mundo 
real, não componentes de software!
Jogador
nome
JogoDeDados
Dado
valor
Rola
Joga
Inclui
2
2
1
1
1
1
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.) 
» Diagramas de colaboração
� Alocação de responsabilidades para objetos ilustrando como 
eles interagem via mensagens
� Mostram o fluxo de mensagens entre instâncias e a 
invocação de métodos
� Ex.:
:Jogador d1 : Dado
d2 : Dado
joga() 1: r1 := rola()
2: r2 := rola()
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.) 
» Diagramas de classes de projeto
� Como os objetos (de software) se conectam? 
� Quais são os métodos de uma classe?
� Ex.:
Rola
Joga
Inclui
2
2
Jogador
nome
joga()
Dado
valor
rola()
JogoDeDados
inicializa()
1
1
1
1
APOO X APE
Metodologias mais antigas, como Análise e Projeto 
Estruturados, baseiam-se em outras dimensões de 
decomposição
Sistema de
Biblioteca
Sistema
A&P Orientados a Objeto
Decomposição por objetos ou conceitos
A&P Estruturados
Decomposição por funções ou processos
Registra
Empréstimos
Adiciona
Recursos
Reporta
Multas
Catálogo
Livro
Bibliotecário
Biblioteca
A Linguagem de Modelagem Unificada 
— UML
A UML é a linguagem padrão de diagramação para 
visualizar os resultados da análise e projeto
A notação (a própria UML) é relativamente trivial
Muito mais importante: habilidade para modelar com 
objetos
» Só aprender a notação UML não ajuda
A UML não é
» um processo ou metodologia
» APOO
» regras de projeto 
Origem e Evolução da UML
Unified Method 0.8 Unificação I
(Out’95)
Booch’93 OMT-2
Outros 
métodos Booch’91 OMT-1 OOSE Fragmentação
UML 1.0
Parceiros
da UML
Padronização
(Jan’97)
UML 1.1 Industrialização
(Set’97)
UML 0.9 & 0.91 Unificação II
(Out’96)
Processo de Desenvolvimento
Organização das atividades relacionas à produção e 
manutenção de sistemas de software
Útil, mas um fator de segunda ordem
» O principal: equipe qualificada
Boa equipe + bom processo = menor risco
O processo racional unificado (RUP), baseado no modelo 
iterativo, é o processo padrão na indústria
Um Processo Iterativo Simplificado
Simplificação do processo iterativo unificado
Fácil extensão e customização
Não inclui atividades importantes como 
» Verificação & validação
» Divisão do trabalho
» Gerência de projeto
» Documentação 
ConstruçãoPlan. &Elaboração Implantação
Fases
Planejamento e Elaboração
» Concepção inicial, investigação de alternativas, 
definição de requisitos, etc.
Construção
» Construção do sistema através de múltiplos ciclos de 
análise, projeto, implementação e teste
Implantação
» Instalação e operação do sistema
Modelos e Artefatos
Um modelo descreve e abstrai aspectos essenciais de um 
sistema
» Modelo estático (estrutura)
» Modelo dinâmico (comportamento)
Modelos são compostos por artefatos— diagramas e 
documentos que descrevem os elementos do modelo
Na APOO, a UML é usada para descrever e visualizar os 
modelos e artefatos produzidos em cada fase do 
processo de desenvolvimento
Fase de Planejamento e 
Elaboração
2. Criar Rel. Prel.
de Investigação 3. Definir Requisitos
9. Refinar Plano7. Definir Mod.Conc. Inicial c
4. Reg. Termos
no Glossário a
6. Definir Casos 
de Uso
1. Definir Plano
Inicial
5. Implementar
Protótipo b, d
a. contínua
b. opcional
c. adiável
d. ordem variada
8. Definir Arquit.
Inicial a, c, d
Notas
ConstruçãoPlan. &Elaboração Implantação
Fase de Planejamento e Elaboração
Atividades:
1. Definir plano inicial
� Prazos, recursos, orçamento
2. Criar relatório preliminar de investigação
� Motivação, alternativas, necessidades de negócio
3. Definir requisitos
� Especificação declarativa dos requisitos
4. Registrar termos no glossário
� Dicionário de termos, regras, restrições
5. Implementar protótipo
� Protótipo do sistema para ajudar na definição dos requisitos
Fase de Planejamento e Elaboração
Atividades:
6. Definir casos de uso
� Descrição em prosa estruturada dos processos de negócio
7. Definir modelo conceitual inicial
� Objetos de domínio e seus relacionamentos
8. Definir arquitetura inicial
� Principais subsistemas e suas dependências
9. Refinar plano
Atividades não lineares 
» Ex.: 7, 4, 6 em paralelo
Fase de Construção
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2 ...
ConstruçãoPlan. &Elaboração Implantação
Fase de Construção
Repetição de ciclos de desenvolvimento
» Construção progressiva do sistema até atingir uma 
versão que satisfaça corretamente os requisitos
Atividades típicas de cada ciclo:
1. Refinar plano
2. Sincronizar artefatos
3. Análise
4. Projeto
5. Implementação
6. Teste
Ciclos de Desenvolvimento
Cada ciclo implementa um conjunto reduzido de 
requisitos, adicionando novas funções ao 
sistema 
» Crescimento incremental, através de expansões e 
refinamentos sucessivos
Ciclos com tempo fixo de duas a oito semanas
Vantagens:
» Evita complexidade excessiva
» Antecipa feedback dos usuários
Ciclos de Desenvolvimento e 
Casos de Uso
Um ciclo deve atacar um ou mais casos de uso, ou 
versões simplificadas de casos de uso
Casos de uso mais relevantes devem ser atacados nos 
primeiros ciclos
» Prioridade para serviços com grande influência na arquitetura do 
sistema ou de alto risco 
Ciclo de 
Desenv. 1
Caso de uso A
Versão
Simplificada
Ciclo de 
Desenv. 2
Caso de uso A
Versão
Completa
Ciclo de 
Desenv. 3
Caso de
uso B
Caso de 
uso C
Análise
a. se ainda não feito
b. contínuo
c. opcional
2. Refinar Diag. 
Casos de Uso
3. Refinar Modelo
Conceitual
4. Refinar 
Glossário b
6. Definir Contrat.
de Operação
1. Definir Casos de
Uso Essenciais a
5. Definir Diag.
Seq.
7. Definir Diag.
Estado c
Notas
...
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2
Análise
Subatividades:
1. Definir casos de uso essenciais
2. Refinar diagramas de casos de uso
3. Refinar modelo conceitual
4. Refinar glossário
5. Definir diagramas de seqüência do sistema
6. Definir contratos de operação
7. Definir diagramas de estado
Projeto
2. Definir Rel. & IU
4. Definir Diag.
Interação
5. Definir Diag.
Classes a
6. Definir Esquema
do BD
1. Definir Casos de
Uso Reais
3. Refinar
Arquitetura b
Notas
a. em paralelo com
diag. interação
b. ordem variada
...
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2
Projeto
Subatividades:
1. Definir casos de uso reais
2. Definir relatórios e interfaces com o usuário
3. Refinar arquitetura do sistema
4. Definir diagramas de interação
5. Definir diagramas de classes de projeto
6. Definir esquema do banco de dados