Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
o s L o h t M n e j e U s b e O D a m o e c o e s d i a l t á n n e A i r O
Rild Ri ldo o F Sant Santos os
[email protected] [email protected]
Twitter: @rildosan Blog: http://rildosan.blogspot.com/
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Conteúdo Parte 1 - Principais Conceitos Conceitos da Orientação Orientação a Objetos Objetos e introdução introdução UML Parte 2 – Especificação de Requisitos de Software Parte 3 – Analise Conceitual (design ) do Modelo de Especificação de Software Parte 4 – Desenho (design Parte 5 – Arquitetura de Software
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetivo
Objetivo: Apresentar os principais conceitos da orientação a objetos. Será demonstrado os seguintes conceitos: Classes, Objetos, Atributos, Métodos, Abstração de Dados, Herança,
Polimorfismo, Encapsulamento, Associação e Interface.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Introdução. Desenvolvimento de Software Orientada a Objetos Influência escolha da Ferramentas
Ferramentas e Artefatos
Tecnologia OO
Atividades Suporte as atividades
WorkFlows
Metodologia/Fases Jacobson pyramid “rational enterprise philosophy”
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Bem, podemos encontrar várias definições para o termo “objeto”, neste momento podemos entender que: “Objeto pode ser qualquer coisa na natureza que possua características e comportamentos” comportamentos”
Veja alguns exemplos de objetos:
Pessoa
Cão
Partida de Futebol
Barco
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, IOF , uma ligação telefônica, telefônica, uma conta corrente e etc...)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Objetos O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que incorporam estrutura de
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
dados (propriedades ou características) e um conjunto de operações que manipulam estes dados.
Objeto: Pessoa
Objeto: Pássaro
Propriedades
Operações
Nome Data de Nascimento Massa (peso) Altura
Andar Correr Trabalhar Chorar Dançar
Propriedades
Operações
Espécie Cor das penas Tamanho Peso
Andar Correr Voar Pousar
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Os objetos tem um identificador único (que podemos chamar de nome do objeto), tem conjunto de propriedades (que podemos chamar de características e/ou atributos) e comportamentos (que podemos chamar de operações).
Atributos cor Número chassi
Identificador
Carro
Ano-fabricação
Operações acelerar O que são operações ? - Cois Coisas as que objet objetoo deve saber fazer
parar
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que ele tem um estado
Atributos cor
branco
Número chassi VW1003G345 Ano-fabricação 1966
Identificador
Carro
Operações acelerar parar
estado
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Os nomes dos objetos geralmente são substantivo no singular, tais como, cliente, conta-corrente, pessoa e etc. Os atributos também são substantivos, exemplo: cor, tamanho, peso, idade, número e etc. Já as operações usualmente são verbos, como: acelerar, validar, validar, verificar, verificar, calcular e etc
Atributos cor
Substantivo
branco
Número chassi VW1003G345 Ano-fabricação 1966
Identificador
Carro
Operações acelerar verbos
parar
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Modelagem de objeto:
Identificador
Carro
Nome (identificador) Representação na Orientação a objetos
Carro
Atributos cor
branco
Número chassi VW1003G345 Ano-fabricação 1966
cor número chassi ano-fabricação acelerar parar
Propriedades (atributos)
Operações acelerar parar
Operações
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Modelagem de objeto:
Carro cor número chassi ano-fabricação acelerar parar Representação na Orientação a objetos
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.
O que é uma classe ?
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Definição de Classe: Uma classe descreve descreve um conjunto de objetos que compartilham compartilham os mesmos atributos, operações, métodos, relacionamentos e semântica 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 Essas classes podem incluir abstrações que são parte do domínio 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 hardware e até itens que sejam somente conceituais. Exemplo: A classe classe Pessoa deverá ter atributos e métodos comuns comuns
Nota: Dicionário Aurélio Em programação ou modelagem orientada a ob jetos (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.
Pessoa nome idade getNome() getIdade() setNome() setIdade()
Nome da Classe Atributos Métodos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe Exemplo de Classe: 3
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
1
Livro
Legenda: 1 – Objeto no mundo real 2 – Classe Livro 3 – Objeto da classe Livro
2
ISBN 0747551006 Titulo: Harry Potter and the Order of the Phoenix Autor: J. K. Rowling
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe e Objeto Classe e Objeto. Exemplo: ISBN 0747551006 Titulo: O Poder da inteligência Emocional Autor: Daniel Goleman
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 ISBN 8571643512 Titulo: AS JANELAS DO PARATII Autor: Amir Klink
Uma coleção de livros pode ser representada por uma classe chamada Livro.
Cada livro desta coleção é “instance” (objeto) da classe livro.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe e Objeto Classe e Objeto. Exemplo:
Identificador
Carro
Atributos cor
branco
Classe (Modelo)
Objeto (“instance”)
Carro
fusca:Carro
cor número chassi ano-fabricação
cor=“branco” número chassi=“VW1003G345
Número chassi VW1003G345 Ano-fabricação 1966
Operações acelerar parar
Acelerar() parar()
ano-fabricação=1966
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe e Objeto Classe e Objeto. Exemplo:
Classe Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Cliente nome cpf idade
Objetos Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16
Cliente: clientehomem clientehomem nome = Felipe cpf = 039.217.908-22 idade = 42
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe, Responsabilidade e Colaboração Responsabilidades Definição de Responsabilidades: Responsabilidades: Um contrato ou obrigação em tipo ou de uma classe
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
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, valor, data, tipo de pagamento e etc.
Responsabilidades
TransacaoPagamento numero valor data situação TipoPagamento Responsabilidade: -- Saber o número número da transação, data, valor -- Conhecer Conhecer o tipo tipo de pagamento...
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe, Responsabilidade e Colaboração Colaboração:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Definição de Colaboração: Ás vezes uma classe precisa colaborar com outra classe para cumprir suas responsabilidades responsabilidades A classe classe Transação de Pagamento tem a responsabilidade responsabilidade pelo conhecimento das seguintes informações: número da transação, situação, valor, 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 tipo de pagamento. Exemplo: CartaoCredito 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 número da transação, data, valor -- Conhecer Conhecer o tipo tipo de pagamento...
CartaoCredito
Colaboração
BoletoBancario
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe, Responsabilidade e Colaboração Classes, Responsabilidades e Colaboração:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
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 conhecer os dados dos aluno: Nome Número da Matricula Curso
Matricula Pessoa Curso
Cartão
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
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
Classes Objetos Atributos Métodos Abstração de Dados Uma classe possui: • Atributos Herança • Métodos Polimorfismo • Responsabilidades (o que ela sabe fazer) Encapsulamento • Colaboração (interação com outras classes) Interface
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Atributo Definindo Atributo: • É uma características (propriedade) presente no objeto. • Valor Valor de todos os atributos at ributos é igual Estado do Objeto. Objeto .
Classes • Somente atributos que são de interesse do sistema sist ema devem ser Objetos descritos na classe. Atributos Cliente nome Métodos cpf idade Abstração de Dados Herança Polimorfismo Encapsulamento Interface
atributos
Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Método Escrevendo os métodos. Para cada atributo é recomendado escrever um par de métodos, os nomes destes métodos devem começar com setXXXX( ) e getXXX( )
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Cliente codigo nome
Métodos
getCodigo() setCodigo() getNome() setNome()
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”
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Método Definição de Método:
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. Chamando os métodos Para chamar um método de um u m 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
Métodos
setDeposito() getSaldo() setSaque()
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Mensagem Definição de Mensagem: Definição:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
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.
Classes Objetos Atributos Desta forma podemos dizer que os métodos “encapsulam” os Métodos atributos. Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Classe Concreta e Abstrata 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.
public class Pessoa { //Atributos private String nome; private int idade; //métodos public public String String getNome(){ getNome(){ return return nome; nome; }
E a Classe abstrata ? Bem, veremos a seguir o que é uma classe abstrata...
public public void void setNome(String setNome(String nome){ this.nome = nome; } publ public ic int int getIdade(){ getIdade(){ return return idade; idade; } public public void void setIdade(int setIdade(int idade){ this.idade = idade; } }
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Abstração de Dados Exemplo: Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas e motos. Estes veículos têm algumas características c aracterísticas semelhantes semelhantes como cor, peso, tamanho e capacidade c apacidade de carga. Entretanto cada veículo possui outras características característ icas 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 t ambém estamos fazendo que características diferente seja tratada de forma diferenciada.
O que é abstração de dados ?
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Abstração de Dados Definição de Abstração de Dados: Definição de abstração: “Habilidade mental que permite aos seres humanos visualizarem os problemas
Classes do mundo real com vários graus de detalhe, dependendo do contexto corrente do problema. (Jim Rumbaugh). Objetos Qual é a função da abstração ? Atributos A função da abstração é capturar as propriedades e os comportamentos essenciais, Métodos como se fosse uma fatoração, desta forma determina-se o que é importante e o que não é. Abstração de Dados Exemplo Herança Polimorfismo Veículo Encapsulamento Abstração Interface Navio especialização
Avião
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Abstração de Dados Exemplo de Abstração de Dados:
Abstração: nos ajuda a lidar com a complexidade. Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Exemplo Generalização
MeiodeComunicação
Carta
Telefone
Jornal
Especialização As classes Contribuinte e MeiodeComunuicação neste MeiodeComunuicação neste caso são abstratas e ambas podem representam um domínio.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Abstração de Dados Abstração de Dados:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Uma classe abstrata é uma classe que: • Provê organização • Não possui “instances”, “instances”, ou seja, não possui objetos. • Possui uma ou mais operações operações (métodos) abstratas public abstract class ContaBancaria extends Object { public public ContaB ContaBanca ancaria ria() () { } protected int numerocontacorrente; public abstract int getNumeroContaCorrente(); public abstract void setNumeroContaCorrente(int numerocontacorrente); }
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos: Abstração de Dados Veja agora a classe Pessoa, que é abstrata, pois, possui um método abstrato.
public abstract class Pessoa { //métodos public abstract String getNome() getNome() public void setNome(String setNome(String nome){ this.nome = nome; }
Um método abstrato não possui implementação somente assinatura (declaração)
public int calcIdade(Date calcIdade()(Date publicabstract abstract int getIdade() getIdade d1, Date d2); public void void setIdade(int setIdade(int setIdade(int (int idade) idade) public setIdade { { this.idade = idade; this.idade = idade; } } }
Um método concreto possui implementação assinatura e implementação.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Resumo: Abstração de Dados Resumindo:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Uma classe abstrata deve ter pelo menos um método 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”
Como eu faço para usar uma classe abstrata ?
Análise e Desenho Orientado a Objetos com UML
Orientação a Objetos. Principais Conceitos: Abstração de Dados
e r a w t f o S Comparação entre Classe Abstrata e Classe Concreta e d Classe Abstrata Classe Concreta a i r a Os métodos podem ser assinados e h Os métodos devem ser somente assinados n implementados e g n Poder sofrer “instance” E Não pode sofrer “instance” o ã ç Relacionamento somente através de a Todos os tipos de relacionamentos t HERANÇA i c a p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Herança Definição de Herança: Definição:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Mecanismo baseado em objetos que permite que as classes compartilhem atributos e operações baseados em um relacionamento, geralmente generalização. (Rumbaugh) 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 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:
Animal Animal Doméstico
Animal Selvagem
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Herança Exemplo de Herança:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Podemos dizer que Pós- Graduação é tipo de Curso Universitário, assim como Curso de Especialização ou de Extensão.
Hierarquia de Classes Super classes
Curso Universitário
Graduação
Pós-Graduação
Sub classe
extends
Especialização
Extensão
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Polimorfismo Definição de Polimorfismo: Definição:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
“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
Telefone Móvel
calcularConta(telefone)
Telefone Fixo
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Polimorfismo Overloading de Método
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
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 .
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Polimorfismo 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 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), Bancária), entretanto para cada tipo de Conta ele tem uma implementação diferente. Por exemplo: - Para apurar o saldo da Conta 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) juros) - resgate resgatess - ir
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Principais Encapsulamento 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.
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Encapsulamento Benefícios do Encapsulamento:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
Benefícios - Seguran Segurança: ça: Protege os atributos dos objetos de terem seus valores corrompidos por outros objetos. - Independênc Independência: ia: “Escondendo” seus atributos, um objeto protege outros objetos de complicações de dependência de sua estrutura interna
Pessoa nome idade
setNome()
nome
getNome()
setNome() getNome() setIdade() getIdade()
setIdade()
idade
getIdade()
encapsulamento
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Interface Definição de Interface: O que é interface ?
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento 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 usa -las também para prover: - Organização Organização e padroniz padronização ação de assinatura assinatura de métodos; métodos; - Simular Simular heranç herançaa múlti múltipla pla e - Fazer Fazer relacionamento relacionamentoss de classes com com responsabilida responsabilidade de distintas. distintas.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Orientação a Objetos. Principais Conceitos:
Interface Exemplo de Interface: Representação:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface
<
> Codigo getcodigo() setcodigo()
realização
Contrato Produto getcodigo() setcodigo()
cpf
Fornecedor getcodigo() setcodigo()
cnpj
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Introdução a aOrientação Orientação Objetos. aPrincipais Objetos Conceitos:
Interface Principais Características Características de uma interface:
Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada
A versão da UML abordada é versão 1.5
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Introdução Por que fazer a modelagem? Construímos modelos para compreender melhor o sistema que estamos desenvolvendo. Com a modelagem, alcançamos alguns objetivos: 1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja; 2 - Os modelos permitem especificar a estrutura ou o comportamento comportamento de um sistema; 3 - Os modelos proporcionam proporcionam um guia para a construção construção do sistema; 4 - Os modelos modelos documenta documenta o sistema sistema.. O Que Que é Modela Modelagem gem Visua Visual? l?
“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Introdução O Que é Modelagem Visual? Modelagem visual significa modelar com a utilização de notações padrão. Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada. UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das mais populares do momento. A UML (Linguagem (Linguagem de Modelagem Unificado) é padrão mantido pelo OMG (www (www.omg.org/uml). .omg.org/uml).
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Introdução A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração da estrutura de projetos de software. A UML poderá ser usada para: •Visualização •Especificação •Construção de modelos e diagramas •Documentação. A UML é adequada para a modelagem de sistemas, cuja a abrangência poderá incluir i ncluir 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 i ndependente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Principais Digramas: ESTÁTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuição
Modela a estrutura do sistema
DINÂMICOS . Diagrama de Casos de Uso . Diagramas de Interação - Diagram Diagramaa de Seqüênci Seqüênciaa - Diagram Diagramaa de Colaboraç Colaboração ão . Diagrama de Atividade . Diagrama de Estados
Modela o comportamento do sistema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Processo de Desenvolvimento:
Processo de Desenvolvimento Modelo Casos Uso de Negócio
Modelo Objetos de Negócio
Necessidades dos Visão Stakeholders
Modelo de Casos de Uso
Modelo de Classes
Análise Realização dos Casos de Uso Classes
Casos de Teste Defeitos
Desenho Classes
Componentes Script de Testes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada 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 •
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Elementos: Elementos estruturais: – classe, interface, colaboração, caso de uso, classe ativa, componente, nó • Elementos comportamentais: – interação, máquina de estados • Elementos de agrupamento: – pacote, subsistema •
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Visões:
Vis Visão ão de Projeto
Visão da Implementação Codificação Montagem
Funcionalidade Vocabulário
Visão de Caso de Uso Visão do Visão da Processo Implantação Desempenho Escalabilidade Throughput Conceitual
Topologia do Sistema Distribuição Instalação Físico
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e • d a i r a h n e g n E o ã ç a t i c a • p a C
UML. Linguagem de Modelagem Unificada Visões: Visão de Caso de Uso
A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica realmente a organização do sistema de software. Porém , ela existe para especificar as forças que determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são representados em diagrama de interação., interação., diagrama de gráfico de estados e diagrama de atividades Visão Visão de Projeto Projeto
A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de atividades.
Análise e Desenho Orientado a Objetos com UML
UML. Linguagem de Modelagem Unificada Visões:
e r a w t f o Visão de Processo S e • A visão do processo abrange os “threads” e os processos que formam formam os mecanismos de d concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões a i r de desempenho, à crescimento escalar e ao “ throughput” do sistema. Com a UML, os aspectos aspect os a h estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do n e projeto, mas o foco voltado para as classes ativas que representam esses threads e threads e processos. g n Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser E programas ou parte. o ã ç a t i Visão de Implementação c a A visão de implementação de um sistema abrange os componentes e os arquivos utilizados p • a para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o C
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.
Análise e Desenho Orientado a Objetos com UML
UML. Linguagem de Modelagem Unificada Visões:
e r a w t f o Visão de Implantação S e A visão de implantação de um sistema abrange os nós que formam a topologia topologia de hardware em d • a que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a i r a instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa h n visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em e g diagramas de interações, de gráfico de estados e diagramas de atividades. n E 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 a t i c interessem. Essas cincos visões também interagem entre si, por exemplo: a p Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez, a C representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões de projeto e de processo.
Análise e Desenho Orientado a Objetos com UML
UML. Linguagem de Modelagem Unificada Exemplo: de Projeto Software Orientado a Objetos:
e r a w t f o S e d a i r a unidades h n e g n E o ã ç a t i c a p a C
Use case view
Formulários
Casos de Uso
Diagrama de Seqüência e/ou Diagrama de Colaboração Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes
Logical view
Diagrama de Classes
Component view
Diagrama de Componentes
Depl Deploym oymen entt view view
Diagrama de Deployment
Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Big Picture. Requisitos e Análise Business Case
Coleta de Requisitos
Análise Conceitual Modelo Conceitual
Documento de Visão
Engenharia de Requisitos 4
Análise de Requisitos
Especificação de Requisitos (Visão de Caso de Uso)
Requisitos Funcionais
Glossário de conceitos
Casos de Uso
Requisitos Não Funcionais
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Introdução. Artefatos: Produtos dos Workflows Workflows de Requisitos e de Análise: Análise: Documento de d e Visão Documento de Requisitos
Requisitos Especificação de Requisitos (Casos de Uso)
Modelo Conceitual ou Modelo de Domínio
Análise
Vocabulário do Sistema Sist ema Modelo de Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Big Picture. Análise & Projeto Projeto (Visão Lógica)
Análise Modelo Conceitual
Diagrama de Classes
4
ReceberPedido
4
PreencherPedido
EnviarFatura
Entrega [pedido urgent e]
[s enão] ReceberPagamento
Especificação de Requisitos (Visão de Caso de Uso)
Entregadurante a noite
: visitante
: FormBusca
: Ca Ca et go ir a
: Po r du ot
EntregaRegular
: Ca a t ol go
getDescricao() exibirCategoria() selecionarCategoria
exibirProduto()
selecionarProduto()
getDescricao()
getQuantidade()
EncerrarPedido
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada
Projeto Principais Produtos (Artefatos): Diagrama Diagr ama de de Sequênci Sequência a / Colaboraç Colaboração ão Diagrama de Atividades Diagrama de Estados
Diagrama de Classes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada Big Picture. Projeto &Arquitetura Projeto (Visão Lógica)
Arquitetura Projeto (Visão de Componentes e Visão de Deployment)
Diagramas
4
ReceberPedido
: visitante
: FormBusca
: Ca Ca et go ir a
: Pr Pr od ut o
PreencherPedido
: Ca a t ol go
EnviarFatura
getDescricao()
Entrega
exibirCategoria() selecionarCategoria
getDescricao()
[ pedi do urgente]
[ senão]
getQuantidade()
ReceberPagamento
exibirProduto()
selecionarProduto()
Entregadurante a noite
EntregaRegular
EncerrarPedido
Diagrama de Componentes Diagrama de Deployment
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
UML. Linguagem de Modelagem Unificada
Arquitetura Principais Produtos (Artefatos): Diagrama de Componentes Diagrama de Distribuição(Deployment) Distribuição(Deployment) Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Especificação Especificação de Requisitos de Software Objetivo desta parte: É apresentar e discutir o Ciclo de Requisitos de Software: – Elicitação, Análise, Análise, Especificação de Requisitos de Software com Caso de Uso
Introdução
Análise e Desenho Orientado a Objetos com UML
Análise de Requisitos: Introdução e Um entendimento completo dos requisitos de software é essencial para um o sucesso do r desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado a w seja, um programa mal analisado e especificado frustrará o usuário. t f Análise de requisitos é um processo de descoberta, refinamento, modelagem e o S especificação. e d O escopo do software, inicialmente i nicialmente estabelecido pelo Analista de Sistemas e refinado a i durante o planejamento do projeto de software, é aperfeiçoado em detalhes. r a Modelos, diagramas, fluxos são criados para melhor compreensão do problema. h n O analista e o usuário desempenham um papel ativo na análise e especificação de e requisitos. g n E O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às o ã vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e ç solucionador de problemas. a t i Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente c a simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as p oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável. a C
O dilema com o qual se depara um analista pode ser mais m ais 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 e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Ferramenta de Desenvolvimento de Software Big Picture. Requisitos Business Case
Coleta de Requisitos
Análise Conceitual Modelo Conceitual
Documento de Visão
Engenharia de Requisitos 4
Análise de Requisitos
Especificação de Requisitos (Visão de Caso de Uso)
Requisitos Funcionais
Glossário de conceitos
Casos de Uso
Restrições
Requisitos Não Funcionais
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow Requisitos
Requisitos Workflow
Arquitetura
Artefatos
Papéis
Documento de Visão
Documento de Requisitos
Especificação de Requisitos (Casos de Uso)
Analista de Sistema Analista de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
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 UML
Requisitos e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
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 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 UML
Requisitos
Requisitos. Road Map
e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos
Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Identificação e elicitação de Requisitos: Por que o “elicitação” é importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente 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. Patrocinador. • Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.
Uma Simples Comparação: Elicitação Boa
Elicitação Ruim
Bom Diagnóstico
Diagnóstico ineficiente
Soluções eficientes
Soluções medíocres
Satisfação dos usuários Melhoria dos processos e redução de custo
Insatisfação dos usuários Problemas operacionais e financeiros
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Identificação e elicitação de Requisitos: Documento (Artefato) desta etapa: “ Documento de Visão”
Participantes: Analistas e Especialista em Negócios Participantes: Usuário, Clientes, Fornecedores e Patrocinadores
reuniões
documentos
identificação/ elicitação de Requisitos entrevistas
Objetivo: Descrever a visão inicial do software Documento de visão
Análise e Desenho Orientado a Objetos com UML
Requisitos
e r a w t f o As fases da Identificação/Elicitação de Requisitos: S e d Um projeto de elicitação de requisitos têm as seguintes fases: a i r a h n Como deve ser feito ? Planejamento e g n E o Elicitação de ã O que devo coletar ? ç Requisitos a t i c a p a Documentação C Como devo documentar ?
Identificação e elicitação de Requisitos:
Identificar Fontes Técnicas Identificar Funcionalidades Identificar Restrições e Riscos
Documento de Visão
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Identificação e elicitação de Requisitos: As informações podem ser identificadas ou encontradas em diversas fontes: - Usuári Usuários; os; - Docume Documento ntos; s; - Especificaç Especificações; ões; - Client Clientes; es; - Patrocinado Patrocinadores; res; - Analista de Negócios (“Domain Domain Expert Expertss” - Especialis Especialista ta em em uma ou ou mais mais área de negócio) negócio) Quais são as técnicas ? Existem várias técnicas, todas elas possuem seus próprios conceitos, vantagens e desvantagens, que podem ser usada nesta atividade entre elas estão: - Reuniõ Reuniões; es; - Entrev Entrevist istas; as; - Questi Questioná onário rios; s; - Work Worksh shop op;; - Brains Brainstor tormin ming; g; - JAD (Join Applica Application tion Developm Development ent)) - Fast Fast; ; - Docume Documento ntos; s; - Sistemas Sistemas Legados. Legados.
Análise e Desenho Orientado a Objetos com UML
Análise de Requisitos
e r a w t f o Identificação dos Requisitos: Tipos de Requisitos S Os Requisitos de Software podem ser divididos em duas categorias: e d a Requisitos i r a h n e g Requisitos Requisitos n E Funcionais Não-Funcionais o ã Os requisitos não funcionais dizem respeito as ç Os requisitos funcionais descrevem o que o a sistema deve fazer, isto é, as funções características que descrevem qualidade do serviço t i (QoS). QoS). c (funcionalidades) necessárias para atender os a objetivos. O que sistema deve saber fazer. A omissão ou esquecimento desses requisitos constitui p uma das principais razões de uma eventual a Exemplos: Buscar cliente, Registrar pedido insatisfação dos usuários com relação a um software. C Calcular conta de consumo, Calcular tributos e
Identificação e elicitação de Requisitos:
etc.
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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Identificação e elicitação de Requisitos: Identificação dos Requisitos: Os requisitos de software podem ser identificados no texto da “ declaração 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 Requisitos funcionais funcionais e - Requisitos Requisitos não não funcionais funcionais..
Texto da Declaração do Problema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
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 Stakehol Stakeholders ders - Lista dos Requisi Requisitos tos - Lista Lista dos Risc Riscos os - Lista das Restriç Restrições ões
Exemplo: Documento de Visão: Data: ________ | Autor: ________ | Revisão: Revisão: ____ Índice: 1.0 - Introd Introduçã ução o 1.1 Objetivo do documento 1.2 Escopo 1.3 Abreviaturas, 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
Análise e Desenho Orientado a Objetos com UML
Requisitos e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos
Requisitos. Road Map Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Análise e Desenho Orientado a Objetos com UML
Requisitos
e r a w t f A análise de requisitos procura sistematizar o processo de definição de requisitos. o c omplexidade dos sistemas exige que se preste mais S Essa sistematização é necessária porque a complexidade e atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma d definição para requisitos é apresentada a seguir. a O Documento de Visão é um artefato importante na Análise i Análise de Requisitos, destacamos algumas r a razões: h - Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais mais critica n e do processo de desenvolvimento de software. g n A Análise de Requisitos deve ser: E Correta: Quando cada requisito expresso nela for encontrado no software; o Correta: ã ç Ambígua: Cada requisito deve ter somente uma interpretação (definição); a Não Ambígua: t i c Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos a Completa: p relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais) a C
Análise de Requisitos: Introdução
Consistente: Consistente: Quando não existir conflito entre os requisitos;
Verificável: Verificável : Quando for possível verificar/validar cada requisito; Modificável: Modificável: Quando os requisitos podem ser facilmente alterados.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.
Detalhar os Requisitos Funcionais Classificar os Requisitos não Funcionais Descrever os Usuários e Entidades Externas Fazer Plano de Redução de Risco
Documento de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Detalhar Requisitos Funcionais: Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para esta atividade. Veja o exemplo: Lista de Requisitos funcionais Autor:
Nome
Revisão:
Código
Data Atualização:
Descrição
Fazer Reserva RF01E Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, remover, alterar e consultar reservas. Cada reserva deverá ter um cliente e um apartamento e respectiva período)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Detalhar Descrição das Regras de Negócio Nome do Projeto Objetivo
id RN01
Serviço de Atendimento e Reserva de Apartamento Descrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.
Nome da Regra Registrar Reserva de Apartamento
Descrição da Regra de Negócio 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. Data
Os código permitem a rastreabilidade
01/01/08
Nome / Equipe RFS
Versão
Status
2.1
Vigente
Requisitos Funcional RN: RN01 Nome: Reserva
Descrição: Serviço de Atendimento e Reserva de Apartamento
ID
Nome
Descrição
RFC01
Registrar Reserva de Apartamento
Esta funcionalidade 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Classificar Requisitos Não Funcionais: Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos categorizar estes requisitos, as mais frequente são: - Performance: Tempo de resposta - Segurança: Uso de senhas, certificados digitais e etc.. - Usabilidade: Identidade Visual e Interfaces amigáveis - Disponibilidade: O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha - Flexib Flexibilid ilidade ade:: 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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Classificar e Detalhar Requisitos Não Funcionais: Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos funcionais, precisamos ter um padrão Lista de Requisitos Não funcionais Categoria: Performance Autor: Req. Funcional
Fazer Consulta
Revisão:
Data Atualização:
Código
Descrição
RNFP1
As consultas que serão realizadas pelo cliente não poderão exceder ao tempo de resposta de 15 segundos Por que preciso de um código ? Este código tem como objetivo facilitar a “rastreabilidade”.
Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual é o caso de uso que realiza este RNF, RNF, no caso de mudanças.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Classificar e Detalhar Requisitos Não Funcionais: Continuação: Lista de Requisitos Não funcionais Categoria: Usabilidade Autor:
Revisão:
Data Atualização:
RF / Aplicação
Código
Descrição
Aplicação
RNFU1
As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa.
Aplicação
RNFU2
As interfaces com usuário devem seguir padrão de interfaces estabelecido pelo Manual de Sistema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Detalhar Lista de Stakeholders: Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de decisão decisão ou participam participam direta direta ou indiretament indiretamentee do processo processo de de construçã construçãoo do softwar software. e. Mais uma vez criaremos um formato padrão. Veja o exemplo: Lista de Stakeholders Autor:
Revisão:
Data Atualização:
Nome
Descrição
Cliente
São todas as pessoas físicas ou jurídicas que fazem reservas
Colaborador
É qualquer pessoa que presta algum tipo serviço para empresa
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Detalhar Lista de Stakeholders: Continuação: Lista de Entidades Externas Autor:
Revisão:
Data Atualização:
Nome
Descrição
Administradora de Cartão de Crédito
Entidade que faz validação de um cartão de crédito presente em transação de pagamento.
Plano de Redução de Riscos: Precisamos elaborar um Plano de Redução de Risco, para os risco que já foram identificados. Este plano deve detalhar como mitigar os riscos identificados.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Análise de Requisitos. Artefato Documento de Requisitos: Objetivo: Classificar, 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 Requisitos Funcio Funcionais nais - Requisito Requisitoss Não Funcionais Funcionais - Lista dos Stakehol Stakeholders ders - Plano de Redução Redução de de Risco
Exemplo:Documento Exemplo:Documento de Requisitos:
Data: ________ | Autor: ________ | Revisão: ____ Índice: 1.0 - Introd Introduçã ução 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
Análise e Desenho Orientado a Objetos com UML
Requisitos e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos
Requisitos. Road Map Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos
Fazer Fazer Especificação de Requisitos (Casos de Uso)
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos: O produto que devemos ter após Análise de Requisitos é a “ A especificação de Requisitos” é feita através de Casos de Uso, Uso, conforme definido pela UML. Um conjunto de casos de uso é importante para se compreender o que o usuário quer. quer. Um caso de uso descreve uma funcionalidade (“requisito”) a ser oferecida pelo sistema, ou seja, um serviço.
Documento de Visão
o ã s N i s a n o o t i i c s n i u u q e F R
s s o i a t i n s o i i u c q e n u R F
Documento de Requisitos Especificação de Requisitos Comportamento externo
Casos de Uso
Comportamento interno
Seqüência
Estrutura Implementação
Classes Distribuição
Modelo de Arquitetura do Software Colaboração
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos Análise de Casos de Uso: •Casos de uso expressam o diálogo entre os usuários e o sistema •Casos de uso expressam “o quê” o sistema deverá fazer. E não “ como” fazer. •Casos de uso formam a base para testes e documentação do sistema •O modelo de casos de uso expressam todos os casos de uso do sistema s istema e os seus relacionamentos. •As técnicas para criar e expressar casos de uso em uma aplicação Web são as mesmas para construir outros sistemas de software.
Objetivos: • • • •
Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso e Escrever cenários.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos Transformar os Requisitos Funcionais em Casos de Uso:
Calcular Total
Cliente
Fazer Cadastro Funcionário Fazer Pedido Emitir NF
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos Atividades e Passos: Fazer Diagrama de Casos de Uso Identificar Atores Atores / Casos de Uso Escrever cenários Escrever Formulário Fazer Diagrama de Caso de Uso
Rational Rose
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Introdução: Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema. sist ema. Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o entendimento do contexto dos requerimentos do sistema. Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional. O que são Caso de Uso? São diagramas de que permitem visualizar, visualizar, especificar especificar e documentar o comportamento de um elemento. Esses diagramas fazem fazem com que sistema, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem com sistema. Definição: Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma elipse. Caso de Uso
Gerenciar Reserva
Ator
Usuário
Nome
Os nomes de casos de uso são breves expressões verbais ativas.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Casos de Uso e Cenários: Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários caminhos para completar esta função. Um cenários é como uma “ instance instance ” do Caso de uso, isto é, um caminho lógico com início e fim. Principais características:
- Cenários Cenários não contém declarações declarações condicionais; condicionais; - Pode ter mesmo mesmo começo, começo, mas, com final diferente; diferente; - Um cenário é narrativa de uma situação situação e - Os cenários cenários devem descrever os bons caminhos e maus também. Exemplo: Autorização de acesso. O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a identificação do usuário, ou seja, seu nome e sua senha, O usuário informa seu nome e sua senha, o sistema valida as informações e dá a autorização de acesso ao Sistema.
Se senha for invalida ou nome neste caso teremos um novo cenário.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Casos de Uso e Fluxo de Eventos: Uso caso de uso descreve “ o quê” um sistema (ou subsistema, subsist ema, classe, ou interface) faz, ele não especifica “ como” 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 poss a entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento. Tipos de fluxos: • Fluxo de eventos principal e • Fluxo alternativo de eventos. Tipicamente descrevemos descrevemos um fluxo de eventos para um caso cas o 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 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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Casos de Uso e Formulário: Os formulários devem ter as seguinte informações: - Ponto de ativação (momento que caso de uso começa) - Nome Nome do caso caso de uso uso - Obje Objetitivo vo - Atores Atores que participam participam do caso caso de uso - Pré-co Pré-condi ndição ção - Fluxo Fluxo Normal Normal - Fluxo Fluxo Altern Alternati ativo vo - Pós-co Pós-condi ndição ção.. Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso . Exemplos: - Nome ou código código dos dos Requisitos Requisitos ( RN ) que estão associados a este caso de uso RN e RNF
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Exemplos de Casos de Uso:
Manter informações dos cursos
Manter informação de aluno
Gerente Manter informação de professor
Gerar catalogo
Pedir lista dos matriculados Sistema de cobrança
Matrícula nos Cursos Professor
Aluno Selecionar curso para ensinar
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Casos de Uso e Formulário Exemplo:
Produto 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 visitante seleciona seleciona a página página de busca 2 - O visitante visitante seleciona seleciona a categoria para busca busca 3 - O visitante visitante informar informar o produto produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa processa a busca busca 6 - Retorna Retorna as informações informações sobre o produto produto Fluxo Alternativo: 1 - O Visita Visitante nte seleciona seleciona a página de busca 2 - O visitante visitante seleciona seleciona a categoria para busca busca 3 - O visitante visitante informar informar o produto produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa processa a busca 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: ---
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Elementos dos Caso de Uso: Ator: Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham desempenham quanto interagem 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 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 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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso. Relacionamentos Organização dos Casos de Uso: Os casos de uso também podem ser organizados pela especificação de relacionamento de generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade de fatorar o comportamento comum (obtendo esse comportamento comportamento a partir de outros casos de uso que ele inclui) e fatorar variantes (obtendo esse esse comportamento em outros casos de uso que o estendem) Generalização: Entre os casos de uso é parecida à generalização existente entre as classes. No caso de uso a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça. Include: Quando você estiver se repetindo em dois ou mais caso de uso separados devemos evitar a repetição Extends: Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso. Realizes: Especifica a colaboração entre os casos de uso * Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino. Substituído pelo include.
Análise e Desenho Orientado a Objetos com UML
Requisitos
e r a w t f o Generalização: S Podemos usar a generalização entre casos de A generalização também pode ser aplicado aos e uso, pelo mesmo motivo que utilizamos atores e seus respectivos papéis. Veja o exemplo: d a nas classes, para compartilhar comportamento: i r a h n Receber Pagamento e g n generalização Funcionário E o ã ç a t i c a p a Pagto Cartão de Crédito Pagto Cartão de Débito C
Casos de Uso. Relacionamentos
Recepcionista
Gerente de Reservas
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso. Relacionamentos Extends: Podemos usa-lo para “Demonstrar Variação 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 Variação de Comportamento. Comportamento. Exemplo: Sala de Conferência
Locadora de Automóveis
Fazer Ligação
Devolver Veículo
<>
<>
<>
Alte lterar rar stat status us do carro rro
Cons Consul ultta Clie liente nte
Calcular Multa
Usuário <>
Fazer Ligação (Conference call)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso. Relacionamentos Explicando o estereotipo “include”
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base. O caso de uso incluído nunca permanece isolado, mas é apenas uma “ instance” como parte de alguma base maior que o inclui. V Você ocê pode pensar na inclusão como o caso de uso base que o obtém o comportamento a partir do fornecedor fornecedor do caso de uso. Você utiliza utiliza um relacionamento de inclusão para evitar descrever o mesmo fluxo de eventos várias vezes, vezes, incluindo o comportamento comum em um caso de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que precisamos utilizar essa funcionalidade. Exemplos: Fazer Pedido
Fazer Fazer Check Check OUT
Fazer Fazer Check Check IN <>Validar Usuário
Acompanhar Pedido <> <>
Gerenciar Reserva
<>
Receber Pagamento
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Casos de Uso Casos de Uso - Identificação de Atores
Os atores não fazem fazem parte do sistema - eles representam qualquer um um e qualquer coisa que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc. Uma ator pode:
- Apenas Apenas fornecer fornecer informações informações ao sistema - Apenas Apenas receber informaç informações ões do sistema - Fornecer Fornecer e receber receber informações informações ao sistema 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 sistema será usado usado ? - Quais áreas áreas serão usuárias usuárias do sistema sistema ? - O sistema sistema usará recurso recurso externo externo ? - Quem será o responsá responsável vel pelo sistema sistema ? - Quem serão serão os usuários usuários do sistema sistema ?
Análise e Desenho Orientado a Objetos com UML
Requisitos
e r a w t f o S Um engano comum na identificação de casos de uso é representar como Caso de uso e passos individuais, operações ou transações. d a i r Exemplo: a ponto de venda, alguém alguém pode definir um caso de uso chamado h No domínio de ponto n “Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo e g no processo muito mais abrangente do caso de uso Comprar Itens n E o Lembre-se: ã ç a Um caso de uso é uma descrição completa de processo, t i c que inclui outros passos ou transações. a p a C
Casos de Uso.Dicas
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as seguintes propriedades: - Número, preços preços base, capacidade capacidade de pessoas - Tipo (Single, (Single, double, triplo ou suite) O preço de cada apartamento está relacionado com seu tipo e sazonalidades sazonalidades (períodos especiais, tais como: férias, natal, carnaval...) Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de reserva do Hotel .
1
2 Refinado pelo
Requisitos Funcionais • Gerenciar Reserva •...
Documento de Visão „
Documento de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Especificação de Requisitos: 3 Formulário
Cenários
Gerenciar Reserva
Usuário Ator
Caso de Uso Associação
Caso de Uso: Gerenciar Reserva
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Escrevendo os Cenários: Cenário 1: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, Reserva, verifica a disponibilidade do apartamento apartamento e confirma a reserva.
Cenários
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 apartamento para o período informado pelo cliente e oferece um outro tipo de apartamento. O cliente aceita o apartamento e então o funcionário confirma a reserva. Cenário 2: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que s olicita 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 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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Escrevendo o Formulário: Compilar os Cenários em Formulário:
Cenários
Formulário
Identificando a pré-condição e pós-condição: Cenário Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento Pré Pré- condiç condição ão ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva. Pós Pós- condiç condição ão
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Escrevendo o Formulário: Compilar os Cenários em Formulário: Primeiras linhas do cenário
“caminho feliz”
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:
Gerenciar Reserva
Fluxo Alternativo:
Gerenciar Reserva
“caminho alternativo”
Pós-condição: Reserva confirmada
Última linha do cenário
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Escrevendo o Formulário de Descrição de Caso de Uso: Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o período (data de chegada e partida) O funcionário do Hotel verifica a disponibilidade do apartamento O funcionário confirma a reserva
Fluxo Alternativo: ... O funcionário do Hotel verifica a disponibilidade do apartamento O funcionário faz proposta de outro apartamento para cliente O cliente aceita e então o funcionário confirma a reserva
Pós-condição: Reserva confirmada
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exemplo: Especificação de Requisitos: 3 Formulário
Cenários
Funcionário Ator
Gerenciar Reserva
Associação
Caso de Uso: Gerenciar Reserva
Caso de Uso
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Mitos e Lendas • Requisitos não são Casos de Uso; • Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo: Caso de Uso Fazer Busca, está associado a dois requisitos: • (RF) Fazer Buscar • (RNF) O tempo de resposta para transação deve ser 10 segundos (Desempenho)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Exercício: Especificação de Requisitos, como fazer:
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique também os ATORES e seus respectivos PAPÉIS; PAPÉIS; 3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único no modelo; 4 - Escreva Escreva os CENÁRIOS CENÁRIOS para o CASO CASO DE USO; 5 - Compile Compile os CENÁRIOS CENÁRIOS em único FORMULÁR FORMULÁRIO IO e 6 - Faça o Diagrama Diagrama de Caso de de Uso.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Especificação de Requisitos. Template: Template do “Formulário”: Data: ______ | Autor: ________ | Revisão: ____ Nome: Ponto de ativação: Ator: Objetivo: Pré-condição: Fluxo Normal:
Fluxo Alternativo:
Pós-condição: RF: RNF:
Rastreabilidade
Análise e Desenho Orientado a Objetos com UML
Requisitos e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos
Requisitos. Road Map Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Validação de Requisito Requisitoss 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. Validade. O sistema fornece as funções que melhor atende as necessidades necessi dades do usuário? Consistência. Consistência. Existem conflitos de requisitos? Todas as funções necessárias para o cliente estão incluídas? Completeza. Completeza. Todas Realismo. Realismo. Os requisitos podem ser implementados i mplementados com a tecnologia e orçamento disponíveis? Facilidade de verificação. verificação . Os requisitos podem ser checados?
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Validação de Requisito Requisitoss Técnicas de validação de requisitos Revisão de requisitos: - Análise manual manual sistemática sistemática dos requisitos 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 consistência do modelo.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos
Validação de Requisito Requisitoss Técnicas de validação de requisitos Revisão de requisitos: - Revisões regulares devem ocorrer durante a formulação da definição dos requisitos - Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões - As revisões podem podem ser formais (com documentos 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”. “Verificabilidade”. O requisito é realisticamente testável? - Compreensibilidade. O requisito é propriamente propriamente entendido? entendido? - Rastreabilidade. A origem do requisito é claramente estabelecida? - Adaptabilid Adaptabilidade. ade. O requisito requisito pode pode ser modificado modificado sem grande grande impacto sobre sobre outros requisitos?
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Requisitos Formato do documento de especificação especificação de requisitos sugerido pela IEEE/ANSI 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 dados,restrições de projeto, características de qualidade. 4. Apêndices 5. índice
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Big Picture.
Requisitos e Análise
Business Case
Coleta de Requisitos
Análise Conceitual Modelo Conceitual
Documento de Visão
Engenharia de Requisitos 4
Análise de Requisitos
Especificação de Requisitos (Visão de Caso de Uso)
Requisitos Funcionais
Glossário de conceitos
Casos de Uso
Requisitos Não Funcionais
Arquitetura Inicial
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Analise Analis e
Analise Workflow
Arquitetura
Artefatos
Papéis
Modelo Conceitual ou Modelo de Domínio
Vocabulário do Sistema Sistem a
Modelo de Arquitetura Inicial
Analista de Sistema Analista de Requisitos Arquiteto de Software
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Introdução: Modelo de Casos de Uso de software é elaborado para dar a Visão de Caso de Uso. Esta visão fornece uma perspectiva do software a partir de um ponto de vista externo. Os aspectos dinâmicos descrevem a troca de mensagens entre os objetos e a sua reação a eventos que ocorrem no software. O aspecto dinâmico será apresentado na terceira parte, no workflow de Projetos. Visão de Funcionalidade Projeto
Visão da Implementação
Vocabulário
Funcionário
Gerenciar Reserva
Visão do
Desempenho Processo Escalabilidade Throughput
Codificação Montagem
Visão de Caso de Uso Visão da Implantação
Topologia do Sistema Distribuição Instalação
O aspecto estrutural estático permite entender como uma software está estruturado internamente para atender os requisitos (visão externa). Esse aspecto é chamado de estático porque não apresenta informações sobre como os objetos se comportam no ciclo de vida de software e também porque representa a estrutura das classes de objetos e os relacionamentos entre elas.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise
Objetivo: Apresentar e discutir como elaborar o Modelo Conceitual 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 Elaborar o Modelo Conceitua Conceituall ou modelo de domínio domínio e 3 - Elaborar Elaborar o Vocabulá Vocabulário rio de Conceitos. Conceitos.
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise Atividades.Road Map
e r a w t f o S e d a i r a h Caso de Uso n e g n E o ã ç Documento de a t Visão i c a p a C
Fazer Análise Conceitual Modelo Conceitual
Fazer Vocabulário Vocabulário
Definir o modelo de Arquitetura Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Atividades e Artefatos: Para este este workflow workflow as principais principais atividad atividades es e artefatos 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise Conceitual. Introdução: “Modelo Conceitual. É o artefato mais importante da Análise Orientada a Objetos”
O modelo representa conceitos relevantes (do ponto de vista do modelador) do domínio do negócio. Este conceitos também são 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 Caso de Uso Uso - Digrama Digrama de Classes Classes (na verdade verdade o Modelo Modelo Conceitual). Conceitual). Os objetivos são: 1 - Apresentar Apresentar técnicas técnicas para identificaçã identificaçãoo dos candidatos candidatos a classe classes, classes, atributos atributos e associações e 2 - Elaborar Elaborar o Modelo Conceitua Conceituall ou Modelo de Domínio. Domínio.
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise
e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i de c Documento a Visão p a C
Atividade: Fazer Análise Conceitual
Fazer Análise Conceitual Modelo Conceitual
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise Conceitual. Modelos: O modelo de classe têm pelo três níveis de abstração: - Modelo Conceitual de Classes: Representa Representa as classes no domínio do do desenvolvimento do software, este modelo m odelo 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 de Especificação: É derivado do Modelo Conceitual. Com 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 e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise Conceitual. Modelos - Modelo de Classes de de Implementação: É derivado do do modelo de especificação e corresponde a implementação das classes em alguma linguagem de programação, como Java, C#, C++ por exemplo. O modelo de implementação é construído na Fase Construção. Workflow de Análise
Workflow de Projeto
Pessoa
Pessoa nome idade
Modelo Conceitual ou Modelo de Domínio
-nome -idade
<>
+setNome() +getNome() +getIdade() +getIdade()
Modelo de Especificação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise Conceitual. Atividades e Passos: Fazer Análise Conceitual Identificar os candidatos a classe Selecionar uma técnica Fazer a Lista de Candidatos Desenhar o Modelo Conceitual Definir a Arquitetura Inicial
4
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise Análise Conceitual. Identificação das Classes:
e r a w t f o S Um software orientado a objetos é composto de uma coleção de objetos que colaboram e para realizar seus requisitos. Entretanto, sabemos que os objetos são “instances” das d classes. a i r Para identificar as classes, podemos usar um método simples. O primeiro passo é fazer a uma lista de todas todas classes que encontramos, encontramos, esta lista pode ser chamada de “Lista de h n Classes Candidatas”. e E depois usando algum critério, eliminamos as classes irrelevantes e aí teremos uma lista g n definitiva. Existem dois métodos principais para realizar a identificação das classes de E domínio de um software: o ã - Método Método dirigido dirigido a dados: dados: ç a Neste método, a ênfase está na identificação da estrutura dos conceitos t i relevantes para o domínio do negócio, resultando em Modelo Conceitual. c a p a - Método Método dirigido a responsab responsabilidade ilidades: s: C 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 e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise
UML. Introdução A UML deve ser utilizada para criarmos o Modelo Conceitual. Os modelos visuais ajudam a compreender melhor o sistema que estamos construindo. As seguir será apresentado os nós, elementos e adornos usados para construir o modelo.
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise
e r a w t f o O Diagrama de Classes Cl asses nasce no Workflow de Análise com Modelo Conceitual (modelo de S e domínio), mais tarde no Workflow de Projeto este o modelo será refinado ganhando d adornos, novos tipos de relacionamentos, operações (métodos) e até novas classes. a i r a h Agora faremos apenas apenas o Modelo Conceitual que podemos considerar como o primeiro n e “esboço ” do que mais tarde se tornará o Diagrama de Classes. g n E o ã ç a t i c a p a C
Diagrama de Classes. Introdução
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise UML. Elementos: Elementos estruturais: Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e Componente Elementos de agrupamento: Pacote e Subsistema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise UML. Elementos: • •
Dependência Associação – Associação – Composição – Agregação
•
Generalização
Mecanismos de Extensibilidade:
• • •
Estereótipo “Tagged va value” Restrição (Constraint)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Diagrama de Classes
O diagrama de classes deve capturar capturar o Vocabu Vocabulário* lário* do sistema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Associação Definição de Associação: Um relacionamento estrutural que descreve um conjunto de vínculos, em que o vínculo é uma conexão entre objetos; relacionamento semântico entre dois ou mais classificadores que envolve as conexões entre seus objetos.
Associação classe
classe
Usuario
Senha
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Associação Nome de Associação: Uma associação pode ter um nome, que pode usado para descrever a natureza do relacionamento. Podemos ainda acrescentar um triângulo para demonstrar a direção do nome, ou seja, a direção que nome deve ser lido. Nome da associação Direção do nome
Cliente
faz
Pedido
Observação: Apesar da possibilidade de a associação ter um nome, não é necessário incluí-lo. Recomendamos o uso do nome quando o modelo possui muitas associações e você tem a necessidade de fazer referência às associações ou de destaca-las.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Associação Navegação: Indica qual é a direção da associação. A direção da associação pode ser unidirecional unidireci onal (onde somente uma das pontas da linha de associação tenha a seta) ou bidireciona (não existem setas em nenhum dos lados)
Associação Navegação
Cliente
Pedido
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Role Name: Definição de Role Name: É um identificador (nome) do papel da associação, podendo cada ponta ter um nome especifico.
Modificadores: (+) public | (-) private | (#) protected
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Multiplicidade Definição: A especificação de uma faixa de números cardinais, que um conjunto pode assumir.
Eqüivale a muitos Multiplicidade
Faixa Válida: 0....1 | 0..* | * | 1 | 1..*
O que é uma multiplicidade ? Uma associação representa um relacionamento entre dois objetos. Em algumas situações de modelagem, é importante especificar a quantidade de objetos que podem ser conectados pela “instance” de uma associação. Essa “quantidade” é chamada de multiplicidade do papel de uma associação e é escrita escr ita como uma expressão equivalente a um intervalo de valores ou de uma valor explícito.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Role Name e Multiplicidade Exemplo:
Multiplicidade Para cada objeto (instance) da classe Pessoa a classe Empresa poder ter uma ou muitos objetos.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise
Análise Conceitual. Técnicas:
Abbot
UML
Kent Beck
Inspeção Gramatical
CRC Scott Ambler Graig Larman Peter Coad
Outras Técnicas
Análise de Caso de Uso
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Introdução: A primeira etapa na construção do Modelo Conceitual é identificar os conceitos 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, simplici dade, 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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Lista de Candidatos:
Conhecimento do Negócio Declaração de Visão
Identificação dos candidatos a classe, associações e atributos
1º Lista
Interações
Lista Final
Fazer revisão da lista: Eliminar conceitos os repetidos, ambíguo, irrelevantes e etc..
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Artefatos:
Modelo Conceitual
Lista de Candidatos
4
Vocabulário de Conceitos Co nceitos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical
Nome da associação Reserva
1..*
numero data-entrada data-saida Atributo
Classe feita por
1
Cliente
id hospede nome documento
0..*
Multiplicidade Apartamento 1..*
numero tipo situacao
Associação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Conceitual. Técnica: Técnica: Inspeção Inspeção Gramatical Gramatical - Exemplo Exemplo Declaração do Problema: O cliente solicitou o desenvolvimento de software para apoiar uma rede bancária computadorizada incluindo computadorizada incluindo caixas humanos e máquinas de auto atendimento (ATM) (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 c omputadores de seus bancos proprietários. Os caixas humanos 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 comunica-se com o sistema central central para executar executar transações, entrega 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 ATM e para a rede. O custo do sistema compartilhado deve ser distribuído pelos bancos de acordo com número transações realizadas.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando do Domínio: (Técnica usada: extração dos substantivos do enunciado do problema)
Fazer transações eletrônica através de caixa de Auto atendimento e caixas
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando os conceitos: (Técnica usada: extração dos substantivos do enunciado do problema) Software
Rede Bancária
Caixa
ATM
Consórcio
Banco
Computador do Banco
Conta
Transação
Terminal do do ca c aixa
Dados de de co c ontas
Dados de de tr t ransações
Computador Ce Central
Cartão Ma M agnético
Usuário
Dinheiro
Extrato
Sistema
Manutenção do Reserva de segurança arquiv arquivoo de Regist Registro ro Preço
Acesso
Cliente
Classes da ATM originadas do conhecimento do do domínio do problema Linha de Comunicação
Registro de transa nsação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando os conceitos: (Técnica usada: extração dos substantivos do enunciado do problema) Após a revisão identificamos o seguinte: Conceitos vagos: Sistema, Reserva de Segurança, Manutenção do arquivo de Registro e Rede Bancária Atributos: Dados de contas, extrato, dinheiro e dados de transações Conceito redundante: Usuário Conceito Irrelevante: Preço Conceito de implementação: Registro de Transação, Acesso, Software e Linha de Comunicação Eliminado às classes apontadas, ficamos com as seguintes conceitos válidos: Conta, ATM, 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 UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações: Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência de uma classe a outra é uma associação. As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais. Isso inclui localização física: - junto a, a, parte de, de, contido 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, real, ou seja, do negócio. negócio. Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e depois refine-as.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações: Lista (Frases (Frases verbais): verbais): Rede de bancária inclui caixas e ATM 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 comunica-s e com o computador c omputador 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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações:
Lista (Frases (Frases verbais): 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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação dos conceitos dos atributos: Os atributos são propriedades de objetos individuais, como nome, peso, altura, velocidade, cor e etc. Os atributos não devem ser objetos; utilize uma associação para demonstrar qualquer relacionamento entre dois objetos. Os atributos geralmente 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação dos conceitos dos atributos: Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade é derivado de data de nascimento e data atual (que é uma propriedade do ambiente). Os atributos derivados como os objetos e associação derivadas podem ser úteis na abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos derivados não devem ser expressos como operações, como obter-idade , embora possam eventualmente ser implementados como tais. Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma propriedade da ligação entre dois objetos e não a propriedade de um objeto isoladamente. Por exemplo: a associação muitos-para-muitos entre 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação dos conceitos dos atributos: Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade é derivado de data de nascimento e data atual (que é uma propriedade do ambiente). Os atributos derivados como os objetos e associação derivadas podem ser úteis na abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos derivados não devem ser expressos como operações, como obter-idade , embora possam eventualmente ser implementados como tais. Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma propriedade da ligação entre dois objetos e não a propriedade de um objeto isoladamente. Por exemplo: a associação muitos-para-muitos entre 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Modelo Conceitual vs Modelo de Especificação
Workflow de Análise
Transacao Datahora
Workflow de d e Projeto
Transacao Datahora:Timestamp +getTransacao() +setDataHora() +getDataHora()
Conceito de classes e atributos
Classes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Modelo Conceitual:
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise CRC Método dirigido a responsabilidades: Neste método, a ênfase está na identificação das classes a partir de seus comportamentos relevante ao sistema. Técnica Cartão (CRC): O CRC foi apresentado por Kent Beck e Ward Cunningham em artigo chamado: "A Laboratory for Teaching Object-Oriented Thinking" no OOPLSA '89. Conceito e Aplicação: CRC (Cartão Responsabilidade e Colaboração) é um cartão índice que é usado para representar as responsabilidades das classes e suas interações com outras classes. O cartão CRC é uma abordagem informal da modelo de orientação a objetos. Os cartões são criados através de cenários, baseado nos Requisitos, 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise 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 colaboração de outros objetos do software para cumprir com sua responsabilidade.
Objeto Responsabilidades: (o que objeto conhece e o que faz)
+
Colaborações: (outras classes que são associadas, para a interação entre os objetos)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise CRC. Elementos: O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que que a classe dever saber fazer e coisas que ela deve conhecer. conhecer. As colaborações as informações que a classe precisa e que está alocada em outra outra classe, desta forma temos que fazer o relacionamento entre classes, para que ela cumpra com sua responsabilidade. Modelo:
Nome da Classe Responsabilidades:
Colaborações:
Lista das responsabilidades responsabilidades
Lista de colaborações
Melhores Práticas: Os candidatos a classe cujo c ujo a responsabilidade não foi encontrada, este candidato c andidato deve ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise CRC. Exemplos: Classe: Reserva Responsabilidades: Conhecer o período da reserva (datas) Saber o nome do cliente Saber o número do apartamento
Colaborações: Apartamento Cliente
Classe: Cliente Responsabilidades:
Colaborações:
Saber o nome do cliente Saber a Reserva do Cliente
Reserva
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical & CRC Inspeção Gramatical Lista de Candidatos
CRC
UML
Classe: Cliente Responsabilidades:
Colaborações:
SaberClasse: o nomeCliente do clienteReserva Saber a Reserva do Cliente Responsabilidades: Colaborações: Saber o nome do clienteReserva Saber a Reserva Classe: Clientedo Cliente Responsabilidades:
Colaborações:
Saber o nome do clienteReserva Saber a Reserva do Cliente
Identificação dos candidatos
Identificação das Responsabilidade
Modelo Conceitual
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise 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 de Requisitos Funcionais. Nesta análise é identificado identificado os candidatos a classe.
Formulário
Cenários
Gerenciar Reserva
Usuário Ator
Caso de Uso Associação
Listas de Candidatos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise de Caso de Uso. Big Picture Documento de Visão
4
Lista de Candidatos
1
Engenharia de Requisitos Análise de Requisitos Lista de Requisitos Funcionais
Especificação Especificação de Requisitos (Visão de Caso de Uso)
3
Formulário
2
Cenários Casos de Uso Lista de Requisitos Não Funcionais Ator
Usuário
Gerenciar Reservas Associação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise de Caso de Uso: Identificando os candidatos a classe Como fazer. Diagrama: 1 - Verifique os nome dos Casos de Uso, eles geralmente contêm bons candidatos.
Usuário
Gerenciar Reserva
Reserva é provável candidato a classe
<>
Buscar Apartamento
Atualizar Atualizar Reserva Reserva
<>
Funcionário Criar Criar Reserva Reserva
Remover Remover Reserva Reserva
Cadastrar Cadastrar Cliente Cliente
prováveis candidatos a classe
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise de Caso de Uso: Identificando os candidatos a classe Como fazer. Cenários: 2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos, substantivos, exemplo: Cenários: Gerenciar de Reserva:
Cenários
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartament apartamentos os para data. data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário funcionário do Setor de Reserva, Reserva, verifica verifica a disponibilid disponibilidade ade do apartamento apartamento e informa que não tem disponibilida disponibilidade de de apartamento apartamento para o período informado 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. confirmada.
Prováveis candidatos a classe
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Análise de Caso de Uso: Atividades Como fazer. Formulário: 3 - Os Formulários também devem usados para para identificação dos candidatos. candidatos. Ache os substantivos, exemplo:
Formulários
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 disponibilidade do apartamento O funcionário confirma a reserva
Fluxo Alternativo: ... O funcionário do Hotel verifica a disponibilidade disponibilidade do apartamento O funcionário faz proposta de outro apartamento para cliente O cliente aceita e então o funcionário confirma a reserva
Pós-condição: Reserva confirmada
Prováveis candidatos a classe
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical & CRC Análise de Caso de Uso Lista de Candidatos
CRC
UML
Classe: Cliente Responsabilidades:Colaborações: Saber o nome do cliente Reserva Classe: Cliente Saber a Reserva do Cliente Responsabilidades:Colaborações: Saber o nome do cliente Reserva Classe: Clientedo Cliente Saber a Reserva Responsabilidades:Colaborações: Saber o nome do cliente Reserva Saber a Reserva do Cliente
Identificação dos candidatos
Identificação das Responsabilidade
Modelo Conceitual
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Dicas: Scott Ambler Para encontrar as classes, vejamos algumas dicas: 1 - Considere que as classes são lugares, eventos, conceitos, pessoas e etc. etc. 2 - Atores Atores são classes classes em potencial; potencial; 3 - Identifique Identifique os clientes; clientes; 4 - Siga o dinheiro, dinheiro, podemos identificar identificar produtos, serviços, eventos como venda, venda, compra e etc; 5 - Conceitos Conceitos são classes classes em potencia potencial; l; 6 - Eventos Eventos são classes classes em potencia potenciall e 7 - Entende Entende o negócio. negócio. Use a técnica técnica CRC para atribuir ou descobrir as responsabilidades responsabilidades e colaborações das classes encontradas
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise 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 C asos 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 caso de de uso começa quando quando um Cliente Cliente chega a um ponto ponto de venda venda e deseja deseja comprar alguns itens. 2 - O Caixa Caixa registr registraa o códig códigoo do produt produtoo de cada cada item item ... Entretanto esta técnica exige uma ou mais revisão nos conceitos encontrados, pois, diferentes substantivos podem representar o mesmo conceito.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Graig Larman Larman também sugere usar uma abordagem de Categoria de Conceitos, que nada mais é que uma lista de categorias. Após determinar lista use-a para identificar os conceitos. Exemplo de lista: Categoria
Exemplos
Objeto físico ou tangível
Terminal de ponto-de-venda Avião
Espe Es peci cififica caçã ção, o, pr proj ojet eto, o, ou ou descr descriç ição ão de de cois coisas as
Especi Espe cififica caçã çãoo de pro produ duto to Descrição de vôo
L u g a re s
L o ja Aeroporto
Transações
Venda, Pagamento Reserva
Itens de transação
Itens de venda Parcelas de pagamento
Papéis de pessoas
Operador Piloto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise 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 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar c omprar.. 2. O Operador registra Operador registra o identi-ficador de cada item. item. Se há mais de um do mesmo item, item, o Operador tam também bém pod podee inf inform ormar ar a quantidade. quantidade.
Resposta do Sistema
3. De Dete term rmin inaa o preç preçoo do item item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Peter Coad A Proposta de Coad & Yourdon: O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon Yourdon e denominado OOA (Object Oriented Analysis ), ), consiste basicamente em cinco passos: 1 - Localização Localização de de classes-&-objet classes-&-objetos: os: entende-se entende-se por por objetos como a abstração abstração de alguma alguma coisa, em um domínio de problema, cujas informações devam ser s er manipuladas pelo sistema. Uma classe corresponde ao conjunto de objetos semelhantes. 2 - Identificaçã Identificaçãoo de estrutur estruturas: as: que podem podem ser classificad classificadas as em: Generalização-especialização : quando uma classe é\ um tipo tipo de uma de uma outra classe. Exemplo: a classe carro é carro é uma especialização da classe veículos ;
Todo-parte : quando uma classe é formada por outras por outras classes. Exemplo: as classes motor e motor e chassis fazem parte da classe carro .
3 - Definição Definição de assuntos assuntos:: onde cada cada qual se relaciona relaciona a diferentes diferentes partes partes do modelo, permitindo minimizar a complexidade de projetos extensos.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Dicas: Peter Coad A Proposta de Coad & Yourdon 4 - Definição Definição de atributos: atributos: um atributo atributo é definido como como uma propriedade, propriedade, uma qualidade 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 class e 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 ocorrência representa relacionamentos entre objetos. 5 - Definição Definição de Serviços: Serviços: um serviço é um comportame comportamento nto específico específico que que um objeto deve exibir. 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, i ncluir, 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.
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise
e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i de c Documento a Visão p a C
Vocabulário.Road ocabulário.Road Map:
Fazer Análise Conceitual Modelo Conceitual
Fazer Vocabulário ocabul ário Vocabulário
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise Vocabulário:
e r a w t f o S Fazer Vocabulário e d a i r Descrever os conceitos a h n Fazer Vocabulário: e g Devemos fazer um Vocabulário de todas as classes presente pres ente no Modelo Conceitual. n O vocabulário consiste em simples descrição do conceito. E o Transacao ã ç a t i Datahora c a Transação – Uma única solicitação integral para operações nas p a contas de um único cliente. Especificamente somente que as ATM C podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também Também queremos prover a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As As diferentes operações devem fechar apropriadamente.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Modelo Conceitual.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: ATM – Uma estação que permite os clientes introduzem suas próprias transações utilizando cartões magnéticos como identificação. A ATM interage com o cliente para obter informações sobre transações, envia as informações sobre transações para o computador central para validação e processamento e entrega de dinheiro ao usuário. Presumimos que uma ATM 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. 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: Cartão Magnético – Cartão vinculado a um cliente do banco que autoriza o acesso às contas utilizando uma máquina ATM. 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 padrões definidos pelo pelo Bacen (Banco Central) sobre cartões de créditos e cartões magnéticos. O código do banco identifica inequivocamente i nequivocamente 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: Computador operado operado pelo consórcio consórcio que despacha despacha transações transações entre entre as ATM ATM e Computador Central - Computador os computadores dos bancos. O computador central valida códigos de bancos mas não processam transações diretamente. ATM. A rede só manipula Consórcio – Organização de bancos que comissiona e opera a rede ATM. transações do consórcio. Conta – Única conta no banco contra a qual as transações 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 ATM podem entregar dinheiro, mas não podemos eliminar a possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Diagrama de Objetos Introdução: Bem o última coisa a fazer neste Workflow é fazer a validação do Diagrama de Classes. Podemos fazer esta validação utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma estaremos garantindo que o Diagrama de Classes feito atende os requisitos. Diagrama de Objetos, é diagrama estrutural, que demonstra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo. Sua principal aplicação é ilustrar as estruturas de dados, registro estáticos estát icos das “instances” dos itens encontrados no diagrama de classe. O diagrama de objetos direcionam a visão estática do projeto ou de processo de um sistema. O Diagrama de Objetos também podem conter pacotes ou subsistemas, notas e restrições. Exemplo da notação: :Nome do Objeto Atributo: Valor do atributo objeto
Nome do Objeto Atributo: Valor do atributo
vínculo
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise Diagrama de Objetos
e r a w t f Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes. o S Exemplo: e d a i r Diagrama de Classe Diagrama de Objetos a h Aluno :Aluno n e Nome: “Fulano de Tal” -Nome: String Nome da g -Data: Date Data: 23-02-2001 associação n Nome do E objeto “Instance” objeto o ã Matricula 201-23-02-01:Matricula ç a -Matricula: int Matricula: 201-23-02-01 t vinculo i -Curso: String Curso: Adm Empresas c a Atributo Valor do atributo p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Diagrama de Objetos Conteúdo do Diagrama de Objetos: Objetos e Vinculo Diagrama de Objetos objeto
:Aluno Nome: “Fulano de Tal” Data: 23-02-2001
201-23-02-01:Matricula Matricula: 201-23-02-01 Curso: Adm Empresas
vínculo 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de de Análise Diagrama de Objetos Como fazer a modelagem de um estrutura de objetos: Como posso validar o diagrama de classes?
Um mecanismo • Identifique o mecanismo cuja modelagem você deseja fazer. Um 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 c ada 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.
Análise e Desenho Orientado a Objetos com UML
Workflow orkflo w de de Análise Arquitetura Inicial.Road Map
e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i de c Documento a Visão p a C
Fazer Análise Conceitual Modelo Conceitual
Fazer Vocabulário Vocabulário
Definir o modelo de Arquitetura Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflo w de Análise Anális e Modelo de Inicial de Arquitetura Definir o Modelo de Arquitetura Definir o Modelo de Arquitetura Inicial
Podemos criar um Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar um visão macro da arquitetura. Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o modelo. Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este modelo ou qualquer outra notação. Este modelo será refinado no workflow de projeto na Atividade “Fazer o Modelo de Arquitetura”.
Camada apresentação 4
Camada de serviço (controle)
Camada regra de negócio
Diagrama de Deployment
Banco de Dados
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Apêndice Diagrama de Pacotes Como podemos definir o diagrama de pacotes? A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem ser usados para fazer decomposição funcional. A nota notaçã çãoo usad usadaa pela ela UML UML para ara rep represe resenntar tar paco pacote tess é:
Nome do Pacote
Nome do Pacote
Nome do Pacote Nome do Pacote
Dependência (import)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Apêndice Diagrama de Pacotes Decomposição. “Dividir para conquistar...” conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito mui to 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 si mplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:
Contas a Pagar
Fluxo de Caixa Nome do Pacote
Subsistema
Contas a Receber
Dependência (import)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Desenho (design (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 UML
Workflow de Projeto Objetivo:
e r a w t f o Apresentar e discutir o Workflow de Projeto, também conhecida como “Fase de S Especificação”, agora faremos faremos uso da intenso da UML para fazer os modelos (diagramas) e e a documentação. d a i r As principais atividades são: a Construção do Modelo de Especificaçã Especificaçãoo (Projeto) (Projeto) h - Construção n - Construção Construção do Modelo de Arquitetura Arquitetura e g - Fazer validaç validação ão do modelo. modelo. n E o ã ç a t i c a p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Introdução. UML, Visões:
Visão de Projeto
Visão da Implementação Codificação Montagem
Funcionalidade Vocabulário
Visão de Caso de Uso Visão do Visão da Processo Implantação Desempenho Escalabilidade Throughput Conceitual
Topologia do Sistema Distribuição Instalação Físico
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto Introdução. UML, Visões:
e r a w t f o Visão de Projeto S e • A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do d a problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os i r a requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários h n finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de e g objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de n atividades. E o ã Visão de Processo ç a t i • A visão do processo abrange os “threads” e os processos que formam os mecanismos mecanismos de c a concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões p a de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos C
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 threads e processos.
Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser programas ou parte.
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto Introdução. Aspecto Aspecto estático e dinâmico:
e r a w t f o O Workflow de Análise é determinado pelo “aspecto estrutural estático ”, ”, que permite S entender como uma software está estruturado internamente para atender os requisitos. e d a Esse aspecto é chamado de estático porque não apresenta informações sobre como os i r objetos se comportam no ciclo de vida de software e também porque representa a estrutura a h das classes de objetos e os relacionamentos entre elas. n e g No Workflow de Projeto, Projeto, faremos a modelagem dos aspectos dinâmicos do sistema , estes n aspectos são capturados em digramas (diagrama de interação, diagrama de estados e E o diagrama de atividades). ã E assim podemos representar os comportamentos internos e desta forma teremos novas ç a visões do software e aí conseguiremos compreender melhor o software. t i c a p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Introdução. Aspecto Aspecto estático e dinâmico: UML. Principais Diagramas: Modela a estrutura do sistema
ESTÁTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuição
Workflow de Análise
Modela o comportamento do sistema
DINÂMICOS . Diagrama de Casos de Uso . Diagramas de Interação - Diagram Diagramaa de Seqüênci Seqüênciaa - Diagram Diagramaa de Colaboraçã Colaboraçãoo . Diagrama de Atividade . Diagrama de Estados Workflow de Projeto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Introdução A Workflow de Projeto depende da Workflow de Análise:
Workflow de Análise
Análise dependência
Workflow de Projeto
Projeto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Introdução A Workflow de Projeto refina a Workflow de Análise: Workflow de Análise
Workflow de Projeto
modelo conceitual
Diagrama de Classes
Cliente codigo nome
Cliente <>
Atributos: Visibilidade
Atributos: Tipo de dados
-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() métodos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Big Picture. Projeto Projeto (Visão Lógica)
Análise Modelo Conceitual
Diagrama de Classes
4
ReceberPedido
4
PreencherPedido
EnviarFatura
Entrega [pedido urgent e]
[s enão] ReceberPagamento
Especificação de Requisitos (Visão de Caso de Uso)
Entregadurante a noite
: visitante
: FormBusca
: Ca et go ri a
: Pr Pr od ut o
EntregaRegular
: Ca Ca at ol go
getDescricao() exibirCategoria() selecionarCategoria
exibirProduto()
selecionarProduto()
getDescricao()
getQuantidade()
EncerrarPedido
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto
Arquitetura Workflow
Arquitetura
Artefatos
Papéis
Diagrama de Seqüência / Colaboração Analista de Sistema Projetista de Software
Diagrama de Atividades
Diagrama de Estados
Diagrama de Classes
Arquiteto de Software
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto Atividades.Road Map
e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i Modelo c conceitual a p a C
Fazer Modelo de Especificação Modelo de Especificação
Fazer Modelo de Arquitetura Modelo de Arquietura
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Projeto. Atividades e Passos: Fazer Modelo Especificação Identificar as classes de Especificação Fazer Diagrama de Interação Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes Modelo de Especificação
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
e r a w t f o Uso caso de uso descreve “o quê” um sistema faz, ele não especifica “ como” isso é feito. S Ao fazer uma modelagem, importante manter clara cl ara a separação de questões entre a visão e d interna e externa. “O como” é modelado pelo Diagrama de Interação. a i r a h n <> “O quê” e g selecionar categoria n E “O como” buscar produtos o Diagrama de Sequência visitante ã ç a Diagrama de Estado t i c a p a C
Casos de Uso. Revisão
: visitante
: FormBusca
: Cat egori a
: P rodut o
: Catalogo
getDescricao( )
exibirCategoria( )
selecionarCategoria
exibirProduto( exibirProduto( )
Formulário
selecionarProduto( selecionarProduto( )
getDescricao( )
getQuantidade( )
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
e r a w t f o Diagrama de Interação são modelos que descrevem como grupos de objetos objetos colaboram S e para atender comportamento. d Tipicamente, um diagrama de interação captura o comportamento de um único caso de a i r uso. O diagrama deve mostrar os vários v ários objetos e as mensagens que são passadas entre a h estes objetos. n e g n Existem dois tipos de diagramas: E o ã • Diagrama de Seqüência: ç a O foco deste diagrama é maneira que as mensagens m ensagens são enviadas ao longo do tempo. t i c • Diagrama de Colaboração: a p Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então a considerar como as mensagens são passadas no contexto dessa estrutura. C
Diagrama de Interação. Introdução
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação O que é Diagramas de Seqüência? É um diagrama que exibe a colaboração dinâmica entre objetos de um sistema. O principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos e os eventos que acontecem em um ponto específico da execução do sistema. Notação: Diagrama de Seqüência :Objeto 1 Ator:
1: mensagem 1 2: mensagem 2
3: mensagem 3
:Objeto 2
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação Diagramas de Seqüência:
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação Diagramas de Seqüência: formulários de registro
formulário de matrícula
entrar com senha de acesso validar acesso Aluno: entrar com o semestre
criar nova matrícula apresentar em tela obter cursos
cursos disponíveis
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação Diagramas de Seqüência. Elementos: Instance das classes ator
: Atendente
: Client e
: Veic ulo
: Loc ac ao
getDadosCliente( )
[* se cliente cadastrado verificar divida ] getDivida( )
getDisponibilidade( )
setSaida( ) [* se veículo disponível ]
Autodelegação
Linha do tempo
As interações entre os objetos
Restrição ou condição
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação Diagramas de Seqüência. Numerando as seqüências das mensagens.
: visitante
: FormBusca
: Categoria
: P roduto
: Catalogo
1: getDescricao( ) 2: exibirCategoria( ) 3: s elecionarCategoria elecionarCategoria
4: getDescricao( ) 5: getQuantidade( )
6: exibirProduto( )
7: selecionarProduto( )
Este diagrama descreve em ordem cronológica as mensagens entre os objetos.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Interação O que é Diagrama de Colaboração? É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante semel hante ao diagrama de seqüência. No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também as colaborações dos objetos. A interação de mensagens é mostrada em ambos os diagramas. Diagrama de Colaboração tem a maioria de suas características semelhantes ao Diagrama de Seqüência. Quando usar o diagrama de Colaboração ? Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência, seqüência, mas se a ênfase for relacionamentos estrutural entre os objetos de uma interação, é melhor dar prioridade ao diagrama de colaboração. colaboração. Podemos também escolher ambos. Diagrama de Seqüência é mais usual.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto 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 m ostrar 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 Também podem mostrar condições, interações, i nterações, valores de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que executam paralelamente com outros. Exemplo: Diagrama de Colaboração
2: validar acesso 1:entrar com chave de acesso
3:entrar com o semestre
4:criar nova matrícula
formulários de registro
Ator (José) 5:apresentar em tela cursos disponíveis
formulário de matrícula 6:obter cursos
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto Diagrama de Interação
e r a w t f o Gerando Diagramas de Colaboração: S e Na ferramenta “Rational Rose”, após criarmos o diagrama de seqüência. Selecionar: d c olaboration Diagram) a ~ Menu Browse e depois a opção F5 (Create colaboration i r a h n e g n E o : ã Categori ç 3: selecionarCategoria : visitante 7: selecionarProduto( ) a t i c 4: getDescricao( ) a 1: getDescricao( ) p a 5: getQuantidade( ) C : : Catalogo Produto
: Form Busca 2: exibirCategoria( ) 6: exibirProduto( )
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Projeto. Atividades e Passos: Fazer Modelo Especificação Identificar as classes de Especificação Fazer Diagrama de Interação Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes Modelo de Especificação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado O que é Diagrama de Estado? É um diagrama que tipicamente complementa a descrição das classes. Pois, este diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se encontrar. 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. s istemas. Aplicação: Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como: - Classes Classes e Casos Casos de Uso Uso
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado Elementos: Os diagramas de estados são compostos de transições e estados. As transições são associadas com ações e são consideradas como processo de curta duração e não podem ser interrompidos. Os estados são associados com as atividades e podem levar mais tempo. Uma atividade pode ser interrompida por algum evento.
Verificando
Estado
Início do fluxo
Transição
Final do fluxo
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado Exemplo:
início
transição fora do gancho Ativo
ocioso no gancho Estado
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado Exemplo 1: Inicializa o Objeto
Lamp On
Espera por Evento Trata Evento
on
on/print(”on”)
off
off
Lamp Off Finaliza Objeto
stop
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado Exemplo 2: (Completo) início
[Nem todos os itens verificados]/pegar verificados]/pegar próximo item [Todos os itens verificados e os todos itens disponíveis]
Verificando
[Todos os itens verificados e alguns itens não estão disponíveis] disponíveis]
[itens ecebidos [alguns itens não estão disponíveis] disponíveis]
Expedindo
Item recebido [os todos itens disponíveis]
Aguardando
cancelamento cancelado Cancelamento
Entregue
final
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Estado Exemplo: Caso de Uso
Cliente
Diagrama de Estado
Autenticar Senha
Consultar Pedido Gerenciar Pedido
Funcionário
Confirmar Pedido
Verificando Verificando S tatus
[Pedido não entregue]
Mudando Status
<> Cancelando Pedido
Cancelar Pedido <>
UpdateStatus Pedido
Logistica
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades O que é Diagrama D iagrama 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades Elementos e Exemplo com comentários: responsabilidades Cliente
Atividade atividade
Vendas
Fazer Pedido
transição
Estoque
atividade Processar Pedido Separar Produtos
separação
Enviar Pedido decisão Receber Pedido
Barras de sincronização
Elementos
Cobrar Cliente
Pagar Fatura Fechar Pedido
junção raias
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada (sem a necessidade de especificar nenhum evento). Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como swimlanes (raias). swimlanes (raias). Uma swimlane agrupa 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 uma maneira alternativa de se mostrar interações, com a possibilidade Um diagrama diagramade deatividade atividadeé pode ser usado com diferentes propósitos inclusive: de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), Para capturar trabalhos que serão executados é disparada (ações). Este quando elas sãoosexecutadas (seqüência das ações),quando e ondeuma elasoperação acontecem ( swimlanes ). ). é o uso mais comum c omum 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 mostra mostrarr como 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 Atividades não é orientado a objetos, na verdade ele é muito semelhante a um fluxograma.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades Exemplo 2: Receber Pedido
Preencher Pedido
Enviar Fatura
Entrega [pedido urgente]
[senão]
Receber Pagamento Entrega durante a noite
Entrega Regular
Encerrar Pedido
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades - Quando Quando utilizar Diagrama Diagrama de Atividad Atividade: e: Como a maioria das técnicas de modelagem comportamental, os diagramas de atividades têm qualidades 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 desvantagem destes diagramas é que eles não deixam muito claro c laro as ligações entre as ações e objetos. Você pode definir uma ligação para um projeto rotulando rotulando uma atividade com um nome 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Atividades Quando utilizar Diagramas de Atividades: Podemos utilizar diagrama de atividade nas seguintes situações: - An Analisand alisando o um caso de uso: 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. - Compreend Compreendo o workflow: workflow: Os diagramas de atividades são muito úteis para compreensão de um processo de negócio. - Descrevendo um algoritmo sequencial complicado: 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: vida: Neste caso o diagrama de estado é o mais indicado.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto
Diagrama de Classes. Introdução Apresentaremos e discutiremos o Diagrama de Classes, ele é considerado o artefato mais importante e é que também exige mais esforço para ser construído. O Diagrama de Classes Cl asses é derivado do Modelo Conceitual C onceitual (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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classe. Revisão: •
O diagrama de classe é um elemento estrutural
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classe. Exemplo:
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classe. Revisão: Refinamentos: 1 - Refinamento Refinamento:: Atributos: Acrescentar Acrescentar tipos de dados e visibilidade exemplo: codigo -codigo: int (private int codigo)
Fase de Análise modelo conceitual
2 - Refinamento: 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 Pessoa nome
Fase de Projeto Diagrama de Classes
Atributos: Tipo de dados e Visibilidade
Cliente
Cliente
codigo nome
-codigo: int -nome: String
Pedido Data Status Numero 1
+getCodigo() +setCodigo() +getNome() +setNome()
1..n item ItemPedito
<>
Quantidade métodos
Cliente cpf codigo
Relacionamento Herança
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refi Refina name mento nto:: Exemplo: Atributos e Métodos: Fase de Análise
Fase de Projeto
modelo conceitual
Diagrama de Classes
Cliente codigo nome
Cliente <>
Atributos: Tipo de dados e Visibilidade
-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() +getCliente()
métodos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refi Refina name mento nto:: Atributos: Acrescentar tipos de dados e visibilidade e métodos. exemplo: codigo -codigo: int (private int codigo) Método: Definir os Métodos Fase de Análise
Fase de Projeto
modelo conceitual
Diagrama de Classes
Cliente Cliente codigo nome
<>
Atributos: Tipo de dados e Visibilidade
-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() métodos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 2 - Refi Refina name mento nto:: Acrescentar: outros tipos de relacionamento entre as classes exemplo: agregação, composição, herança Acrescentar: Navegação, Role Name (papéis) e Multiplicidade Fase de Análise
Fase de Projeto
modelo conceitual
Diagrama de Classes
Pessoa nome
PessoaFisica codigo cpf
Pessoa <>
Relacionamento Herança
cpf nome cliente
PessoaFisica codigo
Role name
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação Herança: É mecanismo baseado em objetos que permite que as classes compartilhem atributos e operações baseados em um relacionamento, geralmente generalização 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. c omportamento.
Herança Curso Universitário extends
Graduação
Podemos dizer que PósGraduação é tipo de Curso Universitário, assim como Curso de Especialização ou de Extensão.
Pós-Graduação
extends
Especialização
Extensão
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação EspecialidadeMédica
Tipo de
generalização
Tipo de
Ortopedia
Pediatria
ContaBancaria
Tipo de ContaCorrente
Tipo de ContaPoupança
especialização
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação Herança: Quais associações são inválidas:
Cartao
Figura
TipoPagamento
Tipo de
Tipo de Retangulo
Circulo Tipo de Ponto
CartaoCredito Tipo de
CartaoDebito
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes Avançado Avançado. Refinamento Refinamentos: 3 - Refinamento Refinamento:: Acrescentar: Associação Qualificada (qualificador), associações reflexivas e Constraint (restrições)
4 - Refinamento: Refinamento: Acrescentar: Classes Associativas, Interfaces e Dependência CPF -cpf getCPF() setCPF()
Pessoa -nome: String +getNome() +setNome() { idade > 18}
CPF -cpf getCPF() setCPF()
{ idade > 18}
Cliente -codigo: int -nome: String -idade: int +getCodigo() +setCodigo() +getNome() +setNome() +getIdade() +setIdade()
Livro -isbn -titulo getISBN() setISBN() setTitulo() getTitulo()
*
*
Emprestimo -data -status getData() setDAta() setStatus() getStatus()
Sociio -codigo: int -idade: int +getCodigo() +setCodigo() +getIdade() +setIdade()
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: 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, vetor, isto quando, quand o, precisamos ter recurso de pesquisa em uma das extremidades da associação. Nome da associação
Classe atributos
qualificador
papel
0..1 papel
Classe atributos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Qualificada (qualificador), associações reflexivas e Constraint (restrições) Associação Qualificada Pedido
Produto
0..1
ItemPedido
Linha de item quantidade: int
Qualificador
O exemplo, demonstra uma associação qualificada, entre as classe Produto, ItemPedido. O qualificador diz que em associação com Pedido poder haver um item de pedido cada ocorrência de produto. Conceitualmente, esse exemplo indica que não é possível existir dois itens de pedido com pedido para o mesmo produto. produto. Para fazer acesso a um item de pedido em especifico, é necessário identificar o produto como argumento.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name mento nto:: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições)
Associação Reflexiva Uma associação reflexiva (também conhecida como auto-associação) liga objetos da mesma classe. Cada objeto tem um papel distinto nesta associação. papel
Classe
Nome da associação
1 *
papéis
Em uma associação o uso dos papéis é importante para evitar ambigüidade na interpretação da associação. Uma associação reflexiva não indica que um objeto se associa a si próprio (um empregado não é gerente dele mesmo; uma condição não é pré-requisito dela mesma). Associação reflexiva indica que um objeto se associa com outros objetos da mesma classe .
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições) Associação Reflexiva: Exemplo Supervisão Supervisor
1
Empregado
* Supervisionado
Neste exemplo existe uma associação reflexiva reflexiva objetos de Empregado. 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name mento nto:: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições) Constraint (restrições): Uma restrição é um relacionamento semântica entre elementos de modelo que especifica condições que devem ser satisfeitas. Classe atributos
{ restrição } 0..1 papel
papel
Classe atributos
Duas opções para representar restrições em UML: • Informal, a UML permite usar qualquer notação para representar as restrições, entretanto entretanto , as estas devem ser especificadas dentro dentro de chaves “{ }”, podemos usar a linguagem formal, por exemplo. fornece linguagem formal de restrições restrições de objetos. objetos. (OCL - Object • Formal, UML fornece Constrai Constraint nt Language Language). ). Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação 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, new, or overlapping e transient. Veja o exemplo: da restrição
Contrato
“ou”.
atributos { ou }
0..1
0..1
Pessoafisica
PessoaJuridica
atributos
atributos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Classe Associativa Em associação entre duas classes, a própria associação poderá ter propriedades. Essas propriedades são originadas a partir da associação de classes com a multiplicidade de: muitos:muitos, para expor a representação destas propriedades é implementado uma nova classe que é resultante da associação, assim como seus atributos e métodos. Classe Classe * * atributos
atributos
Nome da Associação
atributos
Classe de Associação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Classe Associativa Exemplo Associação de muitos:muitos
Produto
*
*
atributos
Fornecedor atributos
ProdutoFornecido
atributos
Classe de associação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Interface: O que é interface ? (Representa (Representa a forma mais pura pura de abstração de dados - Linguagem 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. <>
Nome Interface
Estereotipo e nome da interface
Métodos (assinatura) Assinatura do métodos
public ic stat static ic fina final l ). Nota: Na interface também podemos declarar constantes ( publ ).
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Interface: Exemplo Interface, realização e classes <>
PessoaJuridica getCNPJ() setCNPJ() setContrato() getContrato()
Realização
Fornecedor
PrestadorServico
atributos
atributos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Dependência: Uma dependência é um relacionamento de utilização, determinando as modificações na especificação de um item, mas não necessariamente o inverso. Utilizamos o relacionamento de dependência no contexto das classes para mostrar que uma classe usa outra como argumento na assinatura de uma operação.
FilmClip play(c: Channel) start() stop() pause() dependência
Channel
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Outros conceitos : Granularidade Granularidade: Geralmente para cada atributo criamos um par de métodos getter e getter e setter , estes métodos garantem o encapsulamento dos dados. Entretanto, Entretanto, quando estamos em um ambiente distribuído (de rede), fazer a manipulação de de vários e métodos e atributos, um a um, pode causar um péssimo péssi mo desempenho, temos que considerar latência de rede, largura de banda e etc. Para evitar esta situação podemos criar um método chamado c hamado getCliente(), que contempla todos os dados do cliente, desta forma estaríamos fazendo um única requisição. Desta forma temos a seguinte estrutura granular: Granularidade Grossa: Manipulação através de único método que encapsula todos os atributos da classe. Granularidade Fina: Fina: Cada atributo tem seu par de método. m étodo.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Granularidade Granularidade: Exemplo
Cliente -codigo: int -descricao: String
Granularidade Grossa
+getCodigo() +setCodigo() +getDescricao() +setDescricao()
+getCliente()
Granularidade Fina
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Construtores: O que são construtores? Construtores são um tipo especial de método usado para inicializar uma “ instance” da classe. Toda a classe deve ter um Construtor. Quando não declaramos o “Construtor default”, que é inicializado automaticamente automaticamente pelo Java. Mas existem casos que se faz necessário a declaração explícita dos construtores.
Cliente
Tipo
- codigo codigo:: int int - nom nome: e: String String - tipo: tipo: Tipo Tipo <> +Cliente(codigo: int, nome: String) +Cliente(codigo: int, nome: String, tipo: Tipo)
-descricao: String
<> + getCodigo(): int + getNome(): String + setCodigo(int codigo) + setNome(String nome) + getTipo(): Tipo + setTipo(tipo Tipo) + getCliente(): String
+getDescricao(): String +setDescricao(d: String)
dependência
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Construtores: Restrição: O Construtor não pode ser herdado. Para chamá-lo a partir de uma subclasse usamos a referência super.
Para escrever um construtor, 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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Construtores: Quantos construtores pode ter uma classe ? Uma classe pode ter vários construtores, entretanto, eles devem seguir s eguir a regra de overloading; 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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Existem três propriedades definidas que poderão ser utilizada como os atributos:
- Change Changeabl able: e: 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.
- Froz Frozen en:: O valor do atributo não pode poderá ser modificado depois que o objeto for iniciado TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)
Propriedade
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Existem três propriedades definidas que poderão ser utilizada como os atributos:
- Change Changeabl able: e: 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.
- Froz Frozen en:: O valor do atributo não pode poderá ser modificado depois que o objeto for iniciado TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)
Propriedade
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Implementando a propriedade Frozen em Java: TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)
Modificador Final (constantes) Para declarar uma variável, um ou uma classe como constante usamos 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 public class class TaxaJur axaJuroo { private final double double VALOR; public TaxaJuro( axaJuro(double double valor) valor) { VALOR = valor; } public public static static void void main( main(Str String ing args[] args[])) { TaxaJuro taxa = new TaxaJuro(21.30); axaJuro(21.30); System.out.println(taxa.VALOR); } }
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Exercício: Implementando a propriedade Frozen em Java, implemente também os métodos set e get e tente mudar o valor da atributo. TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Definição de Delegação: A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma mensagem. O reúso de propriedades de uma classe pode ser realizado não só através do mecanismo generalização entre as classes, mas também através do mecanismo de delegação. O reúso por generalização se baseia na estrutura de superclasse e subclasse, onde a subclasse herda todos os métodos e atributos da classe “pai” (superclasse).
Recomendamos usar o mecanismo de delegação em algumas situações: • Para não violar regra de encapsulamento; • Para não sobrecarregar de responsabilidade uma classe; • Para atender a semântica da classe e • Favorecer o mecanismo de reúso. A seguir veremos um exemplo completo, onde a aplicação do mecanismo de delegação é melhor solução para obedecermos as regras da orientação a objetos.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: No Modelo Conceitual devemos identificar os candidatos a classe e seus respectivos conceitos. Entretanto, devemos antes lembrar da definição da classe. Classe A descrição de conjunto de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica.
Temos a primeira sugestão do modelo, como classe Cliente fazendo uma associação a Senha.
Cliente codigo nome
possui
Senha senha
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Em segunda sugestão de modelo, como classe Cliente tem como atributo senha, desta forma a classe Senha não seria necessário.
Cliente codigo nome senha
Quais são as implicações que o atributo “senha” pode causar ao modelo ?
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: 1 - Identificar Identificar todas classes classes que fazem uso ou que tem um determinado determinado atributo, atributo, neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deve está explícito no documento “Domínio do Problema”. Veja o exemplo:
Conceito diferente
Cliente
Funcionario
codigo nome
codigo-funcional nome
senha
senha
O mesmo conceito
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) - Uma sugestão sugestão para solução solução do problema: problema:
Pedido
HistoricoCliente
Cliente
Funcionario
codigo nome
codigo-funcional nome
possui
Senha senha
possui
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) 2 - Uma vez que senha é um atributo de de cliente como podemos podemos implementar implementar regras de negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de conceito (semântica). (semântica ). Veja Veja o exemplo:
Cliente codigo nome senha qde_dias_expiracao_senha
Este atributo somente é regra que se aplica somente a senha e não a cliente.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) 3 - Reús Reúso: o: - O atributo senha poderá poderá ser utilizado por outra outra aplicação, que que nem sempre deverá deverá ver os outros atributos de cliente.
Cliente codigo nome senha
Podemos concluir, que no exemplo apresentado duas regras da orientação a objetos foram violadas: - Semâ Semânti ntica ca e - Baixo Baixo reúso reúso
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto Mitos e Lendas
e r a w t f o S e O que é dito: d - Modelo de entidade e relacioname relacionamento nto (MER), deve deve ser feito antes do diagrama diagrama de a classes. i r a h n Entretanto, a realidade é outra... e g n E Quando estamos a metodologia de orientação a objetos os dados são o Assim o “MER” deve ser derivado do modelo de ã encapsulados. Assim ç classes. a t i c a p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Arquitetura de Software Objetivo desta parte: É apresentar e discutir Arquitetura Arquitetura de Software, conceitos modelos e técnicas
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Objetivo: Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Projeto, nesta fase criamos os componentes, modelos físicos e como serão distribuídos. Os principais diagramas UML são: - Di Diag agra rama ma de Dep Deplo loym ymen entt e - Diagrama Diagrama de Componente Componentes. s. Também nesta fase refinamos o Modelo de Arquitetura. Arquitetura. Objetivo primário da arquitetura é atender os requisitos não funcionais. O artefato deste passo é: - Modelo de Arquitetura Arquitetura..
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Big Picture. Arquitetura Projeto (Visão Lógica)
Arquitetura
Diagramas
Projeto (Visão de Componentes e Visão de Deployment)
4
ReceberPedido
: visitante
: FormBusca
: Ca et go ir a
: Po r du ot
PreencherPedido
: Ca at ol go
EnviarFatura
getDescricao()
Entrega
exibirCategoria() selecionarCategoria
getDescricao()
[pedido urgente]
[ senão]
getQuantidade()
ReceberPagamento
exibirProduto()
selecionarProduto()
Entregadurante a noite
EntregaRegular
EncerrarPedido
Diagrama de Componentes Diagrama de Deployment
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a
Arquitetura Workflow
Arquitetura
Artefatos
Papéis
Digrama de Componentes Analista de Sistema Projetista de Software
Diagrama de Deployment
Modelo de Arquitetura
Arquiteto de Software
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões:
Visão de Projeto
Visão da Implementação Codificação Montagem
Funcionalidade Vocabulário
Visão de Caso de Uso Visão do Visão da Processo Implantação Desempenho Escalabilidade Throughput Conceitual
Topologia do Sistema Distribuição Instalação Físico
Análise e Desenho Orientado a Objetos com UML
Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões:
e r a w t f o Visão de Implementação S e • A visão de implementação de um sistema abrange os componentes e os arquivos utilizados d para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o a i r gerenciamento da configuração das versões do sistema, compostas por componentes e a h arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para n e a produção de um sistema executável. g n E o Visão de Implantação ã ç a • A visão de implantação de um sistema abrange os nós que formam a topologia topologia de hardware em t i c que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a a p instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa a C 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões: Cada uma dessas visões pode ser considerada c onsiderada 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 implement açã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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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”. Arquitetura”.
Passos: 1 - Selecionar Selecionar o Modelo Modelo de Arquitet Arquitetura ura 2 – Refinar o Modelo de Arquitetura Inicial.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Decomposição e Camadas Decomposição: A decomposição refere-se à fragmentação de uma aplicação ou sistema em partes menores e lógicas facilitando gerenciar a complexidade. Os módulos, os subsistemas e componentes são bom exemplo de decomposição. A decomposição decomposição ajuda a definir e a esclarecer as interfaces entre as diferentes partes de um sistema. Também 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 pode também auxiliar auxili ar 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 facilm ente 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Arquitetura UML. Diagrama de Pacotes Como podemos definir o diagrama de pacotes? A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é linha pontilhada com uma seta que indica dependência. dependência. Os diagramas de pacote podem ser usados para fazer decomposição funcional. A nota notaçã çãoo usad usadaa pela ela UML UML para ara rep represe resenntar tar paco pacote tess é:
Nome do Pacote
Nome do Pacote
Nome do Pacote Nome do Pacote
Dependência (import)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Arquitetura UML. Diagrama de Pacotes Decomposição. “Dividir para conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito mui to 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 si mplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:
Contas a Pagar
Fluxo de Caixa Nome do Pacote
Subsistema
Contas a Receber
Dependência (import)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Separação em camadas Camada: Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar. A camada é um padrão para a decomposição. A decomposição leva uma fragmentação lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos. O Rational Rational Unified Unified Process Process (RUP) ou simplesmente simplesmente UP identif identifica ica duas duas abordage abordagens ns para para a camada: - Camada Camada baseada em responsab responsabilidade ilidade e - Camada Camada baseada baseada em reúso. 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 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 dis ponibilidade e separação de funcionalidades e de papéis de uma aplicação
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Separação em camadas Níveis: A forma 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, cliente, lida com interação interação com usuário usuário - O nível de apresentação, lida com apresentação dos dos dados - O nível de negócio, contém as regras de negócios negócios e as entidades entidades - O nível de dados, fornece a interface para para armazenamento de dados
<> Cliente
<> Apresentação
<> Negócios
<> Dados
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Pattern. Mode Modell View iew Cont Contrrolle ollerr 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, model, view e controller. controller. Onde: Model: Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans e EJB. View: View : É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP Controller: Controller: Recebe as requisições, faz validação e define o model que manipulará os dados. Algumas vantagens do MVC: - Decomp Decomposi osição ção;; - Reús Reúsoo; - Possibilita Possibilita o desenvolvime desenvolvimento nto em paralelo; paralelo; - Separação Separação de responsabilid responsabilidades ades e papéis; papéis; - Isolamento Isolamento e separação separação das das camadas camadas e - Baixo Baixo acoplame acoplamento nto.. MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, 2, como veremos a seguir s eguir..
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Model View Controller. Model 1 cl iente faz uma requisição para uma página dinâmica (JSP ou ASP) que pode Model 1: 1: O cliente chamar um model (componente) (componente) ou outra página dinâmica que faz algum processamento e devolve para cliente a resposta
View
View
Web Server
View Model
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Model View Controller. Model 2 c amada controller que redireciona para Model 2: 2: O cliente faz uma requisição para a camada camada model que executa algum processamento e retorna para controller que gera uma página dinâmica (JSP ou ASP) que é devolvida como a resposta ao cliente
View
View
Controller Componentes (Model)
View
Web Server
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Model View View Controller Aplicação do MVC em ambiente de três camadas (Web) View: Visão representa a apresentação (interface com usuário) de uma aplicação. O componentes da View obtém os valores do estado do Model. Separação do View e do Model habilita a construção independente interfaces com skins). Diferentes Diferentes Views podem podem interagir interagir diferentes “Look and Feel” (aparências - skins). 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 receber as requisições e determinar qual o Model apropriado para atende-la. Ele também poder tratar a resposta.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Model View Controller Aplicação do MVC (Model, View e Controller) Model: O modelo representa as regras de negócios de uma aplicação. Encapsulando as regras dentro de um componente facilita os testes, melhora a qualidade e promove o reúso de componentes. Estado do componentes (model): O estado define um conjunto de valores do Model e inclui métodos para mudar estes valores. Estes métodos são regras de negócios e outros métodos. O “estado” de componente são geralmente um protocolo independente. Na
tecnologia Java os JavaBeans e os EJBs são uma boa escolha para implementar estes componentes. Na tecnologia .Net (Microsoft) podemos usar os componentes COM+
Análise e Desenho Orientado a Objetos com UML
Workflow orkflow Arquitetura Arquitetur a Introdução: O papel da d a Arquitetura: Arquitetura:
e r a w t f o S e Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor servi dor d a e em diversas estações clientes em ambiente de rede local. i r Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem a r ede distribuída, com diversos servidores, quando h ser distribuídos, ou seja, rodar em uma rede n alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o e criti ca. g funcionamento (desempenho) deste software é missão mais difícil e até critica. n E o O papel do “Arquiteto de Software” é garantir o funcionamento do software e atendimento ã pleno dos Requisitos Não Funcionais (Desempenho, “Escalabilidade”, Confiabilidade, ç a Segurança e etc) e das Restrições, Restrições, como uso de determinada tecnologia (protocolos, t i c linguagens de programação, banco de dados e etc) a As responsabilidades do Arquiteto Arquiteto de Software: p a - Selecionar uma tecnologia adequada e projetar um modelo robusto, flexível flexível e eficiente. C - Propor um plano de redução de risco.Um ambiente complexo tem um risco maior, maior, cabe ao
Arquiteto desenvolver um plano para redução de risco. - O Arquitet Arquitetoo também deve deve sugerir sugerir o uso de Patterns de Arquitetura que são as boas práticas para a construção do Modelo.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Arquitetura 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Road Arquitetura.Road Map
Modelo de Especificação Documentos de Requisitos
Modelo de Arquitetura Inicial
Caso de Uso
Digrama de Deployment
Fazer Diagramas
Digrama de Componentes
Fazer Modelo de Arquitetura
View
Controller
Model
Resources
JSP/HTML
Servlet
EJB
Banco de Dados
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura. Atividades e Passos: Fazer Modelo Arquitetura Arquitetura Selecionar uma Arquitetura Modelo de Arquitetura Inicial
Fazer Diagrama de Deployment
Digrama de Deployment
Fazer Diagrama de Componentes
Digrama de Componentes
Refinar Modelo de Arquitetura (RNFs) Refinar o Modelo de Especificação Modelo de Arquitetura
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment O que é Diagrama de Deployment? Variações 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 hardware e do software 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 topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: c apacidade de Processor (Processador): É qualquer máquina que possua a capacidade processamento. Os servidores, estações de trabalho por exemplo. Servidor
processador
finali dade ou finalidade limita. Os Device (Dispositivo): É qualquer máquina com finalidade dispositivos são os itens como impressoras, roteadores, raids, storages, s torages, scanners, leitoras de código de barra e etc. Impressora
Dispositivo
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: Connection (conexão): conexão): A conexão é o vinculo entre processadores e dispositivos. Geralmente representam as conexões de rede físicas (rede local ou distribuída). estereotipo
Cliente
<>
Servidor
<>
conexão
Processador (Nó)
Impressora
Dispositivo (Nó)
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento físico que existe em tempo de execução e representa um recurso r ecurso computacional. <> WebBrowser
<> Apache <>
<> Impressora
Nós <> JBoss
<>
<> Cliente
<> Oracle
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment O diagrama de Deployment pode ser substituído por outro diagrama que exibam com maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se s e faça necessário.
WebServer Apache
Banco de Dados
Oracle Application Server JBoss
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment & Diagrama de Componentes Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma visão mais “clara” da arquitetura baseada na UML
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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
Dependência
Componente genérico
Componente B
Nome do componente
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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. ReservaUI Dependência
Room
ReservaService
Reserva Service_ stub
Component
Interface
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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. i nterfaces. Interfaces: Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe cl asse 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; - Corb Corbaa (CCM) (CCM) e - Microso Microsoftft COM+ COM+..
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Exemplo: CatalogHome
Catalog Home Stub
Catalog.jsp
CatalogHome
Catalog EJB Home
Catalog Business Delegate CatalogRemote
Catalog Remote Stub
CatalogRemote
Catalog EJB Object
Catalog Bean
CatalogRemote
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: Existem três tipos de componentes: - Componentes de Implantação: 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.}
Video.dll
Disk.dll Floppy.dll
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: (continuação) - Componentes do Produto do Trabalho: Trabalho: Esses componentes são essencialmente o é parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema executável, mas são os produtos de desenvolvimento, usados para criação do sistema executável. Cliente.class Conta.class
Conta.jar {versão 1} Historico.class
Conta.java
- Componentes de Execução: 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: - Componente: 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: subprograma : Estes ícones representam a especificação visível de um subprograma e o seu corpo de implementação. i mplementação. Um subprograma costuma ser uma coleção de sub-rotinas. Os subprogramas não contém c ontém definições de classe. New NewSubpr ubprog ogSp Speec
NewS ewSubpr ubprog ogB Body
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: - Programa Principal: Principal: Este ícone representam o programa principal. princi pal. 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: pacote : Um pacote é a implementação impl ementaçã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
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
Package Body
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
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a 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 NewTaskS skSpec
NewTaskB skBody
Além de modelar o componente propriamente dito, podemos modelar o relacionamento entre o componente e sua interface. Veja o exemplo abaixo:
Componente genérico
Interface
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Neste exemplo criaremos um diagrama de componentes para a funcionalidade “cesta de compra”. Neste momento identificaremos as classes que são necessárias para realizar o caso de uso “adicionar item na cesta de compra”. Como alguns
casos de usos são embutidos, novos componentes serão adicionados ao diagrama. A tecnologia deste exemplo é Java. Component view
Boundary
Services
Entities
Visão principal do Diagrama de Componentes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Entities. Entities. Esses são os componentes que conterão as classes de entidades. entidades. Component view Cesta
Entities
Cesta Item
As classes Entidades
Produto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Services. Services. Esses são os componentes que conterão as classes de serviços ou de controle. controle . Component view CestaService
Services
ProdutoService
As classes de Serviços ou Controle
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Boundaries. Boundaries. Esses são os componentes que conterão as classes de Boundaries (ou de interface com usuário). usuário) . Component view
CestaInterface Boundary
As classes de Interfaces
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Uma visão dos componentes e relacionamentos MainProgram
CestaInterface
CestaService ProdutoService
Cesta
Cesta Item
Produto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Um novo exemplo, o cenário fazer Reserva de apartamento.
View
Menu Principal
ReservaUI
Controller
ReservaService ClienteService
Model
Cliente
ApartamentoService
Reserva
Apartamento
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Identificação de Componentes: Componentes: Componentes são grupos de classes que representam uma funcionalidade funcionali dade dentro de sistema. Como faço o diagrama de componentes ?
Componentes
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 Projet o 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Independência Independência Funcional
Independência Funcional: •Coesão e • Acoplamento
Conceito que está diretamente relacionado a modularidade, abstração e encapsulamento 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão (High Cohesion) É uma medida de força funcional relativa de um módulo. Uma classe coesiva executa uma única tarefa, exigindo pouca interação com outras classes ou objetos. Alta coesão é o desejável. Como manter a alta coesão ?
Independência Funcional: •Coesão e • Acoplamento
- Solução: Atribuir 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 c oesão (ou mais especificamente, coesão funcional) é uma medida de quão fortemente relacionadas e focalizadas são as responsabilidades responsabili dades de uma classe. Uma classe com responsabilidade altamente relacionadas e que não executa um formidável volume de trabalho tem coesão alta.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação)
Independência Funcional: •Coesão e • Acoplamento
Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou executa demasiado trabalho. Tais Tais classes são s ão indesejáveis, elas sofrem dos seguintes problemas: - São difíceis difíceis de compree compreender; nder; - São difíceis de reusar; reusar; - São difíceis difíceis de de manter; manter; - São muito muito sensíveis sensíveis a mudança; mudança; Classes de coesão baixa representam, geralmente, uma abstração abstr ação de “grande granularidade” ou atribuíram responsabilidades que deveriam ter
sido delgadas a outras classes ou objetos
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Exemplo:
Independência Funcional: •Coesão e • Acoplamento
Neste exemplo é demonstrado a baixa coesão, coesão, uma vez que a classe Nota Fiscal assume a responsabilidade de fazer o cálculo dos imposto Tributo - codi codigo go - nome nome
NotaFiscal
Cliente
- núme número ro - data emissão emissão - tipo tipo +calcularImposto() +getNumero +setNumero ....
- codi codigo go - nome nome +getCodigo() +setCodigo() +getNome()
NotaFiscalItem
Produto
- item item[[ ] - quantidad quantidadee +getQuantidade() +setQuantidade() ...
- codi codigo go - descr descriçã içãoo +setCodigo() +getCodigo()
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Tributo
Coesão: (continuação)
- codi codigo go - nome nome
Exemplo:
Independência Funcional: •Coesão e • Acoplamento
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. Produto - codi codigo go - descri descriçã çãoo +setCodigo() +getCodigo() +gerProduto
NotaFiscal - núme número ro - data emissão emissão - tipo tipo +getNumero +setNumero ....
CalculoImposto +calcularImposto()
NotaFiscalItem
Cliente
- quantida quantidade de
- codi codigo go - nome nome +getCodigo() +setCodigo() +getNome() +get/cliente()
+getQuantidade() +setQuantidade() ...
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Tipos de coesão funcional:
•
Coesão Muito Baixa: –
Independência Funcional: •Coesão e • Acoplamento
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 exclusivas em umas poucas áreas diferentes que estão logicamente relacionadas ao conceito da classe, mas não entre si.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Benefícios:
• • • •
Independência Funcional: •Coesão e • Acoplamento
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..
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Acoplamento (Low Coupling) É uma medida da interdependência relativa entre as classes. Depende da complexidade de interface entre as classes. Baixo acoplamento é o desejável Como manter o baixo acoplamento ?
Independência Funcional: •Coesão e • Acoplamento
- Solução: Solução: Atribuir Atribuir uma responsabilidad responsabilidadee 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.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Acoplamento (continuação) Uma classe com acoplamento alto (forte) depende de muitas outras classes. Tais Tais classes são indesejáveis; 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.
Independência Funcional: Benefícios: •Coesão e • Acoplamento • Não afeta por mudanças em outros componentes • •
simples de entender conveniente para o reúso.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento. Tipos:
Abaixo os possíveis tipos de acoplamento: Acoplamento Acoplamento Abstrata: Cliente
Service
<>
Cliente
Service
{abstract}
Independência Funcional: •Coesão e • Acoplamento
Service
Service
Sem acoplamento Cliente
Service
Com acoplamento Cliente Service
Service
Service
Forte acoplamento Cliente
Service
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow de Projeto, Arquitetura Conceitos: Acoplamento e Coesão Acoplamento
Princípio da Dependência Inversa: “Abstração não deve depender classe concreta. Uma classe concreta deve depender de uma abstração”
Exemplo: Independência Funcional: •Coesão e • Acoplamento
Moeda
MaskMoeda
- valo valorr +getValor +setValor
+maskFormat()
dependência
Este modelo tem alguns problemas: 1 - Herança. Todos Todos que herdarem a classe Moeda são obrigados obrigados a herdar também a classe MaskMoeda e as vezes somente precisamos da classe Moeda.
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento
Princípio da Dependência Inversa (continuação): Moeda - valo valorr
MaskMoeda
+getValor +setValor
Independência Funcional: •Coesão e • Acoplamento
+maskMoeda()
dependência
2 - O relacionamento de dependência dependência inibe a extensibilidade da classe Moeda. Vamos 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).
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento
Princípio da Dependência Inversa (continuação): Aplicando a DIP, DIP, podemos resolver a situação, veja os modelos abaixo: DIP com Classe Abstrata: Cliente
Independência Funcional: •Coesão e • Acoplamento
DIP com Interface: <>
Cliente
Service
Service
{abstract}
Service
Service
Service
Solução para a classe Moeda: Moeda
MoedaMask {abstract}
Real
Dolar
Service
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Relacionamento de Realização Problema:
Independência Funcional: •Coesão e • Acoplamento
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.
<> iPessoa
Cliente
Realização
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Relacionamento de Realização
Independência Funcional: •Coesão e • Acoplamento
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 <> iPessoa
Realização PessoaAdapter
Cliente
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Exemplo: A partir do diagrama de classe, tentamos agrupar classes cl asses usando técnicas de coesão e acoplamento.
Exemplo: Acoplamento Coesão e Componentes
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Exemplo: Temos o seguinte resultado:
Exemplo: Acoplamento Coesão e Componentes
Análise e Desenho Orientado a Objetos com UML
Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes
e r a w t f Exemplo 2: o S Diagrama de Classes: e d a i r a h n e g n E o ã ç a t i c a p a C
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a UML. Diagrama de Componentes Exemplo 2: A partir do diagrama de classe, agrupar classes usando os conceitos de coesão e acoplamento.
Pedido Cesta de Compra Produto FormaPagto
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto, Arquitetura Diagrama de Componentes
e r a w t f Exemplo 2: o S Diagrama de Componentes e d a i r a h Pedido n e g n Cesta de Compra E o ã Produto ç a t i c FormaPagto a p a C
Produto
Cesta
Pedido
FormaPagto
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura: Arquitetura: Sugestão para modelo de Arquitetura para aplicações Web de três camadas: Servidor de Aplicação JBoss
Cliente
Servidor de Banco de Dados
HTTP TCP/IP
Oracle
HTML
Windows
Linux Suse
Linux Suse
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)
DeskTop
Servidor de Aplicação
ReservaUI
Reserva
<>
Funcionário << Stub>>
<>
RMI
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Web Browser FormConsulta
Cliente
HTTP
WebServer
Servlet
Tabelas de Reserva
ServletsController
JSP JavaBeans
<< Reserva>>
<< ConnDB>>
Banco de Dados
HotelSchema
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Web Cliente Browser FormConsulta
Apresentação ServletsController
Negócio << Reserva>>
Integração JDBC 2.0
HTTP << ConnDB>>
Cliente
HTML
Recursos
Servlet/JSP
JavaBeans
Banco de Dados
SQL
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Workflow orkflow Arquitetura Arquitetur a Implementando os Requisitos Não Funcionais: Neste momento devemos construir modelo de arquitetura para atender todos os RNF e os casos de uso mais relevante ao negócio. A seguir demonstraremos um exemplo de como criar uma arquitetura para RNF. Considerando o cenário de Loja Virtual, numa transação de pagamento. Browser FormPagamento Cliente
Fazer Pedido
<>
Cliente
HTTPs (HTTP + SSL) Fazer Pagamento
<> Fechar Pedido
WebServer ServletsController
CartaoCredito
Pagamento
Requisito Não Funcional: Segurança: Todas Todas as transações de pagamento deve ser realizado em ambiente seguro
Análise e Desenho Orientado a Objetos com UML
Quer Mais Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material... e r Envie um e-mail para com subject : “Quero entrar na comunidade” para [email protected] que te a enviaremos um convite para participar da nossa comunidade w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
http://etecnologia.ning.com/
Desenho Sobre o Análise autor: eRildo F. Orientado Santos a Objetos com UML Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
A Gestão Ágil ajuda as empresas a responder r esponder 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 Lider anç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 de Governança de TI e Gerenciamento de Serviços 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 Proj etista 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: certificações: CSM - Certified SCRUM Master, CSPO CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International IIBA-International Institute of Business Analysis Analysis (Canada)
Onde estou: Twitter: http://twitter.com/rildosan http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/ http://rildosan.blogspot.com/
Análise e Desenho Orientado a Objetos com UML Marcas Marcas Registradas: Registradas: e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Todos os termos mencionados e reconhecidos recon hecidos 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 f avorecimento 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 email para nós. Imagens: Google, Flickr e Banco de Imagem.
Rildo F dos Santos ([email protected])
Licença: e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
Análise e Desenho Orientado a Objetos com UML
Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C
o s L o h t M n e j e U s b e O D a m o e c o e s d i a l t á n n e A i r O
Rild Ri ldo o F Sant Santos os [email protected] [email protected]
Twitter: @rildosan Blog: http://rildosan.blogspot.com/