�1
Faculdade de Ciências e Tecnologia
Departamento de Matemática e Computação
Bacharelado em Ciência da Computação
Engenharia de Software II
Aula 01
Rogério Eduardo Garcia([email protected])
Bibliografia Básica
PRESSMAN, R. S. Engenharia de Software: umaabordagem profissional, 7ª Edição, McGraw-Hill-Bookman, Porto Alegre, 2011.
SOMMERVILLE, I. Engenharia de software, 9ª Edição,Ed. Pearson Prentice Hall, São Paulo, 2011.
PETERS, J.F., PEDRYCZ, W. Engenharia de software:teoria e prática, Editora Campus, Rio de Janeiro, 2001.
PFLEEGER, S. L., Engenharia de Software, Teoria ePrática. Pearson Brasil, 2004.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a2
�2
14/0
8/20
12R
ogér
io E
duar
do G
arci
a3
Avaliação
� As notas de todas as atividades – entre 0 (zero) e 10,0 (dez) – serão atribuídas individualmente, mesmo em atividades em grupo;
� A média final será calculada da seguinte maneira:– MA = (NP1 + 2*NP2)/3– Mt = (NT1 + NT2 +...+ NTn) / n– MT = (8 * NPJ + 2 * Mt)
� Média Final:– MF = (8*MA + 2*MT)/10 SE E SOMENTE SE (MA>=5 E MT>=5)
� Caso contrário (MA<5 OU MT<5)– MF = Menor Nota (MA ou MT)
� Onde:– MF = Média Final.– MA = Média de Provas– Mt = Média de Trabalho (exercícios e atividades ao longo da disciplina)– NPJ = Nota Projeto– MT = Média final dos trabalhos (parte prática)
� Caso o aluno não obtenha a nota mínima para aprovação, será aplicado o RegimeEspecial de Recuperação
14/0
8/20
12R
ogér
io E
duar
do G
arci
a4
Tópicos da Disciplina
� Gerenciamento de projetos de software
� Gerenciamento de riscos
� Gerenciamento de times
� Qualidade de software
�3
14/0
8/20
12R
ogér
io E
duar
do G
arci
a5
Metodologia
� Aulas expositivas teórico-práticas;
� Exercícios práticos;
� Projetos individuais e/ou em grupo;
� Trabalhos teóricos sobre tópicos abordados erelacionados
14/0
8/20
12R
ogér
io E
duar
do G
arci
a7
Abordagem Prática
� Vantagens– Mão na massa
– Prática
– Fixação
� Problemas potenciais– Falta de comprometimento dos alunos
– Dependência inter-grupos
– Importante a responsabilidade e consideração dosgrupos com os colegas
O sucesso depende de vocês!
�4
14/0
8/20
12R
ogér
io E
duar
do G
arci
a8
Engenharia de Software
A aplicação de uma abordagemsistemática, disciplinada e possível de sermedida para o desenvolvimento, operaçãoe manutenção do software (IEEE)
PROCESSO DE SOFTWARE
14/0
8/20
12R
ogér
io E
duar
do G
arci
a9
UsuárioDesenvolvedorOrganização
requisitos de software produto
Processo
de
Desenvolvimento
SOFTWARE
PRODUTO
requisitos
atendidos
SOFTWARE COM QUALIDADE
PROCESSO DE SOFTWAREDefinição
Avaliação
Qualidade de Software
�5
14/0
8/20
12R
ogér
io E
duar
do G
arci
a10
O Processo de Software
� Abrange um conjunto de três elementosfundamentais: Métodos, Ferramentas eProcedimentos para projetar, construir emanter grandes sistemas de software de formaprofissional
14/0
8/20
12R
ogér
io E
duar
do G
arci
a11
O Processo de Software
� MÉTODOS: proporcionam os detalhes decomo fazer para construir o software
� Planejamento e estimativa de projeto
� Análise de requisitos de software e de sistemas
� Projeto da estrutura de dados
� Algoritmo de processamento
� Codificação
� Teste
� Manutenção
�6
14/0
8/20
12R
ogér
io E
duar
do G
arci
a12
O Processo de Software
� FERRAMENTAS: dão suporte automatizadoaos métodos.
– Existem atualmente ferramentas para sustentarcada um dos métodos
– Quando as ferramentas são integradas, éestabelecido um sistema de suporte aodesenvolvimento de software chamado CASE -Computer Aided Software Engineering
14/0
8/20
12R
ogér
io E
duar
do G
arci
a13
O Processo de Software
� PROCEDIMENTOS: constituem o elo deligação entre os métodos e ferramentas
– Seqüência em que os métodos devem seraplicados
– Produtos que se exige que sejam entregues
– Controles que ajudam assegurar a qualidade ecoordenar as alterações
– Marcos de referência que possibilitam administraro progresso do software.
�7
14/0
8/20
12R
ogér
io E
duar
do G
arci
a14
Fases Genéricas dos Modelos de Processo de SOFTWARE
� Independentemente da natureza do projeto eaplicação os modelos de processo desoftware possuem:
– fase de definição– fase de desenvolvimento– fase de manutenção– atividades de apoio
14/0
8/20
12R
ogér
io E
duar
do G
arci
a15
Fase de Definição do Processo de Software
focaliza "o que" será desenvolvido� que informação vai ser processada� que função e desempenho são desejados� que comportamento pode ser esperado do
sistema� que interfaces vão ser estabelecidas� que restrições de projeto existem� que critérios de validação são exigidos para
definir um sistema bem sucedido� que tarefas serão realizadas
�8
14/0
8/20
12R
ogér
io E
duar
do G
arci
a16
Fase de Definição do Processo de Software
focaliza "o que" será desenvolvido
� que informação vai ser processada
� que função e desempenho são desejados
� que comportamento pode ser esperado do sistema
� que interfaces vão ser estabelecidas
� que restrições de projeto existem
� que critérios de validação são exigidos para definir umsistema bem sucedido
três tarefas principais ocorrem de alguma forma:
engenharia de sistemas
planejamento do projeto de software
análise de requisitos
14/0
8/20
12R
ogér
io E
duar
do G
arci
a17
Fase de Desenvolvimento do Processo de Software
Focaliza "como" o software será desenvolvido
� como os dados vão ser estruturados
� como a função vai ser implementada como umaarquitetura de software
� como os detalhes procedimentais vão serimplementados
� como as interfaces vão ser caracterizadas
� como o projeto será traduzido em uma linguagem deprogramação
� como os testes serão efetuados
�9
14/0
8/20
12R
ogér
io E
duar
do G
arci
a18
Fase de Desenvolvimento do Processo de Software
� Focaliza "como" o software será desenvolvido
� como os dados vão ser estruturados
� como a função vai ser implementada como umaarquitetura de software
� como os detalhes procedimentais vão serimplementados
� como as interfaces vão ser caracterizadas
� como o projeto será traduzido em uma linguagem deprogramação
� como os testes serão efetuados
três tarefas técnicas específicas deverão ocorrer sempre:
projeto de software
geração de código
Inspeção e teste de software
14/0
8/20
12R
ogér
io E
duar
do G
arci
a19
Fase de Manutenção do Processo de Software
focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional
� A fase de manutenção reaplica os passos das fasesde definição e desenvolvimento, mas faz isso nocontexto de um software existente.
�10
14/0
8/20
12R
ogér
io E
duar
do G
arci
a20
Fase de Manutenção do Processo de Software
� focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional
� A fase de manutenção reaplica os passos das fasesde definição e desenvolvimento, mas faz isso nocontexto de um software existente
As mudanças estão associadas com• correção de erros/defeitos• adaptações exigidas conforme o ambiente
do software evolui• mudanças devido a melhoramentos
ocorridos por alterações nos requisitos dos clientes
14/0
8/20
12R
ogér
io E
duar
do G
arci
a21
Atividades de Apoio ao Processo de Software
� As três fases genéricas do processo de software sãocomplementadas por uma série de atividades deapoio.
� As atividades de apoio são aplicadas durante toda aengenharia do software
�11
14/0
8/20
12R
ogér
io E
duar
do G
arci
a22
Atividades de Apoio ao Processo de Software
� As três fases genéricas do processo de software sãocomplementadas por uma série de atividades deapoio.
� As atividades de apoio são aplicadas durante toda aengenharia do software
Atividades típicas nessa categoria são:
� Controle e Acompanhamento do Projeto de Software� Revisões Técnicas Formais
� Garantia de Qualidade de Software� Gerenciamento de Configuração de Software
� Preparação e Produção de Documentos� Gerenciamento de Reusabilidade
� Medidas
14/0
8/20
12R
ogér
io E
duar
do G
arci
a23
Modelos de Processo de Software
� Existem vários modelos de processo desoftware (ou paradigmas de engenharia desoftware)
� Cada um representa uma tentativa de colocarordem em uma atividade inerentementecaótica
� Pode-se citar os seguintes modelos deprocesso de software
�12
14/0
8/20
12R
ogér
io E
duar
do G
arci
a24
Modelos de Processo de Software
� O Modelo Seqüencial Linear– também chamado Modelo Cascata
� O Modelo de Prototipação� O Modelo RAD (Rapid Application Development)� Modelos Evolutivos de Processo de Software
– O Modelo Incremental– O Modelo Espiral– O Modelo de Montagem de Componentes– O Modelo de Desenvolvimento Concorrente
� Modelo de Métodos Formais� Técnicas de Quarta Geração
14/0
8/20
12R
ogér
io E
duar
do G
arci
a25
Modelos de Processo de Software
� O Modelo Seqüencial Linear– também chamado Modelo Cascata
� O Paradigma de Prototipação� O Modelo RAD (Rapid Application Development)� Modelos Evolutivos de Processo de Software
– O Modelo Incremental– O Modelo Espiral– O Modelo de Montagem de Componentes– O Modelo de Desenvolvimento Concorrente
� Modelos de Métodos Formais� Técnicas de Quarta Geração
�13
14/0
8/20
12R
ogér
io E
duar
do G
arci
a26
O Modelo Cascata
� modelo mais antigo e o mais amplamenteusado da engenharia de software
� modelado em função do ciclo da engenhariaconvencional
� requer uma abordagem sistemática, seqüencialao desenvolvimento de software
� o resultado de uma fase se constitui na entradada outra
14/0
8/20
12R
ogér
io E
duar
do G
arci
a27
O Modelo Cascata
Engenharia de
SistemasAnálise de
Requisitos Projeto
Codificação
Testes
Manutenção
�14
14/0
8/20
12R
ogér
io E
duar
do G
arci
a28
Método Larman: Planejar e Elaborar
Planejar e Elaborar Construir Implantar
1. DefinirPlano Inicial
2. Criar Relatório deInvestigação Preliminar
3. Definir Requisitos
4. RegistrarTermos no Glossário a
5. ImplementarProtótipo bd
6. Definir Casos de Uso(Alto Nível e Essenciais)
7. Definir ModeloConceitual Inicial c
8. Definir ArquiteturaInicial do Sistema acd
9. Aperfeiçoar (Refinar)Plano
a on
goin
g
b o
pci
on
al
c ad
iável
d o
rdem
var
iad
a
14/0
8/20
12R
ogér
io E
duar
do G
arci
a29
Método Larman
Planejar e Elaborar Construir Implantar
1. DefinirPlano Inicial
2. Criar Relatório deInvestigação Preliminar
3. Definir Requisitos
4. RegistrarTermos no Glossário
5. ImplementarProtótipo
6. Definir Casos de Uso(Alto Nível e Essenciais)
7. Definir ModeloConceitual Inicial
8. Definir ArquiteturaInicial do Sistema
9. Aperfeiçoar (Refinar)Plano
Engenharia de Requisitos
�15
Desenvolvimento Iterativo
Planejar eelaborar
Construir Instalar
Ciclo de Desenvolvimento 1
Ciclo de Desenvolvimento 2
…
RefinarPlano
SincronizarArtefatos
Analisar Projetar Construir Testar
14/0
8/20
12R
ogér
io E
duar
do G
arci
a30
Refinar
Plano
Sincronizar
artefatosAnalisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas
de Casos de Uso
3. Refinar o Modelo
Conceitual
4. Refinar Glossário 5. Definir Diagramas de
Seqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
14/0
8/20
12R
ogér
io E
duar
do G
arci
a31
�16
Refinar
Plano
Sincronizar
artefatosAnalisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas
de Casos de Uso
3. Refinar o Modelo
Conceitual
4. Refinar Glossário 5. Definir Diagramas de
Seqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
14/0
8/20
12R
ogér
io E
duar
do G
arci
a32
Refinar
Plano
Sincronizar
artefatosAnalisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas
de Casos de Uso
3. Refinar o Modelo
Conceitual
4. Refinar Glossário 5. Definir Diagramas de
Seqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
14/0
8/20
12R
ogér
io E
duar
do G
arci
a33
�17
Desenvolvimento Iterativo
Planejar eelaborar
Construir Instalar
Ciclo de Desenvolvimento 1
Ciclo de Desenvolvimento 2
…
RefinarPlano
SincronizarArtefatos
Analisar Projetar Construir Testar
Próximo passo...
14/0
8/20
12R
ogér
io E
duar
do G
arci
a34
Refinar
Plano
Sincronizar
artefatosAnalisar Projetar Construir Testar
1. Definir Casos de
Uso Reais
2. Definir Relatórios,
IU e “Storyboards”
3. Refinar a arquitetura
do sistema
4. Definir Diagramas
de Interação
5. Definir Diagramas de
Classes de Projeto6. Definir o Esquema
Do Banco de Dados
Atividades da Fase Projetar
14/0
8/20
12R
ogér
io E
duar
do G
arci
a35
�18
Atividades da Fase Projetar
Refinar
Plano
Sincronizar
artefatosAnalisar Projetar Construir Testar
1. Definir Casos de
Uso Reais
2. Definir Relatórios,
IU e “Storyboards”
3. Refinar a arquitetura
do sistema
4. Definir Diagramas
de Interação
5. Definir Diagramas de
Classes de Projeto6. Definir o Esquema
Do Banco de Dados
14/0
8/20
12R
ogér
io E
duar
do G
arci
a36
Faculdade de Ciências e Tecnologia
Departamento de Matemática e Computação
Bacharelado em Ciência da Computação
Padrões de Projeto(revisão)
Uma breve introdução e GRASP
�19
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a38
Padrões
� Padrões usualmente não contêm novas idé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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a39
�20
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)
14/0
8/20
12R
ogér
io E
duar
do G
arci
a40
Controlador
� Problema: Quem deve ser responsável por tratarum evento do sistema ?
� Solução: A responsabilidade de receber ou trataras mensagens 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>
14/0
8/20
12R
ogér
io E
duar
do G
arci
a41
�21
Controlador
� Exemplo: quem vai tratar os eventos do sistema TPV?
:Caixa
:SistemaComprar Itens
terminarVenda()
fazerPagamento(quantia)
troco, recibo
entrarItem(CUP, quantidade)
descrição item, total
iniciarNovaVenda( )
*[mais itens]
14/0
8/20
12R
ogér
io E
duar
do G
arci
a42
ExemploID Item
Quantidade
Entrar Item
:Caixa
:CWindow
:????
Camada de Interface
Camada do Domínio
entrarItem(itemId, quantidade)
açãoExecutada(eventoDaAção)
14/0
8/20
12R
ogér
io E
duar
do G
arci
a43
�22
Exemplo: Opções de Controlador
� todo o sistema(controlador fachada):TPV
:TPVentrarItem(…)
:ControladorDe
ComprarItem
entrarItem(…)
• um tratador artificial do caso de uso: ControladorDeComprarItem
14/0
8/20
12R
ogér
io E
duar
do G
arci
a44
Discussão: Controladores Fachada
� Um controlador fachada deve ser um objeto (do domínio)que sugira uma cobertura sobre outras camadas e que sejao ponto principal para as chamadas provenientes dainterface com 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 muitogrande de eventos de sistema
� Não é possível redirecionar mensagens do sistema paracontroladores alternativos (ex: outros subsistemas )
14/0
8/20
12R
ogér
io E
duar
do G
arci
a45
�23
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.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a46
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ãoalta, não especialista)
– controlador tem muitos atributos e mantém informaçãosignificativa sobre o domínio, ou duplica informaçõesexistentes em outros lugares
14/0
8/20
12R
ogér
io E
duar
do G
arci
a47
�24
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ãodevem ter a responsabilidade de tratar eventos dosistema
14/0
8/20
12R
ogér
io E
duar
do G
arci
a48
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 de uso,garantindo a seqüência correta de execução deoperações
14/0
8/20
12R
ogér
io E
duar
do G
arci
a49
�25
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)
14/0
8/20
12R
ogér
io E
duar
do G
arci
a50
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a51
�26
Exemplo
� Venda � conhece o total da venda
� ItemLinhaVenda � conhece o subtotal da linha
� EspecificaçãoProduto � conhece o preço doproduto.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a52
1.1: p:=obterPreço( )
t:=obterTotal( ):Venda
:Especificaçãode
Produto
:LinhadeItemdeVenda
*
1*: st:=obterSubtotal( )
14/0
8/20
12R
ogér
io E
duar
do G
arci
a53
�27
� Discussão– É o padrão mais utilizado
– “Fazê-lo eu mesmo”
� objetos fazem coisas relacionadas à informação quetêm
– Lembrar que existem especialistas parciais quecolaboram numa tarefa
� informação espalhada → comunicação viamensagens
– Tem uma analogia no mundo real
Especialista
14/0
8/20
12R
ogér
io E
duar
do G
arci
a54
� 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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a55
�28
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a56
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a57
�29
� 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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a58
Exemplo
fazerPagamento(quantia):Venda
:Pagamento
1:criar(quantia)
� Venda possui dados iniciais do pagamento
14/0
8/20
12R
ogér
io E
duar
do G
arci
a59
�30
Criador
� Benefícios– favorece o acoplamento fraco
� provavelmente o acoplamento não é aumentado porque oobjeto criado provavelmente já é visível para o objetocriador, devido às associações existentes que motivaramsua escolha como criador
14/0
8/20
12R
ogér
io E
duar
do G
arci
a60
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a61
�31
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a62
Acoplamento Fraco
� Problema: como favorecer a baixa dependência eaumentar a reutilização ?
� Solução: Atribuir responsabilidade de maneira queo acoplamento permaneça baixo.
� Exemplo: No sistema TPV, suponha quequeremos criar uma instância de pagamento eassociá-la à venda. Qual classe deve serresponsável por essa tarefa?
14/0
8/20
12R
ogér
io E
duar
do G
arci
a63
�32
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( )
14/0
8/20
12R
ogér
io E
duar
do G
arci
a64
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a65
�33
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a66
� 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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a67
�34
� 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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a68
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a69
�35
Coesão Alta
� Problema: Como manter a complexidade sobcontrole?
� Solução: Atribuir responsabilidade de tal formaque a 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.Qual classe deve ser responsável por essa tarefa?
14/0
8/20
12R
ogér
io E
duar
do G
arci
a70
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?
14/0
8/20
12R
ogér
io E
duar
do G
arci
a71
�36
Exemplo
Projeto 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( )
14/0
8/20
12R
ogér
io E
duar
do G
arci
a72
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ãoassociadas podem tornar-se (e normalmente tornam-se)ineficientes
14/0
8/20
12R
ogér
io E
duar
do G
arci
a73
�37
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 umafinalidade bastante específica
14/0
8/20
12R
ogér
io E
duar
do G
arci
a74
Faculdade de Ciências e Tecnologia
Departamento de Matemática e Computação
Bacharelado em Ciência da Computação
Próximos Passos...
�38
Tipos de Padrões
14/0
8/20
12R
ogér
io E
duar
do G
arci
a76
Factory Method
� Classificação: Criacional.
� Conhecido como: Virtual Constructor
� Propósito:– Definir uma interface ou classe abstrata para a criação
de um objeto, permitindo decidir qual dasimplementações ou subclasses devem ser instanciadas;deixa uma classe deferir instanciação para subclasses[Gamma et al, 1994].
– Retornar uma instância dentre muitas possíveis classes,dependendo dos dados providos a ele [Destro, 2004].(dependendo do parâmetro passado na sua invocação)
14/0
8/20
12R
ogér
io E
duar
do G
arci
a77
�39
Factory Method
� Motivação:
– Útil para se construir objetos individuais, para umpropósito específico, sem que a construção requeiraconhecimento das classes específicas sendoinstanciadas.
– Uma classe de abstração é criada, contendo um métodoem que decide qual das opções de classe retornar.Então, apenas este método é invocado, sem conhecer aclasse que será retornada por ele [Destro, 2004].Por isso, este padrão é chamado de Factory Method(“método-fábrica”): um método é responsável pela“fabricação” de um objeto [Gamma et al, 1994].
14/0
8/20
12R
ogér
io E
duar
do G
arci
a78
Factory Method
� Aplicabilidade:
– Quando uma classe não pode antecipar ou conhecer aclasse dos objetos que deve criar;
– Quando uma classe quer suas subclasses paraespecificar os objetos que cria;
– Quando classes delegam responsabilidade à algumadas várias subclasses ajudantes, e deseja-se localizarqual é a subclasse ajudante acessada.
[Gamma et al, 1994]
14/0
8/20
12R
ogér
io E
duar
do G
arci
a79
�40
Factory Method
� Estrutura:Onde:•Super : é a classe abstrata (ou superclasse) dos objetos que o “método-fábrica” cria. •Sub [n]: classes que vão herdar
(ou implementar) a classe abstrata (ou interface) Super. Representam as diferentes classes sobre as quais se deve decidir instanciar.
•Factory : nesta classe reside o
“método-fábrica”, que avalia o parâmetro passado na sua invocação, para retornar um determinado objeto do tipo Super.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a80
Factory Method
� Conseqüências
– Vantagens:
� Dá maior flexibilidade para as classes.� Factory Methods eliminam a necessidade de colocar
classes específicas da aplicação no código:– Sendo um exemplo de aplicação:
– O código só lida com a interface Produto– O código pode portanto funcionar com qualquer classe
ProdutoConcreto
14/0
8/20
12R
ogér
io E
duar
do G
arci
a81
�41
Factory Method
� Conseqüências
– Desvantagens:
� Em alguns casos, pode ser criada uma relaçãosuperclasse-subclasse para a criação de classes quesuportam o “método-fábrica”, e de acordo com a classe aser criada, uma das várias subclasses podemsobrescrever o “método-fábrica”, a fim de conectarhierarquias de classes paralelas e fornecer maiorportabilidade [Gamma et al, 1994].
14/0
8/20
12R
ogér
io E
duar
do G
arci
a82
Factory Method
� Implementação 1:
Onde:•Main: é a classe Java que inicializa aexecução do aplicativo.•O "método-fábrica" de CarroFactory éinvocado (é um método estático, o quedispensa a instanciação da classe à qualpertence).•A opção escolhida em CarroFactory épassada como parâmetro na invocaçãodo "método-fábrica", o que lhe permiteidentificar qual subclasse de Carro deveser instanciada (Gol, Golf, Vectra ouÔmega), contendo as informações aserem consultadas (por exemplo, preço).
14/0
8/20
12R
ogér
io E
duar
do G
arci
a83
�42
Factory Method
� Usos Conhecidos
– Factory Methods são comumente usados em toolkits eframeworks
14/0
8/20
12R
ogér
io E
duar
do G
arci
a84
Factory Method
� Resumo
– Factory Method é apenas um apelido para ummétodo que instancia objetos. Como uma fábrica, otrabalho do Factory Method é criar objetos.
– Factory Method é útil quando você não está certode que implementação concreta da classeinstanciar. Você pode deixar esses detalhes com oFactory Method.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a85
�43
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
14/0
8/20
12R
ogér
io E
duar
do G
arci
a86
Abordagem Prática
� Separação em equipes
� Mesma equipe assume papéis distintos ematividades do desenvolvimento
� Exemplo:– Equipes E1, E2, E3 e E4
– Projetos P1
– E1 gerencia as atividades, planejando as tarefas econtrolando seus resultados. E2 é responsável poratividades de SQA. E3 é responsável pela Análise eProjeto. E E4 é responsável pela implementação.
14/0
8/20
12R
ogér
io E
duar
do G
arci
a87
�44
Conteúdo:
� Parte 1:– Gerenciamento & Qualidade
– Plano de Projeto - aspectos gerais
� Parte 2:– Plano de Projeto - Métricas e Estimativas
� Parte 3:– Plano de Projeto - Cronograma e Controle
� Parte 4:– Exercícios de Fixação
1 2 3 4 5
14/0
8/20
12R
ogér
io E
duar
do G
arci
a88
Atividade
� Definir os Grupos/Equipes
14/0
8/20
12R
ogér
io E
duar
do G
arci
a89
�45
Distribuição de atividades
Grupos Equipes Identificação P1 P2 P3 P41 11 Gerência SQA An&Prj Codifica2 12 Codifica Gerência SQA An&Prj8 13 An&Prj Codifica Gerência SQA4 14 SQA An&Prj Codifica Gerência13 21 Gerência SQA An&Prj Codifica14 22 Codifica Gerência SQA An&Prj10 23 An&Prj Codifica Gerência SQA7 24 SQA An&Prj Codifica Gerência12 31 Gerência SQA An&Prj Codifica11 32 Codifica Gerência SQA An&Prj6 33 An&Prj Codifica Gerência SQA3 34 SQA An&Prj Codifica Gerência
Projetos
1
2
3
14/0
8/20
12R
ogér
io E
duar
do G
arci
a90