Engenharia de Software II - :: UNESP : Campus de Presidente … · 2014-11-20 · Engenharia de...

�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


� 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


� 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


� 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


� 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


� 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


…

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


1. Definir Casos

de Uso Essenciais


de Casos de Uso

3. Refinar o Modelo

Conceitual




de Operação


de Estado

Método Larman

14/0

8/20

12R

ogér

io E

duar

do G

arci

a32

Refinar

Plano

Sincronizar


1. Definir Casos

de Uso Essenciais


de Casos de Uso

3. Refinar o Modelo

Conceitual




de Operação


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



…

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


1. Definir Casos de

Uso Reais

2. Definir Relatórios,

IU e “Storyboards”

3. Refinar a arquitetura

do sistema


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


1. Definir Casos de

Uso Reais

2. Definir Relatórios,

IU e “Storyboards”

3. Refinar a arquitetura

do sistema


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




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




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

Engenharia de Software II - :: UNESP : Campus de Presidente … · 2014-11-20 · Engenharia de...

Documents

Transcript of Engenharia de Software II - :: UNESP : Campus de Presidente … · 2014-11-20 · Engenharia de...