Analise e Desenho Orientado A Objetos Com UML

com UML
Análise e Desenho
Orientado a Objetos
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Versão 27 |
Análise e Desenho Orientado a Objetos com UML
Conteúdo
Capacitação Engenharia de Software
Parte 1 - Principais Conceitos da Orientação a Objetos e introdução

UML
Parte 2 – Especificação de Requisitos de Software
Parte 3 – Analise Conceitual
Parte 4 – Desenho (design) do Modelo de Especificação de Software
Parte 5 – Arquitetura de Software

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br) 2
Principais Conceitos da
Orientação a Objetos e UML
Objetivo desta parte:
É apresentar e discutir os principais conceitos da
Orientação a Objetos e fazer uma breve introdução a UML

Todos os direitos reservados e protegidos © 2006 e 2007 3
Orientação a Objetos. Principais Conceitos:

Objetivo
Objetivo:
Apresentar os principais conceitos da orientação a objetos. Será demonstrado os seguintes
conceitos: Classes, Objetos, Atributos, Métodos, Abstração de Dados, Herança,
Polimorfismo, Encapsulamento, Associação e Interface.


Introdução. Desenvolvimento de Software Orientada a Objetos
Influência escolha da
Ferramentas
Ferramentas
Tecnologia OO
e
Artefatos
Atividades
Suporte as atividades
WorkFlows
Metodologia/Fases
Jacobson pyramid “rational enterprise philosophy”


Objetos do Mundo Real

Bem, podemos encontrar várias definições para o termo “objeto”, neste momento
podemos entender que:
“Objeto pode ser qualquer coisa na natureza que possua

características e comportamentos”
Veja alguns exemplos de objetos:
Pessoa Cão Partida Barco

de Futebol
Os objetos podem ser físico (aqueles que podemos pegar, exemplos: uma pessoa,
um animal, um barco, um livro, um carro, uma casa e etc) e os conceituais
(aqueles que não podemos pegar, tais como: cobrança de IOF, uma ligação
telefônica, uma conta corrente e etc...)


Objetos
O termo orientação a objetos significa organizar o mundo real

como uma coleção de objetos que incorporam estrutura de
dados (propriedades ou características) e um conjunto de
operações que manipulam estes dados.
Classes
Objetos Objeto: Pessoa Propriedades Operações
Atributos Nome
Andar
Correr
Métodos Data de Nascimento
Trabalhar
Massa (peso)
Abstração de Dados Altura
Chorar
Dançar
Herança
Polimorfismo Objeto: Pássaro Propriedades Operações
Encapsulamento Espécie Andar
Correr
Interface Cor das penas
Voar
Tamanho
Peso Pousar



Os objetos tem um identificador único (que podemos chamar de nome do objeto), tem
conjunto de propriedades (que podemos chamar de características e/ou atributos) e
comportamentos (que podemos chamar de operações).
Atributos
cor
Número chassi
Ano-fabricação
Identificador
Carro
Operações
acelerar
O que são operações ? parar
- Coisas que objeto deve
saber fazer


Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que
ele tem um estado
Atributos
cor branco
Número chassi VW1003G345
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar estado
parar



Os nomes dos objetos geralmente são substantivo no singular, tais como, cliente, conta-corrente,
pessoa e etc.
Os atributos também são substantivos, exemplo: cor, tamanho, peso, idade, número e etc.
Já as operações usualmente são verbos, como: acelerar, validar, verificar, calcular e etc
Atributos
cor branco
Substantivo
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar
parar
verbos



Modelagem de objeto:
Identificador Carro
Nome (identificador)
Representação na
Orientação a objetos
Carro
Atributos cor
número chassi
cor branco
ano-fabricação
Número chassi VW1003G345 Propriedades
acelerar (atributos)
Ano-fabricação 1966 parar
Operações
acelerar
parar Operações



Modelagem de objeto:
Para representar os objetos do mundo real criamos classes, E

aí partir destas classes podemos criar os “objetos”.
Podemos dizer que um objeto é uma “instance” (espécie) da
classe.
Carro As classes são “blueprint” (projeto) para os objetos. São fôrmas
cor de objetos.
número chassi
ano-fabricação O que é
acelerar uma classe ?
parar
Representação na
Orientação a objetos


Classe
Definição de Classe:
Uma classe descreve um conjunto de objetos que compartilham os
mesmos atributos, operações, métodos, relacionamentos e semântica
Classes
As classes são as partes mais importantes de qualquer sistema orientada a
Objetos objetos.
Atributos Usamos as classes para capturar o vocabulário do sistema que está em
desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do
Métodos problema, assim como as classes que fazem uma implementação. Podemos usar ainda
as classes para representar itens de software, de hardware e até itens que sejam
Abstração de Dados somente conceituais.
Herança Exemplo:
A classe Pessoa deverá ter atributos e métodos comuns
Polimorfismo
Encapsulamento Pessoa Nome da Classe
Interface nome Atributos
idade
getNome()
getIdade()
Nota: Dicionário Aurélio Métodos
Em programação ou modelagem orientada a objetos (v. orientação a objetos), categoria descritiva setNome()
geral, que abrange o conjunto de objetos que compartilham uma ou mais características quanto a
seus itens de dados e procedimentos associados. 22. Lóg. Agrupamento de objetos que têm uma ou
setIdade()
mais características em comum.


Classe
Exemplo de Classe:
3
1 Livro
Legenda:
Classes 1 – Objeto no mundo real
Objetos 2 – Classe Livro
3 – Objeto da classe Livro
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
2 ISBN 0747551006
Encapsulamento
Titulo: Harry Potter and the
Interface Order of the Phoenix
Autor: J. K. Rowling


Classe e Objeto
Classe e Objeto. Exemplo:
ISBN 0747551006
Titulo: O Poder da inteligência
Classes Emocional
Autor: Daniel Goleman
Objetos
Atributos
ISBN 0747551006
Métodos
Titulo: Harry Potter and the
Abstração de Dados Order of the Phoenix
Autor: J. K. Rowling
Herança
Polimorfismo ISBN 8571643512
Encapsulamento Titulo: AS JANELAS DO
PARATII
Interface Autor: Amir Klink
Uma coleção de livros

pode ser representada Cada livro desta coleção é
por uma classe chamada “instance” (objeto) da classe livro.
Livro.


Classe e Objeto
Identificador Carro
Classe (Modelo) Objeto (“instance”)

Carro fusca:Carro
cor cor=“branco”
Atributos número chassi número chassi=“VW1003G345
cor branco ano-fabricação ano-fabricação=1966

Acelerar()
Ano-fabricação 1966 parar()
Operações
acelerar
parar

Classe e Objeto
Classe
Classes
Cliente
Objetos nome
cpf
Atributos idade
Métodos
Herança
Objetos
Polimorfismo
Encapsulamento
Interface Cliente: clientemulher Cliente: clientehomem
nome = Marina nome = Felipe
cpf = 022.200.708-12 cpf = 039.217.908-22
idade = 16 idade = 42


Classe, Responsabilidade e Colaboração

Responsabilidades
Definição de Responsabilidades:
Um contrato ou obrigação em tipo ou de uma classe
Classes Ao criar uma classe você estará criando uma declaração de que todos os objetos dessa
classe têm o mesmo tipo de estado e o mesmo tipo de comportamento.
Objetos Em nível mais abstrato, esses atributos e operações são apenas as características com
Atributos quais as responsabilidades das classes executadas.
Métodos Uma classe chamada de Transação de Pagamento tem a responsabilidade pelo

conhecimento das informações inerente a operação, tais como número da
Abstração de Dados transação, situação, valor, data, tipo de pagamento e etc.
Herança
TransacaoPagamento
Polimorfismo numero
Encapsulamento valor
data
Interface situação
TipoPagamento
Responsabilidades
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...



Colaboração:
Definição de Colaboração:
Ás vezes uma classe precisa colaborar com outra classe para
Classes cumprir suas responsabilidades
A classe Transação de Pagamento tem a responsabilidade pelo conhecimento das
Objetos seguintes informações: número da transação, situação, valor, data, tipo de
Atributos pagamento e etc.
As informações sobre tipo de pagamentos estão outras classes que tem dados
Métodos especifica para cada tipo de pagamento. Exemplo: CartaoCredito e BoletoBancario.
Desta forma precisamos ter uma colaboração entre as classes para atender as
Abstração de Dados responsabilidades.
Herança
TransacaoPagamento CartaoCredito
Polimorfismo numero
Encapsulamento valor
data
Interface situação
TipoPagamento Colaboração BoletoBancario
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...



Classes, Responsabilidades e Colaboração:
As responsabilidades são apenas texto em formato livre. Na prática uma única
responsabilidade pode ser escrita como expressão, ou uma oração ou breve
parágrafo.
Classes O CRC (Cartão de Responsabilidade e Colaboração) é técnica para capturar e
representar as classes suas responsabilidade e colaborações.
Objetos Outra técnica que pode ser usada é a Análise baseada em Caso de Uso podem ser
Atributos usada.
Métodos
Abstração de Dados Nome da classe Cartão
Herança
Responsabilidades Colaborações
Polimorfismo
Encapsulamento
Interface Aluno
-- Deve conhecer os Matricula
dados dos aluno: Pessoa
Nome Curso
Número da Matricula
Curso


Resumo: Classe e Objeto

Resumindo:
Um objeto possui:
• um estado (definido pelo conjunto de valores dos seus
Classes atributos em determinado instante)
Objetos • um comportamento (definido pelo conjunto de métodos
Atributos definido na sua interface)
• uma identidade única
Métodos
Abstração de Dados Uma classe possui:
Herança • Atributos
Polimorfismo • Métodos
• Responsabilidades (o que ela sabe fazer)
Encapsulamento • Colaboração (interação com outras classes)
Interface


Atributo
Definindo Atributo:
• É uma características (propriedade) presente no objeto.

• Valor de todos os atributos é igual Estado do Objeto.
Classes
Objetos • Somente atributos que são de interesse do sistema devem ser
descritos na classe.
Atributos Cliente
Métodos nome
cpf
Abstração de Dados idade
Herança
Polimorfismo
Encapsulamento
Interface
Cliente: clientemulher
nome = Marina
atributos cpf = 022.200.708-12
idade = 16


Método
Escrevendo os métodos.
Para cada atributo é recomendado escrever um par de métodos, os nomes destes

métodos devem começar com setXXXX( ) e getXXX( )
Classes
Objetos setCodigo():
Atributos Para trocar o valor do atributo
Cliente getCodigo():
Métodos Para recuperar o valor do atributo
codigo
Abstração de Dados nome Exemplo:
Valor do atributo: nome = null
Herança getCodigo()
setNome(“Duke”).
setCodigo()
Polimorfismo Métodos getNome() Agora valor do atributo nome = “Duke”
Encapsulamento setNome() getNome(), retornará “Duke”
Interface


Método
Definição de Método:
Definição:
Método é a implementação de uma operação.
Classes Definição de Operação:
Objetos É a implementação de serviço que pode ser solicitado por qualquer
Atributos objeto da classe com a finalidade de afetar um comportamento.
Métodos Chamando os métodos
Para chamar um método de um objeto é necessário enviar uma mensagem para ele.
Abstração de Dados As mensagens identificam os métodos a serem executados no objeto receptor.
Herança Por definição todas as mensagens tem um tipo de retorno.
Polimorfismo
Encapsulamento ContaCorrente
Interface conta
saldo
setDeposito()
Métodos getSaldo()
setSaque()


Mensagem
Definição de Mensagem:
Definição:
Mensagem é uma chamada de uma operação sobre um objeto,
Classes compreendendo um nome de operação e uma lista de valores de
argumentos. (Rumbaugh)
Objetos
Atributos Um mensagem representa a requisição de um objeto remetente a um objeto receptor
para este último execute alguma operação definida para sua classe.
Métodos Essa mensagem deve conter informações suficiente para que a operações do objeto
receptor possa ser executada
Herança
Polimorfismo
Encapsulamento
Interface


Resumo: Métodos
Resumindo:
Os métodos são a implementação das operações de objetos.
Os métodos são responsáveis pelo comportamento do objeto.
Classes A mudança de estado de um objeto deve ocorrer através dos
Objetos métodos.
Atributos
Desta forma podemos dizer que os métodos “encapsulam” os
Métodos atributos.
Herança
Polimorfismo
Encapsulamento
Interface


Classe Concreta e Abstrata

Temos dois tipos de classes: Concreto
e Abstrato public class Pessoa {
Classe concreta: //Atributos
São aquelas classes que podem private String nome;
sofrer “instance” (criar objetos) e private int idade;
tem seus métodos implementados //métodos
public String getNome(){
por completo. return nome; }
E a Classe abstrata ? public void setNome(String

nome){
Bem, veremos a seguir o que é this.nome = nome; }
uma classe abstrata...
public int getIdade(){
return idade; }
public void setIdade(int

idade){
this.idade = idade; }
}


Exemplo:
Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas
e motos.
Estes veículos têm algumas características semelhantes como cor, peso, tamanho e capacidade de
carga. Entretanto cada veículo possui outras características diferentes como número de eixos sistema
de freio, tipo de motor e etc.
A abstração de dados é utilizada neste caso para identificar todas as propriedades comuns e reuni-las
em novo conjunto, isto lembra alguns princípios da matemática como fatoração.
Desta forma estaríamos fazendo um melhor aproveitamento de informações que se repetem e também
estamos fazendo que características diferente seja tratada de forma diferenciada.
O que é
abstração
de dados ?


Definição de Abstração de Dados:
Definição de abstração:
“Habilidade mental que permite aos seres humanos visualizarem os problemas
Classes do mundo real com vários graus de detalhe, dependendo do contexto corrente do
Objetos problema. (Jim Rumbaugh).
Atributos Qual é a função da abstração ?

A função da abstração é capturar as propriedades e os comportamentos essenciais,
Métodos como se fosse uma fatoração, desta forma determina-se o que é importante e o que
não é.
Exemplo
Herança
Polimorfismo
Veículo
Encapsulamento
Abstração
Interface
Navio Avião
especialização


Exemplo de Abstração de Dados:
Abstração: nos ajuda a lidar com a complexidade.

Classes Exemplo
Objetos Generalização
Atributos MeiodeComunicação
Métodos
Herança Carta Telefone Jornal
Polimorfismo
Encapsulamento
Interface
Especialização
As classes Contribuinte e MeiodeComunuicação neste caso são abstratas e
ambas podem representam um domínio.


Abstração de Dados:
Uma classe abstrata é uma classe que:
• Provê organização
Classes • Não possui “instances”, ou seja, não possui objetos.
• Possui uma ou mais operações (métodos) abstratas
Objetos
Atributos public abstract class ContaBancaria extends Object {
public ContaBancaria() { }
Métodos protected int numerocontacorrente;
Abstração de Dados public abstract int getNumeroContaCorrente();

public abstract void setNumeroContaCorrente(int numerocontacorrente);
Herança }
Polimorfismo
Encapsulamento
Interface


Veja agora a classe Pessoa, que é public abstract class Pessoa {
abstrata, pois, possui um método //métodos
public abstract String getNome()
abstrato.
public void setNome(String nome){
this.nome = nome;
}
Um método abstrato não possui public abstract int calcIdade(Date
public abstract int getIdade()
implementação somente assinatura d1, Date d2);
(declaração) public void
public void setIdade(int
setIdade(int idade)
idade)
{ {
this.idade = idade;
this.idade = idade;
} }
Um método concreto possui implementação

assinatura e implementação.


Resumo: Abstração de Dados

Resumindo:
Uma classe abstrata deve ter pelo menos um método abstrato.
Mas, poder ter outros métodos que não são abstrato, são os
Classes métodos concreto.
Objetos Uma classe abstrata não possui “instance”
Atributos
Métodos
Abstração de Dados Como eu faço
Herança
para usar uma
Polimorfismo
Encapsulamento classe abstrata ?
Interface


Comparação entre Classe Abstrata e Classe Concreta
Classe Abstrata Classe Concreta
Os métodos podem ser assinados e

Os métodos devem ser somente assinados
implementados
Não pode sofrer “instance” Poder sofrer “instance”
Relacionamento somente através de

Todos os tipos de relacionamentos
HERANÇA


Herança
Definição de Herança:
Definição:
Mecanismo baseado em objetos que permite que as classes compartilhem atributos
Classes e operações baseados em um relacionamento, geralmente generalização.
(Rumbaugh)
Objetos
Atributos Uma classe derivada herda a estrutura de atributos e métodos de sua
classe “base”, mas pode seletivamente:
Métodos • adicionar novos métodos
• estender a estrutura de dados
Abstração de Dados • redefinir a implementação de métodos já existentes
Herança
Uma classe “pai” ou super classe proporciona a funcionalidade que é comum a todas as
Polimorfismo suas classes derivadas, filhas ou sub classe, enquanto que uma classe derivada
proporciona a funcionalidade adicional que especializa seu comportamento.
Encapsulamento
Interface Exemplo:
Animal
Animal Doméstico Animal Selvagem


Herança
Exemplo de Herança:
Classes
Podemos dizer que Pós-
Objetos Hierarquia de Classes Graduação é tipo de Curso
Universitário, assim como
Atributos Super classes Curso Curso de Especialização ou
Métodos Universitário de Extensão.
Sub classe
Herança Graduação Pós-Graduação
Polimorfismo extends
Encapsulamento
Interface Especialização Extensão


Polimorfismo
Definição de Polimorfismo:
Definição:
“Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade

Classes segundo o qual uma operação pode comportar-se diferentemente em classes
diferentes” (Rumbaugh)
Objetos O polimorfismo é o responsável pela extensibilidade em programação orientada a
Atributos objetos.
Promove o reúso.
Métodos Exemplo:
Herança
Billhetagem Telefone Móvel
Polimorfismo
Encapsulamento calcularConta(telefone)
Interface
Telefone Fixo


Polimorfismo
Overloading de Método
Possibilidade de reúso do nome do método para diferentes implementações, em
tempo de execução, a aplicação, escolherá o método adequado para cada
Classes chamada, veja o exemplo.
Objetos
Atributos TesteSoma Soma
Métodos
somar(int a, int b)
Abstração de Dados somar(float a, float b)
Herança somar(char a, char b)
somar(long a, long b))
Polimorfismo
Encapsulamento
Interface
Para cada tipo de dados existe um método, o reúso do nome do método é permitido,
entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método
somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta
forma evitaremos problemas como ambigüidade.


Polimorfismo
Overridde de Método
Uma subclasse pode mudar o comportamento herdado da Superclasse, ou

seja, um método herdado poderá ser modificado. Veja o exemplo abaixo:
Classes
Objetos Conta Bancária
Atributos getSaldo()
Métodos
Herança Conta Corrente Conta Poupança Investimentos
Polimorfismo getSaldo() getSaldo() getSaldo()
Encapsulamento O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada tipo de
Interface Conta ele tem uma implementação diferente. Por exemplo:
- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) -
saques
Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros) -
saques
Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior +
juros) - resgates - ir


Principais Conceitos
Encapsulamento
Definição de Encapsulamento:
É uma proteção adicional dos dados do objeto de possíveis modificações

impróprias, forçando o acesso a um nível mais baixo para tratamento do dados.
Classes
Objetos Public
Atributos Operações/métodos/interface
Métodos
Herança
Polimorfismo
Encapsulamento Private
Dados/Atributos/propriedades
Interface
Exemplo:
Quanto temos um arquivo protegido por senha de acesso, podemos dizer que ele está
protegido, pois, apenas podemos lê-lo sem fazermos alteração


Encapsulamento
Benefícios do Encapsulamento:
Benefícios
- Segurança:
Classes Protege os atributos dos objetos de terem seus valores corrompidos por
outros objetos.
Objetos - Independência:
Atributos “Escondendo” seus atributos, um objeto protege outros objetos de
complicações de dependência de sua estrutura interna
Métodos
Herança Pessoa
Polimorfismo nome
idade setNome() nome getNome()
Encapsulamento
setNome()
Interface getNome()
setIdade() setIdade() idade getIdade()
getIdade()
encapsulamento


Interface
Definição de Interface:
O que é interface ?
Classes Interface é um contrato entre o cliente (classe) e uma interface. Este

contrato é garantia que o métodos assinados na interface serão
Objetos implementados na classe cliente.
Atributos
As interfaces são consideradas a forma mais pura de abstração de dados,
Métodos pois, somente podemos assinar (declarar) os métodos. Podemos usa-las
Abstração de Dados também para prover:
Herança - Organização e padronização de assinatura de métodos;
- Simular herança múltipla e
Polimorfismo - Fazer relacionamentos de classes com responsabilidade distintas.
Encapsulamento
Interface


Interface
Exemplo de Interface:
Representação:
Classes
<<interface>>
Objetos Codigo
realização
Atributos getcodigo()
setcodigo()
Métodos
Herança Contrato
Polimorfismo Produto cpf Fornecedor cnpj

Encapsulamento
getcodigo() getcodigo()
Interface setcodigo() setcodigo()

Introdução a aOrientação
Orientação Objetos. aPrincipais
Objetos Conceitos:
Interface
Principais Características
Características de uma interface:
Classes •Não possui implementação própria.

•Ela define operações, mas não os métodos.
Objetos •Uma interface especifica, usualmente, uma parte limitada do comportamento de uma
classe ou componente.
Atributos •Uma classe pode realizar várias interfaces.
Métodos Porque utilizar interfaces:
Abstração de Dados • Reduz o acoplamento (dependência) entre classes, aumentando a sua
Herança reusabilidade.
• Permite que componentes possam ter diferentes interfaces de acordo com as
Polimorfismo necessidades dos seus usuários.
• Ajuda a esconder a complexidade da arquitetura de componentes.
Encapsulamento • Oferece uma forma simplificada de implementar herança múltipla.
Interface

UML. Linguagem de Modelagem Unificada

A versão da UML abordada é versão 1.5


Introdução
Por que fazer a modelagem?
Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.

Com a modelagem, alcançamos alguns objetivos:
1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja;
2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema;
3 - Os modelos proporcionam um guia para a construção do sistema;
4 - Os modelos documenta o sistema.
O Que é Modelagem Visual?
“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)


Introdução
O Que é Modelagem Visual?
Modelagem visual significa modelar com a utilização de notações padrão.
Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada.
UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das
mais populares do momento.
A UML (Linguagem de Modelagem Unificado) é

padrão mantido pelo OMG (www.omg.org/uml).


Introdução
A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração
da estrutura de projetos de software. A UML poderá ser usada para:
•Visualização
•Especificação
•Construção de modelos e diagramas
•Documentação.
A UML é adequada para a modelagem de sistemas, cuja a abrangência poderá incluir

sistemas de informação corporativos a serem distribuídos a aplicação baseadas em Web
e até sistemas complexos embutidos de tempo real.
A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para
desenvolvimento de software. Ela é independente do processo, apesar de ser
perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura,
iterativo e incremental.


Principais Digramas:
ESTÁTICOS
. Diagrama de Classes
. Diagrama de Objetos Modela a estrutura do sistema
. Diagrama de Componentes
. Diagrama de Distribuição
DINÂMICOS
. Diagrama de Casos de Uso

. Diagramas de Interação Modela o comportamento do sistema
- Diagrama de Seqüência
- Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados


Processo de Desenvolvimento:
Processo de Desenvolvimento
Modelo Casos Modelo Objetos

Modelo de Classes
Uso de Negócio de Negócio
Análise Desenho
Necessidades dos Visão Modelo de dosRealização
Casos de Uso Classes Classes
Stakeholders Casos de Uso
Casos de Teste
Componentes
Defeitos Script de Testes


A Linguagem:
• Linguagem = Sintaxe + semântica
– syntax = rules by which language elements (e.g., words) are assembled
into expressions (e.g., phrases, clauses)
– semantics = rules by which syntactic expressions are assigned
meanings
• Notação = (UML Notation Guide) – define uma sintaxe gráfica UML
• Semântica = (UML Semantics) – define uma semântica UML


Elementos:
• Elementos estruturais:
– classe, interface, colaboração, caso de uso, classe ativa, componente,
nó
• Elementos comportamentais:
– interação, máquina de estados
• Elementos de agrupamento:
– pacote, subsistema


Visões:
Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
Conceitual Físico

Visões:
Visão de Caso
de Uso
• A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema
conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica
realmente a organização do sistema de software. Porém , ela existe para especificar as forças que
determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão
são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são
representados em diagrama de interação., diagrama de gráfico de estados e diagrama de
atividades
Visão de Projeto
• A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do

problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os
requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários
finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de
objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de
atividades.

Visões:
Visão de Processo
• A visão do processo abrange os “threads” e os processos que formam os mecanismos de

concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões
de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos
estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do
projeto, mas o foco voltado para as classes ativas que representam esses threads e processos.
Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser
programas ou parte.
Visão de Implementação
• A visão de implementação de um sistema abrange os componentes e os arquivos utilizados

para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o
gerenciamento da configuração das versões do sistema, compostas por componentes e
arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para
a produção de um sistema executável.


Visões:
Visão de Implantação
• A visão de implantação de um sistema abrange os nós que formam a topologia de hardware em

que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a
instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa
visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em
diagramas de interações, de gráfico de estados e diagramas de atividades.
Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes
participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes
interessem. Essas cincos visões também interagem entre si, por exemplo:
Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez,
representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões
de projeto e de processo.


Exemplo: de Projeto Software Orientado a Objetos:
Use case view Formulários
unidades Diagrama de Seqüência e/ou

Diagrama de Colaboração
Casos de Uso
Diagrama de Estado
Logical view Diagrama de Atividades
Diagrama de Pacotes
Diagrama de Estado
Diagrama de Classes Diagrama de Atividades
Diagrama de Pacotes
Component view
Diagrama de Componentes
Deployment view
Diagrama de Deployment


Big Picture. Requisitos e Análise

Business Case Coleta de Requisitos Análise Conceitual
Modelo Conceitual
Documento
de Visão
Engenharia de Requisitos
4
Análise de Requisitos Especificação de Requisitos

(Visão de Caso de Uso)
Requisitos Funcionais
Glossário de
conceitos
Casos de Uso
Requisitos Não
Funcionais Arquitetura Inicial


Introdução. Artefatos:
Produtos dos Workflows de Requisitos e de Análise:
Documento de Visão
Documento de Requisitos
Requisitos
Especificação de Requisitos (Casos de Uso)
Modelo Conceitual ou Modelo de Domínio
Análise Vocabulário do Sistema
Modelo de Arquitetura Inicial


Big Picture. Análise & Projeto

Análise Projeto (Visão Lógica)
Modelo Conceitual Diagrama de Classes
Receber Pedido
Preencher Pedido Enviar Fatura
Entrega
[pedido urgente] [senão]
Receber Pagamento
Entrega durante Entrega Regular
Especificação de Requisitos a noite

: FormBusca : Categoria : Produto : Catalogo
: visitante
getDescricao( )
exibirCategoria( )
selecionarCategoria
getDescricao( ) getQuantidade( )
exibirProduto( )
Encerrar Pedido
selecionarProduto( )


Projeto
Principais Produtos (Artefatos):
Diagrama de Sequência / Colaboração
Diagrama de Atividades
Diagrama de Estados
Diagrama de Classes


Big Picture. Projeto &Arquitetura

Projeto (Visão Lógica) Arquitetura
Diagramas Projeto (Visão de Componentes e
Visão de Deployment)
Receber Pedido

: visitante
getDescricao( )
Entrega
exibirCategoria( )
selecionarCategoria [pedido urgente] [senão]

Receber Pagamento
exibirProduto( )

a noite
Encerrar Pedido


Arquitetura
Principais Produtos (Artefatos):
Diagrama de Distribuição(Deployment)
Modelo de Arquitetura

Especificação de Requisitos
de Software
É apresentar e discutir o Ciclo de Requisitos de Software:
– Elicitação, Análise, Especificação de Requisitos de
Software com Caso de Uso

Introdução Análise e Desenho Orientado a Objetos com UML
Análise de Requisitos: Introdução
Um entendimento completo dos requisitos de software é essencial para um o sucesso do
desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado
seja, um programa mal analisado e especificado frustrará o usuário.
Análise de requisitos é um processo de descoberta, refinamento, modelagem e
especificação.
O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado

durante o planejamento do projeto de software, é aperfeiçoado em detalhes.
Modelos, diagramas, fluxos são criados para melhor compreensão do problema.
O analista e o usuário desempenham um papel ativo na análise e especificação de
requisitos.
O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às

vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e
solucionador de problemas.
Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente
simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as
oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.
O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a
declaração de um cliente anônimo:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo
que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”
Ferramenta de Desenvolvimento de Software

Big Picture. Requisitos

Modelo Conceitual
Documento
de Visão
4

Glossário de
conceitos
Casos de Uso
Restrições Requisitos Não


Workflow Requisitos
Requisitos
Workflow Artefatos Papéis
Arquitetura Documento de Visão
Analista de Sistema
Analista de Requisitos
(Casos de Uso)

Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a mais parte mais critica
do processo de desenvolvimento de software.
Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise
de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.

Requisitos
Definições de requisito (segundo IEEE)

1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um
problema ou alcançar um objetivo.
2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema
ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação
ou outros documentos impostos formalmente.
3) Uma representação documentada de uma condição ou capacidade, conforme os itens

(1) e (2).

Requisitos
Requisitos. Road Map
Fazer identificação e elicitação

Regras de
negócio
de requisitos
Documento de Visão
Fazer Análise de Requisitos

Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos
Documentos Fazer Validação de Requisitos
Documento de
Especificação
de Requisitos
Requisitos
Identificação e elicitação de Requisitos:

Por que o “elicitação” é importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitação de
requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou
fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema.
Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é
elaborada de forma metodológica, geralmente tem uma abordagem intuitiva.
Principais características de uma “boa elicitação de requisitos”:
• Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros;

• Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e
Qualidade;
• Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo:
Clientes, Fornecedores, Usuários e o Patrocinador.
• Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.
Uma Simples Comparação:

Elicitação Boa Elicitação Ruim
Bom Diagnóstico Diagnóstico ineficiente
Soluções eficientes Soluções medíocres

Satisfação dos usuários Insatisfação dos usuários
Melhoria dos processos e redução de custo Problemas operacionais e financeiros
Requisitos

Documento (Artefato) desta etapa: “Documento de Visão”
Participantes:
Analistas e
documentos Objetivo:
Especialista reuniões
em Negócios Descrever
a visão inicial
Participantes: identificação/
do software
Usuário, elicitação de
Clientes, Requisitos
Fornecedores e Documento
Patrocinadores de visão
entrevistas

Requisitos

As fases da Identificação/Elicitação de Requisitos:
Um projeto de elicitação de requisitos têm as seguintes fases:
Identificar Fontes
Como deve ser feito ? Planejamento Técnicas
Elicitação de Identificar Funcionalidades

O que devo coletar ?
Requisitos Identificar Restrições e Riscos
Como devo documentar ? Documentação
Documento de Visão

Requisitos

As informações podem ser identificadas ou encontradas em diversas fontes:
- Usuários;
- Documentos;
- Especificações;
- Clientes;
- Patrocinadores;
- Analista de Negócios (“Domain Experts” - Especialista em uma ou mais área de negócio)
Quais são as técnicas ?
Existem várias técnicas, todas elas possuem seus

próprios conceitos, vantagens e desvantagens,
que podem ser usada nesta atividade entre elas estão:
- Reuniões;
- Entrevistas;
- Questionários;
- Workshop;
- Brainstorming;
- JAD (Join Application Development)
- Fast;
- Documentos;
- Sistemas Legados.
Análise de Requisitos

Identificação dos Requisitos: Tipos de Requisitos
Os Requisitos de Software podem ser divididos em duas categorias:
Requisitos
Requisitos Requisitos
Funcionais Não-Funcionais
Os requisitos funcionais descrevem o que o Os requisitos não funcionais dizem respeito as
sistema deve fazer, isto é, as funções características que descrevem qualidade do serviço
(funcionalidades) necessárias para atender os (QoS).
objetivos. O que sistema deve saber fazer. A omissão ou esquecimento desses requisitos constitui
Exemplos: Buscar cliente, Registrar pedido uma das principais razões de uma eventual
Calcular conta de consumo, Calcular tributos e insatisfação dos usuários com relação a um software.
etc. Os Requisitos Não Funcionais (RNF) também são
chamamos de “Requisito Suplementares.”
Exemplos: performance, disponibiliade, confiabilidade,
segurança, usabilidade e etc.

Requisitos

Identificação dos Requisitos:
Os requisitos de software podem ser identificados no texto da “declaração do
problema” (geralmente são verbos que identificam algumas ações).
Este documento possibilita a identificação, extração e

classificação dos requisitos
- Requisitos funcionais e
- Requisitos não funcionais.
Texto da Declaração do Problema

Requisitos

Documento de Visão: Exemplo: Documento de Visão:
Data: ________ | Autor: ________ | Revisão: ____
Objetivo: Índice:
Fazer uma descrição da visão da solução 1.0 - Introdução
1.1 Objetivo do documento
Este documento tem as seguintes seções: 1.2 Escopo
-Entendimento do Problema; 1.3 Abreviaturas, Siglas e etc.
- Lista dos Stakeholders 2.0 Entendimento do Problema (Contexto)
- Lista dos Requisitos 2.1 Declaração do Problema
- Lista dos Riscos 2.2 Diagrama de Contexto
- Lista das Restrições 3.0 Lista de Stakeholders
3.0 Usuários
3.1 Entidades
4.0 Lista dos Requisitos
4.1 Requisitos funcionais
4.2 Requisitos não funcionais
5.0 Lista dos Riscos
6.0 Lista das Restrições
6.1 Software
6.2 Hardware
6.3 Ambiente e Tecnologia
Requisitos

Regras de
negócio
de requisitos
Documento de Visão

Usuários e
Clientes
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Requisitos
Análise de Requisitos: Introdução

A análise de requisitos procura sistematizar o processo de definição de requisitos.
Essa sistematização é necessária porque a complexidade dos sistemas exige que se preste mais
atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma
definição para requisitos é apresentada a seguir.
O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos algumas
razões:
- Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais critica
do processo de desenvolvimento de software.
A Análise de Requisitos deve ser:
Correta: Quando cada requisito expresso nela for encontrado no software;
Não Ambígua: Cada requisito deve ter somente uma interpretação (definição);
Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos

relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais)
Consistente: Quando não existir conflito entre os requisitos;
Verificável: Quando for possível verificar/validar cada requisito;
Modificável: Quando os requisitos podem ser facilmente alterados.

Requisitos
Análise de Requisitos
Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades,
classificando e detalhando os requisitos encontrados na coleta.
Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.
Detalhar os
Classificar os
Requisitos não Funcionais
Descrever os Usuários
e Entidades Externas
Fazer Plano de Redução

de Risco

Requisitos
Análise de Requisitos. Detalhar

Requisitos Funcionais:
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para
esta atividade. Veja o exemplo:
Lista de Requisitos funcionais
Autor: Revisão: Data Atualização:
Nome Código Descrição

Fazer Reserva RF01E Esta funcionalidade deverá permitir o usuário (funcionário)
a fazer reserva de apartamentos, as ações que estarão
disponíveis são: criar, remover, alterar e consultar reservas.
Cada reserva deverá ter um cliente e um apartamento e
respectiva período)

Requisitos

Descrição das Regras de Negócio
Nome do Projeto Serviço de Atendimento e Reserva de Apartamento
Objetivo
Descrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.
id Nome da Regra Descrição da Regra de Negócio
A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de

RN01 Registrar Reserva de 25% do valor da estadia.
Apartamento Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem
preferência de data e tipo de apartamento.
No período de baixa a estação (de mar a jun e ago a nov) o valor da diária tem um
desconto de 40%.
Para que agilizar o atendimento manter a satisfação do cliente as consultas de reserva devem
ser feitas em no máximo 30 segundos.
Data Nome / Equipe Versão Status
Os código permitem a rastreabilidade 01/01/08 RFS 2.1 Vigente
Requisitos Funcional
RN: RN01 Nome: Reserva Descrição: Serviço de Atendimento e Reserva de Apartamento
ID Nome Descrição
RFC01 Registrar Reserva Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos,
de Apartamento as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.

Requisitos
Análise de Requisitos. Classificar

Requisitos Não Funcionais:
Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos
categorizar estes requisitos, as mais frequente são:
- Performance:
Tempo de resposta
- Segurança:
Uso de senhas, certificados digitais e etc..
- Usabilidade:
Identidade Visual e Interfaces amigáveis
- Disponibilidade:
O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha
- Flexibilidade:
Capacidade de adaptação quando um requisito muda
- Portabilidade:
Capacidade de se adaptar a outros ambientes (sistemas operacionais)
- Escalabilidade:
Capacidade de responder aumento de carga (novos usuários)
Outras categorias como Integração, Processamento, Manutenível e etc.

Requisitos
Análise de Requisitos. Classificar e Detalhar

Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos
funcionais, precisamos ter um padrão
Lista de Requisitos Não funcionais
Categoria: Performance

Req. Funcional
Código Descrição
Fazer As consultas que serão realizadas pelo cliente não poderão

RNFP1
Consulta exceder ao tempo de resposta de 15 segundos
Por que preciso de um código ?

Este código tem como objetivo facilitar a “rastreabilidade”.
Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta
forma conseguiremos identificar qual é o caso de uso que realiza este
RNF, no caso de mudanças.

Requisitos
Análise de Requisitos. Classificar e Detalhar

Continuação:
Lista de Requisitos Não funcionais
Categoria: Usabilidade
RF /
Código Descrição
Aplicação
As cores, as fontes e logotipos devem seguir o Manual de
Aplicação RNFU1
Identidade Visual da empresa.
As interfaces com usuário devem seguir padrão de interfaces

Aplicação RNFU2
estabelecido pelo Manual de Sistema

Requisitos

Lista de Stakeholders:
Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de
decisão ou participam direta ou indiretamente do processo de construção do software.
Mais uma vez criaremos um formato padrão. Veja o exemplo:
Lista de Stakeholders
Nome Descrição
Cliente São todas as pessoas físicas ou jurídicas que fazem reservas
É qualquer pessoa que presta algum tipo serviço para

Colaborador
empresa

Requisitos

Lista de Stakeholders:
Continuação:
Lista de Entidades Externas
Nome Descrição
Administradora de Entidade que faz validação de um cartão de crédito presente

Cartão de Crédito em transação de pagamento.
Plano de Redução de Riscos:

Precisamos elaborar um Plano de Redução de Risco, para os risco que já foram
identificados. Este plano deve detalhar como mitigar os riscos identificados.

Requisitos
Análise de Requisitos. Artefato

Documento de Requisitos: Exemplo:Documento de Requisitos:
Data: ________ | Autor: ________ | Revisão: ____
Objetivo:
Classificar, descrever os requisitos de
Índice:
software, usuários e entidade externas e
1.0 - Introdução
elaboração do plano de redução de risco.
1.1 Objetivo do documento
1.2 Escopo
Este documento tem as seguintes
2.0 Requisitos Funcionais
seções:
- Requisitos Funcionais
3.0 Requisitos Não Funcionais
- Requisitos Não Funcionais 4.0 Lista Stakeholders
- Lista dos Stakeholders 4.1 Usuários
- Plano de Redução de Risco 4.2 Entidades
5.0 Plano de Redução de Riscos

Requisitos

Regras de
negócio
de requisitos
Documento de Visão

Usuários e
Clientes
Documento de
Fazer Especificação de Requisitos Requisitos
(Casos de Uso)
Documento de
Especificação
de Requisitos
Requisitos
Especificação de Requisitos:
O produto que devemos ter após Análise de Requisitos é a “A especificação de Requisitos” é feita
através de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso é importante
para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”)
a ser oferecida pelo sistema, ou seja, um serviço.
Requisitos Não
Documento
Funcionais
Requisitos
Funcionais
de Visão
Documento de
Requisitos
Modelo de
Comportamento externo Casos de Uso Arquitetura
do Software
Comportamento interno Seqüência Colaboração
Estrutura Classes
Implementação Distribuição
Requisitos
Análise de Casos de Uso:
•Casos de uso expressam o diálogo entre os usuários e o sistema
•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.
•Casos de uso formam a base para testes e documentação do sistema
•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus
relacionamentos.
•As técnicas para criar e expressar casos de uso em uma aplicação Web são as
mesmas para construir outros sistemas de software.
Objetivos:
• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.

Requisitos
Transformar os Requisitos
Funcionais em Casos de Uso:
Calcular Total
Fazer Cadastro
Cliente
Funcionário
Fazer Pedido
Emitir NF
Requisitos
Atividades e Passos:
Fazer Diagrama de
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever cenários
Rational Rose
Escrever Formulário
Fazer Diagrama de
Caso de Uso

Requisitos
Casos de Uso
Introdução:
Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema.
Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o
entendimento do contexto dos requerimentos do sistema.
Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional.
O que são Caso de Uso?

São diagramas de que permitem visualizar, especificar e documentar o comportamento de um
elemento. Esses diagramas fazem com que sistema, subsistemas e classes fiquem acessíveis e
compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem
com sistema.
Definição:
Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um
sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma
elipse.
Caso de Uso Os nomes de casos de uso

Gerenciar são breves expressões verbais
Reserva ativas.
Usuário
Ator
Nome
Requisitos
Casos de Uso
Casos de Uso e Cenários:
Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários
caminhos para completar esta função. Um cenários é como uma “instance” do Caso de uso, isto é, um
caminho lógico com início e fim.
Principais características:
- Cenários não contém declarações condicionais;
- Pode ter mesmo começo, mas, com final diferente;
- Um cenário é narrativa de uma situação e
- Os cenários devem descrever os bons caminhos e maus também.
Exemplo: Autorização de acesso.

O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a identificação
do usuário, ou seja, seu nome e sua senha, O usuário informa seu nome e sua senha, o sistema
valida as informações e dá a autorização de acesso ao Sistema.
Se senha for invalida ou nome neste caso teremos um novo cenário.

Requisitos
Casos de Uso
Casos de Uso e Fluxo de Eventos:
Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz,
ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter clara a separação
de questões entre a visão interna e externa.
Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto
de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao
escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e
quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento.
Tipos de fluxos:
• Fluxo de eventos principal e
• Fluxo alternativo de eventos.
Tipicamente descrevemos um fluxo de eventos para um caso de

uso. Os fluxos de eventos ajudam a compreensão dos requisitos do
sistema, entretanto, você desejará utilizar os diagramas de
interação para especificar esses fluxos graficamente. Além disso,
você também utilizará um diagrama de seqüência para especificar
o fluxo principal de um caso de uso e variação deste diagrama para
especificar os fluxos excepcionais.

Requisitos
Casos de Uso
Casos de Uso e Formulário:
Os formulários devem ter as seguinte informações:
- Ponto de ativação (momento que caso de uso começa)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pré-condição
- Fluxo Normal
- Fluxo Alternativo
- Pós-condição.
Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.

Exemplos:
- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso

Requisitos
Casos de Uso
Exemplos de Casos de Uso:
Manter informações dos

Manter informação de cursos
aluno
Gerente
Gerar catalogo
Manter informação de
professor
Pedir lista dos

matriculados
Sistema de
cobrança
Matrícula nos
Cursos
Professor
Aluno
Selecionar curso
para ensinar

Requisitos
Casos de Uso
Casos de Uso e Formulário Nome: Fazer Busca Produto
Ponto de ativação: Este caso de uso começa quando entra na página
Exemplo: de Busca e seleciona um item da caixa de seleção
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pré-condição: Aplicação Disponível
Fluxo Normal:
1 - O visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as informações sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem “produto não encontrado”
Pós-condição: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto
Requisito Não Funcional: ---
Requisitos
Casos de Uso
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de
uso desempenham quanto interagem com esses casos de uso. Geralmente um
ator representa um papel, que pode ser de pessoa, de um sistema ou de um
dispositivo e etc...
Cenários:
É narrativa de determinado fato ou de uma situação.
“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos
cenários quantos forem necessários para se entender completamente todo o
sistema. Podem ser considerados como teste informais para validação dos requisitos do
sistema.”
Formulário:
É a representação estruturada de um ou mais cenários

Requisitos
Casos de Uso. Relacionamentos

Organização dos Casos de Uso:
Os casos de uso também podem ser organizados pela especificação de relacionamento de
generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade
de fatorar o comportamento comum (obtendo esse comportamento a partir de outros casos de uso que
ele inclui) e fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem)
Generalização:
Entre os casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o
comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo
fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
* Use (obsoleto): Especifica que a semântica do elemento de origem depende da

semântica da parte pública do destino. Substituído pelo include.
Requisitos

Generalização:
Podemos usar a generalização entre casos de A generalização também pode ser aplicado aos
uso, pelo mesmo motivo que utilizamos atores e seus respectivos papéis. Veja o exemplo:
nas classes, para compartilhar comportamento:
Receber Pagamento
generalização
Funcionário
Pagto Cartão de Crédito Pagto Cartão de Débito
Gerente de
Recepcionista
Reservas

Requisitos

Extends:
Podemos usa-lo para “Demonstrar Variação de Comportamento”:
Cada uma das extensões descreve as diferentes maneiras com que um passo do
caso de uso pode ser executado. Variação de Comportamento. Exemplo:
Locadora de Automóveis Sala de Conferência
Devolver Veículo Fazer Ligação
Usuário
<<extend>>
<<include>> <<extend>>
<<include>>
Alterar status do carro Consulta Cliente Calcular Multa Fazer Ligação

(Conference call)

Requisitos

Explicando o estereotipo “include”
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora
explicitamente o comportamento de outro caso de uso em uma localização especificada na base.
O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de alguma
base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o obtém o
comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento de inclusão para
evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um caso
de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta
um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois,
permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de
responsabilidade sempre que precisamos utilizar essa funcionalidade.
Exemplos:
Fazer Pedido Fazer Check IN Fazer Check OUT
<<include>> Validar Usuário
Gerenciar Receber
Acompanhar Pedido Pagamento
Reserva <<include>>
<<include>>
<<include>>

Requisitos
Casos de Uso
Casos de Uso - Identificação de Atores
Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa
que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode:

- Apenas fornecer informações ao sistema
- Apenas receber informações do sistema
- Fornecer e receber informações ao sistema
Tipicamente os atores são identificados nas Declarações de Problemas (Documento

de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo,
como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio,
por exemplo.
As seguintes questões podem ser usadas para identificar o atores:
- Onde o sistema será usado ?
- Quais áreas serão usuárias do sistema ?
- O sistema usará recurso externo ?
- Quem será o responsável pelo sistema ?
- Quem serão os usuários do sistema ?
Requisitos
Casos de Uso.Dicas
Um engano comum na identificação de casos de uso é representar como Caso de uso
passos individuais, operações ou transações.
Exemplo:
No domínio de ponto de venda, alguém pode definir um caso de uso chamado
“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo
no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se:
Um caso de uso é uma descrição completa de processo,

que inclui outros passos ou transações.

Requisitos
Especificação de Requisitos. Exemplo:

O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as
seguintes propriedades:
- Número, preços base, capacidade de pessoas
- Tipo (Single, double, triplo ou suite)
O preço de cada apartamento está relacionado com seu tipo e sazonalidades (períodos especiais, tais como: férias, natal,
carnaval...)
Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de
reserva do Hotel .
1 Requisitos Funcionais
2
• Gerenciar Reserva
 •...
Refinado pelo 


Documento de
Visão
„
Documento
de Requisitos

Requisitos

3
Formulário
Cenários
Gerenciar Reserva
Usuário
Caso de Uso
Ator
Associação
Caso de Uso: Gerenciar Reserva

Requisitos

Escrevendo os Cenários:
Cenário 1: Gerenciamento de Reserva:
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos
para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva.

Cenários O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para
data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem
disponibilidade de apartamento para o período informado pelo cliente e oferece um outro tipo de
apartamento.
O cliente aceita o apartamento e então o funcionário confirma a reserva.
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos
para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem
disponibilidade de apartamento para o período informado pelo cliente e oferece um outro tipo de
apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.

Requisitos

Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Cenários Formulário
Identificando a pré-condição e pós-condição:

Cenário
Gerenciamento de Reserva:
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
Pré- condição ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Pós- condição
Requisitos

Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Primeiras linhas do cenário

Nome: Gerenciar Reserva
Ponto de ativação: Este caso de uso começa quando o
funcionário do setor de reserva recebe uma solicitação de
reserva
Ator: Funcionário
Objetivo: Fazer reservar de apartamentos
Gerenciar Reserva Pré-condição: Solicitação de reserva
“caminho feliz” Fluxo Normal:
Gerenciar Reserva Fluxo Alternativo:

“caminho alternativo”
Pós-condição: Reserva confirmada
Última linha do cenário

Requisitos

Escrevendo o Formulário de Descrição de Caso de Uso:
Ponto de ativação: Este caso de uso começa quando o funcionário do setor de

reserva recebe uma solicitação de reserva
Ator: Funcionário
Pré-condição: Solicitação de reserva

Fluxo Normal:
O cliente informa o tipo de apartamento
O cliente o período (data de chegada e partida)
O funcionário do Hotel verifica a disponibilidade do apartamento
O funcionário confirma a reserva
Fluxo Alternativo:
...
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva

Requisitos

3
Formulário
Cenários
Gerenciar Reserva
Funcionário
Caso de Uso
Ator
Associação
Caso de Uso: Gerenciar Reserva

Requisitos
Mitos e Lendas
• Requisitos não são Casos de Uso;
• Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo:

Caso de Uso Fazer Busca, está associado a dois requisitos:
• (RF) Fazer Buscar
• (RNF) O tempo de resposta para transação deve ser 10 segundos
(Desempenho)

Requisitos
Especificação de Requisitos. Exercício:

Especificação de Requisitos, como fazer:
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO;

2 - Identifique também os ATORES e seus respectivos PAPÉIS;
3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único
no modelo;
4 - Escreva os CENÁRIOS para o CASO DE USO;
5 - Compile os CENÁRIOS em único FORMULÁRIO e
6 - Faça o Diagrama de Caso de Uso.

Requisitos
Especificação de Requisitos. Template:

Template do “Formulário”:
Data: ______ | Autor: ________ | Revisão: ____
Nome: <nome do caso de uso>
Ponto de ativação: <informar o ponto de ativação>
Ator: <informar os atores>
Objetivo: <descrever o objetivo>
Pré-condição: <descrever a pré-condição>

Fluxo Normal:
<descrever o fluxo normal>
Fluxo Alternativo:
<descrever o fluxo alternativo>
Pós-condição: <descrever a pós-condição>
RF: <informar os código ou nomes dos RFs>

Rastreabilidade
RNF: <informar os código ou nomes dos RNFs>

Requisitos

Regras de
negócio
de requisitos
Documento de Visão

Usuários e
Clientes
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Requisitos
Validação de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário
deseja.
Validação é importante uma vez que o custo para remover um erro de requisitos é
grande.
Pequeno Check List de Requisitos:
Validade. O sistema fornece as funções que melhor atende as necessidades do usuário?
Consistência. Existem conflitos de requisitos?
Completeza. Todas as funções necessárias para o cliente estão incluídas?
Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento

disponíveis?
Facilidade de verificação. Os requisitos podem ser checados?

Requisitos
Técnicas de validação de requisitos
Revisão de requisitos:
- Análise manual sistemática dos requisitos
Prototipação:
- Uso de um modelo executável do sistema para checar os requisitos.
Geração de casos de teste:
- Desenvolver testes para os requisitos a fim de verificar a “testabilidade”.
Análise automatizada da consistência:
- Uso de ferramenta para verificar a consistência do modelo.

Requisitos
Técnicas de validação de requisitos
Revisão de requisitos:
- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos
- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões
- As revisões podem ser formais (com documentos completos) ou informais. Uma boa
comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em
estágios iniciais
Verificação de revisões:
- “Verificabilidade”. O requisito é realisticamente testável?
- Compreensibilidade. O requisito é propriamente entendido?
- Rastreabilidade. A origem do requisito é claramente estabelecida?
- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros
requisitos?

Requisitos
Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993:
Estrutura do Documento:
1.0 Introdução
1.1 propósito do documento de requisitos
1.2 escopo do produto
1.3 definições, acrônimos e abreviações
1.4 referências
1.5 visão geral do restante do documento
2.0 Descrição geral
2.1 perspectiva do produto
2.2 funções do produto
2.3 características do usuário
2.4 restrições gerais
2.5 suposições e dependências
3. Requisitos (Específicos)
os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do
sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, características de
qualidade.
4. Apêndices
5. índice

Análise Conceitual

É apresentar e discutir a Análise Conceitual suas técnicas,
conceitos e modelos.

Big Picture. Requisitos e Análise

Modelo Conceitual
Documento
de Visão
4

Glossário de
conceitos
Casos de Uso
Requisitos Não

Workflow Analise
Analise
Arquitetura Modelo Conceitual ou Modelo
de Domínio
Analista de Sistema
Analista de Requisitos
Arquiteto de Software
Vocabulário do Sistema
Modelo de Arquitetura Inicial

Workflow de Análise
Introdução:
Modelo de Casos de Uso de software é elaborado para dar a Visão de Caso de Uso.
Esta visão fornece uma perspectiva do software a partir de um ponto de vista externo.
Os aspectos dinâmicos descrevem a troca de mensagens entre os objetos e a sua
reação a eventos que ocorrem no software. O aspecto dinâmico será apresentado na
terceira parte, no workflow de Projetos.
Visão da
Visão de
Implementação
Funcionalidade Projeto Codificação
Vocabulário Montagem
Visão de Caso de
Uso
Gerenciar Reserva Visão do Visão da Implantação
Funcionário Desempenho Processo Topologia do Sistema
O aspecto estrutural estático permite entender como uma software está estruturado
internamente para atender os requisitos (visão externa).
Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.

Objetivo:
Apresentar e discutir como elaborar o Modelo Conceitual (também chamado de modelo de
domínio) e o Vocabulário de Conceitos. Para isto apresentaremos um algumas técnicas
para identificação dos candidatos a classes.
Os objetivos desta etapa são:
1 - Apresentar técnicas para identificação dos candidatos a classes, atributos e
associações;
2 - Elaborar o Modelo Conceitual ou modelo de domínio e
3 - Elaborar o Vocabulário de Conceitos.

Atividades.Road Map
Fazer Análise Conceitual

Caso de Uso
Modelo Conceitual
Fazer Vocabulário
Documento de
Visão Vocabulário
Definir o modelo de
Arquitetura

Atividades e Artefatos:
Para este workflow as principais atividades e artefatos são:
Workflow de Requisitos:
Atividade:
Coletar Requisitos
Fazer Análise de Requisitos.
Fazer Especificação de Requisitos;
Artefatos: Documento de Visão
Caso de Uso
Atividade:
Fazer Vocabulário de Conceitos
Artefatos: Modelo Conceitual e

Vocabulário do Sistema.

Análise Conceitual. Introdução:

“Modelo Conceitual. É o artefato mais importante da Análise Orientada a Objetos”
O modelo representa conceitos relevantes (do ponto de vista do modelador) do domínio

do negócio. Este conceitos também são chamados de Chaves da Abstração.
“A chave da abstração é uma classe ou objeto que fazem parte do vocabulário do
domínio do problema” (Booch).
Na UML, esta fase é ilustrada com os diagramas de estruturas estáticas:

- Caso de Uso
- Digrama de Classes (na verdade o Modelo Conceitual).
Os objetivos são:
1 - Apresentar técnicas para identificação dos candidatos a classe classes, atributos e

associações e
2 - Elaborar o Modelo Conceitual ou Modelo de Domínio.

Atividade: Fazer Análise Conceitual

Caso de Uso
Modelo Conceitual
Documento de
Visão

Análise Conceitual. Modelos:

O modelo de classe têm pelo três níveis de abstração:
- Modelo Conceitual de Classes: Representa as classes no domínio do

desenvolvimento do software, este modelo pertence a Workflow de Análise. Por
definição, um modelo de classes de domínio não leva em consideração restrições
referente à tecnologia a ser utilizada na solução do problema. Este modelo também
conhecido como “Modelo de Classes de Domínio”.
- Modelo de Classes de Especificação: É derivado do Modelo Conceitual. Com

acréscimos de detalhes, tais como, tipo de dado, operações (métodos),
implementação de associações, generalização, agregação e composição e
incremento de novas classes para que se fazem necessária para dar uma solução ao
problema.
Exemplo:
Classes associativas. Este modelo é desenvolvido no Workflow de Projeto.

Análise Conceitual. Modelos

- Modelo de Classes de Implementação: É derivado do modelo de especificação e
corresponde a implementação das classes em alguma linguagem de programação,
como Java, C#, C++ por exemplo. O modelo de implementação é construído na Fase
Construção.
Workflow de Análise Workflow de Projeto
Pessoa
Pessoa
-nome
nome -idade
idade
<<refines>> +setNome()
+getNome()
+getIdade()
+getIdade()
Modelo Conceitual ou Modelo de Especificação

Modelo de Domínio

Análise Conceitual. Atividades e Passos:
Identificar os candidatos
a classe
Selecionar uma técnica
Fazer a Lista de
Candidatos
Desenhar o Modelo
Conceitual
Definir a Arquitetura
Inicial

Análise Conceitual. Identificação das Classes:

Um software orientado a objetos é composto de uma coleção de objetos que colaboram
para realizar seus requisitos. Entretanto, sabemos que os objetos são “instances” das
classes.
Para identificar as classes, podemos usar um método simples. O primeiro passo é fazer
uma lista de todas classes que encontramos, esta lista pode ser chamada de “Lista de
Classes Candidatas”.
E depois usando algum critério, eliminamos as classes irrelevantes e aí teremos uma lista
definitiva. Existem dois métodos principais para realizar a identificação das classes de
domínio de um software:
- Método dirigido a dados:
Neste método, a ênfase está na identificação da estrutura dos conceitos
relevantes para o domínio do negócio, resultando em Modelo Conceitual.
- Método dirigido a responsabilidades:

Neste método, a ênfase está na identificação de classes a partir de seus
comportamentos relevante ao sistema. Este método também resulta em
Modelo Conceitual.

UML. Introdução
A UML deve ser utilizada para criarmos o Modelo Conceitual. Os modelos visuais ajudam
a compreender melhor o sistema que estamos construindo.
As seguir será apresentado os nós, elementos e adornos usados para construir o modelo.

Diagrama de Classes. Introdução

O Diagrama de Classes nasce no Workflow de Análise com Modelo Conceitual (modelo de
domínio), mais tarde no Workflow de Projeto este o modelo será refinado ganhando
adornos, novos tipos de relacionamentos, operações (métodos) e até novas classes.
Agora faremos apenas o Modelo Conceitual que podemos considerar como o primeiro
“esboço” do que mais tarde se tornará o Diagrama de Classes.

UML. Elementos:
Elementos estruturais:
Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e
Componente
Elementos de agrupamento:
Pacote e Subsistema

UML. Elementos:
• Dependência
• Associação
– Associação
– Composição
– Agregação
• Generalização
Mecanismos de Extensibilidade:
• Estereótipo
• “Tagged value”
• Restrição (Constraint)

Diagrama de Classes
O diagrama de classes deve

capturar o Vocabulário* do
sistema

Associação
Definição de Associação:
Um relacionamento estrutural que descreve um conjunto de vínculos, em que o vínculo
é uma conexão entre objetos; relacionamento semântico entre dois ou mais
classificadores que envolve as conexões entre seus objetos.
Associação
classe classe
Usuario Senha

Associação
Nome de Associação:
Uma associação pode ter um nome, que pode usado para descrever a natureza do
relacionamento. Podemos ainda acrescentar um triângulo para demonstrar a direção do
nome, ou seja, a direção que nome deve ser lido.
Nome da associação
Direção do nome
faz
Cliente Pedido
Observação:
Apesar da possibilidade de a associação ter um nome, não é necessário incluí-lo. Recomendamos o uso do
nome quando o modelo possui muitas associações e você tem a necessidade de fazer referência às
associações ou de destaca-las.

Associação
Navegação:
Indica qual é a direção da associação. A direção da associação pode ser unidirecional (onde
somente uma das pontas da linha de associação tenha a seta) ou bidireciona (não existem
setas em nenhum dos lados)
Associação
Navegação
Cliente Pedido

Role Name:
Definição de Role Name:
É um identificador (nome) do papel da associação, podendo cada ponta ter um nome
especifico.
Modificadores:
(+) public | (-) private | (#) protected

Multiplicidade
Definição:
A especificação de uma faixa de números cardinais, que um conjunto pode assumir.
Eqüivale a muitos
Multiplicidade Faixa Válida:

0....1 | 0..* | * | 1 | 1..*
O que é uma multiplicidade ?

Uma associação representa um relacionamento entre dois objetos. Em algumas situações
de modelagem, é importante especificar a quantidade de objetos que podem ser
conectados pela “instance” de uma associação.
Essa “quantidade” é chamada de multiplicidade do papel de uma associação e é escrita
como uma expressão equivalente a um intervalo de valores ou de uma valor explícito.

Role Name e Multiplicidade

Exemplo:
Multiplicidade
Para cada objeto (instance) da classe Pessoa a classe
Empresa poder ter uma ou muitos objetos.

Análise Conceitual. Técnicas:
Abbot Kent Beck UML
Inspeção Análise de
CRC
Gramatical Caso de Uso
Scott Ambler
Graig Larman
Peter Coad
Outras
Técnicas
Modelo Conceitual. Técnica: Inspeção Gramatical

Introdução:
A primeira etapa na construção do Modelo Conceitual é identificar os conceitos (idéias ou

coisas). Podemos achar os candidatos a classe com a identificação de substantivos
(Inspeção Gramatical).
É uma técnica útil, por causa da simplicidade, proposta por Abbot. Consiste em identificar
os substantivos no texto da Declaração de Problema e considerá-los como candidatos a
a classe ou conceitos.


Lista de Candidatos:
Conhecimento do Negócio Interações
Declaração de
Visão 1º Lista Lista Final
Identificação dos Fazer revisão da lista:

candidatos a classe, Eliminar conceitos os repetidos,
associações e atributos ambíguo, irrelevantes e etc..

Artefatos:
Modelo Conceitual
Lista de Candidatos
Vocabulário de Conceitos

Nome da associação
Classe
Reserva Cliente
1..* feita por 1
numero id
data-entrada hospede nome
data-saida documento
Atributo 0..*
Multiplicidade
Apartamento
1..*
numero
tipo
situacao
Associação

Modelo Conceitual. Técnica: Inspeção Gramatical - Exemplo

Declaração do Problema:
O cliente solicitou o desenvolvimento de software para apoiar uma rede bancária

computadorizada incluindo caixas humanos e máquinas de auto atendimento (ATM) a ser
compartilhada por um consórcio de bancos. Cada banco provê seu próprio computador
para manter suas contas e processar transações sobre elas. Os caixa automáticos são
propriedade dos bancos e se comunicam diretamente com os computadores de seus
bancos proprietários. Os caixas humanos introduzem dados sobre as contas e
transações. Os caixas eletrônicos comunicam-se com um computador central que liquida
as transações com os bancos adequados. Um caixa automático receber cartão
magnéticos, interage com o usuário, comunica-se com o sistema central para executar
transações, entrega de dinheiro e impressão de extratos.
O sistema exige um adequado arquivamento de registros e reservas de segurança. O
sistema deve manipular corretamente acessos concorrente à mesma conta. Os bancos
devem prover seu próprio software para seus próprios computadores; devemos projetar o
software para as ATM e para a rede. O custo do sistema compartilhado deve ser
distribuído pelos bancos de acordo com número transações realizadas.


Identificando do Domínio:
(Técnica usada: extração dos substantivos do enunciado do problema)
Fazer transações eletrônica através de caixa de

Auto atendimento e caixas


Identificando os conceitos:
Software Rede Bancária Caixa
ATM Consórcio Banco
Computador do Banco Conta Transação
Terminal do caixa Dados de contas Dados de transações
Computador Central Cartão Magnético Usuário
Dinheiro Extrato Sistema
Manutenção do Reserva de segurança Acesso

arquivo de Registro
Preço Cliente
Classes da ATM originadas do conhecimento do domínio do problema

Linha de Comunicação Registro de transação


Identificando os conceitos:
Após a revisão identificamos o seguinte:
Conceitos vagos:
Sistema, Reserva de Segurança, Manutenção do arquivo de Registro e Rede Bancária
Atributos:
Dados de contas, extrato, dinheiro e dados de transações
Conceito redundante:
Usuário
Conceito Irrelevante:
Preço
Conceito de implementação:
Registro de Transação, Acesso, Software e Linha de Comunicação
Eliminado às classes apontadas, ficamos com as seguintes conceitos válidos:
Conta, ATM, Banco, Computador do Banco, Cartão Magnético, Caixa Terminal do Caixa, Computador
Central, Consórcio, Cliente e Transação

Identificando as Associações:
Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência
de uma classe a outra é uma associação.
As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais.
Isso inclui localização física:
- junto a, parte de, contido em e etc
Ações indiretas:
- direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfação de alguma
condição (trabalha para, casado com, gerencia).
Tente identificar as associações, lembre-se que nem todas, estão explicitas, pode haver
muitas transações implícitas e algumas associação dependem do conhecimento do
mundo real, ou seja, do negócio.
Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e
depois refine-as.


Lista (Frases verbais):

Rede de bancária inclui caixas e ATM
Consórcio compartilha ATM
Banco provê computador do banco
Computador do banco mantém contas
Computador do banco processa transações contra a conta
Banco possui terminal de caixa
Terminal de caixa comunica-se com o computador do banco
Caixa introduz transação para a conta
ATM comunica-se com computador central sobre transação
Computador central liquida transação com banco
ATM aceita cartão magnético
ATM interage com usuário


Lista (Frases verbais):

ATM entrega o dinheiro
ATM imprime extrato
Sistema manipula acesso concorrente
Bancos fornecem software
Custo repartido pelos bancos
Frases Verbais implícitas:

Consórcio compõem-se de bancos
Banco mantém conta
Consórcio possui computador central
Sistema provê arquivamento de registros
Sistema provê segurança
Clientes possuem cartões magnéticos
Conhecimento do domínio do problema:

Cartão magnético permite acesso a contas
Banco emprega caixas

Identificação dos conceitos dos atributos:
Os atributos são propriedades de objetos individuais, como nome, peso, altura,

velocidade, cor e etc.
Os atributos não devem ser objetos; utilize uma associação para demonstrar qualquer
relacionamento entre dois objetos.
Os atributos geralmente correspondem a substantivos seguidos por frases possessivas,
por exemplo: “a cor do carro” ou “o número da conta”.
Os adjetivos muitas vezes representam valores de atributos específicos e enumerados,
como vermelho sobre ou expirado. Diretamente das classes e associações, os atributos
têm menos probabilidade de serem integralmente descritos no enunciado do problema.
Devemos valer-se de nosso conhecimento do domínio da aplicação e do mundo real
para encontrá-los. Lembre-se que os atributos raramente afetam a estrutura básica do
problema.

Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade é

derivado de data de nascimento e data atual (que é uma propriedade do ambiente). Os
atributos derivados como os objetos e associação derivadas podem ser úteis na
abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos
nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos
derivados não devem ser expressos como operações, como obter-idade, embora
possam eventualmente ser implementados como tais.
Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma
propriedade da ligação entre dois objetos e não a propriedade de um objeto
isoladamente. Por exemplo: a associação muitos-para-muitos entre Acionistas e
Empresa tem o atributo de ligação número de ações. Os atributos de ligação às vezes
são tomadas erradamente por atributos de objetos.


Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade é

derivado de data de nascimento e data atual (que é uma propriedade do ambiente). Os
atributos derivados como os objetos e associação derivadas podem ser úteis na
abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos
nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos
derivados não devem ser expressos como operações, como obter-idade, embora
possam eventualmente ser implementados como tais.
Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma
propriedade da ligação entre dois objetos e não a propriedade de um objeto
isoladamente. Por exemplo: a associação muitos-para-muitos entre Acionistas e
Empresa tem o atributo de ligação número de ações. Os atributos de ligação às vezes
são tomadas erradamente por atributos de objetos.


Modelo Conceitual vs Modelo de Especificação
Transacao Transacao
Datahora Datahora:Timestamp
+getTransacao()
+setDataHora()
+getDataHora()
Conceito de Classes
classes e atributos


Modelo Conceitual:

CRC
Método dirigido a responsabilidades:
Neste método, a ênfase está na identificação das classes a partir de seus comportamentos
relevante ao sistema.
Técnica Cartão (CRC):
O CRC foi apresentado por Kent Beck e Ward Cunningham em artigo chamado:
"A Laboratory for Teaching Object-Oriented Thinking" no OOPLSA '89.
Conceito e Aplicação:
CRC (Cartão Responsabilidade e Colaboração) é um cartão índice que é usado para

representar as responsabilidades das classes e suas interações com outras classes.
O cartão CRC é uma abordagem informal da modelo de orientação a objetos.
Os cartões são criados através de cenários, baseado nos Requisitos, que modela o
comportamento do sistema.
Observação:
O CRC não faz parte da UML. Mas é uma técnica recomendada, pela sua simplicidade,
principalmente para quem tem pouca experiência com orientação a objetos.

CRC. Responsabilidades e Colaborações:

Em sistema orientado a objetos, os objetos encapsulam os dados e os comportamentos.
O comportamento de um objeto é definido de tal forma que ela possa cumprir com as
responsabilidades. Uma responsabilidade é uma obrigação que um objeto tem para como
sistema no qual ele estará inserido.
Através das responsabilidades, um objeto colabora com outros objetos para que os
objetos sejam alcançados.
Podemos considerar que uma responsabilidade é alguma coisa que objeto deve conhecer
ou que ele deve saber fazer.
Em alguns casos, um objeto tem uma responsabilidade com qual ele não pode cumprir
sozinho. Nesses casos, o objeto deve requisitar colaboração de outros objetos do software
para cumprir com sua responsabilidade.
Objeto
Colaborações:
Responsabilidades:
(o que objeto conhece e o que faz) + (outras classes que são associadas,
para a interação entre os objetos)

CRC. Elementos:
O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que a
classe dever saber fazer e coisas que ela deve conhecer.
As colaborações as informações que a classe precisa e que está alocada em outra classe,
desta forma temos que fazer o relacionamento entre classes, para que ela
cumpra com sua responsabilidade.
Modelo:
Nome da Classe
Responsabilidades: Colaborações:
Lista das responsabilidades Lista de colaborações
Melhores Práticas:
Os candidatos a classe cujo a responsabilidade não foi encontrada, este candidato deve
ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.

CRC. Exemplos:
Classe: Reserva
Conhecer o período da reserva
Apartamento
(datas)
Cliente
Saber o nome do cliente
Saber o número do apartamento
Classe: Cliente
Saber o nome do cliente Reserva

Saber a Reserva do Cliente

Modelo Conceitual. Técnica: Inspeção Gramatical & CRC
Inspeção Gramatical CRC UML
Lista de Candidatos Classe: Cliente
SaberClasse:
o nome do clienteReserva
Cliente
Saber o nome do clienteReserva

Saber a Reserva
Classe: Clientedo Cliente
Saber o nome do clienteReserva

Identificação dos candidatos Identificação das Responsabilidade Modelo Conceitual

Análise de Caso de Uso:

Análise começa com verificação do Modelo de Caso de Uso, Diagrama, Cenários e
Formulários e a Lista de Requisitos Funcionais. Nesta análise é identificado os candidatos
a classe.
Formulário
Cenários
Usuário
Gerenciar Reserva
Caso de Uso Listas de Candidatos
Ator Associação

Análise de Caso de Uso. Big Picture

Documento de Visão 4 Lista de
1 Candidatos

3 (Visão de Caso de Uso)
Lista de Requisitos
Funcionais Formulário
Cenários
Casos de Uso
Lista de Requisitos
Não Funcionais
Usuário Gerenciar Reservas
Ator Associação
Análise de Caso de Uso: Identificando os candidatos a classe

Como fazer. Diagrama:
1 - Verifique os nome dos Casos de Uso, eles geralmente contêm bons candidatos.
Usuário
Gerenciar Reserva Reserva é provável candidato a classe
<<include>>
Atualizar Reserva Buscar Apartamento
Funcionário <<include>>
Criar Reserva Cadastrar Cliente prováveis candidatos a classe
Remover Reserva

Análise de Caso de Uso: Identificando os candidatos a classe

Como fazer. Cenários:
2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos,
exemplo:
Cenários:
Gerenciar de Reserva:
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa
Cenários que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.
Prováveis candidatos a classe

Análise de Caso de Uso: Atividades

Como fazer. Formulário:
3 - Os Formulários também devem usados para identificação dos candidatos. Ache os
substantivos, exemplo:
Ponto de ativação: Este caso de uso começa quando o funcionário do setor de
reserva recebe uma solicitação de reserva
Ator: Funcionário
Formulários
Pré-condição: Solicitação de reserva
Fluxo Normal:
O cliente informa o tipo de apartamento
O cliente o período (data de chegada e partida)
O funcionário confirma a reserva
Fluxo Alternativo:
...
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva
Prováveis candidatos a classe

Modelo Conceitual. Técnica: Inspeção Gramatical & CRC
Análise de Caso de Uso CRC UML
Lista de Candidatos Classe: Cliente

Saber o nome
Classe: do cliente
Cliente Reserva

Reserva
Classe:
Saber Clientedo Cliente
a Reserva

Reserva
Identificação dos candidatos Identificação das Responsabilidade Modelo Conceitual

Dicas: Scott Ambler

Para encontrar as classes, vejamos algumas dicas:
1 - Considere que as classes são lugares, eventos, conceitos, pessoas e etc.

2 - Atores são classes em potencial;
3 - Identifique os clientes;
4 - Siga o dinheiro, podemos identificar produtos, serviços, eventos como venda,
compra e etc;
5 - Conceitos são classes em potencial;
6 - Eventos são classes em potencial e
7 - Entende o negócio.
Use a técnica CRC para atribuir ou descobrir as responsabilidades e colaborações

das classes encontradas

Graig Larman
Larman sugere a que a identificação dos substantivos, que são os candidatos a classe ou
conceitos seja feito através dos Casos de Uso “expandidos”, pois, eles fornecem uma
excelente descrição a serem usadas como fontes para este tipo de análise.
Exemplo:
Exemplo de Caso de Uso expandido:
Seqüência típica de eventos:

1 - Este caso de uso começa quando um Cliente chega a um ponto de venda e deseja
comprar alguns itens.
2 - O Caixa registra o código do produto de cada item
...
Entretanto esta técnica exige uma ou mais revisão nos conceitos encontrados, pois,
diferentes substantivos podem representar o mesmo conceito.

Graig Larman
Larman também sugere usar uma abordagem de Categoria de Conceitos, que nada mais
é que uma lista de categorias. Após determinar lista use-a para identificar os conceitos.
Exemplo de lista:
Categoria Exemplos
Objeto físico ou tangível Terminal de ponto-de-venda
Avião
Especificação, projeto, ou descrição de coisas Especificação de produto

Descrição de vôo
Lugares Loja
Aeroporto
Transações Venda, Pagamento

Reserva
Itens de transação Itens de venda

Parcelas de pagamento
Papéis de pessoas Operador

Piloto

Graig Larman
Identificação dos Conceitos:
Abaixo um exemplo de identificação dos conceitos a partir dos Formulários dos Casos
de Uso:
Ação do Ator Resposta do Sistema

1. Este caso de uso começa quando
um Cliente chega no caixa com itens
para comprar. 3. Determina o preço do item e
2. O Operador registra o identi-ficador adiciona informação sobre o item à
de cada item. transação de venda em anda-mento.
Se há mais de um do mesmo item, o Mostra a descrição e o preço do item
Operador também pode informar a corrente.
quantidade.

Peter Coad
A Proposta de Coad & Yourdon:
O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon e denominado
OOA (Object Oriented Analysis), consiste basicamente em cinco passos:
1 - Localização de classes-&-objetos: entende-se por objetos como a abstração de alguma

coisa, em um domínio de problema, cujas informações devam ser manipuladas pelo
sistema. Uma classe corresponde ao conjunto de objetos semelhantes.
2 - Identificação de estruturas: que podem ser classificadas em:
Generalização-especialização: quando uma classe é\ um tipo de uma outra classe.
Exemplo: a classe carro é uma especialização da classe veículos;
Todo-parte: quando uma classe é formada por outras classes. Exemplo: as classes
motor e chassis fazem parte da classe carro.
3 - Definição de assuntos: onde cada qual se relaciona a diferentes partes do modelo,
permitindo minimizar a complexidade de projetos extensos.

Dicas: Peter Coad

A Proposta de Coad & Yourdon
4 - Definição de atributos: um atributo é definido como uma propriedade, uma qualidade

ou uma característica de um determinado objeto. Um atributo consiste em alguns dados
(informações de estado) através dos quais cada objeto em uma classe tem seu próprio
valor. Atributos comuns a todas as subclasses (especializações) de uma classe são
apenas listados na classe e, automaticamente, estendidos para as suas subclasses.
Uma conexão de ocorrência representa relacionamentos entre objetos.
5 - Definição de Serviços: um serviço é um comportamento específico que um objeto
deve exibir. Um serviço altera o estado de um objeto. Serviços pertencentes a todas
subclasses são definidos apenas na classe. Os serviços implícitos, tais como incluir,
remover, alterar e selecionar instâncias, não são apresentados no diagrama. Uma
conexão de mensagem representa a comunicação entre objetos, onde um “emissor”'
envia uma mensagem para um “`receptor'', para a realização de algum processamento.

Vocabulário.Road Map:

Caso de Uso
Modelo Conceitual
Fazer Vocabulário
Documento de
Visão Vocabulário

Vocabulário:
Fazer Vocabulário
Descrever os conceitos
Fazer Vocabulário:
Devemos fazer um Vocabulário de todas as classes presente no Modelo Conceitual.
O vocabulário consiste em simples descrição do conceito.
Transacao
Datahora
Transação – Uma única solicitação integral para operações nas
contas de um único cliente. Especificamente somente que as ATM
podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou
cheques. Também queremos prover a flexibilidade de operar as
contas de diferente clientes, embora isso não seja exigido. As
diferentes operações devem fechar apropriadamente.

Modelo Conceitual.

Vocabulário. Exemplo:
Vocabulário:
ATM – Uma estação que permite os clientes introduzem suas próprias transações
utilizando cartões magnéticos como identificação. A ATM interage com o cliente para
obter informações sobre transações, envia as informações sobre transações para o
computador central para validação e processamento e entrega de dinheiro ao usuário.
Presumimos que uma ATM não necessita operar independente de rede.
Banco – Uma instituição financeira que mantém contas de cliente e emite cartões
magnéticos autorizando o acesso às contas através da ATM.
Caixa – Um empregado do banco autorizado a introduzir transações nos terminais de

caixa e a receber e entregar dinheiro e cheques aos clientes. As transações, o dinheiro e
os cheques manipulados por cada caixa devem ser registrados e devidamente
contabilizados.

Vocabulário:
Cartão Magnético – Cartão vinculado a um cliente do banco que autoriza o acesso às

contas utilizando uma máquina ATM. Cada cartão contém um código de banco e um
número de cartão, codificados de acordo com os padrões definidos pelo Bacen (Banco
Central) sobre cartões de créditos e cartões magnéticos.
O código do banco identifica inequivocamente o banco dentro do consórcio.
O número do cartão determina as contas a que cartão pode ter acesso. Um cartão não
necessariamente dá acesso a todas as contas do cliente.
Cada cartão pertence a um usuário cliente, mas podem existir múltiplas cópias dele, de
modo que a utilização simultânea do mesmo cartão em diferentes máquinas deve ser
considerada.
Cliente – Possuidor de uma ou mais contas em um banco. Um cliente pode ser uma ou
mais pessoas ou corporações; a correspondência não é relevante para este problema. Se
uma pessoa possui conta em um diferente banco é considerada cliente diferente.

Vocabulário:
Computador Central - Computador operado pelo consórcio que despacha transações entre as ATM e
os computadores dos bancos. O computador central valida códigos de bancos mas não processam
transações diretamente.
Consórcio – Organização de bancos que comissiona e opera a rede ATM. A rede só manipula
transações do consórcio.
Conta – Única conta no banco contra a qual as transações podem ser aplicadas. As contas podem ser
de vários tipos, no mínimo de cheques e de poupança. Um cliente pode manter mais de uma conta.
Terminal de caixa – Terminal no qual os caixas introduzem transações para os clientes. Os caixas
entregam a recebem dinheiro e cheques; a impressora do terminal imprime extratos. O terminal do
caixa comunica-se com o computador central do banco para validar e processar transações.
Transações – Uma única solicitação integral para operações nas contas de um único cliente.
Especificamente somente que as ATM podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também queremos prover
a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As diferentes
operações devem fechar apropriadamente.

Diagrama de Objetos
Introdução:
Bem o última coisa a fazer neste Workflow é fazer a validação do Diagrama de Classes.
Podemos fazer esta validação utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma
estaremos garantindo que o Diagrama de Classes feito atende os requisitos.
Diagrama de Objetos, é diagrama estrutural, que demonstra um conjunto de objetos e seus

relacionamentos em determinado ponto no tempo.
Sua principal aplicação é ilustrar as estruturas de dados, registro estáticos das “instances” dos itens
encontrados no diagrama de classe.
O diagrama de objetos direcionam a visão estática do projeto ou de processo de um sistema.
O Diagrama de Objetos também podem conter pacotes ou subsistemas, notas e restrições.
Exemplo da notação:
:Nome do Objeto
Atributo: Valor do atributo

objeto
Nome do Objeto
vínculo
Atributo: Valor do atributo

Diagrama de Objetos
Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes.
Exemplo:
Diagrama de Classe Diagrama de Objetos

Aluno :Aluno
Nome da -Nome: String Nome: “Fulano de Tal”
associação -Data: Date Data: 23-02-2001
Nome do
“Instance” objeto
objeto
Matricula 201-23-02-01:Matricula
-Matricula: int Matricula: 201-23-02-01 vinculo
-Curso: String Curso: Adm Empresas
Atributo Valor do atributo

Diagrama de Objetos
Conteúdo do Diagrama de Objetos:
Objetos e Vinculo
Diagrama de Objetos
objeto :Aluno
Nome: “Fulano de Tal”
Data: 23-02-2001
201-23-02-01:Matricula
Matricula: 201-23-02-01 vínculo
Curso: Adm Empresas
Um vínculo é uma
conexão semântica existente
entre os objetos.
Em geral, um vínculo é uma
“instance” de uma associação.
Desta forma um objeto pode
enviar uma mensagem para
outro.

Diagrama de Objetos
Como fazer a modelagem de um estrutura de objetos:
Como posso
• Identifique o mecanismo cuja modelagem você deseja fazer. Um mecanismo
validar o
representa algum requisito ou comportamento da parte do sistema cuja a
diagrama de
modelagem você está fazendo e que é resultante da interação de um conjunto
classes?
de classes, interfaces e outros itens.
• Para cada mecanismo, identifique todos os itens (classes, interfaces e outros
elementos) que participam nessa colaboração e seus relacionamentos.
• Leve em consideração somente um cenário capaz de percorrer esse
mecanismo. Congele o cenário em determinado momento e represente cada
objeto que participa do mecanismo.
• Exponha o estado e os valores dos atributos de cada um desses objetos,
conforme seja necessário, para compreensão do cenário.
• De maneira semelhante, exponha os vínculos existentes entre esses objetos,
representando as “instance” de associação entre eles.

Arquitetura Inicial.Road Map

Caso de Uso
Modelo Conceitual
Fazer Vocabulário
Documento de
Visão Vocabulário
Definir o modelo de
Arquitetura

Modelo de Inicial de Arquitetura

Definir o Modelo de
Arquitetura
Definir o Modelo de
Arquitetura Inicial
Podemos criar um Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar
um visão macro da arquitetura.
Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o modelo.
Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este
modelo ou qualquer outra notação.
Este modelo será refinado no workflow de projeto na Atividade “Fazer o Modelo de Arquitetura”.
Camada de Camada
Camada Banco de
serviço regra de
apresentação Dados
4
(controle) negócio

Apêndice
Diagrama de Pacotes
Como podemos definir o diagrama de pacotes?
A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de
organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida
que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é
linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem
ser usados para fazer decomposição funcional.
A notação usada pela UML para representar pacotes é:
Nome do Nome do
Pacote Pacote
Nome do Pacote
Nome do
Pacote
Dependência
(import)
Apêndice
Diagrama de Pacotes
Decomposição. “Dividir para conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou
ambas as coisas. Para facilitar é necessário fazer uma decomposição.
A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a
modelagem ou processo de desenvolvimento de um software.
Veja o exemplo abaixo:
Contas a Fluxo de
Pagar Caixa
Nome do Pacote
Subsistema
Contas a
Receber Dependência
(import)
Desenho (design) do Modelo de

Especificação de Software
É apresentar e discutir o desenho (modelo de especificação)
seus conceitos, técnicas e modelo.

Workflow de Projeto
Objetivo:
Apresentar e discutir o Workflow de Projeto, também conhecida como “Fase de
Especificação”, agora faremos uso da intenso da UML para fazer os modelos (diagramas)
e a documentação.
As principais atividades são:

- Construção do Modelo de Especificação (Projeto)
- Construção do Modelo de Arquitetura
- Fazer validação do modelo.

Workflow de Projeto
Introdução. UML, Visões:
Visão de Visão da
Codificação
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Conceitual Físico
Workflow de Projeto

Visão de Projeto
• A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do

problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os
requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários
finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de
objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de
atividades.
Visão de Processo
• A visão do processo abrange os “threads” e os processos que formam os mecanismos de

concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões
de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos
estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do
projeto, mas o foco voltado para as classes ativas que representam esses threads e processos.
Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser
programas ou parte.
Workflow de Projeto
Introdução. Aspecto estático e dinâmico:

O Workflow de Análise é determinado pelo “aspecto estrutural estático”, que permite
entender como uma software está estruturado internamente para atender os requisitos.
Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.
No Workflow de Projeto, faremos a modelagem dos aspectos dinâmicos do sistema, estes

aspectos são capturados em digramas (diagrama de interação, diagrama de estados e
diagrama de atividades).
E assim podemos representar os comportamentos internos e desta forma teremos novas
visões do software e aí conseguiremos compreender melhor o software.

Workflow de Projeto
Introdução. Aspecto estático e dinâmico:

UML. Principais Diagramas:
Modela a estrutura do sistema Modela o comportamento do sistema
ESTÁTICOS DINÂMICOS
. Diagrama de Classes . Diagrama de Casos de Uso
. Diagrama de Objetos . Diagramas de Interação
. Diagrama de Componentes - Diagrama de Seqüência
. Diagrama de Distribuição - Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados

Workflow de Projeto
Introdução
A Workflow de Projeto depende da Workflow de
Análise:
Workflow de Análise Análise
dependência
Workflow de Projeto Projeto

Workflow de Projeto
Introdução
A Workflow de Projeto refina a Workflow de
Análise:
modelo conceitual Diagrama de Classes
Atributos:
Cliente Cliente Tipo de dados
codigo -codigo: int

<<refine>>
nome -nome: String
+getCodigo()
+setCodigo()
Atributos: +getNome()
Visibilidade
+setNome()
métodos

Workflow de Projeto
Big Picture. Projeto

Análise Projeto (Visão Lógica)
Modelo Conceitual Diagrama de Classes
Receber Pedido
Entrega
Receber Pagamento
Especificação de Requisitos a noite

: visitante
getDescricao( )
exibirCategoria( )
selecionarCategoria
exibirProduto( )
Encerrar Pedido

Workflow de Projeto
Arquitetura
Arquitetura Diagrama de Seqüência /
Colaboração
Analista de Sistema
Projetista de Software
Diagrama de Atividades Arquiteto de Software
Diagrama de Estados
Diagrama de Classes

Workflow de Projeto
Atividades.Road Map
Fazer Modelo de Especificação

Caso de Uso
Modelo de Especificação
Fazer Modelo de Arquitetura

Modelo
conceitual
Modelo de Arquietura

Workflow de Projeto
Projeto. Atividades e Passos:
Fazer Modelo Especificação
Identificar as classes de
Especificação
Fazer Diagrama de
Interação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Modelo de
Especificação

Workflow de Projeto
Casos de Uso. Revisão

Uso caso de uso descreve “o quê” um sistema faz, ele não especifica “como” isso é feito.
Ao fazer uma modelagem, importante manter clara a separação de questões entre a visão
interna e externa. “O como” é modelado pelo Diagrama de Interação.
“O quê” <<include>>
selecionar categoria
buscar produtos Diagrama de Sequência

“O como”
visitante
Diagrama de Estado : visitante

getDescricao( )
exibirCategoria( )
selecionarCategoria
exibirProduto( )
Formulário

Workflow de Projeto
Diagrama de Interação. Introdução

Diagrama de Interação são modelos que descrevem como grupos de objetos colaboram
para atender comportamento.
Tipicamente, um diagrama de interação captura o comportamento de um único caso de
uso. O diagrama deve mostrar os vários objetos e as mensagens que são passadas entre
estes objetos.
Existem dois tipos de diagramas:
• Diagrama de Seqüência:
O foco deste diagrama é maneira que as mensagens são enviadas ao longo do tempo.
• Diagrama de Colaboração:
Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então
considerar como as mensagens são passadas no contexto dessa estrutura.

Workflow de Projeto
Diagrama de Interação
O que é Diagramas de Seqüência?
É um diagrama que exibe a colaboração dinâmica entre objetos de um sistema. O
principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de
mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos e os
eventos que acontecem em um ponto específico da execução do sistema.
Notação:
Diagrama de Seqüência
:Objeto 1 :Objeto 2
Ator: 1: mensagem 1
2: mensagem 2
3: mensagem 3

Workflow de Projeto
Diagramas de Seqüência:

Workflow de Projeto
Diagramas de Seqüência:
formulários de formulário de cursos

registro matrícula disponíveis
entrar com senha de

acesso
validar acesso
Aluno:
entrar com o
semestre
criar nova matrícula

apresentar em tela
obter cursos

Workflow de Projeto
Diagramas de Seqüência. Elementos:
Instance das classes
ator
: Cliente : Veiculo : Locacao

: Atendente
getDadosCliente( )
[* se cliente cadastrado
verificar divida ]
getDivida( )
getDisponibilidade( )
setSaida( )
[* se veículo
disponível ]
Autodelegação
As interações entre os Restrição ou

Linha do tempo objetos condição

Workflow de Projeto
Diagramas de Seqüência. Numerando as seqüências das mensagens.

: visitante
1: getDescricao( )
2: exibirCategoria( )
3: selecionarCategoria
4: getDescricao( ) 5: getQuantidade( )
6: exibirProduto( )
7: selecionarProduto( )
Este diagrama descreve em ordem cronológica as mensagens entre os objetos.

Workflow de Projeto
O que é Diagrama de Colaboração?
É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante ao
diagrama de seqüência.
No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,
percebe-se também as colaborações dos objetos.
A interação de mensagens é mostrada em ambos os diagramas.
Diagrama de Colaboração tem a maioria de suas características semelhantes ao
Diagrama de Seqüência.
Quando usar o diagrama de Colaboração ?

Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o
diagrama de seqüência, mas se a ênfase for relacionamentos estrutural
entre os objetos de uma interação, é melhor dar prioridade ao diagrama
de colaboração. Podemos também escolher ambos.
Diagrama de Seqüência é mais usual.

Workflow de Projeto
O que é Diagrama de Colaboração ?
O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos
objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens
são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As
mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas. Também podem mostrar condições, interações, valores de
resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que
executam paralelamente com outros.
Exemplo:
Diagrama de Colaboração 2: validar acesso
1:entrar com chave 3:entrar com o
de acesso semestre
formulários de registro
4:criar nova matrícula
Ator (José)
5:apresentar
em tela
cursos disponíveis formulário de matrícula

6:obter cursos

Workflow de Projeto
Gerando Diagramas de Colaboração:
Na ferramenta “Rational Rose”, após criarmos o diagrama de seqüência. Selecionar:
~ Menu Browse e depois a opção F5 (Create colaboration Diagram)
:
Categori
3: selecionarCategoria
: visitante
7: selecionarProduto( )
4: getDescricao( )
1: getDescricao( )
5: getQuantidade( )
: : Catalogo
Produto
: Form
Busca
2: exibirCategoria( )
6: exibirProduto( )

Workflow de Projeto
Projeto. Atividades e Passos:
Fazer Modelo Especificação
Identificar as classes de
Especificação
Fazer Diagrama de
Interação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Modelo de
Especificação

Workflow de Projeto
Diagrama de Estado
O que é Diagrama de Estado?
É um diagrama que tipicamente complementa a descrição das classes. Pois, este
diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se
encontrar. Mostra também quais as variações de comportamento provocam tais
mudanças.
Não necessário escrever o diagrama de estado para todas as classes de um sistema,
mas, apenas para aquelas que possuem um número definido de estados conhecidos e
onde o comportamento das classes é afetado e modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas.
Aplicação:
Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:
- Classes e Casos de Uso

Workflow de Projeto
Diagrama de Estado
Elementos:
Os diagramas de estados são compostos de transições e estados. As transições são

associadas com ações e são consideradas como processo de curta duração e não
podem ser interrompidos. Os estados são associados com as atividades e podem levar
mais tempo. Uma atividade pode ser interrompida por algum evento.
Verificando
Estado Transição
Início do fluxo Final do fluxo

Workflow de Projeto
Diagrama de Estado
Exemplo:
início
transição
fora do gancho
ocioso Ativo
no gancho
Estado

Workflow de Projeto
Diagrama de Estado
Exemplo 1:
on
Inicializa o
Objeto Lamp
On
Espera por
Evento on/print(”on”)
Trata
Evento
off
off
Lamp
Off
Finaliza
Objeto
stop

Workflow de Projeto
Diagrama de Estado
Exemplo 2: (Completo)
[Nem todos os itens verificados]/pegar
próximo item
início
[Todos os itens verificados e

Verificando
os todos itens disponíveis] Expedindo
[itens ecebidos
[Todos os itens [alguns itens não
verificados e estão disponíveis]
alguns itens não Item recebido
estão disponíveis] [os todos itens
disponíveis]
Aguardando cancelamento
cancelado
Cancelamento Entregue
final

Workflow de Projeto
Diagrama de Estado
Exemplo:
Caso de Uso
Cliente
Autenticar Diagrama de Estado

Senha
Consultar
Verificando Status [Pedido não entregue] Mudando Status
Pedido
Gerenciar <<extends>>
Cancelando Pedido
Pedido
Cancelar
Pedido
<<include>>
UpdateStatus Logistica
Funcionário Confirmar Pedido
Pedido

Workflow de Projeto
O que é Diagrama de Atividade?
É um diagrama que exibe o fluxo seqüencial das atividades, é geralmente utilizado para
demonstrar as atividades executadas por uma operação específica do sistema, como por
exemplo seleção de um item do menu principal.
Consistem em estados de ação, que contém a especificação de uma atividade a ser
desempenhada por uma operação do sistema. Decisões e condições, como execução
paralela, também podem ser representados no diagrama de atividade.
O diagrama também pode conter especificações de mensagens enviadas e recebidas
como partes de ações executadas.
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa
“instance” de um objeto. O diagrama de atividade é uma variação do diagrama de estado
e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar
ações (trabalho e atividades que serão executados) e seus resultados em termos das
mudanças de estados dos objetos.

Workflow de Projeto
Elementos e Exemplo com comentários:
responsabilidades
Cliente Vendas Estoque

Atividade
atividade
Fazer Pedido atividade
transição Processar Pedido
separação Separar Produtos
Enviar Pedido
decisão
Receber Pedido Cobrar Cliente
Pagar Fatura
Barras de
sincronização Fechar Pedido
junção
Elementos
raias
Workflow de Projeto
Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é
executada (sem a necessidade de especificar nenhum evento).
Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como
swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem é responsável e onde
estas atividades residem na organização, e é representada por retângulos que englobam todos os
objetos que estão ligados a ela (swimlane).
Um
Um diagrama
diagramade deatividade
atividadeé pode
uma maneira alternativa
ser usado de se mostrar
com diferentes interações,
propósitos com a possibilidade
inclusive:
de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos),
quando
Para capturar
elas sãoos trabalhos que
executadas serão executados
(seqüência das ações),quando
e ondeuma
elasoperação
acontecemé disparada (ações). Este
(swimlanes).
é o uso mais comum para o diagrama de atividade.
 Para capturar o trabalho interno em um objeto.
• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar
os objetos em torno delas.
• Para mostrar como uma “instance” pode ser executada em termos de ações e objetos.
 Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho,
organização, e objetos (fatores físicos e intelectuais usados no negócio).
Diagrama de Atividades não é orientado a objetos, na verdade ele é muito semelhante a um
fluxograma.

Workflow de Projeto
Exemplo 2:
Receber Pedido
Entrega
Receber Pagamento

a noite
Encerrar Pedido

Workflow de Projeto
- Quando utilizar Diagrama de Atividade:
Como a maioria das técnicas de modelagem comportamental, os diagramas de

atividades têm qualidades e deficiências, a melhor forma de usá-lo é a combinado com
outras técnicas.
A maior qualidade dos diagramas de atividades está no fato que eles suportam e
encorajam comportamento paralelo.
Isso faz que ele possa ser utilizado como uma ferramenta para modelagem de “workflow”,
e, em princípio, para programação concorrente.
A desvantagem destes diagramas é que eles não deixam muito claro as ligações entre as
ações e objetos.
Você pode definir uma ligação para um projeto rotulando uma atividade com um nome
de objeto ou usando raias que dividem uma diagrama de atividades em base em
responsabilidades, mas, isso não tem a clareza simples de diagramas de interação.

Workflow de Projeto
Quando utilizar Diagramas de Atividades:
Podemos utilizar diagrama de atividade nas seguintes situações:

- Analisando um caso de uso: Neste estágio, não estamos interessados em alocar ações aos
objetos; precisamos simplesmente compreender que ações precisam acontecer e quais são
as dependências comportamentais.
- Compreendo workflow: Os diagramas de atividades são muito úteis para compreensão de
um processo de negócio.
- Descrevendo um algoritmo sequencial complicado: Neste caso, um diagrama de
atividades é simples “flowcharts” em notação UML.
- Modelando processamento paralelo: Podemos usar o diagrama de atividades para modelar
aplicações de processamento paralelo.
Quando não é indicado:

- Tentando ver como os objetos colaboram: O diagrama de interação é mais indicado.
- Tentando ver o comportamento de objeto durante se ciclo de vida: Neste caso o
diagrama de estado é o mais indicado.

Workflow de Projeto
Diagrama de Classes. Introdução

Apresentaremos e discutiremos o Diagrama de Classes, ele é considerado o artefato mais
importante e é que também exige mais esforço para ser construído.
O Diagrama de Classes é derivado do Modelo Conceitual (Workflow de Análise)
Agora no Workflow de Projeto o modelo é refinado ganhando adornos, novos tipos de
relacionamentos, métodos e até novas classes.
Esta atividade tem a seguinte divisão, a qual chamamos de refinamento, são quatro
passos. A cada passo faremos alguns refinamentos no modelo.
Também será definido alguns conceito durante estes passsos.

Workflow de Projeto
Diagrama de Classe. Revisão:

• O diagrama de classe é um elemento estrutural

Workflow de Projeto
Diagrama de Classe. Exemplo:

Workflow de Projeto
Diagrama de Classe. Revisão:

Refinamentos:
1 - Refinamento: 2 - Refinamento:
Atributos: Acrescentar tipos de dados e visibilidade Acrescentar: outros tipos de relacionamento entre as classes
exemplo: codigo exemplo: agregação, composição, herança
Acrescentar outros elementos como: Seta de navegação, Role
-codigo: int (private int codigo)
Name (papéis) e multiplicidade
Pessoa
nome
Fase de Análise Fase de Projeto
modelo Diagrama de
Atributos:
conceitual Classes
Tipo de dados e
Cliente Cliente Visibilidade Pedido Cliente
Data Relacionamento
codigo -codigo: int cpf Herança
<<refine>> Status
nome -nome: String codigo
Numero
1
+getCodigo()
1..n item
+setCodigo()
+getNome() ItemPedito
+setNome()
Quantidade
métodos

Workflow de Projeto
Diagrama de Classes. Refinamento

1 - Refinamento:
Exemplo: Atributos e Métodos:

modelo conceitual Diagrama de Classes Atributos:
Tipo de dados e
Cliente Cliente Visibilidade
codigo -codigo: int
<<refine>>
nome -nome: String
+getCodigo()
+setCodigo()
+getNome()
+setNome()
+getCliente() métodos

Workflow de Projeto

1 - Refinamento:
Atributos: Acrescentar tipos de dados e visibilidade e métodos.
exemplo: codigo
-codigo: int (private int codigo)
Método: Definir os Métodos
Cliente
Cliente -codigo: int
codigo <<refine>> -nome: String
nome +getCodigo()
+setCodigo()
Atributos:
Tipo de dados e Visibilidade +getNome()
métodos

Workflow de Projeto

2 - Refinamento:
Acrescentar: outros tipos de relacionamento entre as classes
exemplo: agregação, composição, herança
Acrescentar: Navegação, Role Name (papéis) e Multiplicidade
Pessoa Pessoa Relacionamento
Herança
nome <<refine>> cpf
nome
cliente
PessoaFisica PessoaFisica
codigo codigo Role name
cpf

Workflow de Projeto

Herança, Agregação, Composição, Associação
Herança: É mecanismo baseado em objetos
que permite que as classes compartilhem
atributos e operações baseados em um
relacionamento, geralmente generalização Herança
Podemos dizer que Pós-
Graduação é tipo de Curso
Curso
Uma classe derivada herda a estrutura de Universitário
Universitário, assim como
Curso de Especialização ou
atributos e métodos de sua de Extensão.
extends
classe “base”, mas pode seletivamente:
• adicionar novos métodos
Graduação Pós-Graduação
• estender a estrutura de dados
• redefinir a implementação de métodos já extends
existentes
Especialização Extensão
Uma classe “pai” proporciona a funcionalidade
que é comum a todas as suas classes
derivadas, filhas, enquanto que uma classe
derivada proporciona a funcionalidade
adicional que especializa seu comportamento.
Workflow de Projeto

EspecialidadeMédica generalização
Tipo de Tipo de
especialização
Ortopedia Pediatria
ContaBancaria
Tipo de Tipo de
ContaCorrente ContaPoupança

Workflow de Projeto

Herança:
Quais associações são inválidas:
Figura Cartao TipoPagamento
Tipo de Tipo de
CartaoCredito CartaoDebito
Retangulo Circulo
Tipo de
Tipo de
Ponto

Workflow de Projeto
Diagrama de Classes Avançado. Refinamento

Refinamentos:
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador), 4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
associações reflexivas e Constraint (restrições)
CPF <Interface>
-cpf Pessoa
getCPF() -nome: String
setCPF() +getNome()
+setNome()
{ idade > 18}
Sociio
CPF Cliente -codigo: int
-cpf Livro
-codigo: int * -idade: int
getCPF() -isbn *
setCPF() { idade > 18} -nome: String -titulo +getCodigo()
-idade: int +setCodigo()
getISBN()
+getCodigo() setISBN() +getIdade()
+setCodigo() setTitulo() +setIdade()
Emprestimo
+getNome() getTitulo()
+setNome() -data
+getIdade() -status
+setIdade() getData()
setDAta()
setStatus()
getStatus()

Workflow de Projeto

3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associação Qualificada
É um equivalente da UML de um conceito de programação conhecido como vetores,
árvores binárias, maps ou dicionários.
Qualificador é um atributo da associação cujo os valores particionam o conjunto de
objetos relacionados a um objeto da associação.
Aplicação:
Redução de semântica da associação. Também pode ser usado como índice para hash
ou vetor, isto quando, precisamos ter recurso de pesquisa em uma das extremidades da
associação.
Nome da
Classe associação
0..1
Classe
qualificador
atributos papel papel atributos

Workflow de Projeto

3 - Refinamento:
Associação Qualificada
0..1
ItemPedido
Pedido Produto
Linha de item quantidade: int
Qualificador
O exemplo, demonstra uma associação qualificada, entre as classe Produto,

ItemPedido. O qualificador diz que em associação com Pedido poder haver um item
de pedido cada ocorrência de produto. Conceitualmente, esse exemplo indica que não
é possível existir dois itens de pedido com pedido para o mesmo produto. Para fazer
acesso a um item de pedido em especifico, é necessário identificar o produto como
argumento.
Workflow de Projeto

3 - Refinamento:
Associações Reflexivas e Constraint (restrições)
Associação Reflexiva
Uma associação reflexiva (também conhecida como auto-associação) liga objetos da
mesma classe. Cada objeto tem um papel distinto nesta associação.
papel Nome da associação

1
Classe
*
papéis
Em uma associação o uso dos papéis é importante para evitar ambigüidade na
interpretação da associação. Uma associação reflexiva não indica que um objeto
se associa a si próprio (um empregado não é gerente dele mesmo; uma condição
não é pré-requisito dela mesma). Associação reflexiva indica que um objeto se
associa com outros objetos da mesma classe.
Workflow de Projeto

3 - Refinamento:
Associação Reflexiva:
Exemplo
Supervisão
Supervisor 1
Empregado
*
Supervisionado
Neste exemplo existe uma associação reflexiva objetos de Empregado. Nesta

associação, há objetos que assumem o papel de supervisor e outros objetos que
assumem o papel de supervisionado. O nome da associação pode ser omitido, uma vez
que os papéis foram definidos.
Workflow de Projeto

3 - Refinamento:
Constraint (restrições):
Uma restrição é um relacionamento semântica entre elementos de modelo que
especifica condições que devem ser satisfeitas.
Classe { restrição } 0..1
Classe
atributos papel papel atributos
Duas opções para representar restrições em UML:

• Informal, a UML permite usar qualquer notação para representar as restrições,
entretanto , as estas devem ser especificadas dentro de chaves “{ }”, podemos usar a
linguagem formal, por exemplo.
• Formal, UML fornece linguagem formal de restrições de objetos. (OCL - Object
Constraint Language).
Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm
Workflow de Projeto

3 - Refinamento:
Constraint (restrições):
Por ser um mecanismo de extensão da UML, certos tipos de restrições já estão
definidos, tais como: complete, destroyd, disjoint, implicit, incomplete, new, or
overlapping e transient.
Veja o exemplo: da restrição Contrato
“ou”.
atributos
{ ou }
0..1 0..1
Pessoafisica PessoaJuridica
atributos atributos

Workflow de Projeto

4 - Refinamento:
Classe Associativa
Em associação entre duas classes, a própria associação poderá ter propriedades.
Essas propriedades são originadas a partir da associação de classes com a
multiplicidade de: muitos:muitos, para expor a representação destas propriedades é
implementado uma nova classe que é resultante da associação, assim como seus
atributos e métodos.
Classe * *
Classe
atributos atributos
Nome da Associação Classe de Associação

atributos

Workflow de Projeto

4 - Refinamento:
Classe Associativa
Exemplo
Associação de muitos:muitos
Produto * * Fornecedor
atributos atributos
ProdutoFornecido Classe de associação
atributos

Workflow de Projeto

4 - Refinamento:
Interface:
O que é interface ?
(Representa a forma mais pura de abstração de dados - Linguagem Java)
Interface é um contrato entre o cliente, onde o cliente pode ser classe concreta ou
abstrata. Este contrato é garantia que o métodos assinados na interface serão
implementados na classe cliente.
O relacionamento entre uma interface e uma classe é chamada de realização.
<<interface>> Estereotipo e
nome da interface
Nome Interface
Métodos (assinatura)
Assinatura do
métodos
Nota: Na interface também podemos declarar constantes (public static final).

Workflow de Projeto

4 - Refinamento:
Interface:
Exemplo
Interface, realização e classes
<<interface>>
PessoaJuridica
getCNPJ()
setCNPJ() Realização
setContrato()
getContrato()
Fornecedor PrestadorServico
atributos atributos

Workflow de Projeto

4 - Refinamento:
Dependência:
Uma dependência é um relacionamento de utilização, determinando as modificações
na especificação de um item, mas não necessariamente o inverso.
Utilizamos o relacionamento de dependência no contexto das classes para mostrar que
uma classe usa outra como argumento na assinatura de uma operação.
FilmClip
play(c: Channel)
Channel
start()
stop()
pause()
dependência

Workflow de Projeto
Diagrama de Classes. Outros conceitos: Granularidade

Granularidade:
Geralmente para cada atributo criamos um par de métodos getter e setter, estes
métodos garantem o encapsulamento dos dados. Entretanto, quando estamos em um
ambiente distribuído (de rede), fazer a manipulação de vários e métodos e atributos,
um a um, pode causar um péssimo desempenho, temos que considerar latência de
rede, largura de banda e etc.
Para evitar esta situação podemos criar um método chamado getCliente(), que
contempla todos os dados do cliente, desta forma estaríamos fazendo um única
requisição.
Desta forma temos a seguinte estrutura granular:
Granularidade Grossa: Manipulação através de único método que encapsula todos os

atributos da classe.
Granularidade Fina: Cada atributo tem seu par de método.

Workflow de Projeto
Diagrama de Classes. Granularidade

Granularidade: Exemplo
Cliente
-codigo: int
Granularidade Fina
-descricao: String
+getCodigo()
+setCodigo()
Granularidade Grossa +getDescricao()
+setDescricao()
+getCliente()

Workflow de Projeto
Diagrama de Classes. Construtores:

O que são construtores?
Construtores são um tipo especial de método usado para inicializar uma “instance” da classe.
Toda a classe deve ter um Construtor. Quando não declaramos o “Construtor default”, que é
inicializado automaticamente pelo Java. Mas existem casos que se faz necessário a declaração explícita
dos construtores.
Cliente Tipo
- codigo: int -descricao: String
- nome: String
- tipo: Tipo +getDescricao(): String
<<construtores>> +setDescricao(d: String)
+Cliente(codigo: int, nome: String) dependência
+Cliente(codigo: int, nome: String, tipo: Tipo)
<<métodos>>
+ getCodigo(): int
+ getNome(): String
+ setCodigo(int codigo)
+ setNome(String nome)
+ getTipo(): Tipo
+ setTipo(tipo Tipo)
+ getCliente(): String

Workflow de Projeto

Restrição:
O Construtor não pode ser herdado. Para chamá-lo a partir de uma subclasse usamos a referência
super.
Para escrever um construtor, devemos seguir algumas regras:

1ª O nome do construtor precisa ser igual ao nome da classe;
2ª Não deve ter tipo de retorno;
3ª Podemos escrever vários construtores para mesma classe.
public class Mamifero {

private int idade;
public Mamifero(int idade)

{
this.idade = idade; construtor
}
//Métodos
}

Workflow de Projeto

Quantos construtores pode ter uma classe ?
Uma classe pode ter vários construtores, entretanto, eles devem seguir a regra de
overloading;
Posso ter construtores com mesmo nome, mas com a lista de argumentos diferente
(quantidade de argumentos, tipos de dados, ordem e etc)
public class Mamifero {

private int idade;
public Mamifero(int idade)

{
this.idade = idade;
} construtores
public Mamifero()
{
}
//Métodos
}

Workflow de Projeto
Diagrama de Classes. Propriedades:

Propriedades dos Atributos:
Existem três propriedades definidas que poderão ser utilizada como os atributos:
- Changeable: Não há restrições para se modificar o valor do atributo.
- addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais
poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.
- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for
iniciado
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double Propriedade
+ setValor(double valor)

Workflow de Projeto

Existem três propriedades definidas que poderão ser utilizada como os atributos:
- Changeable: Não há restrições para se modificar o valor do atributo.
- addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais
poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.
- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for
iniciado
TaxaJuro
<<métodos>>
+ getValor(): double Propriedade

Workflow de Projeto

Implementando a propriedade Frozen em Java:
TaxaJuro Modificador Final (constantes)
Para declarar uma variável, um ou uma classe como constante usamos o modificador
- valor: double {frozen} final.
Entretanto, o uso deste modificador deve obedecer a certas restrições como:
<<métodos>> • Uma classe constante não pode ter subclasses;
+ getValor(): double • Um método constante não pode ser sobrescrito;
+ setValor(double valor) • O valor para variável constante deve ser definido no momento da declaração ou através
de um construtor, para variáveis membro, uma vez atribuído o valor, este não mudará
mais.
public class TaxaJuro {
private final double VALOR;
public TaxaJuro(double valor)
{
VALOR = valor;
}
public static void main(String args[])
{
TaxaJuro taxa = new TaxaJuro(21.30);
System.out.println(taxa.VALOR);
}
}

Workflow de Projeto

Exercício: Implementando a propriedade Frozen em Java, implemente também os métodos
set e get e tente mudar o valor da atributo.
TaxaJuro
<<métodos>>
+ getValor(): double

Workflow de Projeto
Diagrama de Classes. Delegação:

Definição de Delegação:
A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma
mensagem.
O reúso de propriedades de uma classe pode ser realizado não só através do mecanismo
generalização entre as classes, mas também através do mecanismo de delegação.
O reúso por generalização se baseia na estrutura de superclasse e subclasse, onde a
subclasse herda todos os métodos e atributos da classe “pai” (superclasse).
Recomendamos usar o mecanismo de delegação em algumas situações:
• Para não violar regra de encapsulamento;
• Para não sobrecarregar de responsabilidade uma classe;
• Para atender a semântica da classe e
• Favorecer o mecanismo de reúso.
A seguir veremos um exemplo completo, onde a aplicação do mecanismo de delegação

é melhor solução para obedecermos as regras da orientação a objetos.

Workflow de Projeto

No Modelo Conceitual devemos identificar os candidatos a classe e seus respectivos
conceitos. Entretanto, devemos antes lembrar da definição da classe.
Classe
A descrição de conjunto de objetos que compartilham os mesmos atributos, operações,
relacionamento e semântica.
Temos a primeira sugestão do modelo, como classe Cliente fazendo uma associação a
Senha.
Cliente Senha
possui
codigo senha
nome

Workflow de Projeto

Em segunda sugestão de modelo, como classe Cliente tem como atributo senha, desta
forma a classe Senha não seria necessário.
Cliente
codigo
nome Quais são as implicações
senha que o atributo “senha” pode
causar ao modelo ?

Workflow de Projeto

Ao modelarmos devemos ter os seguintes cuidados:
1 - Identificar todas classes que fazem uso ou que tem um determinado atributo,
neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deve está explícito no
documento “Domínio do Problema”. Veja o exemplo:
Conceito diferente
Cliente Funcionario
codigo codigo-funcional
nome nome
senha senha
O mesmo conceito
Workflow de Projeto

Ao modelarmos devemos ter os seguintes cuidados: (continuação)
- Uma sugestão para solução do problema:
Pedido Cliente Funcionario

codigo codigo-funcional
nome nome
HistoricoCliente possui Senha possui

senha

Workflow de Projeto

2 - Uma vez que senha é um atributo de cliente como podemos implementar regras de
negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de
conceito (semântica). Veja o exemplo:
Cliente
codigo
nome
senha Este atributo somente é regra
qde_dias_expiracao_senha que se aplica somente a senha e
não a cliente.

Workflow de Projeto

3 - Reúso:
- O atributo senha poderá ser utilizado por outra aplicação, que nem sempre deverá
ver os outros atributos de cliente.
Cliente
codigo
nome
senha
Podemos concluir, que no exemplo apresentado duas regras da orientação a

objetos foram violadas:
- Semântica e
- Baixo reúso

Workflow de Projeto
Mitos e Lendas
O que é dito:
- Modelo de entidade e relacionamento (MER), deve ser feito antes do diagrama de
classes.
Entretanto, a realidade é outra...
Quando estamos a metodologia de orientação a objetos os dados são

encapsulados. Assim o “MER” deve ser derivado do modelo de
classes.

Arquitetura de Software

É apresentar e discutir Arquitetura de Software, conceitos
modelos e técnicas

Workflow Arquitetura
Objetivo:
Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Projeto,
nesta fase criamos os componentes, modelos físicos e como serão distribuídos. Os
principais diagramas UML são:
- Diagrama de Deployment e
- Diagrama de Componentes.
Também nesta fase refinamos o Modelo de Arquitetura. Objetivo primário da arquitetura é

atender os requisitos não funcionais. O artefato deste passo é:
- Modelo de Arquitetura.

Big Picture. Arquitetura

Projeto (Visão Lógica)
Diagramas Arquitetura
Projeto (Visão de Componentes e
Visão de Deployment)
Receber Pedido

: visitante
getDescricao( )
Entrega
exibirCategoria( )
selecionarCategoria [pedido urgente] [senão]

Receber Pagamento
exibirProduto( )

a noite
Encerrar Pedido

Arquitetura
Arquitetura
Digrama de Componentes
Analista de Sistema
Projetista de Software
Diagrama de Deployment Arquiteto de Software

Visão de Visão da
Codificação
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Conceitual Físico

Visão de Implementação
• A visão de implementação de um sistema abrange os componentes e os arquivos utilizados

para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o
gerenciamento da configuração das versões do sistema, compostas por componentes e
arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para
a produção de um sistema executável.
Visão de Implantação
• A visão de implantação de um sistema abrange os nós que formam a topologia de hardware em

que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a
instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa
visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em
diagramas de interações, de gráfico de estados e diagramas de atividades.


Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes
participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes
interessem. Essas cincos visões também interagem entre si, por exemplo:
Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez,
representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das
visões de projeto e de processo.

Modelo de Inicial de Arquitetura

Na Análise fizemos um o Modelo de Arquitetura Inicial para aplicação. O objetivo deste
modelo é apresentar um visão macro da arquitetura.
Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o
Modelo de Arquitetura.
Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para
representar este modelo ou qualquer outra notação.
Este modelo será refinado no workflow de arquitetura na Atividade “Refinar o Modelo
de Arquitetura”.
Passos:
1 - Selecionar o Modelo de Arquitetura
2 – Refinar o Modelo de Arquitetura Inicial.

Decomposição e Camadas
Decomposição:
A decomposição refere-se à fragmentação de uma aplicação ou sistema em partes

menores e lógicas facilitando gerenciar a complexidade. Os módulos, os subsistemas e
componentes são bom exemplo de decomposição.
A decomposição ajuda a definir e a esclarecer as interfaces entre as diferentes partes de
um sistema. Também pode ser útil nas situações em que você tem de integrar com o
legado e ou aplicações de terceiros.
A decomposição pode também auxiliar na distribuição do software em diversos
processadores.
A decomposição ajuda na distribuição de responsabilidades e papéis na equipe de
desenvolvimento.
As desvantagens:
As decomposições inadequadas ou excesso pode levar facilmente a uma grave
degradação do desempenho devido ao “overhead” de comunicação.
Na UML a decomposição pode ser representada através do diagrama de pacotes e

subsitemas.

Workflow de Arquitetura
UML. Diagrama de Pacotes

Como podemos definir o diagrama de pacotes?
A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de
organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida
que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é
linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem
ser usados para fazer decomposição funcional.
A notação usada pela UML para representar pacotes é:
Nome do Nome do
Pacote Pacote
Nome do Pacote
Nome do
Pacote
Dependência
(import)
UML. Diagrama de Pacotes

Decomposição. “Dividir para conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou
ambas as coisas. Para facilitar é necessário fazer uma decomposição.
A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a
modelagem ou processo de desenvolvimento de um software.
Veja o exemplo abaixo:
Contas a Fluxo de
Pagar Caixa
Nome do Pacote
Subsistema
Contas a
Receber Dependência
(import)

Separação em camadas
Camada:
Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar.
A camada é um padrão para a decomposição. A decomposição leva uma fragmentação
lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses
subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos.
O Rational Unified Process (RUP) ou simplesmente UP identifica duas abordagens para a
camada:
- Camada baseada em responsabilidade e
- Camada baseada em reúso.
Camada baseada em responsabilidade:
Estas as camadas são bem definidas, significando que cumprem um papel específico no
esquema geral das coisas. Tais camadas também são conhecidas como níveis.
Níveis:
Os níveis podem ser mapeados para as camadas baseada em responsabilidades, neste
caso um nível torna-se sinônimo de cumprir um papel específico no sistema, como a
apresentação, a lógica de negócio, apresentação e etc.
Uma arquitetura baseada em níveis facilitam a manutenção, disponibilidade e separação
de funcionalidades e de papéis de uma aplicação
Separação em camadas
Níveis:
A forma de se conseguir a distribuição em arquitetura com n níveis é alinhar as camadas
específicas com cada nível, exemplo:
- O nível de cliente, lida com interação com usuário
- O nível de apresentação, lida com apresentação dos dados
- O nível de negócio, contém as regras de negócios e as entidades
- O nível de dados, fornece a interface para armazenamento de dados
<<tier>> <<tier>> <<tier>> <<tier>>

Cliente Apresentação Negócios Dados

Pattern. Model View Controller

Aplicação do MVC (Model, View e Controller)
O padrão MVC originou da linguagem Smalltalk e foi usada para projetar interfaces com
usuário. Esta interface é divida em três partes: model, view e controller.
Onde:
Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans
e EJB.
View: É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP
Controller: Recebe as requisições, faz validação e define o model que manipulará os
dados.
Algumas vantagens do MVC:
- Decomposição;
- Reúso;
- Possibilita o desenvolvimento em paralelo;
- Separação de responsabilidades e papéis;
- Isolamento e separação das camadas e
- Baixo acoplamento.
MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, como
veremos a seguir.

Model View Controller. Model 1

Model 1: O cliente faz uma requisição para uma página dinâmica (JSP ou ASP) que pode
chamar um model (componente) ou outra página dinâmica que faz algum processamento
e devolve para cliente a resposta
View View View
Web Server Model

Model View Controller. Model 2

Model 2: O cliente faz uma requisição para a camada controller que redireciona para
camada model que executa algum processamento e retorna para controller que gera uma
página dinâmica (JSP ou ASP) que é devolvida como a resposta ao cliente
View View View
Controller
Web
Componentes (Model) Server
Model View Controller

Aplicação do MVC em ambiente de três camadas (Web)
View:
Visão representa a apresentação (interface com usuário) de uma aplicação. O componentes
da View obtém os valores do estado do Model.
Separação do View e do Model habilita a construção independente interfaces com

diferentes “Look and Feel” (aparências - skins). Diferentes Views podem interagir
com mesmo model. JSP é escolha natural para implementação do View
Controller:
O Controller fornece a ligação da arquitetura MVC. Ela é responsável por receber as
requisições e determinar qual o Model apropriado para atende-la. Ele também poder
tratar a resposta.

Model View Controller

Aplicação do MVC (Model, View e Controller)
Model:
O modelo representa as regras de negócios de uma aplicação. Encapsulando as regras
dentro de um componente facilita os testes, melhora a qualidade e promove o reúso de
componentes.
Estado do componentes (model):
O estado define um conjunto de valores do Model e inclui métodos para mudar estes
valores. Estes métodos são regras de negócios e outros métodos.
O “estado” de componente são geralmente um protocolo independente. Na

tecnologia Java os JavaBeans e os EJBs são uma boa escolha para implementar
estes componentes.
Na tecnologia .Net (Microsoft) podemos usar os componentes COM+

Introdução:
O papel da Arquitetura:
Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor
e em diversas estações clientes em ambiente de rede local.
Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem
ser distribuídos, ou seja, rodar em uma rede distribuída, com diversos servidores, quando
alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o
funcionamento (desempenho) deste software é missão mais difícil e até critica.
O papel do “Arquiteto de Software” é garantir o funcionamento do software e atendimento

pleno dos Requisitos Não Funcionais (Desempenho, “Escalabilidade”, Confiabilidade,
Segurança e etc) e das Restrições, como uso de determinada tecnologia (protocolos,
linguagens de programação, banco de dados e etc)
As responsabilidades do Arquiteto de Software:
- Selecionar uma tecnologia adequada e projetar um modelo robusto, flexível e eficiente.
- Propor um plano de redução de risco.Um ambiente complexo tem um risco maior, cabe ao
Arquiteto desenvolver um plano para redução de risco.
- O Arquiteto também deve sugerir o uso de Patterns de Arquitetura que são as boas
práticas para a construção do Modelo.

Princípios:
Existem diversos princípios que podemos aplicar a arquitetura de software, entretanto
existem dois que se destacam:
- Separação de Camadas e
- Princípio da Dependência Inversa.

Arquitetura.Road Map
Modelo de Digrama de
Especificação Deployment
Documentos Fazer Diagramas
de Requisitos Digrama de
Componentes
View Controller Model Resources
Modelo de
Fazer Modelo de Arquitetura
Arquitetura Inicial Banco de
JSP/HTML Servlet EJB
Dados
Caso de Uso

Arquitetura. Atividades e Passos:
Fazer Modelo Arquitetura

Selecionar uma
Arquitetura
Fazer Diagrama de Digrama de

Modelo de Deployment
Arquitetura Inicial Deployment
Fazer Diagrama de Digrama de

Componentes Componentes
Refinar Modelo de
Arquitetura (RNFs)
Refinar o Modelo
de Especificação
O que é Diagrama de Deployment?
Variações tradução:
• Diagrama de Deployment <=> Diagrama de Implantação
• Diagrama de Deployment <=> Diagrama de Distribuição
É um diagrama que exibe a arquitetura física do hardware e do software no sistema.

Pode apresentar os computadores e periféricos, juntamente com as conexões que eles
estabelecem entre si. Podemos mostrar também os tipos de conexões entre esses
computadores.
Especifica-se os componentes executáveis e objetos que são alocados para exibir quais
unidades de software são executados e quais computadores.
O diagrama de deployment demonstra a arquitetura “runtime” de processadores,
dispositivos físicos e de software que executam no ambiente onde o sistema
desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo
a estrutura de hardware e software que executam em cada unidade.

Elementos:
Processor (Processador): É qualquer máquina que possua a capacidade de

processamento. Os servidores, estações de trabalho por exemplo.
Servidor
processador
Device (Dispositivo): É qualquer máquina com finalidade ou finalidade limita. Os

dispositivos são os itens como impressoras, roteadores, raids, storages, scanners,
leitoras de código de barra e etc.
Impressora
Dispositivo
Elementos:
Connection (conexão): A conexão é o vinculo entre processadores e dispositivos.
Geralmente representam as conexões de rede físicas (rede local ou distribuída).
estereotipo
Servidor
Cliente <<TCP/IP>>
<<RS 232>>
Processador
Impressora (Nó)
conexão
Dispositivo
(Nó)

Elementos:
Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento
físico que existe em tempo de execução e representa um recurso computacional.
<<WebServer>>
<<Cliente>> Apache
WebBrowser <<HTTP>>
<<RS 232>>
Impressora
Nós
<<Application Server>> <<Banco de Dados>>
JBoss Oracle
<<RMI>>
<<Client-Server>>
Cliente

O diagrama de Deployment pode ser substituído por outro diagrama que exibam com
maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa
recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se
faça necessário.
WebServer Banco de Dados

Apache
Oracle
Application Server
JBoss

Diagrama de Deployment & Diagrama de Componentes

Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma
visão mais “clara” da arquitetura baseada na UML

Diagrama de Componentes. Introdução:

Os componentes são utilizados para a modelagem de coisas físicas que podem residir em
nó, como executáveis, bibliotecas, tabelas, arquivos e documentos.
Um componente tipicamente representa o pacote físico de elementos lógicos, como
classes, interfaces, colaborações.
Bons componentes definem abstrações com interfaces bem-definidas, desta forma é

possível atualização de componentes, ou seja, trocar os componentes mais velhos por
outros componentes mais novos ou por novas versões.
Dependência Componente
A
Componente
genérico
Componente Nome do
B componente

O que é um Diagrama de Componentes?
É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre
seus componentes e a organização de seus módulos durante sua execução.
O diagrama de componente descreve os componentes de software e suas dependências
entre si, representando a estrutura do código gerado. Eles são tipicamente os arquivos
implementados no ambiente de desenvolvimento.
Diagrama de componente representa uma visão física, é um pedaço de software de
sistema e seus relacionamentos.
Quando um componente colabora com outro componente, está colaboração é ilustrada
com uma dependência entre o componente cliente e o componente de serviço.
ReservaService
ReservaUI
Dependência Reserva
Service_ Interface
stub
Room Component

Diagrama de Componentes. Definições:

Componente:
Um componente é a parte física e substituível de um sistema ao qual se adapta e fornece a
realização de um conjunto de interfaces.
Interfaces:
Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe
ou de um componente. O relacionamento entre componente e interface é muito importe.
As tecnologias mais populares usam interfaces na implementação de componentes, tais
como:
- Enterprise Java Beans;
- Corba (CCM) e
- Microsoft COM+.

Diagrama de Componentes. Exemplo:
CatalogHome
CatalogHome
Catalog Catalog
Home EJB
Catalog.jsp Stub Home
Catalog
Business
Delegate
Catalog
CatalogRemote
CatalogRemote Bean
Catalog
Catalog
EJB
Remote
Object CatalogRemote
Stub

Tipos de Componentes:
Existem três tipos de componentes:
- Componentes de Implantação: São os componentes necessários para montar um
sistema executável, como as DLLs e os arquivos EXEs. A definição da UML para
componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB),
além de modelos alternativos como páginas web, tabelas de banco de dados e etc...
CheckIT.exe Video.dll
{versão 1.}
Disk.dll
Floppy.dll

Tipos de Componentes: (continuação)
- Componentes do Produto do Trabalho: Esses componentes são essencialmente o é
parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos
de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema
executável, mas são os produtos de desenvolvimento, usados para criação do sistema
executável. Cliente.class
Conta.class Conta.jar
{versão 1}
Historico.class
Conta.java
- Componentes de Execução: Esses componentes são criados como uma

conseqüência de um sistema em execução, como um componente COM+, que é sofre
“instance” a partir de uma DLL.

Diagrama de Componentes. Elementos:

Elementos:
A UML define cinco estereótipos-padrão que se aplica aos componentes:
1 - Executável:
Especifica um componente que poderá ser executado em um nó
2 - Biblioteca:
Especifica uma biblioteca de objetos estática ou dinâmica
3 - Tabela:
Especifica um componente que representa uma tabela de banco de dados
5 - Arquivo:
Especifica um componente que representa um documento contendo código-fonte ou
dados
6 - Documento:
Especifica um componente que representa um documento.

- Componente: O ícone de componente representa um módulo (pedaço) de software
com uma interface bem definida. Na especificação de componente definimos o
estereótipo como: ActiveX, Applet, Application, DLL e EXE.
Componente
Nome do genérico
Componente
- Especificação e corpo do subprograma: Estes ícones representam a especificação

visível de um subprograma e o seu corpo de implementação. Um subprograma costuma
ser uma coleção de sub-rotinas. Os subprogramas não contém definições de classe.
NewSubprogSpec NewSubprogBody

- Programa Principal: Este ícone representam o programa principal. Um programa
principal que contém a raiz de um programa. Na linguagem Java seria o programa que
tem o método “main”. MainProgram
Programa princial
(método main)
- Especificação e corpo do pacote: Um pacote é a implementação de uma classe. Uma

especificação de pacote constitui-se em um arquivo de cabeçalho, o qual contém as
informações referentes ao protótipo de função para a classe.
Package Specification Package Body
Um corpo de pacote pode
apresentar o código para as
Na linguagem C++, as
operações da classe. Em C++,
especificações de pacote são os
os corpos de pacotes são os
arquivos .h (header). Em Java
arquivos
usamos o ícone de especificação
.cpp
de pacote para representar os
arquivos .java
- Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem
linhas independentes de controle. Uma arquivo executável é geralmente representado
como uma especificação de tarefa com uma extensão .exe
NewTaskSpec NewTaskBody
Além de modelar o componente propriamente dito, podemos modelar o relacionamento

entre o componente e sua interface. Veja o exemplo abaixo:
Componente
genérico
Interface

Arquitetura.Diagrama de Componentes. Exemplo:

Neste exemplo criaremos um diagrama de componentes para a funcionalidade
“cesta de compra”. Neste momento identificaremos as classes que são necessárias
para realizar o caso de uso “adicionar item na cesta de compra”. Como alguns
casos de usos são embutidos, novos componentes serão adicionados ao
diagrama. A tecnologia deste exemplo é Java.
Component view
Boundary
Services
Entities
Visão principal do Diagrama de Componentes


Todos os componentes do pacote Entities. Esses são os componentes que conterão as
classes de entidades.
Component view
Cesta
Entities
Cesta Item Produto
As classes Entidades


Todos os componentes do pacote Services. Esses são os componentes que conterão as
classes de serviços ou de controle.
Component view
CestaService
Services
ProdutoService
As classes de Serviços ou Controle


Todos os componentes do pacote Boundaries. Esses são os componentes que conterão
as classes de Boundaries (ou de interface com usuário).
Component view
CestaInterface
Boundary
As classes de Interfaces


Uma visão dos componentes e relacionamentos
MainProgram
CestaInterface
CestaService
ProdutoService
Cesta
Produto
Cesta Item


Um novo exemplo, o cenário fazer Reserva de apartamento.
Menu Principal
ReservaUI
View
Controller ReservaService
ClienteService
ApartamentoService
Model Cliente Reserva Apartamento

Diagrama de Componentes. Identificação de Componentes:

Componentes:
Componentes são grupos de classes que representam uma funcionalidade

dentro de sistema.
Como faço Componentes são identificados usando coesão e acoplamento. Grupos de

o diagrama de
classes que exigem alta coesão e baixo acoplamento formam um
componentes ?
componente.
Como identificar os componentes ?

Componentes
Na fase de Projeto os componentes são desenhados da
seguinte forma:
• O Diagrama de Classe são revisados e grupos de
classes são identificados usando coesão e
acoplamento.
• Este grupos representaram os componentes.

Conceitos: Acoplamento e Coesão

Independência Funcional
Conceito que está diretamente relacionado a modularidade,

abstração e encapsulamento de informação.
Principais características:
– função de propósito único.
– Interfaces simples quando visto de outras partes da
Independência estrutura do programa.
Funcional: – É medida usando-se dois critérios qualitativos: coesão e
•Coesão e acoplamento.
•Acoplamento
Coesão e Acoplamento ajudaram na divisão de classe dentro

de componente.


Coesão (High Cohesion)
É uma medida de força funcional relativa de um módulo.

Uma classe coesiva executa uma única tarefa, exigindo pouca
interação com outras classes ou objetos. Alta coesão é o desejável.
Como manter a alta coesão ?
Independência - Solução: Atribuir uma responsabilidade de forma que a coesão

Funcional: permaneça alta.
•Coesão e
Como manter a complexidade sob controle ?
•Acoplamento
Em termos de projeto orientado a objetos, a coesão (ou mais
especificamente, coesão funcional) é uma medida de quão
fortemente relacionadas e focalizadas são as responsabilidades
de uma classe.
Uma classe com responsabilidade altamente relacionadas e que
não executa um formidável volume de trabalho tem coesão alta.


Coesão: (continuação)
Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou

executa demasiado trabalho. Tais classes são indesejáveis, elas sofrem
dos seguintes problemas:
- São difíceis de compreender;
- São difíceis de reusar;
- São difíceis de manter;
Independência - São muito sensíveis a mudança;
Funcional:
Classes de coesão baixa representam, geralmente, uma abstração de
•Coesão e
“grande granularidade” ou atribuíram responsabilidades que deveriam ter
•Acoplamento sido delgadas a outras classes ou objetos


Exemplo:
Neste exemplo é NotaFiscal Cliente

- número - codigo
demonstrado a baixa - nome
- data emissão
coesão, uma vez que a - tipo +getCodigo()
classe Nota Fiscal +calcularImposto() +setCodigo()
+getNumero +getNome()
Independência assume a
+setNumero
Funcional: responsabilidade de ....
fazer o cálculo dos
•Coesão e
imposto
•Acoplamento
Tributo NotaFiscalItem Produto
- item[ ] - codigo
- codigo
- quantidade - descrição
- nome
+getQuantidade()
+setCodigo()
+setQuantidade()
+getCodigo()
...


Tributo
Coesão: (continuação) - codigo
- nome
Exemplo:
Solução é delegar a NotaFiscal

responsabilidade de - número
cálculo de imposto para - data emissão
- tipo
uma classe especializada CalculoImposto
+getNumero
neste assunto (usamos
Independência +setNumero
aqui o mecanismo de .... +calcularImposto()
Funcional: delegação). Desta forma
•Coesão e teremos uma alta coesão.
•Acoplamento
Produto NotaFiscalItem Cliente
- codigo - codigo
- quantidade
- descrição - nome
+setCodigo() +getQuantidade() +getCodigo()
+getCodigo() +setQuantidade() +setCodigo()
+gerProduto ... +getNome()
+get/cliente()

Tipos de coesão funcional:
• Coesão Muito Baixa:

– Uma classe é a única responsável por muitas coisas em áreas funcionais
muito diferentes
• Coesão Baixa:
– Uma classe é a única com a responsabilidade de uma tarefa complexa em
Independência área funcional
Funcional: • Coesão Alta:
–
•Coesão e Uma classe tem a responsabilidade moderadas em uma área funcional e
colabora com outras classes para levar a termo as tarefas
•Acoplamento • Coesão Moderada:
– Uma classe tem peso leve e responsabilidade exclusivas em umas poucas
áreas diferentes que estão logicamente relacionadas ao conceito da classe,
mas não entre si.


Benefícios:
• Clareza e a facilidade de compreensão do projeto aumentam;

• A manutenção e as melhorias são simplificadas;
• Freqüentemente, o baixo acoplamento é favorecido;
• A granularidade fina de funcionalidades altamente relacionadas suporta
Independência o aumento do potencial de reúso, porque uma classe altamente coesiva
pode ser usada para finalidade muito específica..
Funcional:
•Coesão e
•Acoplamento


Acoplamento (Low Coupling)
É uma medida da interdependência relativa entre as classes.

Depende da complexidade de interface entre as classes.
Baixo acoplamento é o desejável
Como manter o baixo acoplamento ?
Independência - Solução: Atribuir uma responsabilidade de forma que o

Funcional: acoplamento permaneça fraco
•Coesão e
•Acoplamento Como suportar uma dependência baixa e aumentar o
reúso?
O acoplamento é uma medida de quão fortemente uma classe
está ligada a uma ou mais classes, tem conhecimento das
mesmas ou depende delas.
Uma classe com acoplamento baixo (fraco) não é dependente
de muitas classes.


Acoplamento (continuação)
Uma classe com acoplamento alto (forte) depende de muitas outras

classes. Tais classes são indesejáveis; elas sofrem dos seguinte
problemas:
• Mudança em classes relacionadas forçam mudanças locais
• Mais difícil de compreender isoladamente
• Mais difícil de reusar porque o seu uso requer a presença adicional
Independência das classes que ela depende.
Funcional:
Benefícios:
•Coesão e
•Acoplamento • Não afeta por mudanças em outros componentes
• simples de entender
• conveniente para o reúso.


Acoplamento. Tipos:
Abaixo os possíveis tipos de acoplamento:

Acoplamento Abstrata:
<<Interface>>
Cliente Service Cliente Service
{abstract}
Independência
Service Service Service Service
Funcional:
•Coesão e Sem acoplamento Forte acoplamento
•Acoplamento
Com acoplamento
Cliente Service
Versão 27 tight
Rildo F Santos (rildo.santos@Companyweb.com.br)
Workflow de Projeto, Arquitetura


Acoplamento
Princípio da Dependência Inversa:
“Abstração não deve depender classe concreta. Uma classe

concreta deve depender de uma abstração”
Exemplo:
Independência Moeda MaskMoeda
Funcional: - valor
•Coesão e +getValor
•Acoplamento +setValor
+maskFormat()
dependência
Este modelo tem alguns problemas:

1 - Herança. Todos que herdarem a classe Moeda são obrigados
a herdar também a classe MaskMoeda e as vezes somente
precisamos da classe Moeda.

Acoplamento
Princípio da Dependência Inversa (continuação):
Moeda MaskMoeda
- valor
+getValor
+maskMoeda()
+setValor
Independência
Funcional: dependência
•Coesão e 2 - O relacionamento de dependência inibe a extensibilidade da

•Acoplamento classe Moeda.
Vamos analisar o seguinte cenário:
Em uma aplicação financeira que lida com mercado
internacional, precisamos ter uma classe Moeda com as
seguintes responsabilidades de saber o valor, formatação de
acordo padrão monetário e exibir o respectivo símbolo da
moeda (cifrão).

Acoplamento
Princípio da Dependência Inversa (continuação):

Aplicando a DIP, podemos resolver a situação, veja os modelos
abaixo:
DIP com Classe Abstrata: DIP com Interface:
<<Interface>>
Independência {abstract}
Funcional:
•Coesão e
Service Service Service Service
•Acoplamento
Solução para a classe Moeda:
Moeda MoedaMask
{abstract}
Real Dolar

Acoplamento
Relacionamento de Realização
Problema:
A classe Cliente realiza a interface iPessoa (isto quer dizes que todos os
métodos assinados na interface deve ser implementado na classe) Uma
vez que se declare uma nova assinatura de método na interface iPessoa
será necessário implementar este novo método na classe Cliente.
Independência
Funcional:
•Coesão e <<interface>>
Realização
•Acoplamento iPessoa
Cliente


Acoplamento
Relacionamento de Realização
Solução:
Criação de nova classe PessoaAdapter esta classe se relacionará com a
interface iPessoa, desta forma todas as modificações ou novos
implementações serão feitas nesta classe.
Desta forma reduziremos o acoplamento entre a interface e a classe
Cliente
Independência
Funcional: <<interface>>
•Coesão e iPessoa
•Acoplamento Realização
PessoaAdapter
Cliente

Exemplo:
A partir do diagrama de classe, tentamos agrupar classes usando
técnicas de coesão e acoplamento.
Exemplo:
Acoplamento
Coesão
e Componentes

Exemplo:
Temos o seguinte resultado:
Exemplo:
Acoplamento
Coesão
e Componentes

Exemplo 2:
Diagrama de Classes:

UML. Diagrama de Componentes

Exemplo 2:
A partir do diagrama de classe,
agrupar classes usando os
conceitos de coesão
e acoplamento.
Pedido
Cesta de Compra
Produto
FormaPagto
331
Workflow de Projeto, Arquitetura

Exemplo 2:
Produto
Pedido
Cesta de Compra
Cesta
Produto
FormaPagto
Pedido FormaPagto

Projetando um Modelo de Arquitetura:

Sugestão para modelo de Arquitetura para aplicações Web de três camadas:
Servidor de Aplicação Servidor de

Cliente JBoss Banco de Dados
HTTP
TCP/IP
Oracle
HTML
Windows Linux Suse Linux Suse

Projetando um Modelo de Arquitetura para Camada Cliente:

Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)
DeskTop Servidor de Aplicação

ReservaUI Reserva
<<JRMP>>
Funcionário
<< Stub>> <<Skeleton>>
RMI

Web
Browser
FormConsulta
Cliente
HTTP
WebServer Servlet Tabelas de Reserva
ServletsController
<< Reserva>>
JSP
HotelSchema
Banco de
<< ConnDB>> Dados
JavaBeans


Web
Cliente Apresentação Negócio Integração Recursos
Browser ServletsController << Reserva>> JDBC 2.0

FormConsulta
HTTP
Banco de
Cliente << ConnDB>>
Dados
HTML Servlet/JSP JavaBeans SQL

Implementando os Requisitos Não Funcionais:

Neste momento devemos construir modelo de arquitetura para atender todos os RNF e os casos de
uso mais relevante ao negócio. A seguir demonstraremos um exemplo de como criar uma arquitetura
para RNF.
Considerando o cenário de Loja Virtual, numa transação de pagamento.
Browser
FormPagamento
Fazer Pedido
Cliente <<include>> Cliente
HTTPs (HTTP + SSL)

<<include>>
Fazer Pagamento Fechar Pedido
WebServer
ServletsController
CartaoCredito
Pagamento
Requisito Não Funcional:

Segurança: Todas as transações de pagamento deve ser realizado em ambiente seguro

Quer Mais
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material...
Envie um e-mail para com subject: “Quero entrar na comunidade” para rildo.santos@etecnologia.com.br que te
enviaremos um convite para participar da nossa comunidade
http://etecnologia.ning.com/
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br) 338
Sobre o Análise
autor:eRildo F. Orientado
Desenho Santos a Objetos com UML
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento
Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado
em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade
Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP -
Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC -
Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e
padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de
Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública,
Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL
Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: http://twitter.com/rildosan

Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de
seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste
material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o
autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou
desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie
um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-
mail para nós.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)

Licença:

com UML
Análise e Desenho
Orientado a Objetos
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
Twitter: @rildosan
Versão 27 |

Analise e Desenho Orientado A Objetos Com UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise e Desenho Orientado A Objetos Com UML

Enviado por

Direitos autorais:

Formatos disponíveis

com UML

Parte 1 - Principais Conceitos da Orientação a Objetos e introdução

Parte 2 – Especificação de Requisitos de Software

Parte 3 – Analise Conceitual

Parte 4 – Desenho (design) do Modelo de Especificação de Software

Parte 5 – Arquitetura de Software

Todos os direitos reservados e protegidos © 2006 e 2007

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Introdução. Desenvolvimento de Software Orientada a Objetos

Jacobson pyramid “rational enterprise philosophy”

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

“Objeto pode ser qualquer coisa na natureza que possua

Veja alguns exemplos de objetos:

Pessoa Cão Partida Barco

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

O termo orientação a objetos significa organizar o mundo real

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Objetos do Mundo Real

Para representar os objetos do mundo real criamos classes, E

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Uma coleção de livros

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Classe (Modelo) Objeto (“instance”)

Número chassi VW1003G345

Orientação a Objetos. Principais Conceitos:

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Classe, Responsabilidade e Colaboração

Métodos Uma classe chamada de Transação de Pagamento tem a responsabilidade pelo

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Classe, Responsabilidade e Colaboração

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Classe, Responsabilidade e Colaboração

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos:

Resumo: Classe e Objeto

Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

Orientação a Objetos. Principais Conceitos: