es i aula06n [modo de...

FCT-UNESP 04/07/2017

Prof. Dr. Rogério E. Garcia 1

Bacharelado emCiência da

Computação04/07/2017

Engenharia de Software I

Rogério Eduardo Garcia([email protected])

Aula 06

In a calm sea every man is a pilot.

BCC04/07/2017

04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2

Engenharia de Software I –Aula 6

Revisão Revisão Geral

Introdução ao Método Larman Planejar e Elaborar

Construir Analisar

Projeto



BCC04/07/2017


Problema Solução

Abstrato

Concreto

Problema X Solução

BCC04/07/2017


Desenvolvimento Iterativo

Um ciclo de vida iterativo (CVI) envolve a repetição dos ciclos deplanejamento, elaboração, construção e instalação

O sistema cresce pela adição de novas funções (e refinamentodas existentes) em cada ciclo iterativo

Cada ciclo ataca um pequeno conjunto de requisitos

planejar

elaborarconstruir

instalar



BCC04/07/2017



Planejar eelaborar

Construir Instalar

Ciclo de Desenvolvimento 1


…

RefinarPlano

SincronizarArtefatos

Analisar Projetar Construir Testar

BCC04/07/2017


Analisar: Atividades

Definir/Refinar os casos de uso essenciais (se aindanão foi feito)

Definir/Refinar os diagramas de casos de uso

Definir/Refinar o modelo conceitual

Definir/Refinar o glossário

Definir/Refinar os diagramas de seqüência dosistema

Definir/Refinar os contratos de operação

Definir/Refinar os diagramas de estado



BCC04/07/2017


Projetar: Atividades

Definir casos de uso reais

Definir Relatórios, Interface e Storyboards,…

Refinar a arquitetura do sistema

Definir diagramas de interação

Definir diagramas de classe do projeto

Definir esquema da base de dados

BCC04/07/2017


Construir: Atividades

Implementar definições de classes einterfaces

Implementar métodos

Implementar interfaces com usuário

Implementar relatórios

Implementar esquema da base de dados(SQL)

Escrever casos de teste



BCC04/07/2017


Diagrama de Seqüência

Um Diagrama de Seqüência mostrainterações de objetos ordenados numaseqüência de tempo

BCC04/07/2017


Diagrama de Seqüência -Exemplo

: Aluno

1: preenche

2: envia

3: curso(gabriel,matemática)

4: está aberto?5: está aberto?

6: incui(gabriel)7: incui (gabriel)

Formulário deMatrúcula

Responsável porMatrículas

MatemáticaBásica

MatemáticaÁlgebra

Como chegar aqui?



BCC04/07/2017



Planejar eelaborar

Construir Instalar



…

RefinarPlano

SincronizarArtefatos


BCC04/07/2017


RefinarPlano

Sincronizarartefatos


1. Definir Casos deUso Reais

2. Definir Relatórios, IU e “Storyboards”

3. Refinar a arquitetura do sistema

4. Definir Diagramasde Interação

5. Definir Diagramas deClasses de Projeto

6. Definir o EsquemaDo Banco de Dados

Atividades da Fase Projetar



BCC04/07/2017


Início da fase Projetar

Nesta fase é desenvolvida uma solução lógicabaseada no paradigma de orientação a objetos –objetos, mensagens, classes, métodos, …. “Fazer Certo a Coisa” – projetar de maneira competente

uma solução que satisfaça os requisitos

Os dois artefatos principais a serem desenvolvidossão: Diagramas de Interação

Diagramas de Classe de Projeto

BCC04/07/2017


Diagramas de Interação

Diagramas de Interação – apresentam como osobjetos interagem, por meio de mensagens, pararesponder a um determinado evento são importantes para o desenvolvimento de um bom

projeto exigem criatividade

A UML fornece dois tipos de diagramas de interaçãoque permitem representar interação (colaboração)entre classes (ou objetos): diagramas de colaboração – formato de grafo diagramas de seqüência – formato de cerca



BCC04/07/2017


Diagrama de Colaboração

Diagrama de Colaboração foca tanto ainteração quanto os links entre um conjuntode objetos que “colaboram” entre si;

O Diagrama de seqüência e o deColaboração mostram as interações, mas ode seqüência foca o tempo e o decolaboração foca o espaço.

BCC04/07/2017


mensagem1():Instância da

Classe A:Instância da

Classe B

1:mensagem2()2:mensagem3()

Diagrama de Colaboração

•Os diagramas de colaboração têm melhor capacidade deexpressar informações contextuais e podem ser maiseconômicos em termos de espaço



BCC04/07/2017


mensagem1()1:mensagem2()

2:mensagem3()

:instância de Classe A

:instância de Classe B

:instância de Classe C

3:mensagem4()

Diagrama de Seqüência

BCC04/07/2017


Diagramas de Colaboração

Diagrama de Colaboração - um dos artefatosmais importantes criados no projeto OO o tempo gasto na sua criação deveria absorver

um percentual de tempo significativo do tempogasto no projeto

Elaborar diagramas de colaboração exigeconhecimento de: princípios de atribuição de responsabilidades

padrões de projeto



BCC07/07/2015

BCC07/07/2015


Classes e Instâncias

Venda

Classe

:Venda

Instância

venda1:Venda

Instância nomeada

BCC04/07/2017


Mensagens

Sintaxe UML:

retorno := mensagem ( parâmetro : tipoParâmetro ) : tipoRetorno

O retorno pode não existir

Os tipos podem ser omitidos ser forem óbvios ou não forem importantes

Exemplo:

especificacao := obterEspecificacaoProduto(id)

especificacao := obterEspecificacaoProduto(id:IdItem)

especificacao := obterEspecificacaoProduto(id:IdItem) : EspecificacaoProduto



BCC04/07/2017


Mensagens

No paradigma de orientação a objetos: Mensagem é o mecanismo de comunicação entre objetos

invoca as operações desejadas

“O processo de invocar um método é chamado de enviode uma mensagem ao objeto”

Ex: quando uma mensagem façaAlgo() é enviada auma objeto obj, o método façaAlgo() definido naclasse de obj é executado:

obj.façaAlgo()

BCC04/07/2017


Ligações

• Ligação: conexão em dois objeto que indica a possibilidade de alguma forma de navegação ou de visibilidade entre eles

• permite que mensagens fluam de um objeto para outro

total:=totalizarVenda():float:Venda:TPV

------:Venda.totalizarVenda()------



BCC04/07/2017


Mensagens Múltiplas

Várias mensagens, em ambos os sentidos, podem fluir ao longode uma mesma ligação usar seta para indicar direção da mensagem

usar números de seqüência para indicar ordem de execução dasmensagens

1:mensagem1() 2:mensagem2() 3:mensagem3() :Instância

Classe A:Instância Classe B4:mensagem4()

BCC04/07/2017


Exemplo

acionar():BotãoElevador

:ControladorElevador

1:atualizar( )

2:iluminar( )



BCC04/07/2017


Primeira Mensagem

A primeira mensagem é aquela enviada ao objeto que inicia otratamento a um determinado evento

O emissor da primeira mensagem não é identificado

1:mensagem1() 2:mensagem2() 3:mensagem3() :Instância

Classe B4:mensagem4()

primeiraMsg()

:Instância Classe A

------:InstÂnciaClasseA.primeiraMsg()------

em a

lgum

luga

r no

sis

tem

a…

BCC04/07/2017


Exemplo

1:ok :=posicionarAngulo(angulo):Booleano:Flape

Aterrissar()

:Aeronave



BCC04/07/2017


Número de Seqüência da Mensagem

Primeira mensagem não é numerada

Numeração formal e agregada indica a ordem e o aninhamentodas mensagens

:ClasseA :ClasseB

:ClasseC

msg1()1:msg2()

1.1:msg3()

aninhamento de mensagens

BCC04/07/2017


Aninhamento de Mensagens

:ClasseA :ClasseB

:ClasseC

msg1()1:msg2()

1.1:msg3()

msg1()------:ClasseB.msg2()------

msg2()------:ClasseC.msg3()------



BCC04/07/2017


Aninhamento de Mensagens –Exemplo

:ClasseA :ClasseB

:ClasseC

:ClasseD

msg1()1:msg2()

1.1:msg3()

2.1:msg5()2:msg4()

2.2:msg6()

BCC04/07/2017


Aninhamento de Mensagens –Exemplo (cont.)

msg1()------:ClasseB.msg2()------:ClasseC.msg4()------

msg2()------:ClasseC.msg3()------

msg4()------:ClasseB.msg5()------:ClasseD.msg6()------

em algum lugar no sistema… :ClasseA.msg1()



BCC04/07/2017


Auto-Mensagem (this)

:TPV

1: iniciar()

:ClasseA

1: msg2()msg1()

iniciarSistema()

BCC04/07/2017


Iteração

msg1()

1*:[i:=1..10]msg2()

2*:[i:=1..10]msg3()

:ClasseA :ClasseB

:ClasseC

------for i=1 to 10 {

:ClasseB.msg2():ClasseC.msg3()

}------

msg1()



BCC04/07/2017


Iteração

:TPV :Venda1 * : linha:=proxLinhaItem():LinhaItemVenda

Cláusula de Iteração([i:=1..10]) é opcional

msg1()

BCC04/07/2017


Criação de Instância

:TPV :Venda1:criar(caixa)

iniciarVenda()

• Uma mensagem pode ser usada para criar uma instância

nomear mensagem como criar()mensagem criar(), com parâmetros opcionais,

normalmente é interpretada, na implementação, como chamada a um construtor da classe de

software



BCC04/07/2017


Mensagens Condicionais

:ClasseA :ClasseB1: [condição] msg2()

msg1()

• Uma mensagem condicional só será enviada se a cláusula entre [ ] tiver valor true

------if (condicao = true) {:ClasseB.msg2()

}------

msg1()

BCC04/07/2017


Mensagens Condicionais

:TPV :Venda1: [nova venda] criar()

msg1()



BCC04/07/2017


:ClasseB

:ClasseC

msg1()1a: [condição] msg2()

1b:[not condição] msg3()

• Apenas uma ou outra mensagem é enviada dependendo da condição ser verdadeira ou falsa

------if (condicao = true) :ClasseB.msg2()

else :ClasseC.msg3()------

msg1()

Caminhos Condicionais Mutuamente Exclusivos

:ClasseA

BCC04/07/2017


1a.1:msg3()

:ClasseA :ClasseB

:ClasseC

msg1() 1a: [condição] msg2()

1b:[not condição] msg4()

:ClasseD

:ClasseE

1b.1:msg5()

2:msg6()

Caminhos Condicionais Mutuamente Exclusivos



BCC04/07/2017


Multiobjetos

Um multiobjeto é uma coleção de instâncias,representada por um único ícone

Uma mensagem pode ser enviada aomultiobjeto ou a cada membro da coleção

BCC04/07/2017


1: qt:=obterQuantidade( ) : Int

Mensagens para Multiobjetos

:Venda

msg1()

ItemLinhaVenda

mensagem enviada à coleção

*:Venda1*: id:=obterID( )

msg1()

ItemLinhaVenda

mensagem enviada a cada membro da

coleção



BCC04/07/2017


:Sistema

:Caixa

Comprar Itens

entrarItem(CUP, quantidade)

terminarVenda()

fazerPagamento(quantia)

troco, recibo

descrição item, total

iniciarNovaVenda( )

*[mais itens]

Exemplo TPV - DSS

BCC04/07/2017


Exemplo TPV – Modelo Conceitual

1..1

Pagamento

quantia

1..1

1..1

TPVVendadatahora

Paga-por

1..1 Capturada-em



BCC04/07/2017


Exemplo TPV – Diagrama de Colaboração

1:fazerPagamento(quantia):Venda:TPV

:Pagamento

1.1:criar(quantia)


BCC04/07/2017


Responsabilidade

Responsabilidade um contrato ou obrigação de um tipo ou classe serviços fornecidos por um elemento (classe ou subsistema) incorpora os objetivos de um elemento

Dois tipos de responsabilidades básicas: Fazer

fazer algo (criar um objeto, executar uma operação,…) iniciar ações em outros objetos coordenar e controlar atividades em outros objetos

Saber conhecer dados privados encapsulados conhecer objetos relacionados conhecer coisas que podem ser derivadas ou calculadas



BCC04/07/2017


Responsabilidade

Exemplos: “uma Venda é responsável por criar ItemLinhaVenda ” –

FAZER

“uma Venda é responsável por conhecer o seu total”-SABER

OBS: responsabilidades do tipo saberfreqüentemente podem ser deduzidas do modeloconceitual (atributos e associações)

BCC04/07/2017


Responsabilidades e Diagramas de Colaboração

Diagramas de colaboração mostram escolhas deatribuição de responsabilidade a objetos

Exemplo: atribuir aos objetos do tipo Venda aresponsabilidade de imprimirem a si próprios.

:Vendaimprimir()

Responsabilidade de imprimir a si própria



BCC04/07/2017


Responsabilidade

A “tradução” de responsabilidade em classes e métodos éinfluenciada pela granularidade da responsabilidade. Ex: “Fornecer acesso a bancos de dados relacionais” – pode

envolver muitas classes e métodos “Imprimir uma venda” – pode envolver apenas um ou alguns

poucos métodos

Os métodos são implementados para satisfazer umaresponsabilidade

Um objeto pode colaborar com outros objetos para atender auma responsabilidade

BCC04/07/2017


Exemplo

fazerPagamento(quantia):Venda

:Pagamento

1:criar(quantia)

Responsabilidade “Fazer Pagamento” atribuída ao objeto Venda colaboração entre Venda e Pagamento



BCC04/07/2017


Visibilidade entre Objetos

Visibilidade: capacidade de um objeto ver ou fazerreferência a outro

Para que um objeto A envie uma mensagem para oobjeto B, é necessário que B seja visível para A

Tipos de visibilidade por atributo: B é um atributo de A

por parâmetro: B é um parâmetro de um método de A

localmente declarada: B é declarado como um objeto localem um método de A

global: B é, de alguma forma, globalmente visível.

BCC04/07/2017


Visibilidade por atributo

Persiste por muito tempo

É a forma mais comum

Geralmente se deve às associaçõesexistentes no modelo conceitual

Ex: TPV tem um atributo para poder enviarmensagens ao Catálogo de Produtos.



BCC04/07/2017


Exemplo

:TPV

entrarItem(itemId,qtd)

:CatálogoProduto

1:espec:=obterEspec(itemId)

class TPV {

…private CatalogoProduto catalogo;…public void entrarItem(…);…

}

public void entrarItem(ID itemId, int qtd) {

EspecificacaoProduto espec;…espec = catalogo.obterEspecificacao(itemId);…

}

BCC04/07/2017


Visibilidade por parâmetro

É relativamente temporária, persiste enquantopersistir o método.

:TPV


:Venda2:criarItemLinha(espec,qtd)

:CatálogoProduto


il:ItemLinhaVenda

2.1:criar(espec,qtd)



BCC04/07/2017


Exemplo

:TPV



:CatálogoProduto


il:ItemLinhaVenda

public void criarItemLinha(EspecificaçãoProduto espec, int qtd) {…li = new ItemLinhaVenda(espec,qtd);…}

espec é passada como parâmetro para que Venda tenha visibilidade de EspecificaçãoProduto.

BCC04/07/2017


Visibilidade localmente declarada

Visibilidade relativamente temporária

Duas formas: criar uma nova instância local e atribuí-la a uma

variável local

atribuir o objeto retornado pela invocação de ummétodo a uma variável local.



BCC04/07/2017


Exemplo

public void criarItemLinha(EspecificaçãoProduto espec, int qtd) {

…ItemLinhaVenda li = new ItemLinhaVenda(espec,qtd);…

}

criação de instância local

public void entrarItem(ID itemId, int qtd) {

EspecificacaoProduto espec;…espec = catalogo.obterEspecificacao(itemId);…

}

atribuição de objeto a variável local

BCC04/07/2017


Visibilidade Global

Menos comum

Relativamente permanente (persisteenquanto A ou B existirem)

Forma óbvia e menos desejável: atribuir umainstância de objeto a uma variável global.



BCC04/07/2017


Notação de Visibilidade em UML

:msg()A B<<associação>>

:msg()A B<<global>>

:msg()A B<<local>>

:msg()A B<<parâmetro>>

<<associação>> é usada para visibilidade de atributo

BCC04/07/2017


Criando Diagramas de Colaboração

Atribuir responsabilidades e criar osdiagramas de colaboração são asatividades mais criativas da fase de projeto.

Não há soluções mágicas ou nãojustificadas. Elas devem ser baseadas emraciocínio lógico.



BCC04/07/2017



O caso de uso sugere eventos do sistema diagramas de seqüência do sistema

Os eventos de sistema representam mensagensque iniciam diagramas de colaboração

Os diagramas de colaboração ilustram como osobjetos interagem para realizar tarefas interação por mensagens de objetos de software, cujos

nomes podem ser inspirados pelos nomes dos conceitos(objetos) do Modelo Conceitual

BCC04/07/2017



Crie um diagrama separado para cada operação do sistema para cada evento do sistema, crie um diagrama com o evento

como a primeira mensagem Se o diagrama se tornar complexo, separe-o em diagramas

menores Use os padrões GRASP para apoiar as decisões sobre atribuição

de responsabilidades Use o modelo conceitual como apoio

conceitos podem inspirar criação de classes de software comorganização similar

Comece escolhendo a classe controladora do evento Exemplo sistema TPV…



BCC04/07/2017


Diagrama de Casos de UsoTPV

ComprarItens

Abrir

ReembolsarItens

Caixa Cliente

Administrador Do Sistema

Gerente

Adicionarnovos

usuários

Iniciar

BCC04/07/2017


Diagrama de Seqüência do Caso de Uso “Comprar Itens”

:Sistema

:Caixa

Comprar Itens

entrarItem(id,qtd)


troco, recibo


terminarVenda()

iniciarNovaVenda( )

*[mais itens]



BCC04/07/2017


Modelo Conceitual

1..1

1..1

Caixa

1..1

Gerente

1..*

1..*

*

1..1

1..1

Pagamento

quantia

1..1

1..1

Cliente

1..1

1..1TPV

1..1

Registra-Vendas-do

Iniciado por

*1..1

Loja

endereçonome

1..1

Possui

1..*1..1

CatálogoProdutos

*

1..1Usado-por

*

1..1

Venda

datahora

1..1

1..1Paga-por

1..1

1..1

Iniciada-por

1..1

*

Registra-Dados-da

1..1

1..1Capturada-em

1..*

Item

*

Estoca

0..1

1..1

EspecificaçãoProduto

descriçãopreçoUPC

1..*1..1

Contém

*

Descreve

*

ItemLinhaVenda

/quantidade

1..1

1..*

Contido-em

1..*

0..1

Registra-venda-de

1..1

*

Descritos-por

1..1

BCC04/07/2017



:Sistema

:Caixa

Comprar Itens

entrarItem(id,qtd)


troco, recibo


terminarVenda()

iniciarNovaVenda( )

*[mais itens]



BCC04/07/2017


Diagrama de Colaboração –iniciarNovaVenda

Quem é a classe controladora?

Opções: representando todo o sistema, um dispositivo ou um

subsistema TPV, SistemaTPV

representando um tratador de todos os eventos de umcenário de caso de uso ControladorDeComprarItens

TratadorDeComprarItens

BCC04/07/2017



Classe controladora (de acordo com padrãoControlador): TPV

Observação: na fase de projeto, o TPV é um objeto no “mundo do

software”, e não o registrador físico (como no ModeloConceitual) mesmo nome foi escolhido para diminuir gap semântico

:TPViniciarNovaVenda( )



BCC04/07/2017



Criar objeto Venda padrão Criador sugere atribuir a responsabilidade à classe que

agrega, registra ou contém o objeto a ser criado pelo Modelo Conceitual: TPV registra Venda

TPV é bom candidato para criar Venda

Pelo Modelo Conceitual: Venda possui váriosItemLinhaVenda. Então, quando uma Venda é criada, umacoleção vazia de ItemLinhaVenda deve ser criada paraarmazenar futuras instâncias pelo padrão Criador, Venda é um bom candidato para criar a

coleção

BCC04/07/2017



iniciarNovaVenda( )

:TPV :Venda1:criar ( )

:ItemLinhaVenda1.1:criar ( )

padrão Criador

padrão Controlador



BCC04/07/2017



:Sistema

:Caixa

Comprar Itens

entrarItem(id, qtd)


troco, recibo


terminarVenda()

iniciarNovaVenda( )

*[mais itens]

BCC04/07/2017


Diagrama de Colaboração –entrarItem


A cada tipo de item vendido está associado umItemLinhaVenda na Venda padrão Criador: Venda é candidata para criar

ItemLinhaVenda cada linha de venda criada será inserida na coleção de

ItemLinhaVenda associada à Venda

:TPVentrarItem(id, qtd )



BCC04/07/2017



Pelo Modelo Conceitual: ItemLinhaVenda tem quantidade eestá associado a EspecificaçãoProduto como obter a informação de especificação de produto por meio do

ID do item?

quem é o especialista nesta informação??

Modelo Conceitual: o CatálogoProdutos contém todas asespecificações pelo padrão Especialista, o CatálogoProduto ébom candidato para a responsabilidade de obter a especificação

quem vai enviar a mensagem obterEspecificação para o objetoCatálogoProduto??? é razoável assumir conexão permanente entre CatálogoProduto e

TPV ?

BCC04/07/2017


Diagrama de Colaboração – entrarItem

:TPV

entrarItem(id,qtd)


:CatálogoProduto

1:espec:=obterEspec(id)

il:ItemLinhaVenda


:EspecificaçãoProduto

1.1:espec:=buscar(id)

padrão Especialista

padrão Criador

:ItemLinhaVenda

2.2:adicionar(il)



BCC04/07/2017



E quanto às informações descrição e preço do itemque, segundo o diagrama de sequência do sistema,devem ser exibidas? não são responsabilidade dos objetos do domínio as

tarefas relacionadas a operações de saída do sistema isso deverá ser feito pela camada de apresentação tudo o que é necessário com relação às responsabilidades

de exibição de informação é que esta seja conhecida eesteja disponível nos objetos do domínio

BCC04/07/2017



:Sistema

:Caixa

Comprar Itens

entrarItem(id,qtd)


troco, recibo


terminarVenda()

iniciarNovaVenda( )

*[mais itens]



BCC04/07/2017


Diagrama de Colaboração –terminarVenda

Classe controladora (de acordo com padrão Controlador):TPV

Quem deve ser responsável por indicar que a venda estáterminada? razoável considerar que Venda tem um atributo booleano

(estaCompleta) que é verdadeiro quando a venda é finalizada

padrão Especialista: a própria Venda é uma candidataapropriada para atribuir o valor Verdadeiro ao atributoestaCompleta, já que é dona da informação (mantém o atributo)

:TPVterminarVenda ( )

BCC04/07/2017


:TPV

terminarVenda()

:Venda1:tornarseCompleta()

padrão Especialistapublic void tornarseCompleta( ) {

estaCompleta = True;}

Diagrama de Colaboração –terminarVenda



BCC04/07/2017


Diagrama de Colaboração –obterTotal

Terminada a venda, o sistema deve apresentar ototal (de acordo com a sequência típica de eventosdo caso de uso Comprar Itens)

Análise Lógica:1. definir a responsabilidade: quem deve ser responsável

por saber o total da venda?2. resumir informações requeridas

total da venda é a soma dos subtotais de todos os itensde linha de venda

o subtotal de cada item de linha de venda é dado por:quantidade de itens X preço item

BCC04/07/2017



Análise Lógica (cont.):3. listar classes que conhecem as informações

necessárias

Informação requerida Especialista

preço do produto EspecificaçãoProduto

quantidade de itens ItemLinhaVenda

todos os ItemLinhasVendas daVenda

Venda



BCC04/07/2017



Quem deve ser responsável por calcular o total da Venda?

pelo padrão Especialista: Venda (conhece todos osItemLinhaVenda)

O cálculo do total requer cálculo do subtotal de cadaItemLinhaVenda. Quem deve ser responsável por calcularesse subtotal? pelo padrão Especialista: ItemLinhaVenda (conhece quantidade

e EspecificaçãoProduto)

O cálculo do subtotal requer o preço do produto. Quem deveser responsável por fornecer o preço? pelo padrão Especialista: EspecificaçãoProduto (conhece preço)

BCC04/07/2017



1.1: p:=obterPreço( )

t:=obterTotal( ):Venda


:ItemLinhaVenda

*

1*: st:=obterSubtotal( )padrão Especialista

public float obterTotal( ) {

float tot = 0;for each il = ItemLinhaVenda

tot = tot + il.obterSubtotal();return tot;

}

public float obterSubtotal( ) {float subtot = quantidade*

:EspecificaoProduto.obterPreco();return subtot;

}



BCC04/07/2017



:Sistema

:Caixa

Comprar Itens

entrarItem(id,qtd)


troco, recibo


terminarVenda()

iniciarNovaVenda( )

*[mais itens]

BCC04/07/2017


Diagrama de Colaboração –fazerPagamento


Quem deve ser responsável pela criação dePagamento? Opções: padrão Criador

TPV – registra Pagamento e tem o valor inicial (quantia)para criação da instância

Venda – usa, de maneira bem próxima, Pagamento

:TPVfazerPagamento(quantia)



BCC04/07/2017



Avaliando as opções – considerar Coesão e Acoplamento escolha de Venda :

pelo Modelo Conceitual - já existe uma associação entre Venda ePagamento

trabalho de TPV fica mais leve aumenta coesão

TPV não toma conhecimento da existência de Pagamento favorece baixo acoplamento

BCC04/07/2017




1: fazer Pagamento(quantia)

:Pagamento

:Venda:TPV

1.1: criar( )

padrão Controladorpadrões Criador eAcoplamento Fraco



BCC04/07/2017



A venda completada deve ser registrada, por exemplo, numarquivo histórico da loja (ver Modelo Conceitual)

Quem deve ser responsável por conhecer todas as vendasregistradas e por registrá-las? padrão Especialista: a Loja conhece e registra todas as vendas

BCC04/07/2017





:Pagamento

v:Venda:TPV

1.1: criar( )

padrão Especialista

:Loja

vendascompletadas:Venda

2:adicionarVenda(v)

2.1:adicionar(v)



BCC04/07/2017


Diagrama de Colaboração –calcularTroco

Caso de Uso Comprar Itens requer que sejadevolvido o troco e apresentado o recibo a forma de exibição do troco e impressão do recibo não

cabe aqui, mas a informação tem que ser conhecida porobjetos do domínio

Quem deve ser responsável por saber/calcular otroco? padrão Especialista: Venda (conhece total da compra) e

Pagamento (conhece quantia paga) são especialistasparciais

BCC04/07/2017



Avaliando as opções: Pagamento : possui quantia paga, mas precisa pedir total

da compra para Venda Pagamento precisará ter visibilidade de Venda (o que ainda

não tem) aumento no acoplamento

Venda : possui total da compra, mas precisa solicitarquantia paga a Pagamento Venda já tem visibilidade de Pagamento (pois é seu

criador) não causa aumento no acoplamento, e portantoé a solução mais desejável



BCC04/07/2017



:Venda

trc:=calcularTroco( )

pg:Pagamento1: qtia:=obterQuantia( )

2: t:=obterTotal( )

public float calcularTroco( ) {

float troco = pg.obterQuantia - this.obterTotal();return troco;

}

BCC04/07/2017


Diagrama de Casos de UsoTPVComprar

Itens

Abrir

ReembolsarItens

Caixa Cliente

Administrador Do Sistema

Gerente

Adicionarnovos

usuários

Iniciar



BCC04/07/2017


Diagrama de Colaboração -iniciar

Deixe o diagrama de inicialização do sistema porúltimo garante que todas as informações que interessam às

atividades iniciais (que apóiam os demais eventos) tenhamsido avaliadas

Objetivo: criar o objeto inicial do domínio esse objeto cria os demais objetos necessários

BCC04/07/2017



Objeto inicial pode ou não assumir o controle do processo em geral, objeto inicial não assume o controle do processo

quando existe uma interface de usuário gráfica

Então, para operação iniciar: crie um diagrama de colaboração com primeira mensagem

criar() para o objeto inicial do domínio

(opcional) se o objeto inicial está assumindo o controle doprocesso, crie um outro diagrama de colaboração e envie umamensagem executar() ao objeto inicial



BCC04/07/2017



No TPV: iniciar ocorre quando Gerente liga o sistema

objeto inicial não assume controle do processo – apenasum diagrama para iniciar

Quem deve ser o objeto inicial do domínio? escolha um objeto que intuitivamente (e conceitualmente)

contenha todos os (ou a maioria dos) objetos do domínio

Ex: Loja

BCC04/07/2017



A partir dos diagramas anteriores, pode-seidentificar as tarefas iniciais: criar Loja, TPV, CatálogoProdutos, EspecificaçãoProduto

associar CatálogoProduto a EspecificaçãoProduto

associar Loja a CatálogoProduto

associar Loja a TPV

associar TPV a CatálogoProduto



BCC04/07/2017



:Loja

criar()

:TPV

:EspecificacãoProduto

ep:EspecificaçãoProduto

2 : criar (cp)

1:criar ( )

cp:CatálogoProdutos

1.1:criar ( )

1.2.2* : adicionar (ep)

1.2.1* : criar(id,preço,descrição)

1.2 : carregarEspecProduto( )

BCC04/07/2017


Comentários

Multiplicidade : observe que a loja só cria um objetoTPV a multiplicidade no Modelo Conceitual e no projeto de

objetos pode não ser a mesma

Persistência: num sistema real,EspecificaçãoProduto residirá num meio dearmazenamento permanente (arquivo em disco oubase de dados). portanto, a criação de objetos dessa classe é temporária e

não será refletida na implementação



BCC04/07/2017


Atividades da Fase ProjetarRefinarPlano

Sincronizarartefatos


1. Definir Casos deUso Reais

2. Definir Relatórios, IU e “Storyboards”

3. Refinar a arquitetura do sistema

4. Definir Diagramasde Interação

5. Definir Diagramas deClasses de Projeto

6. Definir o EsquemaDo Banco de Dados

BCC04/07/2017


Definição

O Diagrama de Classes de Projeto apresentaespecificações para classes de software einterfaces (ex: interfaces Java) de uma aplicação

Informação típica: classes, associações e atributos

interfaces, com operações e constantes

métodos

tipos dos atributos

navegabilidade

dependências



BCC04/07/2017


Definição (cont.)

Modelo Conceitual abstrações de conceitos, ouobjetos, do mundo real conceitos são também chamados de classes conceituais

Diagrama de Classes de Projeto definição declasses como componentes de software classes de software

Na prática, o Diagrama de classes pode serconstruído à medida que a fase de projeto avança,a partir dos diagramas de colaboração

BCC04/07/2017


Criando Diagramas de Classes

Identificar classes a partir dos diagramas de colaboração eilustrá-las

Acrescentar os atributos identificados no Modelo Conceitual Acrescentar os métodos provenientes dos diagramas de

colaboração Acrescentar tipos de atributos, parâmetros e retornos de

métodos Acrescentar as associações e navegabilidade (visibilidade por

atributo) Indicar relacionamentos de dependência (visibilidade não

implementada por atributo)



BCC04/07/2017









BCC04/07/2017


Identificando Classes… Diagramas de colaboração:

:TPV

entrarItem(id,qtd)


:CatálogoProduto


il:ItemLinhaVenda




:ItemLinhaVenda

2.2:adicionar(il)

Classes:TPVCatalogoProdutoEspecificacaoProdutoItemLinhaVendaVenda



BCC04/07/2017


Identificando Classes…

Classes:TPVCatalogoProdutoEspecificacaoProdutoItemLinhaVendaVenda



:Pagamento

v:Venda:TPV

1.1: criar( )

:Loja

vendascompletadas:Venda

2:adicionarVenda(v)

2.1:adicionar(v)

LojaPagamento

Diagramas de colaboração:

BCC04/07/2017











BCC04/07/2017


Exemplo

TPV CatálogoProdutosEspecificaçãoProduto

descriçãopreçoCUP

Loja


Loja

Conceitos (Modelo Conceitual)

endereço nome


endereço nome

Classes de software (Diagrama de Classes de Projeto)

BCC04/07/2017


Vendadatahora

Exemplo



Loja


Conceitos (Modelo Conceitual)

Classes de software (Diagrama de Classes de Projeto)

endereço nome

descriçãopreçoCUPestaCompleta

identificado durante a criação dos diagramas de colaboração



BCC04/07/2017









BCC04/07/2017


Acrescentando métodos…

VendadataestáCompletahora

:TPV

entrarItem(id,qtd)


:TPV

terminarVenda()

:Venda1:tornarseCompleta()

criarItemLinha(…)tornarseCompleta( )



BCC04/07/2017


Acrescentando métodos…


criarItemLinha(…)tornarseCompleta( )obterTotal( )fazerPagamento(…)calcularTroco( )



1: fazer Pagamento(quantia) v:Venda:TPV

:Venda

trc:=calcularTroco( )

pg:Pagamento1: qtia:=obterQuantia( )

BCC04/07/2017


Cuidados com a inserção de métodos

Linguagens de programação distintas podem tersintaxes distintas para métodos recomendável: usar sintaxe básica UML

nomeMétodo(Par1, Par2, … Parn)

Interpretação do método criar(): dependente dalinguagem de programação

Não incluir métodos de acesso a atritutos Ex: setData( ), getHora( ), …



BCC04/07/2017


Cuidados com a inserção de métodos (cont.)

Mensagens para multiobjetos: não incluir métodoscorrespondentes a mensagens enviadas a classe coleção tratamento da mensagem depende da implementação - a

coleção pode ser representada, por exemplo, por um set emC++

:CatálogoProduto




A mensagem buscar é para a coleção e não para EspecificaçãoProduto

A classe coleção não é representada

BCC04/07/2017











BCC04/07/2017


Acrescentando tipos…

Os tipos dos atributos e métodos podem,opcionalmente, ser acrescentados aos diagramasde classes de projeto se uma ferramenta CASE for utilizada para geração

automática de código, os tipos detalhados são necessários

se o diagrama for usado exclusivamente pordesenvolvedores de software, o excesso de informaçãopode “poluir” o diagrama e dificultar seu entendimento incluir informação de tipo quando relevante/necessária

BCC04/07/2017


Vendadata: DataestáCompleta: Booleanohora: Hora

criarItemLinha(espec:EspecificacaoProduto, qtd: Inteiro)tornarseCompleta( )obterTotal( ): MoedafazerPagamento(quantia:Moeda)calcularTroco( ): Moeda

Exemplo



BCC04/07/2017









BCC04/07/2017


Associações e Navegabilidade

Associações e navegabilidade entre classe sãoindicadas pelos diagramas de colaboração Navegabilidade indica possibilidade de navegação

unidirecional por meio de uma associação entre classes geralmente implica visibilidade por atributos

A multiplicidade e os nomes das associações sãoretirados do Modelo Conceitual

Notação: seta contínua



BCC04/07/2017


Associações e Navegabilidade

Indícios de associação e com presença denavegabilidade: A envia mensagem para B

A cria B

A precisa manter uma conexão com B

BCC04/07/2017


Exemplo

iniciarNovaVenda( )

:TPV :Venda1:criar ( ):ItemLinhaVenda1.1:criar ( )



TPV

terminarVenda( )entrarItem( )iniciarNovaVenda( )

Captura

1

vendaAtual: Venda

•TPV tem como atributo um objeto (ou uma referência para um objeto) do tipo Venda •Atributo pode ser omitido, pois está implícito na associação navegável

1



BCC04/07/2017


Exemplo



ItemLinhaVendaquantidade

obterSubTotal( )

Contém

1 *

• Venda tem como atributo (omitido) uma coleçãode objetos do tipo ItemLinhaVenda (multiplicidade *, do Modelo Conceitual)

:TPVentrarItem(id,qtd)


il:ItemLinhaVenda


:ItemLinhaVenda

2.2:adicionar(il)

BCC04/07/2017


Modelo Conceitual

1..1

1..1

Caixa

1..1

Gerente

1..*

1..*

*

1..1

1..1

Pagamento

quantia

1..1

1..1

Cliente

1..1

1..1TPV

1..1

Registra-Vendas-do

Iniciado por

*1..1

Loja

endereçonome

1..1

Possui

1..*1..1

Catálogo de Produtos

*

1..1Usado-por

*

1..1

Venda

datahora

1..1

1..1

Paga-por

1..1

1..1

Iniciada-por

1..1

*

Registra-Dados-da

1..1

1..1Capturada-em

1..*

Item

*

Estoca

0..1

1..1

Especificação de Produto

descriçãopreçoUPC

1..*1..1

Contém

*

Descreve

*

ItemLinhaVenda

/quantidade

1..1

1..*

Contido-em

1..*

0..1

Registra-venda-de

1..1

*

Descritos-por

1..1



BCC04/07/2017



:Loja

criar()

:TPV



2 : criar (cp)

1:criar ( )


1.1:criar ( )




BCC04/07/2017


Exemplo:Loja

criar()

1:criar ( )



Loja……

CatálogoProdutos

……

Usa 11..*



BCC04/07/2017


Contém

Exemplo:Loja

criar()



1:criar ( )


1.1:criar ( )




Loja……

CatálogoProdutos

……


……

Usa 11..*

1..*1

BCC04/07/2017


Exemplo:Loja

criar():TPV2 : criar (cp)

Loja……

TPV……

Possui

1

1..*

CatálogoProdutos

……

1..*

Recupera

• Note que esta associação não existe no Modelo Conceitual• A conexão entre TPV e CatálogoProduto foi identificada durante a criação de Diagramas de Colaboração• A mensagem criar(cp) enviada por Loja a TPV tem como parâmetro de construtor um objeto do tipo CatálogoProdutos, que será um atributo de TPV

1



BCC04/07/2017


Exemplo

Loja……

TPV……

CatalogoProduto

…… Especificação

Produto……

Possui

Usa

Contém

1..*

1

11..*

1..*1

1

CatalogoProduto

……

1..*

Recupera

BCC04/07/2017











BCC04/07/2017


Relacionamentos de Dependência

No Diagrama de Classes, o relacionamento dedependência representa a visibilidade entre classesque não é implementada por atributo visibilidade por parâmetro

visibilidade local ou global

Um objeto de uma classe A tem conhecimento(enxerga) um objeto da classe B

Notação: seta tracejada

BCC04/07/2017


Exemplo

:TPV

entrarItem(id,qtd)


:CatálogoProduto


il:ItemLinhaVenda




:ItemLinhaVenda

2.2:adicionar(il)

visibilidade por parâmetro

visi

bilid

ade

loca

l



BCC04/07/2017


Exemplo VendadataestáCompletahora


TPV

terminarVenda( )entrarItem( )iniciarNovaVenda( )

Captura

1 1



Dependência

BCC04/07/2017


Diagrama de Classes

1

Pagamento

quantia : Moeda

1

1 1..*

*

1

*

ItemLinhaVenda

quantidade : Inteiro

obterSubTotal( )

*

1..1

1..*

Especificação de Produto

descrição : Textopreço : QuantidadeCUP : CUP

^Descreve

1

1..*

1

Loja

endereço : Endereçonome : Texto

adicionarVenda(…)

1..1 1..1

Venda

data : Datahora : HoraestáCompleta : Booleano

tornarseCompleta( )criarItemLinha(…)fazerPagamento(...)obterTotal( )calcularTroco()

Paga-por

Contém

1

*

Registra-Dados-da >

Catálogo de Produtos

obterEspecificacao(…)

Usa

Contém

1..*

TPV

terminarVenda( )entrarItem(…)fazerPagamento(…)iniciarNovaVenda(…)

Possui

1..1 1..1

Captura

1.

Recupera





Padrões de Projeto

Uma breve introdução e GRASP

BCC04/07/2017


Padrões

Desenvolvedores de software experientescriaram um repertório de princípios gerais eboas soluções para guiar a construção desoftwares

Essas soluções foram descritas em umformato padronizado (nome, problema,solução) e podem ser usadas em outroscontextos



BCC04/07/2017


Padrões

Padrões usualmente não contêm novasidéias organizam conhecimentos e princípios existentes,

testados e consagrados

Padrão é uma descrição nomeada de umproblema e uma solução, que pode seraplicado em novos contextos

BCC04/07/2017


Padrões GRASP

GRASP = General Responsibility AssignmentSoftware Patterns

Descrevem princípios fundamentais de atribuiçãode responsabilidade a objetos

Alguns padrões GRASP principais: Especialista (Expert) Criador (Creator) Coesão alta (High Cohesion) Acoplamento fraco (Low Coupling) Controlador (Controller)



BCC04/07/2017


Controlador

Problema: Quem deve ser responsável por tratarum evento do sistema ?

Solução: A responsabilidade de receber ou tratar asmensagens de eventos (operações) do sistemapode ser atribuída uma classe que: represente todo o sistema, um dispositivo ou um

subsistema – chamado de controlador fachada - OU represente um cenário de um caso de uso dentro do qual

ocorra o evento TratadorDe<NomeDoCasoDeUso>,

ControladorDe<NomeDoCasoDeUso>

BCC04/07/2017


Controlador

Exemplo: quem vai tratar os eventos do sistema TPV?

:Caixa

:SistemaComprar Itens

terminarVenda()


troco, recibo

entrarItem(CUP, quantidade)


iniciarNovaVenda( )

*[mais itens]



BCC04/07/2017


Exemplo ID Item

Quantidade

Entrar Item

:Caixa

:CWindow

:????

Camada de Interface

Camada do Domínio

entrarItem(itemId, quantidade)

açãoExecutada(eventoDaAção)

BCC04/07/2017


Exemplo: Opções de Controlador

todo o sistema(controlador fachada):TPV

:TPVentrarItem(…)

:ControladorDeComprarItem

entrarItem(…)

• um tratador artificial do caso de uso: ControladorDeComprarItem



BCC04/07/2017


Discussão: Controladores Fachada

Um controlador fachada deve ser um objeto (do domínio) quesugira uma cobertura sobre outras camadas e que seja oponto principal para as chamadas provenientes da interfacecom o usuário ou de outros sistemas pode ser uma abstração de uma entidade física – ex: TPV pode ser um conceito que represente o sistema – ex:

sistemaTPV

São adequados quando não há uma quantidade muito grandede eventos de sistema

Não é possível redirecionar mensagens do sistema paracontroladores alternativos (ex: outros subsistemas )

BCC04/07/2017


Discussão :Controladores de Casos de Uso

Deve existir um controlador diferente para cada caso de uso

Não é um objeto do domínio, e sim uma construção artificialpara dar suporte ao sistema. Ex: ControladorDeComprarItem,ControladorDeDevolução

Pode ser uma alternativa se a escolha de controladoresfachada deixar a classe controladora com alto acoplamentoe/ou baixa coesão (controlador inchado por excesso deresponsabilidade)

É uma boa alternativa quando existem muitos eventosenvolvendo diferentes processos.



BCC04/07/2017


Controladores inchados

Classe controladora mal projetada - inchada coesão baixa – falta de foco e tratamentos de muitas

responsabilidades

Sinais de inchaço: uma única classe controladora tratando todos os eventos, que

são muitos. Comum com controladores fachada

o próprio controlador executa as tarefas necessárias paraatender o evento, sem delegar para outras classes (coesão alta,não especialista)

controlador tem muitos atributos e mantém informaçãosignificativa sobre o domínio, ou duplica informações existentesem outros lugares

BCC04/07/2017


Controlador

Curas para controladores inchados acrescentar mais controladores – misturar controladores

fachada e de casos de uso

delegar responsabilidades

Corolário: objetos de interface (como objetos“janela”) e da camada de apresentação não devemter a responsabilidade de tratar eventos do sistema



BCC04/07/2017


Controlador

Benefícios: aumento das possibilidades de reutilização de

classes e do uso de interfaces “plugáveis”.

conhecimento do estado do caso de uso –controlador pode armazenar estado do caso deuso, garantindo a seqüência correta de execuçãode operações

BCC04/07/2017


ExemploID Item

Quantidade

Entrar Item

:Caixa

:CWindow

:TPV

Camada de Interface

Camada do Domínio

entrarItem(itemId, quantidade)

açãoExecutada(eventoDaAção)

:Venda

criarItemLinhaVenda (itemId, quantidade)



BCC04/07/2017


Especialista

Problema: qual é o princípio mais básico deatribuição de responsabilidades a objetos ?

Solução: Atribuir responsabilidade aoespecialista da informação.

Exemplo: no sistema TPV, alguma classeprecisa conhecer o total geral de uma venda

BCC04/07/2017


Exemplo

Venda conhece o total da venda

ItemLinhaVenda conhece o subtotal dalinha

EspecificaçãoProduto conhece o preço doproduto.



BCC04/07/2017


1.1: p:=obterPreço( )


:EspecificaçãodeProduto

:LinhadeItemdeVenda

*

1*: st:=obterSubtotal( )

BCC04/07/2017


Discussão É o padrão mais utilizado

“Fazê-lo eu mesmo” objetos fazem coisas relacionadas à informação que

têm

Lembrar que existem especialistas parciais quecolaboram numa tarefa informação espalhada comunicação via mensagens

Tem uma analogia no mundo real

Especialista



BCC04/07/2017


Benefícios: Mantém encapsulamento favorece o acoplamento

fraco

O comportamento fica distribuído entre as classes quetêm a informação necessária (classes “leves”) favorece alta coesão

Contra-indicações contra indicado quando aumenta acoplamento e reduz

coesão

Ex: quem é responsável por salvar uma Venda nobanco de dados?

Especialista

BCC04/07/2017


Criador

Problema: Quem deveria ser responsável pela criação deuma nova instância de alguma classe ?

Solução: atribua à classe B a responsabilidade de criar umanova instância da classe A se uma das seguintes condiçõesfor verdadeira: B agrega objetos de A

B contém objetos de A

B registra objetos de A

B usa objetos de A

B tem os valores iniciais que serão passados para objetos deA, quando de sua criação



BCC04/07/2017


Criador

Exemplo: No sistema TPV, quem é responsável pela criaçãode uma instância de ItemLinhaVenda ?

1:criar(quantidade)

:VendacriarItemLinha (quantidade)

:ItemLinhaVenda

Venda contém vários itens de linha de venda

BCC04/07/2017


Discussão objetivo do padrão: definir como criador o objeto que

precise ser conectado ao objeto criado em algumevento escolha adequada favorece acoplamento fraco

objetos agregados, contêineres e registradores sãobons candidatos à responsabilidade de criar outrosobjetos

algumas vezes o candidato a criador é o objeto queconhece os dados iniciais do objeto a ser criado Ex: Venda e Pagamento

Criador



BCC04/07/2017


Exemplo

fazerPagamento(quantia):Venda

:Pagamento

1:criar(quantia)

Venda possui dados iniciais do pagamento

BCC04/07/2017


Criador

Benefícios favorece o acoplamento fraco

provavelmente o acoplamento não é aumentadoporque o objeto criado provavelmente já é visível parao objeto criador, devido às associações existentesque motivaram sua escolha como criador



BCC04/07/2017


Acoplamento

Acoplamento: dependência entre elementos(classes, subsistemas,…), normalmente resultantede colaboração para atender a umaresponsabilidade

O acoplamento mede o quanto um objeto estáconectado a, tem conhecimento de ou depende deoutros objetos acoplamento fraco (ou baixo) – um objeto não depende de

muitos outros acoplamento forte (ou alto) – um objeto depende de muitos

outros

BCC04/07/2017


Acoplamento

Problemas do acoplamento alto: mudanças em classes interdependentes forçam mudanças

locais

dificulta a compreensão do objetivo de cada classe

dificulta reutilização



BCC04/07/2017


Acoplamento Fraco

Problema: como favorecer a baixa dependência eaumentar a reutilização ?

Solução: Atribuir responsabilidade de maneira que oacoplamento permaneça baixo.

Exemplo: No sistema TPV, suponha que queremoscriar uma instância de pagamento e associá-la àvenda. Qual classe deve ser responsável por essatarefa?

BCC04/07/2017


Qual?

fazerPagamento( )1: criar( )

2 : adicionarPagamento(p)

p:Pagamento

:Venda

:TPV

Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV

fazerPagamento( )

1: fazer Pagamento( )

:Pagamento

:Venda:TPV

Projeto 2: alternativa – responsabilidade atribuída à Venda

1.1: criar( )



BCC04/07/2017


Qual projeto é melhor?

Qual dos projetos anteriores favorece oacoplamento fraco? em ambos os casos, Venda será acoplada a (terá

conhecimento de) Pagamento

projeto 1 – acoplamento entre Pagamento e TPV

projeto 2 – não aumenta acoplamento

PREFERÍVEL

BCC04/07/2017


Formas de Acoplamento

Um objeto tem um atributo que referencia umobjeto de outra classe

Um objeto tem um método que referencia umobjeto de outra classe parâmetro, variável local ou retorno

Um objeto invoca os serviços de um objeto de outraclasse

Uma classe é subclasse de outra, direta ouindiretamente



BCC04/07/2017


Discussão: Acoplamento fraco classes mais independentes

reduz impacto de mudanças

favorece reuso de classes

Considerado em conjunto com outros padrões

Extremo de acoplamento fraco não é desejável fere princípios da tecnologia de objetos – comunicação

por mensagens

projeto pobre: objetos inchados e complexos,responsáveis por muito trabalho baixa coesão

Acoplamento Fraco

BCC04/07/2017


Discussão: dica: concentre-se em reduzir o acoplamento em

pontos de evolução ou de alta instabilidade do sistema ex: cálculo de impostos terceirizados no sistema TPV

Benefícios: classe são pouco afetadas por mudanças em outras

partes

classes são simples de entender isoladamente

conveniente para reutilização

Acoplamento Fraco



BCC04/07/2017


Coesão

Coesão mede o quanto as responsabilidades de umelemento (classe, objeto, subsistema,…) são fortementefocalizadas e relacionadas

Objeto com Coesão Alta objeto cujas responsabilidadessão altamente relacionadas e que não executa um volumemuito grande de trabalho

Objeto com Coesão Baixa objeto que faz muitas coisasnão relacionadas ou executa muitas tarefas difícil de compreender, reutilizar e manter

constantemente afetadas por mudanças

BCC04/07/2017


Coesão Alta

Problema: Como manter a complexidade sobcontrole?

Solução: Atribuir responsabilidade de tal forma quea coesão permaneça alta.

Exemplo (o mesmo para o acoplamento fraco): Nosistema TPV, suponha que queremos criar umainstância de pagamento e associá-la à venda. Qualclasse deve ser responsável por essa tarefa?



BCC04/07/2017


Exemplo

fazerPagamento( )

1: criar( )

2 : adicionarPagamento(p)

p:Pagamento

:Venda

:TPV

Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV

O TPV toma parte na responsabilidade de fazer pagamento. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvessem 50 mensagens recebidas por TPV?

BCC04/07/2017


ExemploProjeto 2: alternativa – responsabilidade atribuída à Venda

Esta solução favorece uma coesão mais alta em TPV e também um acoplamento mais fraco. Portanto, projeto 2 é preferível.

fazerPagamento( )

1: fazer Pagamento( )

:Pagamento

:Venda:TPV

1.1: criar( )



BCC04/07/2017


Coesão Alta

Discussão: Coesão alta, assim como Acoplamento Fraco, são princípios que

devem ser considerados no projeto de objetos má coesão traz acoplamento ruim e vice-versa

regra prática: classe com coesão alta tem um númerorelativamente pequeno de métodos, com funcionalidadesrelacionadas, e não executa muito trabalho

analogia com mundo real ex: pessoas que assume muitas responsabilidades não

associadas podem tornar-se (e normalmente tornam-se)ineficientes

BCC04/07/2017


Coesão Alta

Benefícios mais clareza e facilidade de compreensão no projeto

simplificação de manutenção e acréscimo defuncionalidade/melhorias

favorecimento do acoplamento fraco

aumento no potencial de reutilização classe altamente coesa pode ser usada para uma

finalidade bastante específica





Próximos Passos...

BCC04/07/2017


Contextualizando…ISO 12207: Estrutura

Processos Fundamentais Processos de Apoio

Processos Organizacionais

Aquisição

Fornecimento

Desenvolvimento

Operação

Manutenção

Documentação

Garantia de Qualidade

Verificação

Validação

Revisão Conjunta

Auditoria

Resolução de Problemas

Gerência

Melhoria

Infra-estrutura

Treinamento

Ada

pta

ção

es i aula06n [modo de...

Documents