Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007
An
áli
se e
Des
enh
o
Ori
enta
do
a O
bje
tos
com
UM
L
Versão 27 |
Rildo F [email protected]
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 2
Conteúdo
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
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 3
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
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 4
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.
Objetivo
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 5
Introdução. Desenvolvimento de Software Orientada a Objetos
Metodologia/Fases
WorkFlows
Atividades
Ferramentas
e
Artefatos
Tecnologia OO
Influência escolha da
Ferramentas
Suporte as atividades
Jacobson pyramid “rational enterprise philosophy”
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 6
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 BarcoPartida
de Futebol
Os objetos podem ser físico (aqueles que podemos pegar, exemplos: uma pessoa,
um animal, um barco, um livro, um carro, uma casa e etc) e os conceituais
(aqueles que não podemos pegar, tais como: cobrança de IOF, uma ligação
telefônica, uma conta corrente e etc...)
Objetos do Mundo Real
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 7
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.
Propriedades Operações
Nome
Data de Nascimento
Massa (peso)
Altura
Andar
Correr
Trabalhar
Chorar
Dançar
Objeto: Pessoa
Espécie
Cor das penas
Tamanho
Peso
Andar
Correr
Voar
Pousar
Propriedades OperaçõesObjeto: Pássaro
Objetos do Mundo Real
Orientação a Objetos. Principais Conceitos:
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 8
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
Operações
Ano-fabricação
acelerar
parar
Identificador
O que são operações ?
- Coisas que objeto deve
saber fazer
Carro
Objetos do Mundo Real
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 9
Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que
ele tem um estado
cor
Número chassi
Operações
Ano-fabricação
acelerar
parar
VW1003G345
branco
1966
IdentificadorCarro
Atributos
Objetos do Mundo Real
estado
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 10
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
cor
Número chassi
Operações
Ano-fabricação
acelerar
parar
VW1003G345
branco
1966
Identificador
Atributos
Carro
Substantivo
verbos
Objetos do Mundo Real
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 11
Modelagem de objeto:
cor
Número chassi
Operações
Ano-fabricação
acelerar
parar
VW1003G345
branco
1966
Identificador
Atributos
Carro
Carro
cor
número chassi
ano-fabricação
acelerar
parar
Objetos do Mundo Real
Representação na
Orientação a objetos
Nome (identificador)
Propriedades
(atributos)
Operações
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 12
Modelagem de objeto:
Carro
cor
número chassi
ano-fabricação
acelerar
parar
Objetos do Mundo Real
O que é
uma classe ?
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.
As classes são “blueprint” (projeto) para os objetos. São fôrmas
de objetos.
Representação na
Orientação a objetos
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 13
Classe
As classes são as partes mais importantes de qualquer sistema orientada a
objetos.
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
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
somente conceituais.
Exemplo:
A classe Pessoa deverá ter atributos e métodos comuns
Definição de Classe:
Uma classe descreve um conjunto de objetos que compartilham os
mesmos atributos, operações, métodos, relacionamentos e semântica
Pessoa
nome
idade
getNome()
getIdade()
setNome()
setIdade()
Nome da Classe
Atributos
Métodos
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Nota: Dicionário Aurélio
Em programação ou modelagem orientada a objetos (v. orientação a objetos), categoria descritiva
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
mais características em comum.
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 14
Classe
Exemplo de Classe:
Livro1
2
Legenda:
1 – Objeto no mundo real
2 – Classe Livro
3 – Objeto da classe Livro
3
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
ISBN 0747551006
Titulo: Harry Potter and the
Order of the Phoenix
Autor: J. K. Rowling
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 15
Classe e Objeto
Classe e Objeto. Exemplo:
ISBN 8571643512
Titulo: AS JANELAS DO
PARATII
Autor: Amir Klink
ISBN 0747551006
Titulo: Harry Potter and the
Order of the Phoenix
Autor: J. K. Rowling
ISBN 0747551006
Titulo: O Poder da inteligência
Emocional
Autor: Daniel Goleman
Uma coleção de livros
pode ser representada
por uma classe chamada
Livro.
Cada livro desta coleção é
“instance” (objeto) da classe livro.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 16
cor
Número chassi
Operações
Ano-fabricação
acelerar
parar
VW1003G345
branco
1966
Identificador
Atributos
Carro
Carro
cor
número chassi
ano-fabricação
Acelerar()
parar()
Classe (Modelo)
fusca:Carro
cor=“branco”
número chassi=“VW1003G345
ano-fabricação=1966
Objeto (“instance”)
Classe e Objeto. Exemplo:
Orientação a Objetos. Principais Conceitos:
Classe e Objeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 17
nome
cpf
idade
Cliente
Cliente: clientehomem
nome = Felipe
cpf = 039.217.908-22
idade = 42
Cliente: clientemulher
nome = Marina
cpf = 022.200.708-12
idade = 16
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Classe e Objeto. Exemplo:
Classe
Objetos
Orientação a Objetos. Principais Conceitos:
Classe e Objeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 18
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Responsabilidades
Definição de Responsabilidades:
Um contrato ou obrigação em tipo ou de uma classe
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.
Em nível mais abstrato, esses atributos e operações são apenas as características com
quais as responsabilidades das classes executadas.
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
transação, situação, valor, data, tipo de pagamento e etc.
TransacaoPagamento
numero
valor
data
situação
TipoPagamento
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...
Responsabilidades
Orientação a Objetos. Principais Conceitos:
Classe, Responsabilidade e Colaboração
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 19
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Colaboração:
Definição de Colaboração:
Ás vezes uma classe precisa colaborar com outra classe para
cumprir suas responsabilidades
A classe Transação de Pagamento tem a responsabilidade pelo conhecimento das
seguintes informações: número da transação, situação, valor, data, tipo de
pagamento e etc.
As informações sobre tipo de pagamentos estão outras classes que tem dados
especifica para cada tipo de pagamento. Exemplo: CartaoCredito e BoletoBancario.
Desta forma precisamos ter uma colaboração entre as classes para atender as
responsabilidades.
TransacaoPagamento
numero
valor
data
situação
TipoPagamento
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...
CartaoCredito
BoletoBancarioColaboração
Orientação a Objetos. Principais Conceitos:
Classe, Responsabilidade e Colaboração
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 20
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
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.
O CRC (Cartão de Responsabilidade e Colaboração) é técnica para capturar e
representar as classes suas responsabilidade e colaborações.
Outra técnica que pode ser usada é a Análise baseada em Caso de Uso podem ser
usada.
Nome da classe
Responsabilidades Colaborações
Aluno
-- Deve conhecer os
dados dos aluno:
Nome
Número da Matricula
Curso
Matricula
Pessoa
Curso
Cartão
Classe, Responsabilidade e Colaboração
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 21
Resumo: Classe e Objeto
Resumindo:
Um objeto possui:
• um estado (definido pelo conjunto de valores dos seus
atributos em determinado instante)
• um comportamento (definido pelo conjunto de métodos
definido na sua interface)
• uma identidade única
Uma classe possui:
• Atributos
• Métodos
• Responsabilidades (o que ela sabe fazer)
• Colaboração (interação com outras classes)
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 22
Atributo
Definindo Atributo:
• É uma características (propriedade) presente no objeto.
• Valor de todos os atributos é igual Estado do Objeto.
• Somente atributos que são de interesse do sistema devem ser
descritos na classe.
nome
cpf
idade
Cliente
Cliente: clientemulher
nome = Marina
cpf = 022.200.708-12
idade = 16
atributos
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 23
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( )
Cliente
codigo
nome
getCodigo()
setCodigo()
getNome()
setNome()
Métodos
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
setCodigo():
Para trocar o valor do atributo
getCodigo():
Para recuperar o valor do atributo
Exemplo:
Valor do atributo: nome = null
setNome(“Duke”).
Agora valor do atributo nome = “Duke”
getNome(), retornará “Duke”
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 24
Método
Definição de Método:
Chamando os métodos
Para chamar um método de um objeto é necessário enviar uma mensagem para ele.
As mensagens identificam os métodos a serem executados no objeto receptor.
Por definição todas as mensagens tem um tipo de retorno.
ContaCorrente
conta
saldo
setDeposito()
getSaldo()
setSaque()
Métodos
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Definição:
Método é a implementação de uma operação.
Definição de Operação:
É a implementação de serviço que pode ser solicitado por qualquer
objeto da classe com a finalidade de afetar um comportamento.
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 25
Mensagem
Definição de Mensagem:
Definição:
Mensagem é uma chamada de uma operação sobre um objeto,
compreendendo um nome de operação e uma lista de valores de
argumentos. (Rumbaugh)
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.
Essa mensagem deve conter informações suficiente para que a operações do objeto
receptor possa ser executada
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 26
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.
A mudança de estado de um objeto deve ocorrer através dos
métodos.
Desta forma podemos dizer que os métodos “encapsulam” os
atributos.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 27
Classe Concreta e Abstrata
Temos dois tipos de classes: Concreto
e Abstrato
Classe concreta:
São aquelas classes que podem
sofrer “instance” (criar objetos) e
tem seus métodos implementados
por completo.
E a Classe abstrata ?
Bem, veremos a seguir o que é
uma classe abstrata...
public class Pessoa {
//Atributos
private String nome;
private int idade;
//métodos
public String getNome(){
return nome; }
public void setNome(String
nome){
this.nome = nome; }
public int getIdade(){
return idade; }
public void setIdade(int
idade){
this.idade = idade; }
}
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 28
Abstração de DadosExemplo:
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 ?
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 29
Definição de Abstração de Dados:
Qual é a função da abstração ?
A função da abstração é capturar as propriedades e os comportamentos essenciais,
como se fosse uma fatoração, desta forma determina-se o que é importante e o que
não é.
Exemplo
especialização
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Veículo
Navio
Abstração
Definição de abstração:
“Habilidade mental que permite aos seres humanos visualizarem os problemas
do mundo real com vários graus de detalhe, dependendo do contexto corrente do
problema. (Jim Rumbaugh).
Avião
Abstração de Dados
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 30
Exemplo de Abstração de Dados:
MeiodeComunicação
Carta Telefone Jornal
As classes Contribuinte e MeiodeComunuicação neste caso são abstratas e
ambas podem representam um domínio.
Exemplo
Generalização
Especialização
Abstração: nos ajuda a lidar com a complexidade.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Abstração de Dados
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 31
Abstração de Dados:
public abstract class ContaBancaria extends Object {
public ContaBancaria() { }
protected int numerocontacorrente;
public abstract int getNumeroContaCorrente();
public abstract void setNumeroContaCorrente(int numerocontacorrente);
}
Uma classe abstrata é uma classe que:
• Provê organização
• Não possui “instances”, ou seja, não possui objetos.
• Possui uma ou mais operações (métodos) abstratasClasses
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Abstração de Dados
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 32
//métodos
public abstract String getNome()
public void setNome(String nome){
this.nome = nome;
}
public abstract int getIdade()
public void setIdade(int idade)
{
this.idade = idade;
}
Veja agora a classe Pessoa, que é
abstrata, pois, possui um método
abstrato.
public abstract class Pessoa {
}
public abstract int calcIdade(Date
d1, Date d2);
Um método abstrato não possui
implementação somente assinatura
(declaração)
Um método concreto possui implementação
assinatura e implementação.
public void setIdade(int idade)
{
this.idade = idade;
}
Abstração de Dados
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 33
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
métodos concreto.
Uma classe abstrata não possui “instance”
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Como eu faço
para usar uma
classe abstrata ?
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 34
Comparação entre Classe Abstrata e Classe Concreta
Classe Abstrata Classe Concreta
Os métodos devem ser somente assinadosOs métodos podem ser assinados e
implementados
Não pode sofrer “instance” Poder sofrer “instance”
Relacionamento somente através de
HERANÇATodos os tipos de relacionamentos
Abstração de Dados
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 35
Herança
Definição de Herança:
Definição:
Mecanismo baseado em objetos que permite que as classes compartilhem atributos
e operações baseados em um relacionamento, geralmente generalização.
(Rumbaugh)Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
InterfaceAnimal
Animal SelvagemAnimal Doméstico
Uma classe derivada herda a estrutura de atributos e métodos de sua
classe “base”, mas pode seletivamente:
• adicionar novos métodos
• estender a estrutura de dados
• redefinir a implementação de métodos já existentes
Uma classe “pai” ou super classe proporciona a funcionalidade que é comum a todas as
suas classes derivadas, filhas ou sub classe, enquanto que uma classe derivada
proporciona a funcionalidade adicional que especializa seu comportamento.
Exemplo:
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 36
Herança
Exemplo de Herança:
Podemos dizer que Pós-
Graduação é tipo de Curso
Universitário, assim como
Curso de Especialização ou
de Extensão.
Graduação Pós-Graduação
Curso
Universitário
Especialização Extensão
Hierarquia de Classes
Super classes
extends
Sub classe
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 37
Polimorfismo
Definição de Polimorfismo:
Definição:
“Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade
segundo o qual uma operação pode comportar-se diferentemente em classes
diferentes” (Rumbaugh)
O polimorfismo é o responsável pela extensibilidade em programação orientada a
objetos.
Promove o reúso.
Exemplo:
Billhetagem
calcularConta(telefone)
Telefone Móvel
Telefone Fixo
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 38
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
chamada, veja o exemplo.
TesteSoma Soma
somar(int a, int b)
somar(float a, float b)
somar(char a, char b)
somar(long a, long b))
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.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Polimorfismo
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 39
Overridde de Método
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Uma subclasse pode mudar o comportamento herdado da Superclasse, ou
seja, um método herdado poderá ser modificado. Veja o exemplo abaixo:
Conta Bancária
getSaldo()
Conta Corrente
getSaldo()
Conta Poupança
getSaldo()
Investimentos
getSaldo()
O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada tipo de
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
Polimorfismo
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 40
Principais Conceitos
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.
Public
Operações/métodos/interface
Private
Dados/Atributos/propriedades
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
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Encapsulamento
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 41
Benefícios do Encapsulamento:
Benefícios
- Segurança:
Protege os atributos dos objetos de terem seus valores corrompidos por
outros objetos.
- Independência:
“Escondendo” seus atributos, um objeto protege outros objetos de
complicações de dependência de sua estrutura interna
nome getNome()setNome()
idade getIdade()setIdade()
encapsulamento
nome
idade
Pessoa
setNome()
getNome()
setIdade()
getIdade()
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Encapsulamento
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 42
Definição de Interface:
O que é interface ?
Interface é um contrato entre o cliente (classe) e uma interface. Este
contrato é garantia que o métodos assinados na interface serão
implementados na classe cliente.
As interfaces são consideradas a forma mais pura de abstração de dados,
pois, somente podemos assinar (declarar) os métodos. Podemos usa-las
também para prover:
- Organização e padronização de assinatura de métodos;
- Simular herança múltipla e
- Fazer relacionamentos de classes com responsabilidade distintas.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 43
Exemplo de Interface:
Representação:
getcodigo()
setcodigo()
<<interface>>
Codigo
getcodigo()
setcodigo()
Produto
getcodigo()
setcodigo()
Fornecedor
realização
cpf cnpj
Contrato
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 44
Principais Características
Características de uma interface:
•Não possui implementação própria.
•Ela define operações, mas não os métodos.
•Uma interface especifica, usualmente, uma parte limitada do comportamento de uma
classe ou componente.
•Uma classe pode realizar várias interfaces.
Porque utilizar interfaces:
• Reduz o acoplamento (dependência) entre classes, aumentando a sua
reusabilidade.
• Permite que componentes possam ter diferentes interfaces de acordo com as
necessidades dos seus usuários.
• Ajuda a esconder a complexidade da arquitetura de componentes.
• Oferece uma forma simplificada de implementar herança múltipla.
Classes
Objetos
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Introdução a Orientação a Objetos
Interface
Orientação a Objetos. Principais Conceitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 45
UML. Linguagem de Modelagem Unificada
A versão da UML abordada é versão 1.5
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 46
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?
Introdução
“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 47
O Que é Modelagem Visual?
Modelagem visual significa modelar com a utilização de notações padrão.
Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada.
UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das
mais populares do momento.
A UML (Linguagem de Modelagem Unificado) é
padrão mantido pelo OMG (www.omg.org/uml).
Introdução
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 48
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.
Introdução
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 49
ESTÁTICOS
. Diagrama de Classes
. Diagrama de Objetos
. Diagrama de Componentes
. Diagrama de Distribuição
DINÂMICOS
. Diagrama de Casos de Uso
. Diagramas de Interação
- Diagrama de Seqüência
- Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados
Modela o comportamento do sistema
Modela a estrutura do sistema
Principais Digramas:
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 50
Processo de Desenvolvimento:
Processo de Desenvolvimento
VisãoAnáliseClasses
Defeitos
Modelo Casos
Uso de Negócio
Modelo Objetos
de NegócioModelo de Classes
Componentes
Desenho Classes
Script de Testes
Casos de Teste
Modelo de
Casos de Uso
Necessidades dosStakeholders
Realização dos Casos de Uso
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 51
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
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 52
• Elementos estruturais:
– classe, interface, colaboração, caso de uso, classe ativa, componente,
nó
• Elementos comportamentais:
– interação, máquina de estados
• Elementos de agrupamento:
– pacote, subsistema
Elementos:
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 53
Visões:
Visão de Projeto
Funcionalidade
Vocabulário
Visão da Implementação
Codificação
Montagem
Visão do Processo
Desempenho
Escalabilidade
Throughput
Visão da Implantação
Topologia do Sistema
Distribuição
Instalação
Conceitual Físico
Visão de Caso de Uso
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 54
• 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
• 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 Caso
de Uso
Visão de Projeto
Visões:
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 55
• 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.
• 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 Implementação
Visão de Processo
Visões:
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 56
• 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.
Visão de Implantação
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.
Visões:
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 57
Exemplo: de Projeto Software Orientado a Objetos:
unidades
Use case view
Logical view
Casos de Uso
Diagrama de Seqüência e/ou
Diagrama de Colaboração
Diagrama de Estado
Diagrama de Atividades
Diagrama de Pacotes
Formulários
Diagrama de ClassesDiagrama de Estado
Diagrama de Atividades
Diagrama de Pacotes
Component view
Diagrama de Componentes
Diagrama de Deployment
Deployment view
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 58
Big Picture. Requisitos e Análise
Glossário de
conceitos
Modelo Conceitual
Análise Conceitual
Casos de Uso
Engenharia de Requisitos
Requisitos Funcionais
Requisitos Não
Funcionais
Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso)
Coleta de Requisitos
Documento
de Visão
Business Case
Arquitetura Inicial
4
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 59
Introdução. Artefatos:
Produtos dos Workflows de Requisitos e de Análise:
Documento de Visão
Especificação de Requisitos (Casos de Uso)
Vocabulário do Sistema
Modelo Conceitual ou Modelo de Domínio
Documento de Requisitos
Análise
Requisitos
UML. Linguagem de Modelagem Unificada
Modelo de Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 60
Big Picture.
Modelo Conceitual
4
Análise
Diagrama de Classes
Projeto (Visão Lógica)
4
: visitante : Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( ) getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noiteEntrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Especificação de Requisitos
(Visão de Caso de Uso)
Análise & Projeto
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 61
Diagrama de Sequência / Colaboração
Diagrama de Classes
Diagrama de Atividades
Principais Produtos (Artefatos):
Projeto
Diagrama de Estados
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 62
Big Picture. Projeto &Arquitetura
Diagramas
Projeto (Visão Lógica)
4
: visitante : Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( ) getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noiteEntrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Projeto (Visão de Componentes e
Visão de Deployment)
Diagrama de Componentes
Diagrama de Deployment
Arquitetura
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 63
Diagrama de Componentes
Diagrama de Distribuição(Deployment)
Principais Produtos (Artefatos):
Arquitetura
Modelo de Arquitetura
UML. Linguagem de Modelagem Unificada
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 64
Especificação de Requisitos
de SoftwareObjetivo 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
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 65
Um entendimento completo dos requisitos de software é essencial para um o sucesso do
desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado
seja, um programa mal analisado e especificado frustrará o usuário.
Análise de requisitos é um processo de descoberta, refinamento, modelagem e
especificação.
O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado
durante o planejamento do projeto de software, é aperfeiçoado em detalhes.
Modelos, diagramas, fluxos são criados para melhor compreensão do problema.
O analista e o usuário desempenham um papel ativo na análise e especificação de
requisitos.
O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às
vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e
solucionador de problemas.
Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente
simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as
oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.
O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a
declaração de um cliente anônimo:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo
que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”
Análise de Requisitos: Introdução
Introdução
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 66
Big Picture. Requisitos
Glossário de
conceitos
Modelo Conceitual
Análise Conceitual
Casos de Uso
Engenharia de Requisitos
Requisitos Funcionais
Requisitos Não
Funcionais
Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso)
Coleta de Requisitos
Documento
de Visão
Restrições
Business Case
Arquitetura Inicial
Ferramenta de Desenvolvimento de Software
4
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 67
Arquitetura
Analista de Sistema
PapéisArtefatosWorkflow
Requisitos
Workflow Requisitos
Analista de Requisitos
Documento de Visão
Especificação de Requisitos
(Casos de Uso)
Documento de Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 68
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 69
Requisitos
Definições de requisito (segundo IEEE)1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um
problema ou alcançar um objetivo.
2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema
ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação
ou outros documentos impostos formalmente.
3) Uma representação documentada de uma condição ou capacidade, conforme os itens
(1) e (2).
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 70
Documento de Visão
Fazer identificação e elicitação
de requisitos
Requisitos
Requisitos. Road Map
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Usuários e
Clientes
Documentos Fazer Validação de Requisitos
Regras de
negócio
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 71
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.
Requisitos
Identificação e elicitação de Requisitos:
Elicitação RuimElicitação Boa
Diagnóstico ineficiente Bom Diagnóstico
Soluções medíocres Soluções eficientes
Insatisfação dos usuários Satisfação dos usuários
Problemas operacionais e financeiros Melhoria dos processos e redução de custo
Uma Simples Comparação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 72
Documento (Artefato) desta etapa: “Documento de Visão”
Objetivo:
Descrever
a visão inicial
do software
Documento
de visão
Participantes:
Analistas e
Especialista
em Negócios
identificação/
elicitação de
Requisitos
entrevistas
documentosreuniões
Participantes:
Usuário,
Clientes,
Fornecedores e
Patrocinadores
Identificação e elicitação de Requisitos:
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 73
As fases da Identificação/Elicitação de Requisitos:
Um projeto de elicitação de requisitos têm as seguintes fases:
Planejamento
Elicitação de
Requisitos
Documentação
Documento de Visão
Identificar FontesTécnicas
Como deve ser feito ?
O que devo coletar ?
Como devo documentar ?
Identificar Funcionalidades
Identificar Restrições e Riscos
Requisitos
Identificação e elicitação de Requisitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 74
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)
Requisitos
Identificação e elicitação de Requisitos:
Quais são as técnicas ?
Existem várias técnicas, todas elas possuem seus
próprios conceitos, vantagens e desvantagens,
que podem ser usada nesta atividade entre elas estão:
- Reuniões;
- Entrevistas;
- Questionários;
- Workshop;
- Brainstorming;
- JAD (Join Application Development)
- Fast;
- Documentos;
- Sistemas Legados.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 75
Identificação dos Requisitos: Tipos de RequisitosOs Requisitos de Software podem ser divididos em duas categorias:
Análise de Requisitos
Requisitos
Requisitos
Funcionais
Requisitos
Não-Funcionais
Identificação e elicitação de Requisitos:
Os requisitos funcionais descrevem o que o
sistema deve fazer, isto é, as funções
(funcionalidades) necessárias para atender os
objetivos. O que sistema deve saber fazer.
Exemplos: Buscar cliente, Registrar pedido
Calcular conta de consumo, Calcular tributos e
etc.
Os requisitos não funcionais dizem respeito as
características que descrevem qualidade do serviço
(QoS).
A omissão ou esquecimento desses requisitos constitui
uma das principais razões de uma eventual
insatisfação dos usuários com relação a um software.
Os Requisitos Não Funcionais (RNF) também são
chamamos de “Requisito Suplementares.”
Exemplos: performance, disponibiliade, confiabilidade,
segurança, usabilidade e etc.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 76
Identificação dos Requisitos:Os requisitos de software podem ser identificados no texto da “declaração do
problema” (geralmente são verbos que identificam algumas ações).
Este documento possibilita a identificação, extração e
classificação dos requisitos
- Requisitos funcionais e
- Requisitos não funcionais.
Texto da Declaração do Problema
Requisitos
Identificação e elicitação de Requisitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 77
Data: ________ | Autor: ________ | Revisão: ____
Índice:
1.0 - Introdução
1.1 Objetivo do documento
1.2 Escopo
1.3 Abreviaturas, Siglas e etc.
2.0 Entendimento do Problema (Contexto)
2.1 Declaração do Problema
2.2 Diagrama de Contexto
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
Exemplo: Documento de Visão:
Requisitos
Identificação e elicitação de Requisitos:Documento de Visão:
Objetivo:
Fazer uma descrição da visão da solução
Este documento tem as seguintes seções:
-Entendimento do Problema;
- Lista dos Stakeholders
- Lista dos Requisitos
- Lista dos Riscos
- Lista das Restrições
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 78
Documento de Visão
Fazer identificação e elicitação
de requisitos
Requisitos
Requisitos. Road Map
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Usuários e
Clientes
Documentos Fazer Validação de Requisitos
Regras de
negócio
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 79
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.
Análise de Requisitos: Introdução
Requisitos
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 80
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.
Análise de Requisitos
Requisitos
Detalhar os
Requisitos Funcionais
Descrever os Usuários
e Entidades Externas
Documento de Requisitos
Classificar os
Requisitos não Funcionais
Fazer Plano de Redução
de Risco
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 81
Requisitos Funcionais:
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para
esta atividade. Veja o exemplo:
Análise de Requisitos. Detalhar
Requisitos
Lista de Requisitos funcionais
Nome Descrição
Fazer ReservaEsta 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)
Autor: Revisão: Data Atualização:
RF01E
Código
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 82
id Nome da Regra
Nome do Projeto Serviço de Atendimento e Reserva de Apartamento
ObjetivoDescrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.
Data
01/01/08 RFS 2.1
Nome / Equipe Versão
RN01
Descrição das Regras de Negócio
Descrição da Regra de Negócio
Registrar Reserva de
Apartamento
A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de
25% do valor da estadia.
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.
Vigente
Status
Nome Descrição
Registrar Reserva
de Apartamento
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, cancelar, alterar e consultar reservas.
Requisitos Funcional
ID
RFC01
Análise de Requisitos. Detalhar
Requisitos
Nome: Reserva Descrição: Serviço de Atendimento e Reserva de ApartamentoRN: RN01
Os código permitem a rastreabilidade
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 83
Requisitos Não Funcionais:
Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos
categorizar estes requisitos, as mais frequente são:
Análise de Requisitos. Classificar
Requisitos
- 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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 84
Requisitos Não Funcionais:
Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos
funcionais, precisamos ter um padrão
Análise de Requisitos. Classificar e Detalhar
Requisitos
Lista de Requisitos Não funcionais
Descrição
Fazer
Consulta
As consultas que serão realizadas pelo cliente não poderão
exceder ao tempo de resposta de 15 segundos
Autor: Revisão: Data Atualização:
Categoria: Performance
Req. Funcional Código
RNFP1
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 85
Requisitos Não Funcionais:
Continuação:
Requisitos
Lista de Requisitos Não funcionais
Categoria: Usabilidade
RF /
AplicaçãoDescrição
AplicaçãoAs cores, as fontes e logotipos devem seguir o Manual de
Identidade Visual da empresa.
Autor: Revisão: Data Atualização:
AplicaçãoAs interfaces com usuário devem seguir padrão de interfaces
estabelecido pelo Manual de Sistema
Código
RNFU1
RNFU2
Análise de Requisitos. Classificar e Detalhar
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 86
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:
Requisitos
Lista de Stakeholders
Nome Descrição
Cliente São todas as pessoas físicas ou jurídicas que fazem reservas
Autor: Revisão: Data Atualização:
ColaboradorÉ qualquer pessoa que presta algum tipo serviço para
empresa
Análise de Requisitos. Detalhar
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 87
Continuação:
Requisitos
Lista de Entidades Externas
Nome Descrição
Administradora de
Cartão de Crédito
Entidade que faz validação de um cartão de crédito presente
em transação de pagamento.
Autor: Revisão: Data Atualização:
Análise de Requisitos. Detalhar
Lista de Stakeholders:
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 88
Documento de Requisitos:
Objetivo:
Classificar, descrever os requisitos de
software, usuários e entidade externas e
elaboração do plano de redução de risco.
Este documento tem as seguintes
seções:
- Requisitos Funcionais
- Requisitos Não Funcionais
- Lista dos Stakeholders
- Plano de Redução de Risco
Análise de Requisitos. Artefato
Requisitos
Data: ________ | Autor: ________ | Revisão: ____
Índice:
1.0 - Introdução
1.1 Objetivo do documento
1.2 Escopo
2.0 Requisitos Funcionais
3.0 Requisitos Não Funcionais
4.0 Lista Stakeholders
4.1 Usuários
4.2 Entidades
5.0 Plano de Redução de Riscos
Exemplo:Documento de Requisitos:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 89
Documento de Visão
Fazer identificação e elicitação
de requisitos
Requisitos
Requisitos. Road Map
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
(Casos de Uso)
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Usuários e
Clientes
Documentos Fazer Validação de Requisitos
Regras de
negócio
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 90
Especificação de Requisitos:
Casos de Uso
Seqüência Colaboração
Classes
DistribuiçãoImplementação
Estrutura
Comportamento interno
Comportamento externo
Especificação de RequisitosR
equ
isit
os
Fu
nci
on
aisDocumento
de Visão
Req
uis
itos
Não
Fu
nci
on
ais
Modelo de
Arquitetura
do Software
Documento de
Requisitos
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 91
Especificação de Requisitos
Objetivos:
• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.
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.
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 92
Especificação de Requisitos
Cliente
Emitir NF
Fazer Pedido
Fazer Cadastro
Calcular Total
Funcionário
Transformar os Requisitos
Funcionais em Casos de Uso:
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 93
Atividades e Passos:
Especificação de Requisitos
Requisitos
Fazer Diagrama de
Casos de Uso
Escrever cenários Rational Rose
Identificar Atores /
Casos de Uso
Escrever Formulário
Fazer Diagrama de
Caso de Uso
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 94
Casos de Uso
O que são Caso de Uso?São diagramas de que permitem visualizar, especificar e documentar o comportamento de umelemento. 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.
Gerenciar
Reserva
Ator
Caso de Uso
Nome
Usuário
Os nomes de casos de uso
são breves expressões verbais
ativas.
Requisitos
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 95
Casos de UsoCasos 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.
Requisitos
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 96
Casos de UsoCasos 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.
Requisitos
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 97
Casos de Uso
Casos de Uso e Formulário:
Os formulários devem ter as seguinte informações:
- Ponto de ativação (momento que caso de uso começa)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pré-condição
- Fluxo Normal
- Fluxo Alternativo
- Pós-condição.
Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.
Exemplos:
- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 98
Casos de UsoExemplos de Casos de Uso:
Professor
Selecionar curso
para ensinar
Pedir lista dos
matriculados
Gerente
Manter informação de
aluno
Manter informação de
professor
Gerar catalogo
Manter informações dos
cursos
Sistema de
cobrançaMatrícula nos
Cursos
Aluno
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 99
Casos de UsoCasos de Uso e Formulário
Exemplo:
Nome: Fazer Busca Produto
Ponto de ativação: Este caso de uso começa quando entra na página
de Busca e seleciona um item da caixa de seleção
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pré-condição: Aplicação Disponível
Fluxo Normal:
1 - O visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as informações sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem “produto não encontrado”
Pós-condição: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto
Requisito Não Funcional: ---
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 100
Casos de Uso
Elementos dos Caso de Uso:
Ator:Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quanto interagem com esses casos de uso. Geralmente um ator representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo e etc...
Cenários:É narrativa de determinado fato ou de uma situação.“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos forem necessários para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação dos requisitos do sistema.”
Formulário:É a representação estruturada de um ou mais cenários
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 101
Casos de Uso. Relacionamentos
Generalização:
Entre os casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o
comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo
fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
* Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino. Substituído pelo include.
Requisitos
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)
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 102
Generalização:
Podemos usar a generalização entre casos de
uso, pelo mesmo motivo que utilizamos
nas classes, para compartilhar comportamento:
Pagto Cartão de Crédito
Receber Pagamento
Casos de Uso. Relacionamentos
Requisitos
generalização
Pagto Cartão de Débito
A generalização também pode ser aplicado aos
atores e seus respectivos papéis. Veja o exemplo:
Funcionário
RecepcionistaGerente de
Reservas
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 103
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:
Casos de Uso. Relacionamentos
Requisitos
Alterar status do carro Consulta Cliente
<<include>>
Devolver Veículo
Calcular Multa
<<extend>><<include>>
Locadora de Automóveis
Fazer Ligação
Fazer Ligação
(Conference call)
<<extend>>
Usuário
Sala de Conferência
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 104
Fazer Pedido
<<include>>
Acompanhar Pedido
Validar Usuário<<include>>
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:
Casos de Uso. Relacionamentos
Requisitos
Fazer Check IN
<<include>>
Gerenciar
Reserva
Fazer Check OUT
Receber
Pagamento<<include>>
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 105
Casos de UsoCasos de Uso - Identificação de Atores
Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa
que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode:
- Apenas fornecer informações ao sistema
- Apenas receber informações do sistema
- Fornecer e receber informações ao sistema
Tipicamente os atores são identificados nas Declarações de Problemas (Documento
de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo,
como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio,
por exemplo.
As seguintes questões podem ser usadas para identificar o atores:
- Onde o sistema será usado ?
- Quais áreas serão usuárias do sistema ?
- O sistema usará recurso externo ?
- Quem será o responsável pelo sistema ?
- Quem serão os usuários do sistema ?
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 106
Casos de Uso.Dicas
Um engano comum na identificação de casos de uso é representar como Caso de uso
passos individuais, operações ou transações.
Exemplo:
No domínio de ponto de venda, alguém pode definir um caso de uso chamado
“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo
no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se:
Um caso de uso é uma descrição completa de processo,
que inclui outros passos ou transações.
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 107
Especificação de Requisitos. Exemplo:
Documento de
Visão
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 .
Refinado pelo
Requisitos Funcionais
• Gerenciar Reserva
•...
12
Requisitos
„
Documento
de Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 108
Especificação de Requisitos. Exemplo:
Especificação de Requisitos:
Cenários
Gerenciar ReservaUsuário
Formulário
Caso de Uso
AssociaçãoAtor
3
Caso de Uso: Gerenciar Reserva
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 109
Especificação de Requisitos. Exemplo:
Escrevendo os Cenários:
Cenários
Requisitos
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 aceita o apartamento e então o funcionário confirma a reserva.
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:
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 110
Especificação de Requisitos. Exemplo:Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Requisitos
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
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Pré- condição
Pós- condição
Identificando a pré-condição e pós-condição:
Cenários Formulário
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 111
Especificação de Requisitos. Exemplo:Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Requisitos
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:
Fluxo Alternativo:
Pós-condição: Reserva confirmada
Primeiras linhas do cenário
Última linha do cenário
Gerenciar Reserva
“caminho feliz”
Gerenciar Reserva
“caminho alternativo”
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 112
Especificação de Requisitos. Exemplo:Escrevendo o Formulário de Descrição de Caso de Uso:
Requisitos
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
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 113
Especificação de Requisitos. Exemplo:
Especificação de Requisitos:
Cenários
Formulário
Gerenciar ReservaFuncionário
Caso de Uso
AssociaçãoAtor
3
Caso de Uso: Gerenciar Reserva
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 114
Mitos e Lendas
• Requisitos não são Casos de Uso;
• Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo:
Caso de Uso Fazer Busca, está associado a dois requisitos:
• (RF) Fazer Buscar
• (RNF) O tempo de resposta para transação deve ser 10 segundos
(Desempenho)
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 115
Especificação de Requisitos. Exercício:Especificação de Requisitos, como fazer:
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO;
2 - Identifique também os ATORES e seus respectivos PAPÉIS;
3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único
no modelo;
4 - Escreva os CENÁRIOS para o CASO DE USO;
5 - Compile os CENÁRIOS em único FORMULÁRIO e
6 - Faça o Diagrama de Caso de Uso.
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 116
Especificação de Requisitos. Template:Template do “Formulário”:
Requisitos
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>
RNF: <informar os código ou nomes dos RNFs>
Data: ______ | Autor: ________ | Revisão: ____
Rastreabilidade
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 117
Documento de Visão
Fazer identificação e elicitação
de requisitos
Requisitos
Requisitos. Road Map
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de
Requisitos
Documento de
Especificação
de Requisitos
Usuários e
Clientes
Documentos Fazer Validação de Requisitos
Regras de
negócio
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 118
Requisitos
Validação de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário
deseja.
Validação é importante uma vez que o custo para remover um erro de requisitos é
grande.
Pequeno Check List de Requisitos:
Validade. O sistema fornece as funções que melhor atende as necessidades do usuário?
Consistência. Existem conflitos de requisitos?
Completeza. Todas as funções necessárias para o cliente estão incluídas?
Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento
disponíveis?
Facilidade de verificação. Os requisitos podem ser checados?
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 119
Requisitos
Validação de RequisitosTé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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 120
Requisitos
Validação de RequisitosTé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?
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 121
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
Requisitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 122
Análise Conceitual
Objetivo desta parte:
É apresentar e discutir a Análise Conceitual suas técnicas,
conceitos e modelos.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 123
Big Picture. Requisitos e Análise
Glossário de
conceitos
Modelo Conceitual
Análise Conceitual
Casos de Uso
Engenharia de Requisitos
Requisitos Funcionais
Requisitos Não
Funcionais
Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso)
Coleta de Requisitos
Documento
de Visão
Business Case
Arquitetura Inicial
4
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 124
Arquitetura
Analista de Sistema
PapéisArtefatosWorkflow
Analise
Workflow Analise
Analista de Requisitos
Arquiteto de SoftwareVocabulário do Sistema
Modelo Conceitual ou Modelo
de Domínio
Modelo de Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 125
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.
Introdução:
Workflow de Análise
Visão de ProjetoFuncionalidade
Vocabulário
Visão da Implementação
Codificação
Montagem
Visão do ProcessoDesempenho
Escalabilidade
Throughput
Visão da ImplantaçãoTopologia do Sistema
Distribuição
Instalação
Visão de Caso de Uso
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.
FuncionárioGerenciar Reserva
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 126
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.
Objetivo:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 127
Modelo Conceitual
Fazer Análise Conceitual
Atividades.Road Map
Fazer Vocabulário
Vocabulário
Documento de
Visão
Caso de Uso
Workflow de Análise
Definir o modelo de
Arquitetura
Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 128
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.
Atividades e Artefatos:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 129
“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).
Análise Conceitual. Introdução:
Workflow de Análise
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 130
Workflow de Análise
Atividade: Fazer Análise Conceitual
Modelo Conceitual
Fazer Análise Conceitual
Documento de
Visão
Caso de Uso
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 131
O modelo de classe têm pelo três níveis de abstração:
- Modelo Conceitual de Classes: Representa as classes no domínio do
desenvolvimento do software, este modelo pertence a Workflow de Análise. Por
definição, um modelo de classes de domínio não leva em consideração restrições
referente à tecnologia a ser utilizada na solução do problema. Este modelo também
conhecido como “Modelo de Classes de Domínio”.
- Modelo de Classes de Especificação: É derivado do Modelo Conceitual. Com
acréscimos de detalhes, tais como, tipo de dado, operações (métodos),
implementação de associações, generalização, agregação e composição e
incremento de novas classes para que se fazem necessária para dar uma solução ao
problema.
Exemplo:
Classes associativas. Este modelo é desenvolvido no Workflow de Projeto.
Análise Conceitual. Modelos:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 132
- 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.
Análise Conceitual. Modelos
nome
idade
Pessoa
<<refines>>
-nome
-idade
Pessoa
+setNome()
+getNome()
+getIdade()
+getIdade()
Workflow de ProjetoWorkflow de Análise
Modelo Conceitual ou
Modelo de DomínioModelo de Especificação
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 133
Fazer Análise Conceitual
Selecionar uma técnica
Identificar os candidatos
a classe
Fazer a Lista de
Candidatos
Desenhar o Modelo
Conceitual
Workflow de Análise
Análise Conceitual. Atividades e Passos:
Definir a Arquitetura
Inicial
4
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 134
- 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.
Análise Conceitual. Identificação das Classes:
Workflow de Análise
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:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 135
Workflow de Análise
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.
UML. Introdução
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 136
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.
Diagrama de Classes. Introdução
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 137
Elementos estruturais:
Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e
Componente
Elementos de agrupamento:
Pacote e Subsistema
UML. Elementos:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 138
• Dependência
• Associação
– Associação
– Composição
– Agregação
• Generalização
Mecanismos de Extensibilidade:
• Estereótipo
• “Tagged value”
• Restrição (Constraint)
UML. Elementos:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 139
Diagrama de Classes
O diagrama de classes deve
capturar o Vocabulário* do
sistema
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 140
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.
Usuario Senha
Associação
classe classe
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 141
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.
Cliente Pedidofaz
Associação
Workflow de Análise
Nome da associação
Direção do nome
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 142
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)
Cliente Pedido
Associação
Navegação
Associação
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 143
Definição de Role Name:
É um identificador (nome) do papel da associação, podendo cada ponta ter um nome
especifico.
Modificadores:
(+) public | (-) private | (#) protected
Workflow de Análise
Role Name:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 144
Definição:
A especificação de uma faixa de números cardinais, que um conjunto pode assumir.
Multiplicidade Faixa Válida:
0....1 | 0..* | * | 1 | 1..*
Workflow de Análise
Multiplicidade
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.
Eqüivale a muitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 145
Exemplo:
Multiplicidade
Para cada objeto (instance) da classe Pessoa a classe
Empresa poder ter uma ou muitos objetos.
Workflow de Análise
Role Name e Multiplicidade
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 146
Inspeção
GramaticalCRC
Outras
Técnicas
Scott Ambler
Graig Larman
Kent BeckAbbot
Peter Coad
Workflow de Análise
Análise Conceitual. Técnicas:
Análise de
Caso de Uso
UML
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 147
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 148
Modelo Conceitual. Técnica: Inspeção Gramatical
1º Lista Lista FinalDeclaração de
Visão
Identificação dos
candidatos a classe,
associações e atributos
Fazer revisão da lista:
Eliminar conceitos os repetidos,
ambíguo, irrelevantes e etc..
Lista de Candidatos:
Conhecimento do Negócio Interações
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 149
Lista de Candidatos
Artefatos:
Vocabulário de Conceitos
4
Modelo Conceitual
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 150
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Classe
Atributo
Associação
Multiplicidade
Nome da associação
Reserva
numero
data-entrada
data-saida
Cliente
id
nome
documento
Apartamento
numero
tipo
situacao
11..* feita por
0..*
1..*
hospede
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 151
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.
Modelo Conceitual. Técnica: Inspeção Gramatical - Exemplo
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 152
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
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 153
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
arquivo de Registro
Reserva de segurança Acesso
Preço Cliente
Identificando os conceitos:
(Técnica usada: extração dos substantivos do enunciado do problema)
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Classes da ATM originadas do conhecimento do domínio do problema
Linha de Comunicação Registro de transação
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 154
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
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
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
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 155
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.
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 156
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
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 157
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
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 158
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.
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 159
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.
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 160
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.
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 161
Conceito de
classes e atributos
Classes
Workflow de Análise Workflow de Projeto
Transacao
Datahora:Timestamp
+getTransacao()
+setDataHora()
+getDataHora()
Transacao
Datahora
Modelo Conceitual vs Modelo de Especificação
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 162
Modelo Conceitual:
Modelo Conceitual. Técnica: Inspeção Gramatical
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 163
CRC
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.
Método dirigido a responsabilidades:
Neste método, a ênfase está na identificação das classes a partir de seus comportamentos
relevante ao sistema.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 164
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.
Responsabilidades:
(o que objeto conhece e o que faz)
Objeto
Colaborações:
(outras classes que são associadas,
para a interação entre os objetos)+
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 165
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:
Responsabilidades:
Nome da Classe
Lista das responsabilidades
Colaborações:
Lista de colaborações
Workflow de Análise
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 166
CRC. Exemplos:
Responsabilidades:
Classe: Reserva
Conhecer o período da reserva
(datas)
Saber o nome do cliente
Saber o número do apartamento
Colaborações:
Apartamento
Cliente
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 167
Modelo Conceitual. Técnica: Inspeção Gramatical & CRC
Lista de Candidatos
Identificação dos candidatos
Inspeção Gramatical
Workflow de Análise
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
CRC
Identificação das Responsabilidade Modelo Conceitual
UML
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 168
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.
Cenários
Gerenciar ReservaUsuário
Formulário
Caso de Uso
AssociaçãoAtor
Listas de Candidatos
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 169
Análise de Caso de Uso. Big Picture
Cenários
Gerenciar ReservasUsuário
Formulário
AssociaçãoAtor
Casos de Uso
Engenharia de Requisitos
Lista de Requisitos
Funcionais
Lista de Requisitos
Não Funcionais
Análise de RequisitosEspecificação de Requisitos
(Visão de Caso de Uso)
Documento de VisãoLista de
Candidatos1
4
Workflow de Análise
2
3
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 170
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.
Workflow de Análise
Gerenciar ReservaUsuário Reserva é provável candidato a classe
Criar Reserva
Atualizar Reserva
Remover Reserva
Cadastrar Cliente
Buscar Apartamento
<<include>>
<<include>>Funcionário
prováveis candidatos a classe
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 171
Como fazer. Cenários:2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos,
exemplo:
Workflow de Análise
Cenários:
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
que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.
Prováveis candidatos a classe
Análise de Caso de Uso: Identificando os candidatos a classe
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 172
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
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:
Workflow de Análise
Formulários
Prováveis candidatos a classe
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 173
Modelo Conceitual. Técnica: Inspeção Gramatical & CRC
Lista de Candidatos
Identificação dos candidatos
Análise de Caso de Uso
Workflow de Análise
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
Responsabilidades:
Classe: Cliente
Saber o nome do cliente
Saber a Reserva do Cliente
Colaborações:
Reserva
CRC
Identificação das Responsabilidade Modelo Conceitual
UML
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 174
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
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 175
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.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 176
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
Especificação, projeto, ou descrição de coisas Especificação de produtoDescrição de vôo
Objeto físico ou tangível Terminal de ponto-de-vendaAvião
Lugares LojaAeroporto
Transações Venda, PagamentoReserva
Exemplos
Itens de transação Itens de vendaParcelas de pagamento
Papéis de pessoas OperadorPiloto
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 177
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 quandoum Cliente chega no caixa com itenspara comprar.2. O Operador registra o identi-ficadorde cada item.
Se há mais de um do mesmo item, oOperador também pode informar aquantidade.
3. Determina o preço do item eadiciona informação sobre o item àtransação de venda em anda-mento.
Mostra a descrição e o preço do itemcorrente.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 178
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.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 179
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.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 180
Modelo Conceitual
Fazer Análise Conceitual
Vocabulário.Road Map:
Fazer Vocabulário
Vocabulário
Documento de
Visão
Caso de Uso
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 181
Vocabulário:
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.
Workflow de Análise
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.
Fazer Vocabulário
Descrever os conceitos
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 182
Modelo Conceitual.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 183
Vocabulário:
ATM – Uma estação que permite os clientes introduzem suas próprias transações
utilizando cartões magnéticos como identificação. A ATM interage com o cliente para
obter informações sobre transações, envia as informações sobre transações para o
computador central para validação e processamento e entrega de dinheiro ao usuário.
Presumimos que uma ATM não necessita operar independente de rede.
Banco – Uma instituição financeira que mantém contas de cliente e emite cartões
magnéticos autorizando o acesso às contas através da ATM.
Caixa – Um empregado do banco autorizado a introduzir transações nos terminais de
caixa e a receber e entregar dinheiro e cheques aos clientes. As transações, o dinheiro e
os cheques manipulados por cada caixa devem ser registrados e devidamente
contabilizados.
Vocabulário. Exemplo:
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 184
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.
Workflow de Análise
Vocabulário. Exemplo:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 185
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.
Workflow de Análise
Vocabulário. Exemplo:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 186
Diagrama de Objetos
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:
Atributo: Valor do atributo
:Nome do Objeto
Atributo: Valor do atributo
Nome do Objeto
vínculo
objeto
Workflow de Análise
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 187
Diagrama de ObjetosRecomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes.
Exemplo:
-Nome: String
-Data: Date
Aluno
-Matricula: int
-Curso: String
Matricula
Diagrama de Classe
Nome: “Fulano de Tal”
Data: 23-02-2001
:Aluno
Matricula: 201-23-02-01
Curso: Adm Empresas
201-23-02-01:Matricula
Nome da
associação
vinculo
objeto
Valor do atributoAtributo
Nome do
objeto“Instance”
Diagrama de Objetos
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 188
Diagrama de Objetos
Conteúdo do Diagrama de Objetos:
Objetos e Vinculo
Nome: “Fulano de Tal”
Data: 23-02-2001
:Aluno
Matricula: 201-23-02-01
Curso: Adm Empresas
201-23-02-01:Matricula
Diagrama de Objetos
vínculo
objeto
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.
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 189
Diagrama de Objetos
Como fazer a modelagem de um estrutura de objetos:
• Identifique o mecanismo cuja modelagem você deseja fazer. Um mecanismo
representa algum requisito ou comportamento da parte do sistema cuja a
modelagem você está fazendo e que é resultante da interação de um conjunto
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.
Como posso
validar o
diagrama de
classes?
Workflow de Análise
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 190
Modelo Conceitual
Fazer Análise Conceitual
Arquitetura Inicial.Road Map
Fazer Vocabulário
Vocabulário
Documento de
Visão
Caso de Uso
Workflow de Análise
Definir o modelo de
Arquitetura
Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 191
Modelo de Inicial de Arquitetura
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”.
Workflow de Análise
4
Camada
apresentação
Banco de
Dados
Diagrama de Deployment
Camada de
serviço
(controle)
Camada
regra de
negócio
Definir o Modelo de
Arquitetura
Definir o Modelo de
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 192
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
Pacote
Nome do Pacote
Nome do
Pacote
Dependência
(import)
Nome do
Pacote
Apêndice
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 193
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:
Nome do Pacote
Dependência
(import)
Contas a
Pagar
Contas a
Receber
Fluxo de
Caixa
Subsistema
Apêndice
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 194
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 195
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.
Objetivo:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 196
Introdução. UML, Visões:
Conceitual Físico
Visão de Projeto
Funcionalidade
Vocabulário
Visão da Implementação
Codificação
Montagem
Visão do Processo
Desempenho
Escalabilidade
Throughput
Visão da Implantação
Topologia do Sistema
Distribuição
Instalação
Visão de Caso de Uso
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 197
Workflow de Projeto
Introdução. UML, Visões:
• 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 Processo
• 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 Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 198
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.
Introdução. Aspecto estático e dinâmico:
Workflow de Projeto
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 199
ESTÁTICOS
. Diagrama de Classes
. Diagrama de Objetos
. Diagrama de Componentes
. Diagrama de Distribuição
DINÂMICOS
. Diagrama de Casos de Uso
. Diagramas de Interação
- Diagrama de Seqüência
- Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados
Modela o comportamento do sistemaModela a estrutura do sistema
Workflow de Projeto
UML. Principais Diagramas:
Workflow de ProjetoWorkflow de Análise
Introdução. Aspecto estático e dinâmico:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 200
A Workflow de Projeto depende da Workflow de
Análise:
Workflow de Análise
Workflow de Projeto
Análise
Projeto
Introdução
dependência
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 201
A Workflow de Projeto refina a Workflow de
Análise:
Cliente
codigo
nome
Cliente
-codigo: int
-nome: String
+getCodigo()
+setCodigo()
+getNome()
+setNome()
Workflow de Análise
modelo conceitual
Workflow de Projeto
Diagrama de Classes
<<refine>>
métodos
Atributos:
Tipo de dados
Introdução
Atributos:
Visibilidade
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 202
Big Picture. Projeto
Modelo Conceitual
4
Análise
Diagrama de Classes
Projeto (Visão Lógica)
4
: visitante : Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( ) getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noiteEntrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Especificação de Requisitos
(Visão de Caso de Uso)
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 203
Arquitetura
Analista de Sistema
Projetista de Software
PapéisArtefatosWorkflow
Arquitetura
Arquiteto de Software
Workflow de Projeto
Diagrama de Seqüência /
Colaboração
Diagrama de Classes
Diagrama de Atividades
Diagrama de Estados
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 204
Modelo de Especificação
Fazer Modelo de Especificação
Atividades.Road Map
Fazer Modelo de Arquitetura
Modelo de Arquietura
Modelo
conceitual
Caso de Uso
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 205
Fazer Modelo Especificação
Fazer Diagrama de
Interação
Identificar as classes de
Especificação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Projeto. Atividades e Passos:
Workflow de Projeto
Modelo de
Especificação
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 206
selecionar categoria
buscar produtos
<<include>>
visitante
Formulário
Diagrama de Sequência
: visitante : Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( ) getQuantidade( )
Diagrama de Estado
Casos de Uso. RevisãoUso 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ê”
“O como”
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 207
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.
Diagrama de Interação. Introdução
Existem dois tipos de diagramas:
• Diagrama de Seqüência:
O foco deste diagrama é maneira que as mensagens são enviadas ao longo do tempo.
• Diagrama de Colaboração:
Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então
considerar como as mensagens são passadas no contexto dessa estrutura.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 208
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.
Ator:
:Objeto 1 :Objeto 2
1: mensagem 1
2: mensagem 2
3: mensagem 3
Notação:
Diagrama de Seqüência
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 209
Diagrama de Interação
Diagramas de Seqüência:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 210
Diagrama de Interação
Aluno:
formulários de
registro
formulário de
matrícula
cursos
disponíveis
entrar com senha de
acesso
validar acesso
entrar com o
semestre
criar nova matrícula
apresentar em tela
obter cursos
Diagramas de Seqüência:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 211
Diagrama de InteraçãoDiagramas de Seqüência. Elementos:
: Atendente : Cliente : Veiculo : Locacao
getDadosCliente( )
[* se cliente cadastrado
verificar divida ]
getDivida( )
getDisponibilidade( )
[* se veículo
disponível ]
setSaida( )
ator
Instance das classes
Linha do tempo
As interações entre os
objetos
Restrição ou
condição
Autodelegação
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 212
Diagrama de Interação
Este diagrama descreve em ordem cronológica as mensagens entre os objetos.
: visitante : Categoria : Produto : Catalogo : FormBusca
2: exibirCategoria( )
6: exibirProduto( )
3: selecionarCategoria
7: selecionarProduto( )
1: getDescricao( )
4: getDescricao( ) 5: getQuantidade( )
Diagramas de Seqüência. Numerando as seqüências das mensagens.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 213
Diagrama de Interação
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.
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.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 214
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
6:obter cursos
Ator (José)
formulários de registro
2: validar acesso
1:entrar com chave
de acesso3:entrar com o
semestre
4:criar nova matrícula
formulário de matrículacursos disponíveis
5:apresentar
em tela
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 215
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)
: visitante
:
Categori
:
Produto
: Form
Busca
: Catalogo
2: exibirCategoria( )
3: selecionarCategoria
5: getQuantidade( )
6: exibirProduto( )
7: selecionarProduto( )
1: getDescricao( )
4: getDescricao( )
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 216
Fazer Modelo Especificação
Fazer Diagrama de
Interação
Identificar as classes de
Especificação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Projeto. Atividades e Passos:
Workflow de Projeto
Modelo de
Especificação
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 217
Diagrama de Estado
O que é Diagrama de Estado?
É um diagrama que tipicamente complementa a descrição das classes. Pois, este
diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se
encontrar. Mostra também quais as variações de comportamento provocam tais
mudanças.
Não necessário escrever o diagrama de estado para todas as classes de um sistema,
mas, apenas para aquelas que possuem um número definido de estados conhecidos e
onde o comportamento das classes é afetado e modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas.
Aplicação:
Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:
- Classes e Casos de Uso
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 218
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 fluxoFinal do fluxo
Diagrama de Estado
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 219
Diagrama de Estado
Exemplo:
ocioso
início
Ativo
fora do gancho
no gancho
transição
Estado
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 220
Exemplo 1:
Diagrama de Estado
Trata
Evento
Inicializa o
Objeto
Finaliza
Objeto
Espera por
Evento
on
off
Lamp
On
Lamp
Off
off
on/print(”on”)
stop
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 221
Diagrama de EstadoExemplo 2: (Completo)
início
Verificando Expedindo
Aguardando
Cancelamento
cancelamento
Entregue
cancelado
[Todos os itens
verificados e
alguns itens não
estão disponíveis]
[Todos os itens verificados e
os todos itens disponíveis]
Item recebido
[os todos itens
disponíveis]
final
[Nem todos os itens verificados]/pegar
próximo item
[itens ecebidos
[alguns itens não
estão disponíveis]
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 222
Exemplo:
Caso de Uso
Diagrama de Estado
Autenticar
Senha
Cliente
Consultar
Pedido
Cancelar
Pedido
Gerenciar
Pedido
Pedido
Confirmar
<<extends>>
FuncionárioUpdateStatus
Pedido
Logistica
<<include>>
Verificando Status
Cancelando Pedido
Mudando Status[Pedido não entregue]
Diagrama de Estado
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 223
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.
Diagrama de Atividades
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 224
Elementos
Fazer Pedido
Cliente
Processar Pedido
Separar Produtos
Enviar Pedido
Cobrar Cliente
Fechar Pedido
Receber Pedido
Pagar Fatura
Vendas Estoque
raias
junção
separação
atividade
Elementos e Exemplo com comentários:
Diagrama de Atividades
Atividade
atividade
decisão
Barras de
sincronização
transição
responsabilidades
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 225
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 diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade
de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos),
quando elas são executadas (seqüência das ações), e onde elas acontecem (swimlanes).
Diagrama de Atividades
Workflow de Projeto
Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:
Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este
é 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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 226
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noiteEntrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Diagrama de Atividades
Exemplo 2:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 227
- 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.
Diagrama de Atividades
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 228
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.
Diagrama de Atividades
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 229
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.
Diagrama de Classes. Introdução
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 230
• O diagrama de classe é um elemento estrutural
Diagrama de Classe. Revisão:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 231
Diagrama de Classe. Exemplo:
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 232
Diagrama de Classe. Revisão:
Refinamentos:
1 - Refinamento:
Atributos: Acrescentar tipos de dados e visibilidade
exemplo: codigo
-codigo: int (private int codigo)
2 - Refinamento:
Acrescentar: outros tipos de relacionamento entre as classes
exemplo: agregação, composição, herança
Acrescentar outros elementos como: Seta de navegação, Role
Name (papéis) e multiplicidade
Cliente
codigo
nome
Cliente
-codigo: int
-nome: String
+getCodigo()
+setCodigo()
+getNome()
+setNome()
Fase de Análise
modelo
conceitual
Fase de Projeto
Diagrama de
Classes
<<refine>>
métodos
Atributos:
Tipo de dados e
Visibilidade
Pessoa
nome
ItemPedito
Quantidade
Cliente
cpf
codigo
1
Relacionamento
Herança
Pedido
Data
Status
Numero
item1..n
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 233
Diagrama de Classes. Refinamento
1 - Refinamento:
Exemplo: Atributos e Métodos:
Cliente
codigo
nome
Cliente
-codigo: int
-nome: String
+getCodigo()
+setCodigo()
+getNome()
+setNome()
+getCliente()
Fase de Análise
modelo conceitualFase de Projeto
Diagrama de Classes
<<refine>>
métodos
Atributos:
Tipo de dados e
Visibilidade
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 234
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
Cliente
codigo
nome
Cliente
-codigo: int
-nome: String
+getCodigo()
+setCodigo()
+getNome()
Fase de Análise
modelo conceitualFase de Projeto
Diagrama de Classes
<<refine>>
métodos
Atributos:
Tipo de dados e Visibilidade
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 235
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
Pessoa
nome
Fase de Análise
modelo conceitualFase de Projeto
Diagrama de Classes
<<refine>>
cliente
PessoaFisica
codigo
cpf
Pessoa
cpf
nome
PessoaFisica
codigo Role name
Relacionamento
Herança
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 236
Diagrama de Classes. Refinamento
Herança, Agregação, Composição, Associação
Graduação Pós-Graduação
Curso
Universitário
Especialização Extensão
Herança
extends
extends
Podemos dizer que Pós-
Graduação é tipo de Curso
Universitário, assim como
Curso de Especialização ou
de Extensão.
Herança: É mecanismo baseado em objetos
que permite que as classes compartilhem
atributos e operações baseados em um
relacionamento, geralmente generalização
Uma classe derivada herda a estrutura de
atributos e métodos de sua
classe “base”, mas pode seletivamente:
• adicionar novos métodos
• estender a estrutura de dados
• redefinir a implementação de métodos já
existentes
Uma classe “pai” proporciona a funcionalidade
que é comum a todas as suas classes
derivadas, filhas, enquanto que uma classe
derivada proporciona a funcionalidade
adicional que especializa seu comportamento.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 237
Diagrama de Classes. Refinamento
Herança, Agregação, Composição, Associação
EspecialidadeMédica
Ortopedia Pediatria
generalização
especializaçãoTipo de Tipo de
ContaBancaria
ContaCorrente ContaPoupança
Tipo de Tipo de
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 238
Diagrama de Classes. Refinamento
Herança, Agregação, Composição, Associação
Figura
Retangulo Circulo
Tipo de
TipoPagamento
CartaoCredito CartaoDebito
Tipo de
Tipo de
Herança:
Quais associações são inválidas:
Ponto
Tipo de
Cartao
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 239
Refinamentos:
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
associações reflexivas e Constraint (restrições)
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
CPF-cpf
Cliente
-codigo: int
-nome: String
-idade: int
+getCodigo()
+setCodigo()
+getNome()
+setNome()
+getIdade()
+setIdade()
getCPF()
setCPF(){ idade > 18}
CPF-cpf
getCPF()
setCPF()
Sociio
-codigo: int
-idade: int
+getCodigo()
+setCodigo()
+getIdade()
+setIdade()
{ idade > 18}
<Interface>
Pessoa-nome: String
+getNome()
+setNome()
Livro
-isbn
-titulo
getISBN()
setISBN()
setTitulo()
getTitulo()Emprestimo
-data
-status
getData()
setDAta()
setStatus()
getStatus()
**
Workflow de Projeto
Diagrama de Classes Avançado. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 240
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.
qualificador
Classe
atributos
Nome da
associação0..1
Classe
atributospapelpapel
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 241
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
associações reflexivas e Constraint (restrições)
Associação Qualificada
Pedido Produto
ItemPedido
quantidade: intLinha de item
0..1
Qualificador
O exemplo, demonstra uma associação qualificada, entre as classe Produto,
ItemPedido. O qualificador diz que em associação com Pedido poder haver um item
de pedido cada ocorrência de produto. Conceitualmente, esse exemplo indica que não
é possível existir dois itens de pedido com pedido para o mesmo produto. Para fazer
acesso a um item de pedido em especifico, é necessário identificar o produto como
argumento.
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 242
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.
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.
Classe*
1Nome da associaçãopapel
papéis
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 243
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associações Reflexivas e Constraint (restrições)
Associação Reflexiva:
Exemplo
Empregado*
1
Supervisão
Supervisor
Supervisionado
Neste exemplo existe uma associação reflexiva objetos de Empregado. Nesta
associação, há objetos que assumem o papel de supervisor e outros objetos que
assumem o papel de supervisionado. O nome da associação pode ser omitido, uma vez
que os papéis foram definidos.
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 244
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associações Reflexivas e Constraint (restrições)
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
Constraint (restrições):
Uma restrição é um relacionamento semântica entre elementos de modelo que
especifica condições que devem ser satisfeitas.
Classe
atributos
{ restrição } 0..1Classe
atributospapelpapel
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 245
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.
0..1
Contrato
atributos
Pessoafisica
atributos
PessoaJuridica
atributos
{ ou }
0..1
Veja o exemplo: da restrição
“ou”.
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 246
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.
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Classe
atributos
*Classe
atributos
*
Nome da Associação
atributos
Classe de Associação
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 247
Classe Associativa
Exemplo
Fornecedor
atributos
*Produto
atributos
*
ProdutoFornecido
atributos
Associação de muitos:muitos
Classe de associação
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 248
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>>
Nome Interface
Métodos (assinatura)
Assinatura do
métodos
Estereotipo e
nome da interface
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Nota: Na interface também podemos declarar constantes (public static final).
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 249
Interface:
Exemplo
Interface, realização e classes
<<interface>>
PessoaJuridicagetCNPJ()
setCNPJ()
setContrato()
getContrato()
PrestadorServico
atributos
Fornecedor
atributos
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
Realização
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 250
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.
4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
FilmClip
play(c: Channel)
start()
stop()
pause()
Channel
dependência
Workflow de Projeto
Diagrama de Classes. Refinamento
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 251
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.
Workflow de Projeto
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.
Diagrama de Classes. Outros conceitos: Granularidade
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 252
Diagrama de Classes. GranularidadeGranularidade: Exemplo
Cliente
-codigo: int
-descricao: String
+getCodigo()
+setCodigo()
+getDescricao()
+setDescricao()
+getCliente()
Granularidade Grossa
Granularidade Fina
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 253
Diagrama de Classes. Construtores:
Cliente
- codigo: int
- nome: String
- tipo: Tipo
dependência<<construtores>>
+Cliente(codigo: int, nome: String)
+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
Tipo
-descricao: String
+getDescricao(): String
+setDescricao(d: String)
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.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 254
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;
}
//Métodos
}
construtor
Workflow de Projeto
Diagrama de Classes. Construtores:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 255
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;
}
public Mamifero()
{
}
//Métodos
}
construtores
Workflow de Projeto
Diagrama de Classes. Construtores:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 256
Diagrama de Classes. Propriedades:
Propriedades dos Atributos:Existem três propriedades definidas que poderão ser utilizada como os atributos:
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double
+ setValor(double valor)
- 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
Propriedade
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 257
Propriedades dos Atributos:Existem três propriedades definidas que poderão ser utilizada como os atributos:
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double
+ setValor(double valor)
- 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
Propriedade
Workflow de Projeto
Diagrama de Classes. Propriedades:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 258
Propriedades dos Atributos:Implementando a propriedade Frozen em Java:
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double
+ setValor(double valor)
Modificador Final (constantes)
Para declarar uma variável, um ou uma classe como constante usamos o modificador
final.
Entretanto, o uso deste modificador deve obedecer a certas restrições como:
• Uma classe constante não pode ter subclasses;
• Um método constante não pode ser sobrescrito;
• O valor para variável constante deve ser definido no momento da declaração ou através
de um construtor, para variáveis membro, uma vez atribuído o valor, este não mudará
mais.
public class TaxaJuro {
private final double VALOR;
public TaxaJuro(double valor)
{
VALOR = valor;
}
public static void main(String args[])
{
TaxaJuro taxa = new TaxaJuro(21.30);
System.out.println(taxa.VALOR);
}
}
Workflow de Projeto
Diagrama de Classes. Propriedades:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 259
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)
Workflow de Projeto
Diagrama de Classes. Propriedades:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 260
Definição de Delegação:
A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma
mensagem.
Diagrama de Classes. Delegação:
O reúso de propriedades de uma classe pode ser realizado não só através do mecanismo
generalização entre as classes, mas também através do mecanismo de delegação.
O reúso por generalização se baseia na estrutura de superclasse e subclasse, onde a
subclasse herda todos os métodos e atributos da classe “pai” (superclasse).
Recomendamos usar o mecanismo de delegação em algumas situações:
• Para não violar regra de encapsulamento;
• Para não sobrecarregar de responsabilidade uma classe;
• Para atender a semântica da classe e
• Favorecer o mecanismo de reúso.
A seguir veremos um exemplo completo, onde a aplicação do mecanismo de delegação
é melhor solução para obedecermos as regras da orientação a objetos.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 261
Cliente
codigo
nome
Senha
senhapossui
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.
Workflow de Projeto
Diagrama de Classes. Delegação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 262
Cliente
codigo
nome
senha
Em segunda sugestão de modelo, como classe Cliente tem como atributo senha, desta
forma a classe Senha não seria necessário.
Quais são as implicações
que o atributo “senha” pode
causar ao modelo ?
Workflow de Projeto
Diagrama de Classes. Delegação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 263
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:
Cliente
codigo
nome
senha
Funcionario
codigo-funcional
nome
senha
O mesmo conceito
Conceito diferente
Workflow de Projeto
Diagrama de Classes. Delegação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 264
Ao modelarmos devemos ter os seguintes cuidados: (continuação)
- Uma sugestão para solução do problema:
Cliente
codigo
nome
Funcionario
codigo-funcional
nome
Senha
senha
possui possuiHistoricoCliente
Pedido
Workflow de Projeto
Diagrama de Classes. Delegação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 265
Cliente
codigo
nome
senha
qde_dias_expiracao_senha
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:
Este atributo somente é regra
que se aplica somente a senha e
não a cliente.
Workflow de Projeto
Diagrama de Classes. Delegação:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 266
Cliente
codigo
nome
senha
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.
Workflow de Projeto
Diagrama de Classes. Delegação:
Podemos concluir, que no exemplo apresentado duas regras da orientação a
objetos foram violadas:
- Semântica e
- Baixo reúso
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 267
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.
Workflow de Projeto
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 268
Arquitetura de Software
Objetivo desta parte:
É apresentar e discutir Arquitetura de Software, conceitos
modelos e técnicas
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 269
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.
Objetivo:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 270
Big Picture. Arquitetura
Diagramas
Projeto (Visão Lógica)
4
: visitante : Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( ) getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noiteEntrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Projeto (Visão de Componentes e
Visão de Deployment)
Diagrama de Componentes
Diagrama de Deployment
Arquitetura
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 271
Digrama de Componentes
Diagrama de Deployment
Arquitetura
Analista de Sistema
Projetista de Software
PapéisArtefatosWorkflow
Arquitetura
Arquiteto de Software
Modelo de Arquitetura
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 272
Introdução. UML, Visões:
Conceitual Físico
Visão de Projeto
Funcionalidade
Vocabulário
Visão da Implementação
Codificação
Montagem
Visão do Processo
Desempenho
Escalabilidade
Throughput
Visão da Implantação
Topologia do Sistema
Distribuição
Instalação
Visão de Caso de Uso
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 273
Introdução. UML, Visões:
• 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 Implementaçã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.
Visão de Implantação
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 274
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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 275
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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 276
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.
Decomposição e Camadas
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 277
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
Pacote
Nome do Pacote
Nome do
PacoteDependência
(import)
Nome do
Pacote
Workflow de Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 278
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:
Nome do Pacote
Dependência
(import)
Contas a
Pagar
Contas a
Receber
Fluxo de
Caixa
Subsistema
UML. Diagrama de Pacotes
Workflow de Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 279
Separação em camadasCamada:
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
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 280
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>>
Cliente
<<tier>>
Apresentação
<<tier>>
Negócios
<<tier>>
Dados
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 281
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.
Pattern. Model View Controller
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 282
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
Model View Controller. Model 1
Web Server Model
ViewViewView
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 283
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
Model View Controller. Model 2
Web
Server
View View
Controller
Componentes (Model)
View
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 284
Aplicação do MVC em ambiente de três camadas (Web)
Model View Controller
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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 285
Model View ControllerAplicaçã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+
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 286
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.
Introdução:
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.
O papel da Arquitetura:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 287
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.
Workflow de Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 288
Arquitetura.Road Map
Fazer Diagramas
Modelo de
Especificação
Documentos
de Requisitos
Caso de Uso
Fazer Modelo de Arquitetura
Digrama de
Componentes
Digrama de
Deployment
View Controller Model Resources
JSP/HTML Servlet EJBBanco de
Dados
Workflow Arquitetura
Modelo de
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 289
Fazer Modelo Arquitetura
Fazer Diagrama de
Componentes
Refinar Modelo de
Arquitetura (RNFs)
Refinar o Modelo
de Especificação
Arquitetura. Atividades e Passos:
Modelo de Arquitetura
Digrama de
Componentes
Fazer Diagrama de
Deployment
Selecionar uma
Arquitetura
Digrama de
Deployment
Workflow Arquitetura
Modelo de
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 290
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.
Diagrama de Deployment
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 291
processador
Elementos:
Processor (Processador): É qualquer máquina que possua a capacidade de
processamento. Os servidores, estações de trabalho por exemplo.
Dispositivo
Diagrama de Deployment
Servidor
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
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 292
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).
Diagrama de Deployment
Servidor
Impressora
Cliente <<TCP/IP>>
<<RS 232>>
conexão
Dispositivo
(Nó)
Processador
(Nó)
estereotipo
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 293
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.
Diagrama de Deployment
Impressora
WebBrowser
<<Cliente>>
<<RS 232>>
Apache
<<WebServer>>
<<HTTP>>
JBoss
<<Application Server>>
Oracle
<<Banco de Dados>>
Cliente
<<Client-Server>>
<<RMI>>
Nós
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 294
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.
Diagrama de Deployment
Oracle
Banco de Dados
Application Server
JBoss
WebServer
Apache
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 295
Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma
visão mais “clara” da arquitetura baseada na UML
Diagrama de Deployment & Diagrama de Componentes
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 296
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.
Componente
A
Componente
B
Dependência
Componente
genérico
Nome do
componente
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 297
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.
Reserva
Service_
stub
ReservaServiceReservaUI
Component
Dependência
Interface
Room
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 298
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+.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 299
Catalog
Business
Delegate
Catalog
Home
Stub
CatalogHome
Catalog
Remote
Stub
CatalogRemote
Catalog
EJB
Home
Catalog
EJB
Object
Catalog
BeanCatalogRemote
CatalogRemote
CatalogHome
Catalog.jsp
Diagrama de Componentes. Exemplo:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 300
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
{versão 1.}
Disk.dll
Video.dll
Floppy.dll
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 301
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.jar
{versão 1}
Historico.class
Conta.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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 302
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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 303
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.
Nome do Componente
Componente
genérico
- 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
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 304
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
Na linguagem C++, as
especificações de pacote são os
arquivos .h (header). Em Java
usamos o ícone de especificação
de pacote para representar os
arquivos .java
Um corpo de pacote pode
apresentar o código para as
operações da classe. Em C++,
os corpos de pacotes são os
arquivos
.cpp
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 305
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
Componente
genérico
Interface
Além de modelar o componente propriamente dito, podemos modelar o relacionamento
entre o componente e sua interface. Veja o exemplo abaixo:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 306
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.
Boundary
Services
Entities
Component view
Visão principal do Diagrama de Componentes
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 307
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
As classes Entidades
Entities
Cesta
Cesta Item Produto
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 308
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
As classes de Serviços ou Controle
CestaService
ProdutoService
Services
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 309
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
As classes de Interfaces
CestaInterface
Boundary
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 310
Arquitetura.Diagrama de Componentes. Exemplo:
Uma visão dos componentes e relacionamentos
CestaInterfaceMainProgram
CestaService
ProdutoService
Cesta
Cesta ItemProduto
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 311
Arquitetura.Diagrama de Componentes. Exemplo:
Um novo exemplo, o cenário fazer Reserva de apartamento.
ReservaUIMenu Principal
ReservaService
ClienteService
Cliente Reserva Apartamento
ApartamentoService
Model
Controller
View
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 312
Componentes
Componentes:
Componentes são grupos de classes que representam uma funcionalidade
dentro de sistema.
Componentes são identificados usando coesão e acoplamento. Grupos de
classes que exigem alta coesão e baixo acoplamento formam um
componente.
Como identificar os 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.
Diagrama de Componentes. Identificação de Componentes:
Como faço
o diagrama de
componentes ?
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 313
Conceitos: Acoplamento e Coesão
Independência
Funcional:
•Coesão e
•Acoplamento
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
estrutura do programa.
– É medida usando-se dois critérios qualitativos: coesão e
acoplamento.
Coesão e Acoplamento ajudaram na divisão de classe dentro
de componente.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 314
Independência
Funcional:
•Coesão e
•Acoplamento
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 ?
- Solução: Atribuir uma responsabilidade de forma que a coesão
permaneça alta.
Como manter a complexidade sob controle ?
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.
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 315
Independência
Funcional:
•Coesão e
•Acoplamento
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;
- São muito sensíveis a mudança;
Classes de coesão baixa representam, geralmente, uma abstração de
“grande granularidade” ou atribuíram responsabilidades que deveriam ter
sido delgadas a outras classes ou objetos
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 316
Independência
Funcional:
•Coesão e
•Acoplamento
Coesão: (continuação)
Exemplo:
Neste exemplo é
demonstrado a baixa
coesão, uma vez que a
classe Nota Fiscal
assume a
responsabilidade de
fazer o cálculo dos
imposto
NotaFiscal
- número
- data emissão
- tipo
+calcularImposto()
+getNumero
+setNumero
....
NotaFiscalItem
- item[ ]
- quantidade
+getQuantidade()
+setQuantidade()
...
Produto
- codigo
- descrição
+setCodigo()
+getCodigo()
Cliente
- codigo
- nome
+getCodigo()
+setCodigo()
+getNome()
Conceitos: Acoplamento e Coesão
Tributo
- codigo
- nome
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 317
Independência
Funcional:
•Coesão e
•Acoplamento
Coesão: (continuação)
Exemplo:
Solução é delegar a
responsabilidade de
cálculo de imposto para
uma classe especializada
neste assunto (usamos
aqui o mecanismo de
delegação). Desta forma
teremos uma alta coesão.
NotaFiscal
- número
- data emissão
- tipo
+getNumero
+setNumero
....
NotaFiscalItem
- quantidade
+getQuantidade()
+setQuantidade()
...
Produto
- codigo
- descrição
+setCodigo()
+getCodigo()
+gerProduto
Cliente
- codigo
- nome
+getCodigo()
+setCodigo()
+getNome()
+get/cliente()
CalculoImposto
+calcularImposto()
Conceitos: Acoplamento e CoesãoTributo
- codigo
- nome
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 318
Independência
Funcional:
•Coesão e
•Acoplamento
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
área funcional
• Coesão Alta:
– Uma classe tem a responsabilidade moderadas em uma área funcional e
colabora com outras classes para levar a termo as tarefas
• 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.
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 319
Independência
Funcional:
•Coesão e
•Acoplamento
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
o aumento do potencial de reúso, porque uma classe altamente coesiva
pode ser usada para finalidade muito específica..
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 320
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento (Low Coupling)
É uma medida da interdependência relativa entre as classes.
Depende da complexidade de interface entre as classes.
Baixo acoplamento é o desejável
Como manter o baixo acoplamento ?
- Solução: Atribuir uma responsabilidade de forma que o
acoplamento permaneça fraco
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.
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 321
Independência
Funcional:
•Coesão e
•Acoplamento
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
das classes que ela depende.
Benefícios:
• Não afeta por mudanças em outros componentes
• simples de entender
• conveniente para o reúso.
Conceitos: Acoplamento e Coesão
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 322
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento. Tipos:
Conceitos: Acoplamento e Coesão
Abaixo os possíveis tipos de acoplamento:
Cliente Service{abstract}
Service Service
Acoplamento Abstrata:
Cliente<<Interface>>
Service
Service Service
Cliente
Sem acoplamento
Service
Cliente Service
Com acoplamento
Cliente Service
Forte acoplamento
tight
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 323
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento
Princípio da Dependência Inversa:
Conceitos: Acoplamento e Coesão
“Abstração não deve depender classe concreta. Uma classe
concreta deve depender de uma abstração”
Exemplo:
Moeda
- valor
+getValor
+setValor
MaskMoeda
+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.
Workflow de Projeto, Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 324
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento
Princípio da Dependência Inversa (continuação):
Conceitos: Acoplamento e Coesão
Moeda
- valor
+getValor
+setValor
MaskMoeda
+maskMoeda()
dependência
2 - O relacionamento de dependência inibe a extensibilidade da
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).
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 325
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento
Princípio da Dependência Inversa (continuação):
Conceitos: Acoplamento e Coesão
Aplicando a DIP, podemos resolver a situação, veja os modelos
abaixo:
Cliente Service{abstract}
Service Service
DIP com Classe Abstrata:
Cliente<<Interface>>
Service
Service Service
DIP com Interface:
Moeda MoedaMask{abstract}
Real Dolar
Solução para a classe Moeda:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 326
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento
Conceitos: Acoplamento e Coesão
<<interface>>
iPessoa
Cliente
Realização
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.
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 327
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento
Conceitos: Acoplamento e Coesão
<<interface>>
iPessoa
Cliente
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
PessoaAdapter
Relacionamento de Realização
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 328
Exemplo:
Acoplamento
Coesão
e Componentes
Exemplo:
A partir do diagrama de classe, tentamos agrupar classes usando
técnicas de coesão e acoplamento.
Diagrama de Componentes
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 329
Exemplo:
Acoplamento
Coesão
e Componentes
Exemplo:
Temos o seguinte resultado:
Diagrama de Componentes
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 330
Exemplo 2:
Diagrama de Classes:
Diagrama de Componentes
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007
331
Exemplo 2:
A partir do diagrama de classe,
agrupar classes usando os
conceitos de coesão
e acoplamento.
UML. Diagrama de Componentes
Pedido
Cesta de Compra
Produto
FormaPagto
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 332
Exemplo 2:
Diagrama de Componentes
Diagrama de Componentes
Cesta
Pedido
Produto
FormaPagto
Pedido
Cesta de Compra
Produto
FormaPagto
Workflow de Projeto, Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 333
Projetando um Modelo de Arquitetura:
Oracle
Servidor de
Banco de Dados
Servidor de Aplicação
JBoss
HTML
Windows
Cliente
HTTP
Linux Suse Linux Suse
TCP/IP
Sugestão para modelo de Arquitetura para aplicações Web de três camadas:
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 334
Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)
Projetando um Modelo de Arquitetura para Camada Cliente:
DeskTop Servidor de Aplicação
Funcionário
<<JRMP>>
ReservaUI
<< Stub>>
Reserva
<<Skeleton>>
RMI
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 335
Web
Projetando um Modelo de Arquitetura para Camada Cliente:
WebServer
Cliente
<< Reserva>>
Browser
FormConsulta
HTTP
JavaBeans
ServletsController
Banco de
Dados<< ConnDB>>
HotelSchema
Tabelas de Reserva
JSP
Servlet
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 336
Web
Projetando um Modelo de Arquitetura para Camada Cliente:
Cliente
<< Reserva>>Browser
FormConsultaHTTP
Cliente
ServletsController
Banco de
Dados<< ConnDB>>
Servlet/JSP JavaBeansHTML
Apresentação Negócio Integração
JDBC 2.0
Recursos
SQL
Workflow Arquitetura
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 337
Considerando o cenário de Loja Virtual, numa transação de pagamento.
Implementando os Requisitos Não Funcionais:
ClienteFazer Pedido
Fechar Pedido
<<include>>
Fazer Pagamento
CartaoCredito
<<include>>
Requisito Não Funcional:
Segurança: Todas as transações de pagamento deve ser realizado em ambiente seguro
Cliente
WebServer
Pagamento
Browser
FormPagamento
HTTPs (HTTP + SSL)
ServletsController
Workflow Arquitetura
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.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007
338
Quer Mais
http://etecnologia.ning.com/
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material...
Envie um e-mail para com subject: “Quero entrar na comunidade” para [email protected] que te
enviaremos um convite para participar da nossa comunidade
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 339
Sobre o autor: Rildo F. Santos Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento
Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado
em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade
Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP -
Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC -
Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e
padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de
Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública,
Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL
Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 340
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de
seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste
material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o
autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou
desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie
um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-
mail para nós.
Rildo F dos Santos ([email protected])
Imagens:
Google, Flickr e Banco de Imagem.
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 341
Licença:
Análise e Desenho Orientado a Objetos com UMLC
ap
ac
ita
çã
o E
ng
en
ha
ria
de
So
ftw
are
Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007
An
áli
se e
Des
enh
o
Ori
enta
do
a O
bje
tos
com
UM
L
Versão 27 |
Rildo F [email protected]
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Top Related