Você está na página 1de 342

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

Todos os direitos reservados e protegidos © 2006 e 2007


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br) 2
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 3
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 4
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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”


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 5
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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...)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 6
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 7
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 8
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 9
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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
Número chassi VW1003G345
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar
parar
verbos

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


Todos os direitos reservados e protegidos © 2006 e 2007 10
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 11
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Objetos do Mundo Real


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 12
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 13
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 14
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 15
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Classe e Objeto
Classe e Objeto. Exemplo:

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

Número chassi VW1003G345


Acelerar()
Ano-fabricação 1966 parar()
Operações
acelerar
parar
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 16
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Classe e Objeto
Classe e Objeto. Exemplo:

Classe
Classes
Cliente
Objetos nome
cpf
Atributos idade
Métodos
Abstração de Dados
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 17
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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...

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


Todos os direitos reservados e protegidos © 2006 e 2007 18
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Classe, Responsabilidade e Colaboração


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...

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


Todos os direitos reservados e protegidos © 2006 e 2007 19
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Classe, Responsabilidade e Colaboração


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 20
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 21
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 22
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 23
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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()

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


Todos os direitos reservados e protegidos © 2006 e 2007 24
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface

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


Todos os direitos reservados e protegidos © 2006 e 2007 25
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface

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


Todos os direitos reservados e protegidos © 2006 e 2007 26
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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; }
}

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


Todos os direitos reservados e protegidos © 2006 e 2007 27
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Abstração de Dados
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 ?

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


Todos os direitos reservados e protegidos © 2006 e 2007 28
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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 é.
Abstração de Dados
Exemplo
Herança
Polimorfismo
Veículo
Encapsulamento
Abstração
Interface

Navio Avião

especialização

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


Todos os direitos reservados e protegidos © 2006 e 2007 29
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Abstração de Dados
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
Abstração de Dados
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 30
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Abstração de Dados
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 31
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Abstração de Dados
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 32
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 33
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Abstração de Dados

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 34
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 35
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.

Abstração de Dados
Sub classe
Herança Graduação Pós-Graduação
Polimorfismo extends
Encapsulamento
Interface Especialização Extensão

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


Todos os direitos reservados e protegidos © 2006 e 2007 36
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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:
Abstração de Dados
Herança
Billhetagem Telefone Móvel
Polimorfismo
Encapsulamento calcularConta(telefone)

Interface

Telefone Fixo

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


Todos os direitos reservados e protegidos © 2006 e 2007 37
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 38
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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
Abstração de Dados
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 39
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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
Abstração de Dados
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 40
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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
Abstração de Dados
Herança Pessoa

Polimorfismo nome
idade setNome() nome getNome()
Encapsulamento
setNome()
Interface getNome()
setIdade() setIdade() idade getIdade()
getIdade()

encapsulamento

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


Todos os direitos reservados e protegidos © 2006 e 2007 41
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 42
Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos:


Capacitação Engenharia de Software

Interface
Exemplo de Interface:

Representação:

Classes
<<interface>>
Objetos Codigo
realização
Atributos getcodigo()
setcodigo()
Métodos
Abstração de Dados
Herança Contrato

Polimorfismo Produto cpf Fornecedor cnpj


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 43
Análise e Desenho Orientado a Objetos com UML

Introdução a aOrientação
Orientação Objetos. aPrincipais
Objetos Conceitos:
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 44
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 45
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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)


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 46
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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).

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


Todos os direitos reservados e protegidos © 2006 e 2007 47
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 48
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 49
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 50
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 51
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

Elementos:
• Elementos estruturais:
– classe, interface, colaboração, caso de uso, classe ativa, componente,

• Elementos comportamentais:
– interação, máquina de estados
• Elementos de agrupamento:
– pacote, subsistema

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


Todos os direitos reservados e protegidos © 2006 e 2007 52
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 53
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 54
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 55
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 56
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 57
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 58
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

Todos os direitos reservados e protegidos © 2006 e 2007 59


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

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

(Visão de Caso de Uso)


: FormBusca : Categoria : Produto : Catalogo
: visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria
getDescricao( ) getQuantidade( )

exibirProduto( )
Encerrar Pedido

selecionarProduto( )

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


Todos os direitos reservados e protegidos © 2006 e 2007 60
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

Projeto
Principais Produtos (Artefatos):

Diagrama de Sequência / Colaboração

Diagrama de Atividades

Diagrama de Estados

Diagrama de Classes

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


Todos os direitos reservados e protegidos © 2006 e 2007 61
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

Big Picture. Projeto &Arquitetura


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

Receber Pedido

: FormBusca : Categoria : Produto : Catalogo


Preencher Pedido Enviar Fatura
: visitante

getDescricao( )

Entrega
exibirCategoria( )

selecionarCategoria [pedido urgente] [senão]


getDescricao( ) getQuantidade( )
Receber Pagamento

exibirProduto( )

Entrega durante Entrega Regular


selecionarProduto( )
a noite

Encerrar Pedido
Diagrama de Componentes
Diagrama de Deployment

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


Todos os direitos reservados e protegidos © 2006 e 2007 62
Análise e Desenho Orientado a Objetos com UML

UML. Linguagem de Modelagem Unificada


Capacitação Engenharia de Software

Arquitetura
Principais Produtos (Artefatos):

Diagrama de Componentes

Diagrama de Distribuição(Deployment)

Modelo de Arquitetura

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


Todos os direitos reservados e protegidos © 2006 e 2007 63
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 64
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
Capacitação Engenharia de Software

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...”
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 65
Análise e Desenho Orientado a Objetos com UML

Ferramenta de Desenvolvimento de Software


Capacitação Engenharia de Software

Big Picture. Requisitos


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

Restrições Requisitos Não


Funcionais Arquitetura Inicial

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


Todos os direitos reservados e protegidos © 2006 e 2007 66
Análise e Desenho Orientado a Objetos com UML

Workflow Requisitos
Capacitação Engenharia de Software

Requisitos
Workflow Artefatos Papéis
Arquitetura Documento de Visão

Analista de Sistema
Analista de Requisitos
Documento de Requisitos

Especificação de Requisitos
(Casos de Uso)

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


Todos os direitos reservados e protegidos © 2006 e 2007 67
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 68
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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).

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


Todos os direitos reservados e protegidos © 2006 e 2007 69
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 70
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 71
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Identificação e elicitação de 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 72
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Identificação e elicitação de 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 73
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Identificação e elicitação de 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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 74
Análise e Desenho Orientado a Objetos com UML

Análise de Requisitos
Capacitação Engenharia de Software

Identificação e elicitação 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 75
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Identificação e elicitação de 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 76
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Identificação e elicitação de 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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 77
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 78
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 79
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Requisitos Funcionais

Classificar os
Requisitos não Funcionais

Documento de Requisitos
Descrever os Usuários
e Entidades Externas

Fazer Plano de Redução


de Risco

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


Todos os direitos reservados e protegidos © 2006 e 2007 80
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 81
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Análise de Requisitos. Detalhar


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 82
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 83
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Análise de Requisitos. Classificar e Detalhar


Requisitos Não Funcionais:
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

Autor: Revisão: Data Atualização:


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 84
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Análise de Requisitos. Classificar e Detalhar


Requisitos Não Funcionais:
Continuação:

Lista de Requisitos Não funcionais

Categoria: Usabilidade
Autor: Revisão: Data Atualização:
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 85
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Análise de Requisitos. Detalhar


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

Autor: Revisão: Data Atualização:

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 86
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Análise de Requisitos. Detalhar


Lista de Stakeholders:
Continuação:

Lista de Entidades Externas

Autor: Revisão: Data Atualização:

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 87
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 88
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Fazer Especificação de Requisitos Requisitos
(Casos de Uso)

Documentos Fazer Validação de Requisitos

Documento de
Especificação
de Requisitos
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 89
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Especificação de Requisitos
Modelo de
Comportamento externo Casos de Uso Arquitetura
do Software
Comportamento interno Seqüência Colaboração

Estrutura Classes

Implementação Distribuição
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 90
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 91
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos
Transformar os Requisitos
Funcionais em Casos de Uso:

Calcular Total

Fazer Cadastro
Cliente
Funcionário
Fazer Pedido

Emitir NF
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 92
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 93
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 94
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 95
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 96
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 97
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 98
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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: ---
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 99
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 100
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 101
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Casos de Uso. Relacionamentos


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 102
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Casos de Uso. Relacionamentos


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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 103
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Casos de Uso. Relacionamentos


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>>

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


Todos os direitos reservados e protegidos © 2006 e 2007 104
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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 ?
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 105
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 106
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 107
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


Especificação de Requisitos:

3
Formulário

Cenários

Gerenciar Reserva
Usuário
Caso de Uso
Ator
Associação

Caso de Uso: Gerenciar Reserva

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


Todos os direitos reservados e protegidos © 2006 e 2007 108
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


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ário 2: Gerenciamento de 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.
Cenário 2: 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 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 109
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


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.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 110
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 111
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


Escrevendo o Formulário de Descrição de Caso de Uso:
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

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 do Hotel verifica a disponibilidade do apartamento
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva

Pós-condição: Reserva confirmada

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


Todos os direitos reservados e protegidos © 2006 e 2007 112
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Especificação de Requisitos. Exemplo:


Especificação de Requisitos:

3
Formulário

Cenários

Gerenciar Reserva
Funcionário
Caso de Uso
Ator
Associação

Caso de Uso: Gerenciar Reserva

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


Todos os direitos reservados e protegidos © 2006 e 2007 113
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 114
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 115
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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>

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


Todos os direitos reservados e protegidos © 2006 e 2007 116
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 117
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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?


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 118
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Validação de 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 119
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

Validação de 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?

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


Todos os direitos reservados e protegidos © 2006 e 2007 120
Análise e Desenho Orientado a Objetos com UML

Requisitos
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 121
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

Análise Conceitual

Objetivo desta parte:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 122
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 123
Análise e Desenho Orientado a Objetos com UML

Workflow Analise
Capacitação Engenharia de Software

Analise
Workflow Artefatos Papéis
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 124
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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
Escalabilidade Distribuição
Throughput Instalação

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 125
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 126
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

Modelo de Arquitetura

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


Todos os direitos reservados e protegidos © 2006 e 2007 127
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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
Documento de Requisitos
Caso de Uso

Workflow de Análise
Atividade:
Fazer Análise Conceitual
Fazer Vocabulário de Conceitos

Artefatos: Modelo Conceitual e


Vocabulário do Sistema.

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


Todos os direitos reservados e protegidos © 2006 e 2007 128
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 129
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Atividade: Fazer Análise Conceitual

Fazer Análise Conceitual


Caso de Uso
Modelo Conceitual

Documento de
Visão

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


Todos os direitos reservados e protegidos © 2006 e 2007 130
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 131
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 132
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Análise Conceitual. Atividades e Passos:

Fazer Análise Conceitual

Identificar os candidatos
a classe

Selecionar uma técnica

Fazer a Lista de
Candidatos

Desenhar o Modelo
Conceitual

Definir a Arquitetura
Inicial

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


Todos os direitos reservados e protegidos © 2006 e 2007 133
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 134
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 135
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 136
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 137
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 138
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Diagrama de Classes

O diagrama de classes deve


capturar o Vocabulário* do
sistema

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


Todos os direitos reservados e protegidos © 2006 e 2007 139
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 140
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 141
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 142
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 143
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 144
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Role Name e Multiplicidade


Exemplo:

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 145
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 146
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 147
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


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..
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 148
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Artefatos:

Modelo Conceitual
Lista de Candidatos

Vocabulário de Conceitos

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


Todos os direitos reservados e protegidos © 2006 e 2007 149
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 150
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 151
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 152
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Identificando os conceitos:
(Técnica usada: extração dos substantivos do enunciado do problema)
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 153
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Identificando os conceitos:
(Técnica usada: extração dos substantivos do enunciado do problema)
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 154
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 155
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Identificando as Associações:

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 156
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Identificando as Associações:

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 157
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 158
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

Identificação dos conceitos dos atributos:

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 159
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Identificação dos conceitos dos atributos:

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 160
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Modelo Conceitual vs Modelo de Especificação

Workflow de Análise Workflow de Projeto

Transacao Transacao

Datahora Datahora:Timestamp
+getTransacao()
+setDataHora()
+getDataHora()

Conceito de Classes
classes e atributos

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


Todos os direitos reservados e protegidos © 2006 e 2007 161
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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


Modelo Conceitual:

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


Todos os direitos reservados e protegidos © 2006 e 2007 162
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 163
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 164
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 165
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

CRC. Exemplos:

Classe: Reserva
Responsabilidades: Colaborações:
Conhecer o período da reserva
Apartamento
(datas)
Cliente
Saber o nome do cliente
Saber o número do apartamento

Classe: Cliente
Responsabilidades: Colaborações:

Saber o nome do cliente Reserva


Saber a Reserva do Cliente

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


Todos os direitos reservados e protegidos © 2006 e 2007 166
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Modelo Conceitual. Técnica: Inspeção Gramatical & CRC

Inspeção Gramatical CRC UML

Lista de Candidatos Classe: Cliente

Responsabilidades: Colaborações:

SaberClasse:
o nome do clienteReserva
Cliente
Saber a Reserva do Cliente
Responsabilidades: Colaborações:

Saber o nome do clienteReserva


Saber a Reserva
Classe: Clientedo Cliente

Responsabilidades: Colaborações:

Saber o nome do clienteReserva


Saber a Reserva do Cliente

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 167
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 168
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Análise de Caso de Uso. Big Picture


Documento de Visão 4 Lista de
1 Candidatos

Engenharia de Requisitos

Análise de Requisitos Especificação de Requisitos


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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 169
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 170
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.
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
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 171
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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:
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
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 do Hotel verifica a disponibilidade do apartamento
O funcionário confirma a reserva
Fluxo Alternativo:
...
O funcionário do Hotel verifica a disponibilidade do apartamento
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva

Pós-condição: Reserva confirmada

Prováveis candidatos a classe


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 172
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Modelo Conceitual. Técnica: Inspeção Gramatical & CRC

Análise de Caso de Uso CRC UML

Lista de Candidatos Classe: Cliente


Responsabilidades: Colaborações:

Saber o nome
Classe: do cliente
Cliente Reserva
Saber a Reserva do Cliente
Responsabilidades: Colaborações:

Saber o nome do cliente


Reserva
Classe:
Saber Clientedo Cliente
a Reserva
Responsabilidades: Colaborações:

Saber o nome do cliente


Reserva
Saber a Reserva do Cliente

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 173
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 174
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 175
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 176
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 177
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 178
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 179
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Vocabulário.Road Map:

Fazer Análise Conceitual


Caso de Uso
Modelo Conceitual

Fazer Vocabulário
Documento de
Visão Vocabulário

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


Todos os direitos reservados e protegidos © 2006 e 2007 180
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 181
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Modelo Conceitual.

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


Todos os direitos reservados e protegidos © 2006 e 2007 182
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 183
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Vocabulário. Exemplo:
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 184
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Vocabulário. Exemplo:
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 185
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 186
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 187
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 188
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 189
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

Arquitetura Inicial.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

Modelo de Arquitetura

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


Todos os direitos reservados e protegidos © 2006 e 2007 190
Análise e Desenho Orientado a Objetos com UML

Workflow de Análise
Capacitação Engenharia de Software

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

Diagrama de Deployment

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


Todos os direitos reservados e protegidos © 2006 e 2007 191
Análise e Desenho Orientado a Objetos com UML

Apêndice
Capacitação Engenharia de Software

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)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 192
Análise e Desenho Orientado a Objetos com UML

Apêndice
Capacitação Engenharia de Software

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)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 193
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

Desenho (design) do Modelo de


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 194
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 195
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Introdução. UML, 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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 196
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Introdução. UML, Visões:


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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 197
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 198
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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 Análise Workflow de Projeto

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


Todos os direitos reservados e protegidos © 2006 e 2007 199
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

Workflow de Análise Análise

dependência

Workflow de Projeto Projeto

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


Todos os direitos reservados e protegidos © 2006 e 2007 200
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Introdução
A Workflow de Projeto refina a Workflow de
Análise:
Workflow de Análise Workflow de Projeto
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 201
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Big Picture. 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

(Visão de Caso de Uso)


: FormBusca : Categoria : Produto : Catalogo
: visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria
getDescricao( ) getQuantidade( )

exibirProduto( )
Encerrar Pedido

selecionarProduto( )

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


Todos os direitos reservados e protegidos © 2006 e 2007 202
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Arquitetura
Workflow Artefatos Papéis
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 203
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Atividades.Road Map

Fazer Modelo de Especificação


Caso de Uso
Modelo de Especificação

Fazer Modelo de Arquitetura


Modelo
conceitual
Modelo de Arquietura

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


Todos os direitos reservados e protegidos © 2006 e 2007 204
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 205
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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


: FormBusca : Categoria : Produto : Catalogo

getDescricao( )

exibirCategoria( )

selecionarCategoria
getDescricao( ) getQuantidade( )

exibirProduto( )

selecionarProduto( )
Formulário

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


Todos os direitos reservados e protegidos © 2006 e 2007 206
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 207
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 208
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
Diagramas de Seqüência:

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


Todos os direitos reservados e protegidos © 2006 e 2007 209
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 210
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 211
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
Diagramas de Seqüência. Numerando as seqüências das mensagens.

: FormBusca : Categoria : Produto : Catalogo


: 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 212
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 213
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 214
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Interação
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( )

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


Todos os direitos reservados e protegidos © 2006 e 2007 215
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 216
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 217
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 218
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Estado
Exemplo:

início

transição

fora do gancho

ocioso Ativo

no gancho

Estado

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


Todos os direitos reservados e protegidos © 2006 e 2007 219
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 220
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 221
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 222
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 223
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 224
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 225
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
Exemplo 2:
Receber Pedido

Preencher Pedido Enviar Fatura

Entrega
[pedido urgente] [senão]
Receber Pagamento

Entrega durante Entrega Regular


a noite

Encerrar Pedido

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


Todos os direitos reservados e protegidos © 2006 e 2007 226
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
- 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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 227
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Atividades
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 228
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 229
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classe. Revisão:


• O diagrama de classe é um elemento estrutural

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


Todos os direitos reservados e protegidos © 2006 e 2007 230
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classe. Exemplo:

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


Todos os direitos reservados e protegidos © 2006 e 2007 231
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 232
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


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

Fase de Análise Fase de Projeto


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 233
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


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
Fase de Análise Fase de Projeto
modelo conceitual Diagrama de Classes
Cliente
Cliente -codigo: int
codigo <<refine>> -nome: String
nome +getCodigo()
+setCodigo()
Atributos:
Tipo de dados e Visibilidade +getNome()
métodos

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


Todos os direitos reservados e protegidos © 2006 e 2007 234
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


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
Fase de Análise Fase de Projeto
modelo conceitual Diagrama de Classes
Pessoa Pessoa Relacionamento
Herança
nome <<refine>> cpf
nome

cliente
PessoaFisica PessoaFisica
codigo codigo Role name
cpf

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


Todos os direitos reservados e protegidos © 2006 e 2007 235
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 236
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


Herança, Agregação, Composição, Associação

EspecialidadeMédica generalização

Tipo de Tipo de
especialização
Ortopedia Pediatria

ContaBancaria

Tipo de Tipo de
ContaCorrente ContaPoupança

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


Todos os direitos reservados e protegidos © 2006 e 2007 237
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


Herança, Agregação, Composição, Associação
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 238
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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()

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


Todos os direitos reservados e protegidos © 2006 e 2007 239
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
associações reflexivas e Constraint (restrições)
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 240
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
associações reflexivas e Constraint (restrições)
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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 241
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 242
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associações Reflexivas e Constraint (restrições)
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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 243
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associações Reflexivas e Constraint (restrições)
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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 244
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associações Reflexivas e Constraint (restrições)
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 245
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 246
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Classe Associativa
Exemplo

Associação de muitos:muitos
Produto * * Fornecedor
atributos atributos

ProdutoFornecido Classe de associação

atributos

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


Todos os direitos reservados e protegidos © 2006 e 2007 247
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
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).


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 248
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Interface:
Exemplo
Interface, realização e classes
<<interface>>
PessoaJuridica
getCNPJ()
setCNPJ() Realização
setContrato()
getContrato()

Fornecedor PrestadorServico
atributos atributos

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


Todos os direitos reservados e protegidos © 2006 e 2007 249
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Refinamento


4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 250
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 251
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Granularidade


Granularidade: Exemplo

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 252
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 253
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Construtores:


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
}

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


Todos os direitos reservados e protegidos © 2006 e 2007 254
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Construtores:


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
}

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


Todos os direitos reservados e protegidos © 2006 e 2007 255
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 256
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 257
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Propriedades:


Propriedades dos Atributos:
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);
}
}

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


Todos os direitos reservados e protegidos © 2006 e 2007 258
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Propriedades:


Propriedades dos Atributos:
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
- valor: double {frozen}

<<métodos>>
+ getValor(): double
+ setValor(double valor)

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


Todos os direitos reservados e protegidos © 2006 e 2007 259
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 260
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 261
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


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 ?

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


Todos os direitos reservados e protegidos © 2006 e 2007 262
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 263
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 264
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


Ao modelarmos devemos ter os seguintes cuidados: (continuação)

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 265
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

Diagrama de Classes. Delegação:


Ao modelarmos devemos ter os seguintes cuidados: (continuação)
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 266
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 267
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

Arquitetura de Software

Objetivo desta parte:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 268
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 269
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Big Picture. Arquitetura


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

Receber Pedido

: FormBusca : Categoria : Produto : Catalogo


Preencher Pedido Enviar Fatura
: visitante

getDescricao( )

Entrega
exibirCategoria( )

selecionarCategoria [pedido urgente] [senão]


getDescricao( ) getQuantidade( )
Receber Pagamento

exibirProduto( )

Entrega durante Entrega Regular


selecionarProduto( )
a noite

Encerrar Pedido
Diagrama de Componentes
Diagrama de Deployment

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


Todos os direitos reservados e protegidos © 2006 e 2007 270
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura
Workflow Artefatos Papéis
Arquitetura
Digrama de Componentes

Analista de Sistema
Projetista de Software
Diagrama de Deployment Arquiteto de Software

Modelo de Arquitetura

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


Todos os direitos reservados e protegidos © 2006 e 2007 271
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Introdução. UML, 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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 272
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Introdução. UML, Visões:


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 273
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Introdução. UML, Visões:


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 274
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 275
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 276
Análise e Desenho Orientado a Objetos com UML

Workflow de Arquitetura
Capacitação Engenharia de Software

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)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 277
Análise e Desenho Orientado a Objetos com UML

Workflow de Arquitetura
Capacitação Engenharia de Software

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)

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


Todos os direitos reservados e protegidos © 2006 e 2007 278
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 279
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 280
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 281
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 282
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 283
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 284
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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+

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


Todos os direitos reservados e protegidos © 2006 e 2007 285
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 286
Análise e Desenho Orientado a Objetos com UML

Workflow de Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 287
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 288
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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
Modelo de Arquitetura
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 289
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Deployment
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 290
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Deployment
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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 291
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Deployment
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ó)

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


Todos os direitos reservados e protegidos © 2006 e 2007 292
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Deployment
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 293
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Deployment
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 294
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 295
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 296
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 297
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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+.

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


Todos os direitos reservados e protegidos © 2006 e 2007 298
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 299
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
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

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


Todos os direitos reservados e protegidos © 2006 e 2007 300
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 301
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 302
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
Tipos de Componentes:
- 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 303
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
Tipos de Componentes:
- 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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 304
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
Tipos de Componentes:
- 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

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


Todos os direitos reservados e protegidos © 2006 e 2007 305
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 306
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura.Diagrama de Componentes. Exemplo:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 307
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura.Diagrama de Componentes. Exemplo:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 308
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura.Diagrama de Componentes. Exemplo:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 309
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura.Diagrama de Componentes. Exemplo:


Uma visão dos componentes e relacionamentos
MainProgram
CestaInterface

CestaService

ProdutoService

Cesta

Produto
Cesta Item

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


Todos os direitos reservados e protegidos © 2006 e 2007 310
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Arquitetura.Diagrama de Componentes. Exemplo:


Um novo exemplo, o cenário fazer Reserva de apartamento.
Menu Principal
ReservaUI
View

Controller ReservaService

ClienteService
ApartamentoService

Model Cliente Reserva Apartamento

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


Todos os direitos reservados e protegidos © 2006 e 2007 311
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 312
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 313
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 314
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 315
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


Coesão: (continuação)

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()
...

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


Todos os direitos reservados e protegidos © 2006 e 2007 316
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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()
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 317
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


Coesão: (continuação)

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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 318
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


Coesão: (continuação)

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 319
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 320
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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.

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


Todos os direitos reservados e protegidos © 2006 e 2007 321
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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
Cliente Service Cliente Service

Com acoplamento
Cliente Service

Versão 27 tight
Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 322
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto, Arquitetura


Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 323
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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).
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 324
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesã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>>
Cliente Service Cliente Service
Independência {abstract}

Funcional:
•Coesão e
Service Service Service Service
•Acoplamento
Solução para a classe Moeda:

Moeda MoedaMask
{abstract}

Real Dolar
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 325
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 326
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Conceitos: Acoplamento e Coesão


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 327
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

Exemplo:
Acoplamento
Coesão
e Componentes

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


Todos os direitos reservados e protegidos © 2006 e 2007 328
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
Exemplo:

Temos o seguinte resultado:

Exemplo:
Acoplamento
Coesão
e Componentes

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


Todos os direitos reservados e protegidos © 2006 e 2007 329
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Diagrama de Componentes
Exemplo 2:
Diagrama de Classes:

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


Todos os direitos reservados e protegidos © 2006 e 2007 330
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Análise e Desenho Orientado a Objetos com UML

Workflow de Projeto, Arquitetura


Capacitação Engenharia de Software

Diagrama de Componentes
Exemplo 2:
Diagrama de Componentes

Produto

Pedido

Cesta de Compra
Cesta

Produto

FormaPagto
Pedido FormaPagto

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


Todos os direitos reservados e protegidos © 2006 e 2007 332
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 333
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 334
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Projetando um Modelo de Arquitetura para Camada Cliente:


Web

Browser
FormConsulta

Cliente
HTTP

WebServer Servlet Tabelas de Reserva

ServletsController

<< Reserva>>
JSP
HotelSchema
Banco de
<< ConnDB>> Dados
JavaBeans

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


Todos os direitos reservados e protegidos © 2006 e 2007 335
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

Projetando um Modelo de Arquitetura para Camada Cliente:


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

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


Todos os direitos reservados e protegidos © 2006 e 2007 336
Análise e Desenho Orientado a Objetos com UML

Workflow Arquitetura
Capacitação Engenharia de Software

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

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


Todos os direitos reservados e protegidos © 2006 e 2007 337
Análise e Desenho Orientado a Objetos com UML
Quer Mais
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material...
Capacitação Engenharia de Software

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/
Todos os direitos reservados e protegidos © 2006 e 2007
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.
Capacitação Engenharia de Software

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
Blog: http://rildosan.blogspot.com/

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


Todos os direitos reservados e protegidos © 2006 e 2007 339
Análise e Desenho Orientado a Objetos com UML
Marcas Registradas:
Capacitação Engenharia de Software

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)


Todos os direitos reservados e protegidos © 2006 e 2007 340
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Análise e Desenho Orientado a Objetos com UML
Licença:
Capacitação Engenharia de Software

Todos os direitos reservados e protegidos © 2006 e 2007 341


Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
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 |