Orientação para Objetos
Projeto de Sistemas Aplicativos
para a Internet
FEA/USP
EAD-5881 – Tecnologia de Informática
Prof. Antonio Geraldo da Rocha Vidal
[email protected]
1
Conteúdo
1. Conceitos de Orientação a Objetos



Classes
Objetos
Programação
2. Introdução à Linguagem Java

Conceitos e recursos básicos
3. Projeto de Sistemas Orientados a
Objetos
4. UML - Unified Modeling Language
2
Paradigma
“Paradigma é um conjunto de regras
que estabelece fronteiras e descreve
como resolver problemas dentro destas
fronteiras. Os paradigmas influenciam
nossa percepção: ajudam-nos a
organizar e a coordenar a maneira
como olhamos para o mundo...”
Daniel Morris e Joel Brandon
3
Paradigmas
Tradicional: baseia-se na compreensão de
um sistema de informação como um conjunto
de programas que executam processos sobre
dados.
Objetos: vê um sistema de informação como
uma coletânea de objetos que interagem
entre si, apresentam características próprias,
que
são
representadas
pelas
suas
propriedades (dados) e métodos (processos).
4
Paradigmas
Programa
Classe
Processos
Propriedades
Dados
Métodos
Tradicional
Objetos
5
Orientação a Objetos - OO
Análise, projeto e programação orientados a
objetos representam uma mudança de
paradigma em relação às técnicas clássicas.
Objetos são os componentes de um sistema
que pertencem a uma classe e possuem:







Encapsulamento
Herança
Polimorfismo
Propriedades
Métodos
Eventos
Mensagens
Reutilização
Flexibilidade
Interoperabilidade
6
Bases das Metodologias OO
Diretamente derivada dos conceitos da
programação orientada a objetos, a análise e
o projeto orientados a objeto definem uma
nova maneira de pensar nos problemas
utilizando modelos organizados a partir de
conceitos do mundo real.
O componente fundamental é a classe de
objetos, algo que combina estrutura e
comportamento em uma única entidade que
pode derivar várias ocorrências ou instâncias
de objetos semelhantes.
7
Origens da OO
Linguagens de Programação: Simula,
Smaltalk, Flavours, Objective C, C++,
Java, C#, Object Pascal e outras.
Inteligência Artificial: frames.
Banco de Dados: modelos semânticos
de dados.
8
Expectativas da OO
A tecnologia de objetos oferece a modularidade de
seus elementos podendo-se tomar um subconjunto
existente e integrá-lo de uma maneira diferente em
outra parte do software (sistema aplicativo).
Uma aplicação no universo de objetos consiste de um
conjunto de blocos de construção auto-contidos
e predefinidos que podem ser localizados, reparados
ou substituídos.
A construção de código auto-contido propicia o teste
completo antes de ser utilizado dentro da lógica de
um sistema de informação.
9
Expectativas da OO
Possibilita incrementos graduais de componentes
aos já instalados, ampliando a abrangência do
sistema.
A combinação de módulos provê inicialmente um
nível básico de funcionalidade que é estendido
sucessivamente para atender novas situações, em
um progresso contínuo da aplicação perante os
usuários.
Forte direcionamento à reutilização de artefatos de
software já existentes, que são criados uma única
vez e disseminados.
10
Objetos Concretos
Coisas
Tangíveis
Automóvel
Eventos
Casamento
Transações
Transação
comercial
11
Objetos de Software
Objetos são pacotes de software compostos por
dados e procedimentos, que atuam sobre estes
dados.
Os procedimentos são também conhecidos
como métodos e determinam o comportamento
do objeto.
Os dados são também conhecidos como
propriedades e determinam o estado do
objeto.
Objeto = dado + procedimento
Objeto = estado + comportamento
12
Objetos de Software
Comportamentos
Variáveis
Dados
Procedimentos
Propriedades
Métodos
13
Objeto Automóvel
Mover
Preço
Dimensões
Cor
Potência
Buzinar
Parar
14
Objetos de Software
Todo acesso aos dados ou propriedades de um objeto
é feito através da sua interface, que expõe métodos e
propriedades a outros objetos.
15
Encapsulamento
É definido como uma técnica para
minimizar interdependências entre
“módulos” através da definição de
interfaces externas.
Interface
Mudanças na implementação de uma classe que preserve
a interface externa não afetam outras definições de classes.
16
Interfaces de Classes
Uma Interface descreve um grupo de classes
com as mesmas:


Propriedades constantes;
Métodos abstratos;
Uma Interface define a estrutura ou
“esqueleto” padrão de uma classe.
Não implementa nenhum comportamento
real, mas apenas os declara.
Implementa propriedades constantes e
métodos abstratos.
17
Mensagens
Objetos interagem e comunicam-se
através de mensagens...
Andar(...)
Emissor
Receptor
As mensagens identificam os métodos a serem executados
no objeto receptor e passam-lhes alguma informação. 18
Métodos
Um determinado método define um
comportamento do objeto.
Tipos básicos de métodos:




Construtor (constrói estados)
Destruidor (destrói estados)
Transformador (transforma estados)
Acesso (fornece estados)
19
Abstração
Focalizar o essencial, ignorar
propriedades acidentais ou específicas.
Classe Automóvel
Classe Mamífero
A abstração deve sempre ter algum objetivo, pois é o objetivo
ele que determina o que é e o que não é essencial
20
Classes de Objetos
Uma classe de objetos descreve um
grupo de objetos com:



Propriedades semelhantes;
Comportamentos semelhantes;
Relacionamentos comuns com outros
objetos.
21
Classes
Classificação
Classe Automóvel
Atributos
Potência
Velocidade
Cor...
Instanciação
Objetos
Instâncias
Métodos
Acelerar
Frear
Buzinar...
22
Classes
Classe Pai
Super Classe
Atributos e métodos
da classe.
Subclasse
Instanciação de classe
Atributos e métodos
específicos.
Subclasse
23
Classes vs. Subclasses
Classes:


Contém informações sobre como uma subclasse
ou um objeto deve ser e como deve se comportar.
Definem a forma e o comportamento padrão de
subclasses e objetos nela baseados.
Subclasses:




São instâncias ou ocorrências de uma classe.
Herdam todas as suas características padrão de
uma classe.
Além disso, podem possuir características
específicas.
Podem derivar outras subclasses ou objetos nelas
baseados.
24
Classes vs. Objetos
Classes:


Contém informações sobre como um objeto deve
ser e como deve se comportar.
Definem a forma e o comportamento padrão de
objetos nela baseados.
Objetos:




São instâncias ou ocorrências de uma classe.
Herdam todas as suas características padrão de
uma classe ou subclasse.
Além disso, podem possuir características
específicas.
Não podem derivar outros objetos neles baseados.
25
Relacionamentos entre Classes
Generalização
Herança
Agregação
Polimorfismo
26
Generalização /
Especialização
Generalização é o relacionamento entre
uma classe e uma ou mais versões
refinadas dessa classe.
Generalização
Generalização é a abstração que permite compartilhar
semelhanças entre classes, preservando suas diferenças.
Especialização
27
Hierarquia de Classes
Super Classe
Classe Primitiva
Sub Classe A
Classe Derivada
Sub Classe B
Classe Derivada
Sub Classe C
Classe Derivada
28
Herança
Uma classe derivada ou subclasse herda
as propriedades e métodos da classe
mãe ou superclasse, mas pode:



Adicionar novos métodos próprios;
Estender suas propriedades/atributos;
Redefinir a implementação de métodos
existentes.
29
Herança
Localização de Métodos e Propriedades na Hierarquia
Super Classe
Classe Primitiva
Sub Classe A
Classe Derivada
Sub Classe B
Classe Derivada
Sub Classe C
Classe Derivada
Subsub Classe 1
Subsub Classe 2
Calcular()
Instância
30
Herança
Generalização
Propriedades e
métodos comuns
compartilhados
por classes.
Automóvel
Automóvel
Esportivo
Ferrari
Propriedades e
métodos
diferentes de
uma subclasse,
acrescentando ou
alterando
características
herdadas.
Especialização
31
Agregação
Um objeto agregado é “construído” por vários componentes
Automóvel
Chassi
Carroceria
Suspensão
Motor
Agregação Fixa
32
Agregação
Um objeto agregado é “feito” de componentes
Empresa
Departamento
Setor
Agregação Variável
Pessoa
33
Polimorfismo
Refere-se a:


Vários comportamentos que um mesmo método
ou operação pode assumir;
Capacidade de um nome referir-se a objetos
diferentes que executam certas responsabilidades
dependendo da mensagem que lhes é passada.
Um nome pode denotar objetos de muitas
subclasses diferentes que estão relacionadas
por alguma superclasse comum. Assim, um
objeto identificado por esse nome tem a
capacidade de responder a algum conjunto
comum de operações de modos diferentes.
34
Evento vs. Estado
Evento:



Uma ocorrência significativa no mundo real que
deve ser tratada pelos objetos de software.
São atividades específicas e predeterminadas,
provocada pelo usuário ou pelo sistema.
Possuem métodos de objetos associados a eles.
Estado:

Situação de um objeto em um dado instante do
tempo.
35
Objetos: propriedades
Características ou atributos dos objetos que
são próprias da classe ou subclasse à qual
pertencem.
Exemplo: objeto JOSÉ, pertencente à
subclasse CLIENTE, da subclasse PESSOA
FÍSICA, da classe PESSOA.






Número: 000001
CPF: 999.888.777-66
Nome: José da Silva
Endereço: Rua da Independência, 709
Telefone: 3089-9090
Etc.
36
Objetos: métodos & eventos
Cada objeto reconhece e pode responder a
ações denominadas eventos próprios da sua
classe/subclasse.
Eventos:


São atividades específicas e predeterminadas
provocada pelo usuário ou pelo sistema.
Possuem métodos associados a eles.
Métodos:


São comportamentos ou procedimentos
associados ao objeto.
Métodos podem existir independentemente de
eventos.
37
Objetos: mensagens
Objetos recebem mensagens de outros
objetos com os quais se relacionam.
Mensagens:



Transferem informações de um objeto para
outro.
São enviadas e recebidas através de
eventos.
São caracterizadas pelos métodos ou
comportamentos dos objetos; tanto do que
envia como do que recebe.
38
Objetos: polimorfismo
Usando a mesma mensagem, objetos
podem assumir características e
comportamentos diferentes:



De acordo com contextos específicos;
De acordo com eventos específicos;
De acordo com eventos e contextos
específicos.
Um objeto pode assumir várias formas:


Propriedades/atributos diferentes;
Métodos/comportamentos diferentes.
39
Linguagens Orientadas a Objetos
40
Introdução às Linguagens
Orientadas a Objetos
Conceitos Básicos
(Válidos para C++, C#, Java, J++ e J#)
41
Java
It’s a jungle out there
So drink your Java
Propaganda do Printer’s Café
em Palo Alto CA/USA
42
Por que surgiu o Java?
Software para eletro-domésticos (1992)



Mínimo uso de memória
Mínimo preço
C++ simplificado
Desenvolvida pela Sun Microsystems Inc.
(1994)
Distribuição de software através da Internet
(1996)
Novo paradigma de programação:



Orientada a objeto
Totalmente aberta
43
Independente de plataforma e sistema operacional
Características do Java da
Sun
Linguagem orientada a objetos
Estrutura semelhante ao C++
Gera Bytecodes


Interpretada
Alta Performance (JIT)
Segurança


Endereçamento restrito
Objetos assinados
Aplicação Carregada Localmente
44
Características do Java da
Sun
Aplicações Personalizadas
Independência de Arquitetura


Neutra
Distribuída
Não há herança múltipla
Não há aritmética de ponteiros
Inclui tratamento de exceções
Implementa “Coletor de Lixo”
45
Arquitetura de Programas Java
46
Java Script
Primeira Versão do Java
Aplicação Interna ao HTML
Interpretada
Não havia o conceito de ByteCodes
<script language=“Java Script”
Function -------{ .......
}
</script>
47
Applet Java
Aplicação executada quando se chama
uma página WWW
É carregada na Máquina Cliente
Restringe-se a uma determinada área
(janela)
<applet code=“apl.class”
codebase=“http://www.fia.fea.usp.br/vidal
align=left
width=300
height=100
<param name=tamanho value=30>
<param name=fonte value “Arial”>
</applet:
48
Aplicação Java
Aplicação executada “stand-alone”
Exige somente a presença do
interpretador Java (Java Virtual Machine)
public class HelloWorldApp
{
// Definição do Método MAIN
public static void main (String args[])
{
String text = "Hello World!";
System.out.println(text);
}
}
49
Java e Orientação a Objetos
Java suporta as principais características da
programação orientada a objeto através de
seus construtores de classes e de interfaces.
Uma classe é um modelo que descreve um
conjunto inteiro de objetos. Em geral, uma
classe tem os mesmos membros, isto é,
propriedades (dados) e métodos
(procedimentos), que os objetos criados a
partir dela.
Uma interface representa uma coleção de
comportamentos relacionados. Contém
somente declarações de métodos e
50
propriedades constantes.
Criando Classes
Uma classe é composta por métodos
(comportamento) e propriedades
(variáveis que determinam o estado).
public class Pessoa {
// Variáveis ou propriedades
String Nome;
boolean ComFome;
// Métodos
int Comer(int quantidade)
{ //... }
}
Métodos mudam o estado das variáveis
51
Exemplo de Definição de
Classe (propriedades)
public class Morador...
{
String nomeCompleto;
String apartamento;
String telefone;
int anoChegada;
....
52
Exemplo de Definição de
Classe (métodos)
public class Morador...
{....
public morador(String no, String ap,
String te, int an)
{ nomeCompleto = no;
apartamento = ap;
telefone = te;
anoChegada = an;
}
public int permanencia()
{ return (2002 - anoChegada); }
}
53
Criando Objetos
Criação do Objeto lassie a partir da
classe Cachorro:
/*Crie uma variável de referência
para a classe Cachorro:*/
Cachorro lassie;
/*Crie um objeto da classe Cachorro
e designe-o para a referência:*/
lassie = new Cachorro();
54
Usando Objetos
Executando um método do objeto
criado:
Cachorro.latir();
/* Errado! -não se pode fazer todos
os cachorros latirem.*/
lassie.latir();
/* Correto! pode-se fazer um
determinado cachorro latir.*/
55
Exemplo de Instanciação de
uma Classe
...
Morador prof;
....
prof = new morador(“Vidal”, “82”, “3081-0001”,1998);
...
56
Exemplo de Métodos com
Mensagens
.....
Morador prof;
int p;
....
prof = new morador(“Vidal”, “81”, “3081-0001”,1998);
....
p = prof.permanencia(); // acionando o método
// permanencia para o
// objeto definido em prof
indica o envio de mensagem para o
objeto prof
....
57
Herança
A herança permite a você reutilizar e
modificar código já existe.
A herança forma relações hierárquicas entre
classes ou interfaces.
A meu ver a mais significativa contribuição do
paradigma da Orientação para Objetos para o
desenvolvimento de software.
58
Exemplo de Herança
import morador;
public class morador_inq extends morador
{
int aluguel;
public morador_inq(String no, String ap,
String tel, int an, int va)
{ super(no, ap, tel, an);
aluguel = va;
}
}
59
Exemplo de Agregação
Objeto Composto
public class material extends Object
{
String rotulo;
Boolean emCaixa;
int anoEstocagem;
double valor;
Morador proprietario;
public material (....)
....
60
Exemplo de Agregação
Objeto Composto
public class material extends Object
{....
public material (String ro, double va,
boolean em, Morador pro, int an)
{rotulo = ro; valor = va;
emCaixa = em; proprietario = pro;
anoEstocagem = an;
}
public int permanencia()
{ return (2002 - anoEstocagem); }
61
Pacotes
Um pacote é um grupo de classes
relacionadas.
Eles são semelhantes a bibliotecas em
outras linguagens de programação.
Ajudam a organizar classes,
relacionando-as em categorias com
funcionalidades (métodos e
comportamentos) semelhantes.
62
Pacotes JAVA
java.lang
java.util
java.io
java.awt
java.applet
Para usar um pacote pré-existente, você
deve importá-lo para o seu programa.
63
Pacotes Java
64
Análise e Projeto de Sistemas
Orientados a Objeto
UML - Unified Modeling Language
65
Conteúdo
Visão Geral
UML
Técnicas de Modelagem
Análise: Classes
Projeto: Objetos, Interface e Sistema
Considerações Finais
66
Metodologia
Conjunto de técnicas e diretrizes para
construção, manutenção e melhoria de
produtos de software.
Fornece uma base de comunicação: um
conjunto de técnicas e uma base para
engenharia de software.
67
Fases Clássicas do
Desenvolvimento de Sistemas
Definição de
Requisitos
Domínio do Problema
Análise
Projeto
Implementação
Teste
Domínio da Solução
Implantação
68
Metodologia OO
Uma metodologia de desenvolvimento
de sistemas é considerada Orientada a
Objetos se ela orienta a construção de
sistemas a partir do entendimento do
mundo real como um conjunto de
objetos que comunicam-se entre si de
forma coordenada.
69
Metodologia OO
Principais Atividades:



Entender quais são os objetos envolvidos
no domínio do problema.
Entender como se comunicam no mundo
real.
Projetar a forma como devem ser
implementados.
70
UML – Unified Modeling Language
Booch
Odell
Rumbaugh
UML
Shlaer-Mellor
Gamma et al
Jacobson
Meyer
Harel
Fusion
Wirgs-Brock
Objetivo: 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 em tempo real, cliente/servidor,
71
orientada a objetos e outros tipos e padrões de software.
A UML
Os fomentadores da UML não inventaram a
maioria das idéias, em vez disso, seu papel
foi selecionar e integrar as melhores práticas,
tornando-a um meio padrão de expressar
projetos de sistemas.
Ajuda a desmistificar o processo de
modelagem de sistemas de software.
Linguagem-padrão para encorajar os
desenvolvedores a modelar os seus sistemas
de software, antes de construí-los.
Adoção rápida e muito difundida.
72
A UML
Tornou-se o modo-padrão para desenhar
diagramas de projetos orientados a objetos.
Também foi adotada em campos nãoorientados a objetos.
É projetada para ser independente do
processo de software.
É uma linguagem padrão para especificar,
visualizar, documentar e construir
componentes de um sistema de informação.
Pode ser utilizada em todos os processos ao
longo do ciclo de desenvolvimento e através
de diferentes tecnologias de implementação.73
A UML
É uma linguagem de modelagem; não é uma
metodologia. Não possui um processo!
Uma linguagem de modelagem é a notação,
principalmente gráfica, utilizada por métodos
para expressar projetos.
O processo é a sugestão de quais passos
devem ser seguidos na elaboração de um
projeto.
A linguagem de modelagem é a parte-chave
do processo para a comunicação.
74
A UML
Está na sua versão 1.3 de 1999.
Define uma notação e um metamodelo:


Notação é a parte gráfica dos modelos; é a
sintaxe da linguagem de modelagem.
Metamodelo é um diagrama, geralmente o
diagrama de classes, que define a como notação
deve ser utilizada corretamente.
A UML tem pouco rigor; suas notações
apelam para a intuição em vez da definição
formal. O mais importante é a utilidade para
o projeto.
Atualmente é um padrão do OMG – Object
75
Management Group.
A UML pode ser usada para:
1. Mostrar as fronteiras de um sistema e suas funções
2.
3.
4.
5.
6.
principais utilizando atores e casos de uso;
Ilustrar a realização de casos de uso com
diagramas de interação;
Representar uma estrutura estática de um sistema
utilizando diagramas de classe;
Modelar o comportamento de objetos com
diagramas de transição de estados;
Revelar a arquitetura de implementação física com
diagramas de componente e de implantação;
Estender sua funcionalidade através de
estereótipos.
76
UML & Análise e Projeto
O objetivo real do desenvolvimento de
software é o código executável.
Nenhum usuário ficará satisfeito apenas
com diagramas de projeto bonitos.
O usuário quer um software que seja
executado!
Portanto, ao utilizar a UML é importante
pensar em como ela ajudará a escrever
o código executável.
77
Processo de
Desenvolvimento
CONCEPÇÃO
Projeto Lógico
(Análise
Conceitual)
REQUISITOS
Revisão
de Processos
de Negócio
ELABORAÇÃO
Projeto Físico
(Projeto de
Software)
1 2 3 ...
Interativo e Incremental
RISCOS:
•Requisitos
•Tecnologia
•Pessoal Habilitado
•Fatores Políticos
CONSTRUÇÃO
Implementação
(Desenvolvimento)
ITERAÇÕES:
•Análise
•Projeto
•Implementação
•Teste & Ajuste
•Treinamento
Domínio do Problema
Domínio da Solução
TRANSIÇÃO
Teste
Ajuste
Treinamento
78
Tipos de Análise
Análise Estática: descreve as
estruturas e os relacionamentos entre
os objetos do domínio do problema
(Diagrama de Classe de Objetos).
Análise Dinâmica: descreve o
comportamento dos objetos em termos
de suas mudanças ao longo do tempo
(Diagrama de Transição de Estados e
Diagrama de Interação).
79
Modelagem com a UML
1. O que fazem e desejam os usuários do sistema?
2.
3.
4.
5.
6.
(análise de processos e casos de uso).
Quais são os objetos no mundo real que interagem
com o sistema em estudo e suas associações?
(diagrama de classes e MER).
Quais objetos são necessários para cada caso de
uso? (análise de processos, casos de uso e CRC).
Como colaboram entre si objetos dentro de um
caso de uso? (diagramas de interação).
Como serão implementados os controles de tempo
real? (diagramas de estados e de atividades).
Como será construído o sistema? (diagrama de
pacotes, diagrama de componentes, diagrama de
implantação).
80
ANÁLISE DE PROCESSOS
(Não faz parte formal da UML)
Processos & Organizações
Uma organização pode ser vista como
um grande processo que recebe
insumos, informações e recursos do
ambiente, os processa e os devolve ao
ambiente na forma de serviços.
A organização também pode ser vista
como um conjunto de processos
operacionais e gerenciais, que se
desdobram em etapas, e que por sua vez
se subdividem em atividades e estas em
tarefas.
82
Revisão vs. Reengenharia
de Processos
•Qualidade Total
•Racionalização e Produtividade
•Desenvolvimento de Processos
Evolua lenta e
gradualmente (Kaizen).
Baixo Risco
Melhoria Contínua
Melhoria, Programas, Projetos
Mudanças suaves,
graduais e
contínuas.
Não informatize,
destrua (Hammer).
Alto Risco
Reengenharia
Redesenho, Reprojeto
Mudanças drásticas,
fundamentais e
descontínuas.
83
Mudança Organizacional
Do foco nas funções...(Sistemas Isolados)
84
Mudança Organizacional
...ao foco nos Processos (Sistemas Integrados).
85
Processo
É um conjunto de atividades estruturadas, seqüenciais e
medidas que transforma um ou mais tipos de entrada e
cria um produto ou serviço que tem valor para
determinados usuários, clientes ou mercados.
Fornecedores
PROCESSO
Produtos/ Clientes
Serviços
Entradas
Requisitos
86
Características dos Processos
Processos eficientes e eficazes possuem
as seguintes características:





Repetitibilidade
Estabilidade
Previsibilidade
Mensurabilidade
Documentação
87
Elementos de um Processo
Nome
Escopo e Limites
Clientes (internos e/ou externos)
Fornecedores (internos e/ou externos)
Requisitos de Entrada e Saída
Atividades e Participantes
Mapa do Processo
Indicadores e Medidas (tempo, custo etc.)
Informações! (incluindo sua documentação)
88
Diagrama de um Processo
Fornecedor
Processo
Cliente
Entradas
Transformação
Saídas
• Informações
• Insumos
• Instruções
• Materiais
• Tecnologia
Atividades
com
Valor
Agregado
• Produtos
• Serviços
• Informações
(informação é serviço)
89
Análise do Processo
Conhecimentos
Habilidades
Fornecedor
- Insumos
- Informações
- Instruções
- Materiais
- Tecnologia
Requisitos
Métodos
Procedimentos
Regras
PROCESSO
Saídas
Entradas
Recursos
Instalações
Requisitos
Cliente
Produtos
- Serviços
- Informações
Padrões de
Desempenho
90
Metodologia para Análise do
Processo
1. Identificação de Produtos e Processos:

A partir do entendimento dos negócios da organização.
2. Matriz Serviço/Fornecedor/Cliente:
Detalha os produtos finais e intermediários de um
processo
 Detalha seus fornecedores e clientes internos e externos
 Detalha as responsabilidades envolvidas

3. Mapa do Processo:
Fluxograma de atividades: identificando as unidades
organizacionais, tarefas, tempos, pessoas e interfaces
envolvidas em cada atividade.
 Fluxograma de informações: identificando as
informações utilizadas no processo, detalhando seu
recebimento, processamento, envio, registro e interfaces
envolvidas.
91

Matriz Fornecedor X Cliente
Cliente
A
Fornecedor
A
Fornecedor
B
Fornecedor
C
Cliente
B
Serviço
1
Cliente
C
...
Cliente
X
Serviço
3
Serviço
2
Serviço
4
...
Fornecedor
X
Serviço
X
92
Símbolos para Fluxogramas
Operação
Entrada
Preparação
Operação Manual
Conector Página
Dados
Decisão
Conector
Disco
Documento
Início/Fim
Arquivar
Processo
Extrair
Armazenamento
Acesso
Consulta
93
Mapa de Processo
Depto.1
Processo de Negócio
Início
Atividade 1
Decisão
Depto. 3
Depto. 2
Não
Sim
Atividade 2
Fim
Atividade 3
94
Mapa de
Processo
Processo de Pedidos de Venda
Unidade
Organizacional
Loja
Vendas
Evento
Pedido
Recebido
Pedido
Reigstrado
Atividade
Entrar
Pedido
Informação
Pedido do
Cliente
Processar
Pedido
Clientes
Regulares
Pedido
Pronto
Perguntar ao
Cliente
Vendas
Necessidade
de
Informações
Vendas
Informações
Recebidas
Preparar
Pedido
Suplementar
Pedido
Suplementado
95
Ciclo de Melhoria de
Processos
Análise do
Processo
Entendimento
do Negócio
Projeto do
Processo
Implementação
do Processo
(automação)
Gerenciamento do Processo
96
Benefícios para a Aplicação
da Tecnologia da Informação
Identificação clara do que deverá ser automatizado
Aponta a priorização das atividades a serem
automatizadas
Visão do todo com responsabilidades bem definidas
Garantia de automatização de um processo já
racionalizado e preparado para usar a TI
Necessidades de suporte de Sistemas de Informação já
identificadas (dados, políticas, normas, regras do
negócio, procedimentos, recursos, capacitação etc.)
Redução do tempo para obtenção da visão global.
97
UML: Casos de Uso
(UML Use Case)
A partir dos Processos de Negócio explicita
requisitos de usuários em partes
significativas.
Descreve a funcionalidade do sistema
percebida por atores externos ligados ao
Processo de Negócio.
Um ator interage com o sistema podendo ser
um usuário, dispositivo ou outro sistema.
O planejamento e a construção de sistemas é
realizado pela implementação de alguns
Casos de Uso em cada iteração.
98
UML: Casos de Uso
Técnica proposta por Jacobson (1992).
Conceitos básicos:
 Cenário: é uma seqüência de passos que
descreve uma interação entre um usuário e
um sistema.
 Caso de uso: é um conjunto de cenários
amarrados por um objetivo comum de um
usuário.
Base para testes dos requisitos do sistema.
99
UML: Casos de Uso
Características dos Casos de Uso:


Há um caso comum, em que tudo dá certo, e que
ocorre com mais freqüência.
Há casos alternativos, menos freqüentes, que
podem ocorrer quando algo sai fora do comum
(outros caminhos ou erros).
Captura de Casos de Uso:


Descrição do cenário primário como uma
seqüência de passos numerados.
Descrição descrição das alternativas, como
variações daquela seqüência de passos mais
comum.
100
UML: Casos de Uso –
Exemplo
Compra de um Produto na Web
1. O cliente navega pelo catálogo e seleciona itens
a serem comprados.
2. O cliente vai para o check out.
3. O cliente preenche o formulário para remessa.
4. O sistema apresenta a informação total
incluindo: faturamento, remessa, preços e
impostos.
5. O cliente preenche a informação de cartão de
crédito.
6. O sistema autoriza a compra.
7. O sistema confirma imediatamente a venda.
8. O sistema envia uma confirmação para o cliente
101
via e-mail.
UML: Casos de Uso –
Exemplo
Caso Alternativo 1 – Falha na Autorização:

No passo 6, o sistema falha na autorização da
compra por cartão de crédito. Permite ainda ao
cliente reenviar a informação do cartão de
crédito ou tentar novamente com outro.
Caso Alternativo 2 – Cliente Habitual


O sistema mostra a informação total e os quatro
últimos dígitos do cartão de crédito.
O cliente pode aceitar ou escrever por cima
destas opções e retornar para o Caso Comum no
passo 6.
102
UML: Diagrama de Casos de Uso
Sistema
«uses»
Caso de Uso
Ator
103
UML: Diagrama de Classes
(UML Static Structure)
Um dos mais importantes componentes da UML.
Mostra a estrutura estática de conceitos, tipos e
classes do sistema.
 Conceitos mostram como os usuários pensam
sobre o mundo real.
 Tipos mostram interfaces de componentes de
software.
 Classes mostram a implementação dos
componentes de software.
É considerado estático pois a estrutura descrita é
sempre válida para o sistema.
104
UML: Diagrama de Classes
Gráfico bidimensional de elementos de
modelagem que pode conter:
 Tipos
 Pacotes
 Relacionamentos
 Classes
Um diagrama de objetos é uma variação do
diagrama de classes que mostra objetos em
vez de classes.
105
UML: Diagrama de Classes
Pedido
-Número
-Data
+IncluirPedido()
+AtenderPedido()
Composição
Agregação
1
1..*
-Pedido
-Pedido -Cliente
0..*
1
Produto
-Item
-Produto
-Quantidade
+IncluirItem()
+CalcularT otal()
-Código
-Nome
-Limite Crédido
-Endereço
+Incluir()
+Avaliar()
Dados/Propriedades
Operações/Métodos
Multiplicidade
-Item
Item Pedido
Cliente
Associação
0..*
1
Hardware
-Código
-Nome
-Preço
-SaldoEstoque
+IncluirProduto()
+AtualizarPreço()
+AtualizarSaldo()
Software
Super Classe
Generalização
Suprimento
Subclasse
106
Diagrama de Classes - Exemplo
Person
-lastName : char
-firstName : char
-address : char
-city : char
-state : char
-zipcode : char
-phoneNumber :
char
-faxNumber : char
-email : char
Person::Employe
e
-salary : float
-cpfNum : char
-title : char
«event» +ir() :
float
Person::Client
Person::Supplier
-creditLimit : float
-creditCarg :
char
-expireDate
+prazo() : int:
char
-productName :
char
-productPrice : float
-cgcNum
: char
+salePrice()
: float
107
Cartões CRC
(Não fazem parte formal da UML)
Ajudam a chegar à essência do objetivo
de uma classe.
Bons para explorar como implementar
Casos de Uso.
Devem se utilizados para simplificar e
esclarecer detalhes.
Úteis para o entendimento de Classes e
Objetos.
108
Cartões CRC
Responsabilidade
PEDIDO
Colaboração
Verifique se os itens estão em estoque
Determine o Preço
Item Pedido
Produto
Verifique se o pagamento é válido
Despache para o endereço de entrega
Cliente
Cliente
109
UML: Diagramas de
Interação
(Sequence & Collaboration)
São modelos que descrevem como grupos de
objetos colaboram em algum comportamento
do sistema.
Tipicamente capturam o comportamento de
um único Caso de Uso.
Mostram vários objetos e as mensagens que
são passadas entre estes objetos em um
Caso de Uso.
Categorias de Diagramas de Interação:
 Diagramas de Seqüência
 Diagramas de Colaboração
110
UML: Diagramas de Seqüência
(UML Sequence)
Mostram o fluxo global de controle da
interação entre objetos através de
mensagens.
Permitem o entendimento da seqüência de
métodos em classes distintas que revela o
comportamento pretendido.
Ajudam o entendimento de processos
concorrentes.
As duas dimensões de um diagrama de
seqüência são tempo (vertical) e objetos
(horizontal).
111
UML: Diagrama de Seqüência
Entrada de Pedido
Pedido
Item de Pedido
Produto
Prepare()
Adicione Item()
VerificarEstoque()
RetirarEstoque()
Message1()
Item Reposição
Retorno OK()
PrecisaRepor()
Message2()
Item Entrega
112
UML: Diagramas de Colaboração
(UML Collaboration)
Mostra uma interação dinâmica de um Caso
de Uso organizada em torno de objetos e
seus vínculos mútuos.
Utiliza números de seqüência para evidenciar
a seqüência de mensagens.
Flechas indicam as mensagens enviadas
dentro de um dado Caso de Uso.
Mostra como objetos são ligados entre si.
Utiliza o layout de Diagramas de Classes ou
de Pacotes para esboçar a colaboração entre
objetos.
113
UML: Diagrama de Colaboração
Pedido
Item Pedido
Item Entrega
Produto
IncluirProduto()
Janela Entrada Pedido
Incluir()
Incluir()
Incluir()
VerificarEstoque()
AtualizarSaldo()
Item Reposição
114
UML: Diagramas de Estados
(UML Statechart)
Mostram como um único objeto se comporta
através de muitos Casos de Uso.
Mostra seqüências de estados que um objeto
ou uma interação assume em sua vida em
resposta a eventos, juntamente com suas
respostas e ações.
É um complemento de uma classe
relacionando os possíveis estados que objetos
da classe podem ter e quais eventos podem
causar a mudança de estado (transição).
115
UML: Diagrama de Estados
Registrando Pedido
Analise
requisitada
Analisando Pedido
Pedido não pode
ser atendido no
momento
Alterando Pedido
Cancelamento de Pedido
Pedido deve ser
cancelado
Pedido para
Aprovação
Pedido já pode
ser atendido
Pedido Pendente
Cancelamento
de Pedido
Solicitado
Alteração de
Pedido Solicitada
Pedido enviado
Aprovando Pedido
Eventos
Pedido deve ser
Atendido
Atendendo Pedido
Pedido Atendido
116
UML: Diagramas de
Atividades
(UML Activity)
Mostra comportamento com estrutura de
controle.
Pode mostrar:



Muitos objetos em muitos usos.
Muitos objetos em Caso de Uso único.
A implementação de métodos.
É um diagrama de estados especial onde a
maioria dos estados é de ação e a maioria
das transições é ativada por conclusão das
ações dos estados de origem.
Seu propósito é estudar fluxos dirigidos por
processamento interno, descrevendo as
atividades desempenhadas numa operação.117
UML: Diagrama de Atividades
Registrar
Pedido
Autorizar
Pagamento
Cancelar
Pedido
Atualizar
Estoqe
Aceitar
Pedido
118
UML: Pacotes
(UML Deployment)
Mostra grupos de classes e as
dependências entre elas.
Pessoa
Indivíduo
Organização
119
UML: Diagramas de Componentes
(UML Component)
São mostradas dependências entre
componentes de software.
Tipos de componentes:



Código-fonte
Código-binário
Executáveis.
120
UML: Diagrama de Componentes
Componente
da Interface 2
Componente
da Interface 1
Componente
de Negócios 1
121
UML: Diagramas de Implantação
(UML Deployment)
Mostra elementos de configuração de
processamento e os componentes de
software, processos e objetos que neles se
mantêm.
Inclui o uso físico do sistema considerando
computadores, dispositivos e suas
interconexões.
Mostram o layout físico dos componentes nos
nós de hardware.
122
UML: Diagrama de Implantação
ESTAÇÃO
CLIENTE
(PC)
Entrada do Pedido
SERVIDOR
WEB
Registro do Pedido
SERVIDOR
BANCO DE
DADOS
ESTAÇÃO
CLIENTE
(PC)
123
Relacionamento entre as
Técnicas de Modelagem
Revisão de
Processos
Use Case
Diagrama de
Classes
DTE
Pacotes
CRC
DI
Componentes
Implantação
124
Tecnologias de Implementação
Ferramentas CASE:

Rational Rose (Rational), Visio Enterprise (Microsoft) etc.
Linguagens Orientadas a Objetos:

Java, J++, J#, C#, VB.NET, C++ e Smalltalk
Ambientes de Desenvolvimento:





VisualAge for Java (WebSphere) (IBM)
Oracle Applications (Oracle)
Visual Studio .NET (Microsoft)
Visual Café (Symantec)
Jbuilder (Borland/Inprise)
Banco de Dados Orientado a Objetos:



O2 (O2 Technology)
Objectstore (Object Design Inc.)
Jasmine (Computer Associates)
125
Implementação de uma
Metodologia OO
Mudança de paradigma – requer treinamento
intensivo.
Protótipos sem compromisso.
Os primeiros sistemas devem ser “livres”.
Grupo formal de metodologia – proposta e
treinamento.
Acerto do ambiente de desenvolvimento –
suporte e padrões.
Administração de classes/objetos – Biblioteca
de Classes.
Ferramenta CASE.
126
Benefícios da OO
Reutilização de código.
Estabilidade.
O 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.
Novos mercados de software.
Desenvolvimento acelerado.
Integridade.
127
Benefícios da OO
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
sistemas e usuários.
Interoperabilidade.
Processamento Cliente/Servidor.
Processamento distribuído e paralelo.
Bibliotecas de classes industrializadas e
corporativas.
128
Fim! Obrigado e Sucesso!
129