Escolar Documentos
Profissional Documentos
Cultura Documentos
DCA/FEEC/UNICAMP
Objetivos
ilmr
Slide 2
Apresentar principais tendncias no desenvolvimento de software; Compreender conceitos da orientao a objetos de modo a obter software que pode ser (de fato) reutilizado; e Como aplicar esses conceitos para o desenvolvimento de software reutilizvel em C++.
Pblico-alvo
Programadores com conhecimento de C++ e com experincia de participao em projetos de sistemas de software. Slide 3
Slide 4
ilmr
Como voc se descreveria em termos de sua atividade prossional? Por que desenvolver software parte de sua atividade?
Viso geral
Desenvolvimento de software
Estratgias bsicas Tendncias atuais Problemas no desenvolvimento de projetos
Desenvolvimento
Slide 5
de software
Slide 6
ilmr
Slide 8
ilmr
O foco na qualidade em desenvolvimento de software depende da aplicao consistente e disciplinada de processos: estabelecimento de uma base slida para o desenvolvimento de software mtodos: estratgias e tcnicas para a construo de software ferramentas: suporte automatizado para processos e mtodos
Qualidade de software
Slide 9
Ferramentas
Mtodos
Processo
Slide 10
ilmr
Combinaes e variaes em torno de Anlise: capturar informao sobre o domnio do problema e construir modelos operacionais para o sistema Projeto: transformar modelos da anlise em modelos de elementos computacionais Codicao: implementar os elementos computacionais do sistema Teste: encontrar erros na implementao Manuteno: tudo de novo a cada mudana Resultado: cdigo (o produto nal)
11
Slide 11
Slide 12
ilmr
13
Slide 13
Slide 14
ilmr
OI-4: meta-ignorncia
no sabe sobre as cinco ordens de ignorncia
15
Slide 16
ilmr
Slide 15
Modelos
Abstrao de um sistema semanticamente fechada
17
Slide 17
Slide 18
ilmr
Transio dos modelos de projeto para o cdigo facilitada pelo vocabulrio comum Linguagens orientadas a objetos permitem expressar diretamente os conceitos usados no desenvolvimento orientado a objetos
classes, atributos e mtodos objetos associaes e composies herana: reaproveitamento de denies
Com a orientao a objetos, voc poder reaproveitar cdigo j desenvolvido e assim acelerar a produo de software. Porm, muitas vezes usamos software genrico em nossos desenvolvimentos
na forma como est ou adaptado s nossas necessidades.
19
Slide 19
Como desenvolver software que pode ser reaproveitado, sem cair nas velhas armadilhas do desenvolvimento de software?
ilmr
Slide 20
21
Slide 21
Pressa: quando o deadline se aproxima, qualquer coisa que parece funcionar aceitvel Apatia: no resolver problemas conhecidos Slide 22 Mente estreita: no praticar solues reconhecidas como efetivas Preguia: tomar decises pobres usando a resposta fcil Avareza: apegar-se a detalhes excessivos na modelagem Ignorncia: no buscar compreender (e.g., migrao de cdigo) Orgulho: sndrome do no-foi-feito-por-ns
ilmr
23
Slide 23
ilmr
Slide 24
Propsito desenvolver e implementar estratgias para resolver os problemas decorrentes das ms prticas Se h problemas, preciso motivar pessoas a assumirem responsabilidades
1. Qual o problema? 2. O que outras pessoas esto fazendo para contribuir para a soluo deste problema? 3. O que voc est fazendo para contribuir para a soluo deste problema?
No basta apontar onde est o problema, mas preciso indicar caminhos para a soluo No desenvolvimento de software, tcnicas bsicas de refabricao de programas incluem:
Abstrao para superclasse Eliminao condicional Abstrao agregada
25
Slide 25
Slide 26
ilmr
Aplicvel a duas ou mais classes similares 1. Transformar assinaturas de mtodos similares em assinaturas comuns 2. Criar superclasse abstrata 3. Modicar cdigo para combinar implementaes selecionadas 4. Migrar mtodos comuns para superclasse
Eliminao condicional
Estrutura e comportamento de uma classe muito dependente de um comando condicional 1. Criar novas subclasses correspondentes a cada condio 2. Migrar o cdigo de ao associado a cada condio para a nova subclasse 3. Redirecionar as referncias s classes para indicar a subclasse adequada
Pode afetar construtores, declaraes de tipo e invocaes a mtodos sobrecarregados
27
Abstrao agregada
Slide 27
Forma geral: Uma classe monopoliza o processamento, outras classes encapsulam dados Slide 28
Sintomas e conseqncias: classes com grande nmero de atributos ou mtodos, perdendo as vantagens da orientao a objetos e tornando difcil teste e reuso Soluo: identicar atributos e operaes relacionadas de acordo com contratos coesos, migrando essas colees de funcionalidades para seus lares naturais; revisar associaes
ilmr
Reorganiza relacionamentos de classes para melhorar estrutura e extensibilidade Possveis formas Transformar relacionamentos de herana em relacionamentos de agregao Migrar classes agregadas para relacionamentos de componentes Migrar relacionamentos de componentes para relacionamentos de agregao
Antipadro: A Bolha
Esta classe o corao de nossa arquitetura!
29
Forma geral: fragmentos de cdigo, variveis de classes aparentemente no relacionados com o sistema Slide 29 Sintomas e conseqncias: segmentos complexos sem documentao, blocos de cdigo comentados sem explicao; se no removido, continua a proliferar pelo sistema e outros desenvolvedores (apressados, intimidados) vo trabalhando ao redor dos uxos de lava, gerando um sistema impossvel de se entender ou documentar Soluo: no desenvolvimento, ter uma arquitetura slida (interfaces estveis, bem denidas e documentadas) antes de gerar cdigo; na manuteno, trabalho de detetive (descoberta de sistema)
Forma geral: Desenvolvimento baseado na decomposio funcional, fazendo classes a partir de subrotinas Slide 30 Sintomas e conseqncias: classes com nomes de funes, contendo um nico mtodo, e nenhum uso de princpios bsicos da orientao a objetos; nenhuma esperana de reusar software Soluo: denir modelos de anlise e de projeto para tentar compreender e explicar o sistema; para classes fora do modelo de projeto, tentar combinar com classes existentes ou transform-las em funes de uso geral
ilmr
31
Antipadro: Poltergeists
Eu no sei bem o que essa classe faz, mas certamente importante.
Forma geral: Classes com ciclo de vida breve, que aparecem brevemente e depois desaparecem Slide 31 Sintomas e conseqncias: Objetos e classes temporrios, com associaes transientes, levando a modelos de objetos desnecessariamente complexos Solues: aes associadas a poltergeists devem ser movidas para as classes que elas referenciavam, removendo as classes fantasmas do modelo
Forma geral: Todas as solues de uma equipe usam um produto no qual a equipe tornou-se prociente Slide 32 Sintomas e conseqncias: Mesmas ferramentas e produtos usadas em produtos conceitualmente diversos, com a arquitetura do sistema sendo melhor descrita pelo produto, ambiente ou ferramenta; resultado em geral podem ter baixo desempenho e escalabilidade, sendo dependentes do vendedor ou da tecnologia Soluo: Suportar losoa de buscar novas tecnologias; projetar e desenvolver sistemas com limites claros para a substituio de componentes individuais.
ilmr
33
Forma geral: Programas ou sistemas com pouca estrutura de software Slide 33 Sintomas e conseqncias: Mtodos muito orientados a processos, com o uxo de execuo ditado pela implementao de objetos; muitos mtodos sem parmetros, usando variveis de classe (globais), sendo de difcil reuso Soluo: preveno (uso apropriado de orientao a objetos); manuteno para limpeza de cdigo (estratgias de refabricao de programas), principalmente quando for acrescentar alguma nova funcionalidade ao cdigo espaguete
Slide 34
Forma geral: Presena de vrios segmentos similares de cdigo espalhados pelo sistema Sintomas e conseqncias: Os mesmos bugs reaparecendo, apesar de vrias correes locais; maior tempo de reviso e inspeo de cdigo; maior custo na manuteno do software Soluo: Enfatizar estratgia de reuso caixa-preta no desenvolvimento ou re-estruturao do cdigo
ilmr
35
Sistemas encanamento: integrao ponto-a-ponto Travamento ao vendedor: no se esquea de renovar a licena Slide 35
Arquitetura por implicao: j zemos sistemas assim antes Projeto por comit: camelo (s.m.): cavalo projetado por um comit
Paralisia da anlise: melhor repensar esses modelos de anlise para torn-los mais orientados a objetos Slide 36 Morte por planejamento: no podemos comear enquanto no houver um plano completo de programao Espigas de milho: sujeitinho difcil de trabalhar. . . Gerenciamento irracional: as prioridades do projeto so as minhas! Falta de gerenciamento: o que aconteceu de errado? Estava tudo indo to bem
ilmr
37
Padres de projeto
Slide 37
Slide 38
ilmr
39
Slide 39
Identicao de objetos: auxiliam a identicar abstraes recorrentes de forma genrica Granularidade de objetos: indicam como representar subsistemas como objetos ou suportar vrios objetos pequenos Especicao de interfaces: indicam os conceitos chaves que devem (ou no devem) estar na interface de um objeto, assim como relacionamentos entre interfaces Especicao de implementao: indicam que classes devem ser abstratas (puras) ou concretas, embora a implementao deva sempre favorecer referncias a interfaces
Slide 40
ilmr
Cdigo
41
Slide 41
area( )
Slide 42
width height
re tu rn rec ta ng le > a rea ()
ilmr
Objetos, interfaces, classes e herana no garantem reuso Abordagens de reuso na orientao a objetos: Herana de classes: reuso caixa-branca, denio esttica (tempo de compilao), simples, mas expe superclasse Composio de objetos: reuso caixa-preta, denio dinmica (obter referncia durante execuo), mais complexo de compreender (uso de delegao, principalmente) Padres de projeto favorecem equilbrio desses mecanismos Outra abordagem de reuso, no ligada OO: templates (C++)
Derivao vs delegao
Rectangle
rec ta ng le re tu rn wid th*h e igh t
Rectangle
Window
area( )
area( )
width height
Window
43
Agregao vs associao
Slide 43
Slide 44
ilmr
Agregao: objeto composto por outros objetos ou um objeto parte de outro objeto
mesmo tempo de vida
Potenciais problemas no projeto de sistemas modicveis: Criar objetos especicando explicitamente sua classe
Assume compromisso com uma implementao em particular, podendo comprometer futuras modicaes Padres de projeto associados: Mtodo Fbrica, Fbrica Abstrata, Prottipo
45
Slide 45
Estrutura:
Criador
Produto
metodoFabrica() umaOperacao()
produto = metodoFabrica()
Slide 46
ProdutoConcreto
CriadorConcreto
metodoFabrica()
return new ProdutoConcreto
ilmr
47
Slide 47
Estrutura:
Cliente Fbr icaAbs tr ata
P r odutoAAbs tr ato
criaProdutoA() criaProdutoB()
ProdutoA1
ProdutoA2
F bricaConcreta2 F bricaConcreta1
Slide 48
P r odutoBAbs tr ato
ProdutoB1
ProdutoB2
ilmr
49
Padro: Prottipo
Objetivo: Especicar o tipo de objeto que deve ser criado usando uma instncia de prottipo e criar novos objetos copiando este prottipo Aplicabilidade: sistema deve ser independente de como objetos devem ser criados, compostos ou representados, e
Conseqncias: permite acrescentar e remover produtos em tempo de execuo; reduz nmero de subclasses; classes devem implementar um mtodo clone (nem sempre simples)
Estrutura:
Cliente
operacao()
prototype
Slide 50
p = prototype > clone()
ilmr
Slide 49
classes a serem instanciadas so conhecidas apenas no momento da execuo, ou para evitar construir uma hierarquia de fbricas paralela hierarquia de classes de produtos
Prototipo
clone()
PrototipoConcreto1
clone()
PrototipoConcreto2
clone()
51
Slide 52
Objetivo: Evitar o acoplamento direto de um solicitante em relao ao atendente de uma requisio dando a oportunidade de ter mais de um objeto respondendo solicitao. Os atendentes so encadeados e a requisio passada por eles at que um dos objetos a atenda. Conseqncias: reduz acoplamento e obtm maior exibilidade na atribuio de responsabilidades a objetos, porm no h garantia de que algum objeto atender a solicitao. Aspectos de implementao: como implementar a cadeia de sucessores (referncias novas ou existentes), como representar as solicitaes (mtodos, objetos)
ilmr
Assume compromisso com uma forma de atender a uma requisio; seria melhor no ter essa denio amarrada ao cdigo Padres de projeto associados: Cadeia de responsabilidade, Comando
53
Estrutura:
Cliente
Hand ler
hand leR equest( )
successor
Slide 53
ConcreteHandler1
ConcreteHandler2
handleRequest( )
handleRequest( )
Padro: Comando
Objetivo: encapsular uma requisio como um objeto, permitindo parametrizar clientes com diferentes solicitaes, enleirar ou registrar solicitaes e suportar operaes que podem ser desfeitas. Conseqncias: desacopla objeto que invoca o servio daquele que sabe como execut-lo; solicitaes, sendo objetos, podem ser manipuladas e compostas como tais.
Slide 54
ilmr
55
Estrutura:
Invoker
Client Command
ex ecute( )
Slide 55
Receiver
action( )
receiver
ConcreteCommand
ex ecute( )
state
ilmr
Usar diretamente APIs e interfaces para sistemas externos que dependem da plataforma de execuo torna portabilidade e mesmo atualizao na prpria plataforma difceis Padres de projeto associados: Fbrica abstrata, Ponte
57
Padro: Ponte
Objetivo: desacoplar uma abstrao de sua implementao de forma que os dois possam variar independentemente. Motivao: uma forma de evitar o acoplamento denitivo entre abstrao e implementao que se d atravs de herana Conseqncias: desacopla interface e implementao, melhora extensibilidade e esconde detalhes de implementao de clientes.
Slide 57
Estrutura:
Client
Abstraction
impl
Implementor
operationImp( )
Slide 58
operation( )
RefinedAbstraction
ConcreteImplementorA
usesOperation( )
operationImpl( )
ilmr
59
Objetivo: Sem violar encapsulao, capturar e externalizar o estado interno de um objeto de forma que ele possa ser restaurado para esse estado em um momento posterior. Slide 60 Motivao: Um memento um objeto que armazena o estado interno de um outro objeto (o originador do memento). Aplicabilidade: usar quando um instantneo (total ou parcial) de um objeto deve ser salvo para posterior recuperao e uma interface direta para obter esse estado exporia detalhes de implementao, quebrando a encapsulao do objeto.
ilmr
Clientes que sabem como um objeto representado, armazenado, localizado ou implementado podem ter que sofrer modicaes quando o objeto muda. Padres de projeto associados: Fbrica abstrata, Memento, Proxy
Padro: Memento
61
Estrutura:
memento
Originator
setMemento(Memento m) createMemento()
M emento
g etS tate() setS tate()
Caretaker
Slide 61
state
state
state = m>getState();
Padro: Proxy
Objetivo: Oferecer um surrogate para outro objeto para controlar o acesso a ele. Slide 62 Aplicabilidade: Sempre que for necessrio ter uma referncia para um objeto que seja mais verstil ou sosticada que um simples ponteiro proxy remoto (referncias fora do espao de endereamento local), proxy virtual (atrasa criao de objetos caros at que haja demanda real), proxy de proteo (controla acesso ao objeto original) e referncias espertas com funcionalidades adicionais (contar nmero de referncias para liberao automtica, carregar objetos persistentes na primeira referncia, locking).
ilmr
63
Estrutura:
Client
Sub ject
request( )
Slide 63
R ealSub ject
request( )
real
...
P roxy
request( )
ilmr
Slide 64
Algoritmos podem ser estendidos, otimizados ou substitudos durante desenvolvimento ou reuso; se objeto depender de um algoritmo especicamente, tambm dever ser alterado nesses casos Padres de projeto associados: Estratgia, Mtodo Gabarito, Iterador
65
Padro: Estratgia
Objetivo: denir uma famlia de algoritmos, encapsul-los e torn-los intercambiveis, permitindo que o algoritmo varie independentemente de seus clientes Slide 65 Aplicabilidade: usar quando classes relacionadas diferem apenas em seu comportamento; quando diferentes variantes de um algoritmo so necessrias; quando se deseja encapsular estruturas de dados complexas, especcas do algoritmo; quando a classe dene diversos comportamentos com mltiplas ocorrncias de um padro condicional Conseqncias: em famlias de algoritmos relacionados, herana pode fatorar funcionalidades comuns; uma alternativa para derivao direta; cliente exposto s diferentes estratgias disponveis
Estrutura:
Context
Strateg y
contextInterface( )
algorithmInterface( )
Slide 66
ConcreteStrategyA ConcreteStrategyB
algorithmInterface( )
algorithmInterface( )
ilmr
67
Estrutura:
AbstractClass
templateMethod( ) primitiveOperation1( ) primitiveOperation2( )
Slide 68
ConcreteClass
primitiveOperation1( ) primitiveOperation2( )
ilmr
69
Padro: Iterador
Objetivo: oferecer uma forma de acessar os elementos de um objeto agregado seqencialmente sem expor sua representao interna Slide 69 Motivao: suportar formas (eventualmente, alternativas) de varrer agregados sem ter de incorporar essas funcionalidades interface do agregado; ter mecanismo uniforme de varrer estruturas agregadas distintas Conseqncias: simplica a interface do agregado; pode ter mais de uma varredura sobre o mesmo agregado em um dado momento
Estrutura:
Agg reg ate
createIterator( )
Cliente
Iterator
first( ) next( ) current( ) isDone( )
Slide 70
ConcreteAggregate
ConcreteIterator
createIterator( )
ilmr
71
Objetivo: oferecer uma interface unicada para um conjunto de interfaces em um subsistema Slide 72 Motivao: denir uma interface de nvel mais alto para tornar o subsistema mais fcil de utilizar Aplicabilidade: usar quando quiser oferecer uma interface simples para um subsistema complexo; quando houver muitas dependncias entre clientes e as classes de implementao de uma abstrao; quando quiser estruturar os subsistemas em camadas
ilmr
Slide 71
Classes fortemente acopladas so difceis de reutilizar isoladamente, levando a sistemas monolticos e de difcil manuteno Padres de projeto associados: Fbrica Abstrata, Ponte, Cadeia de Responsabilidade, Comando, Fachada, Mediador, Observador
Padro: Fachada
73
Estrutura:
F acade
Slide 73
Padro: Mediador
Objetivo: denir um objeto que encapsula como conjuntos de outros objetos interagem Slide 74 Motivao: reduzir o nmero de interconexes entre objetos fazendo com que eles se comuniquem atravs do mediador Conseqncias: desacopla objetos colegas; simplica protocolos entre objetos; porm, mediador centraliza controle, tornando-se eventualmente um elemento complexo e de difcil reuso
ilmr
75
Estrutura:
Mediator
m ediator
Colleag ue
Slide 75
ConcreteMediator ConcreteColleague1 ConcreteColleague2
Padro: Observador
Objetivo: denir uma dependncia de um objeto para muitos de forma que, quando um objeto muda de estado, todos os seus dependentes so noticados e automaticamente atualizados Slide 76 Motivao: manter consistncia entre objetos da aplicao sem recorrer a um forte acoplamento entre eles Aplicabilidade: usar quando uma abstrao tem dois aspectos, um dependente do outro; quando mudana em um objeto requer mudanas em outros; quando um objeto deve poder noticar outros sem assumir nenhum conhecimento sobre quais so esses outros objetos
ilmr
77
Estrutura:
Subject
attach(Observer) detach(Observer) notify( )
for all o in observers o>update()
observers
Observer
update( )
Slide 77
ConcreteSubject
getS tate( ) setS tate( )
subject
ConcreteObserv er
u pdate( )
observerS tate
subjectS tate
return subjectState observerState = subject>getState();
ilmr
79
Interpretador: dene a representao para uma gramtica e um interpretador para sentenas nessa linguagem (padro de comportamento); Peso-pena: usa compartilhamento para lidar com grande nmero de pequenos objetos de forma eciente (padro estrutural); Visitante: representa uma operao a ser executada nos elementos da estrutura de um objeto; Singleton: garante que uma classe tem apenas uma instncia e oferece um ponto de acesso para essa instncia (padro de criao);
Slide 79
Padres e frameworks
Padres de projeto: descries de solues de projeto recorrentes que foram aprovadas pelo uso ao longo do tempo; Slide 80 Frameworks: projeto reutilizvel do todo ou de parte de um sistema que representada por um conjunto de classes abstratas e pela forma que suas instncias interagem
ilmr
81
Frameworks e reuso
Slide 81
Modularidade: detalhes de implementao so encapsulados por trs de interfaces estveis Slide 82 Reusabilidade: denem componentes genricos associados s interfaces estveis que podem ser reutilizados para criar novas aplicaes Extensabilidade: denem pontos de adaptao e extenso nas interfaces estveis (pontos variveis, mtodos hook) Inverso de controle: framework dene seqncia de invocao da aplicao
ilmr
Reuso de projeto
um framework dene um esqueleto de aplicao que pode ser adaptado por um desenvolvedor de aplicao um tipo de arquitetura voltada para um domnio
Reuso de cdigo
frameworks so expressos em linguagens de programao so programas facilita uso de componentes que se conformem s interfaces do framework tornam-se dependentes das linguagens
Caractersticas de frameworks
Princpio de Hollywood
83
Slide 83
Slide 84
Ponto varivel X
Ponto varivel X
Xk
X1
Xk Xn
ilmr
85
Tipos de frameworks
Slide 85
Frameworks caixa-branca: todos os pontos variveis so caixa-branca; Frameworks caixa-preta: todos os seus pontos variveis so caixa-preta; Frameworks caixa-cinza: apresenta pontos-variveis caixa-cinza.
Slide 86
ilmr
87
Slide 87
1. identicar domnio especco de aplicao do framework 2. determinar os principais casos de uso suportados e atores interagindo com o framework Slide 88 3. determinar padres/solues para auxiliar desenvolvimento do framework 4. projetar interfaces e componentes do framework; mapear atores e papis para as interfaces 5. desenvolver implementao padro para interfaces do framework 6. descrever e documentar os pontos de extenso do framework 7. criar planos e casos de teste
ilmr
89
Slide 89
Slide 90
identificar objetos e classes
ilmr
Anlise do domnio identica pontos variveis quais aspectos do framework diferem entre aplicaes? qual o grau de exibilidade desejado? o comportamento exvel precisa ser alterado durante o funcionamento da aplicao?
Especialista do domnio
M etapadres
(R e)projeto do fram ew rk o
Adaptao do fram ew rk o
91
Metapadres
Slide 91
Slide 92
ilmr
Estabelecem padres de relao entre classes genricas (template classes) e classes componentes (hook classes) Classes genricas possuem os mtodos gabaritos, que denem comportamento abstrato, uxo de controle genrico, relao entre objetos Classes componentes possuem os mtodos componentes, que fazem parte das implementaes dos mtodos gabaritos e podem ser abstratos, regulares ou novos gabaritos.
Metapadres de unicao
U nificao recursiva 1: 1
thRef
TH
U nificao
U nificao recursiva 1: n
thList
*
TH
TH
93
Metapadres de conexo
Conexo recursiva 1: 1 Conexo recursiva 1: n
Conexo 1: 1
Conexo 1: n
Slide 93
T
hRef
T
hList
* H H
hRef
hList
Slide 94
ilmr
Criao de um modelo de aplicao no domnio Anlise de alto nvel dos pontos variveis Para cada ponto varivel detectado
anlise e especicao detalhada projeto de alto nvel transformao do modelo de classes por generalizao com o subsistema de ponto varivel
95
Slide 96
ilmr
Slide 95
Outra forma de estabelecer os padres bsicos de relao entre as classes genricas e suas concretizaes Variabilidade obtida por meio de uma referncia polimrca, que estabelece a ligao dinmica entre o mtodo genrico e as operaes concretas Quando a ligao faz referncia a servios dentro do prprio sistema, o subsistema de ponto varivel recursivo
cliente
Bas e
C oncreta1
C oncreta2
97
cliente
Bas e
Slide 97
C oncreta1
C oncreta2
cliente
Bas e
Slide 98
C oncreta1
C oncreta2
ilmr
99
Padro de projeto fbrica abstrata, mtodo fbrica, prottipo, ponte, comando, iterador, observador, estratgia, mtodo gabarito, construtor, adaptador, mediador, estado, visitante cadeia de responsabilidade, decorador composto, interpretador
Slide 99
no recusivo
conexo recursiva 1:1, unicao recursiva 1:1 conexo recursiva 1:n, unicao recursiva 1:n
Uso do framework
Slide 100
ilmr
101
Manuteno de frameworks
Slide 101
Slide 102
Infra-estrutura: framework simplica o desenvolvimento da infra-estrutura de sistemas de forma porttil e eciente; tipicamente de uso no desenvolvimento interno s empresas Integrao middleware: framework permite a integrao de componentes e aplicaes distribudas; parte importante dos sistemas modernos Aplicao empresarial: framework voltado para uma rea de aplicao; foco de desenvolvimento nas empresas desenvolvendo aplicaes para usurios nais
ilmr
103
Foco no desenvolvimento dos frameworks est na extenso das funcionalidades, no na integrao com outros frameworks Slide 103
Coeso do framework: quo amarrada est a conexo de uma classe do framework s demais? Cobertura do domnio: quo bem especicado e isolado est o domnio de aplicao do framework? Objetivos do projeto: os desenvolvedores do framework devem explicitar se integrao foi uma preocupao no projeto Falta de acesso ao cdigo fonte: integrao pode requerer modicaes e adaptaes no cdigo; importante ter uma abordagem open source Falta de padres: ainda no h padres voltados para o desenvolvimento de frameworks
Slide 104
ilmr
Alguns frameworks podem assumir que tm controle completo sobre o uxo de execuo da aplicao
Quando mais de um framework em uso. . . ?
Como integrar sistemas legados a frameworks? O que acontece se dois frameworks tm componentes com sobreposio de funcionalidades?
105
Slide 105
Slide 106
ilmr
Usar threads de execuo independentes para cada framework Usar padro Adaptador para estabelecer integrao com cdigo legado Alterar cdigo do framework No desenvolvimento:
Tornar explcitas e bem documentadas as decises relativas arquitetura do framework Construir o framework em blocos independentes Estabelecer no framework previses para congurao, mediao e adaptao, atravs do uso de padres
107
O conceito da herana
Slide 107
Slide 108
ilmr
Denio de (boas) hierarquias de classes um dos conceitos chaves por trs da orientao a objetos
Mecanismos de derivao
Implementando hierarquias IS-A Lidando com excees nas hierarquias
109
Slide 109
Slide 110
ilmr
Atravs da derivao public class Pessoa { ... }; class Estudante : public Pessoa { ... }; Todo estudante uma pessoa Nem toda pessoa um estudante
void dance(const Pessoa& p); void estude(const Estudante& e); Pessoa p; Estudante e; dance(p); dance(e); estude(p); // oops estude(e);
111
Slide 111
Slide 112
ilmr
Derivao usando private no dene uma hierarquia do tipo IS-A como todos os membros da superclasse, pblicos ou protegidos, tornam-se privativos na nova classe, a interface da superclasse no herdada no h converso automtica de um objeto do tipo derivado para um objeto do tipo da classe base falha o princpio da substituio
class Pessoa { ... }; class Estudante : private Pessoa { ... }; void dance(const Pessoa& p); void estude(const Estudante& e); Pessoa p; Estudante e; dance(p); dance(e); // oops estude(p); // oops estude(e);
113
Slide 113
Slide 114
ilmr
void erro(const string& mens); class Pinguim : public Passaro { public: virtual void voe() { erro(Pingim no voa); } ... }; Pingins podem tentar voar, mas faz-lo um erro. Abordagem tipicamente adotada em linguagens interpretadas, mas no em C++
115
Slide 115
Slide 116
ilmr
Se no houver um mtodo voe denido para pingins, compilao j detectar o erro class Passaro { ... }; class PassaroVoador: public Passaro ( public: virtual void voe(); ... }; class PassaroNaoVoador: public Passaro { ... }; class Pinguim: public PassaroNaoVoador { ... };
Abuso de herana
Nem sempre a relao adequada entre duas classes a de herana Herana deve sempre ser uma expresso da relao IS-A
117
Interfaces e implementaes
Separao entre a especicao de uma interface e sua implementao essencial na boa programao orientada a objetos
Slide 117
Slide 118
ilmr
Interfaces tendem a estabilizar rapidamente, implementaes no Programar com base no conhecimento apenas da interface favorece programao genrica e reduz a dependncia de compilao entre mdulos do sistema
class Pessoa { public: Pessoa(string& nome, Data& aniv, Endereco& end, Pais& p); virtual ~Pessoa(); string nome() const; string dataNascimento() const; string endereco() const; string nacionalidade() const; private: string name_; Data birthday_; Endereco address_; Pais nation_; };
119
Destrutor virtual
Slide 119
Slide 120
ilmr
Por qu?
class Base { public: ~Base(); ... }; class Derivada: public Base { public: ~Derivada(); ... }; Base *p = new Derivada; delete p; // comportamento indefinido
Se destrutor na classe base for declarado como virtual, ambos sero invocados
Deve estar presente em qualquer classe que sirva de base para outras Mesmo que virtual puro, deve ter implementao
Cria dependncia deste mdulo (e dos que utilizem a classe Pessoa) em relao queles
121
Slide 121
Slide 122
ilmr
Da mesma forma, para denir ponteiros ou referncias basta conhecer a declarao, no a denio de um tipo
#include <string> class Data; class Endereco; class Pais; class PessoaImpl; class Pessoa { public: Pessoa(string& nome, Data& aniv, Endereco& end, Pais& p); virtual ~Pessoa(); string nome() const; string dataNascimento() const; string endereco() const; string nacionalidade() const; private: PessoaImpl *parte_impl; };
123
Slide 123
#include "Pessoa.h" #include "PessoaImpl.h" Pessoa::Pessoa(string& n, Data& d, Endereco& e, Pais& p) { parte_impl = new PessoaImpl(n, d, e, p); } string Pessoa::nome() const { return parte_impl -> getNome(); } ...
Slide 124
ilmr
Classes que usam os protocolos operam com ponteiros ou referncias para essas classes
no possvel instanciar diretamente objetos de protocolos objetos de classes derivadas podem ser criados
125
Slide 125
class Pessoa { public: virtual ~Pessoa(); virtual string nome() const = 0; virtual string dataNascimento() const = 0; virtual string endereco() const = 0; virtual string nacionalidade() const = 0; };
Slide 126
ilmr
127
Slide 127
Slide 128
ilmr
129
Slide 129
Slide 130
ilmr
Obtida pelo uso da funo virtual pura No exemplo, draw No precisa (mas at poderia) ter uma implementao Se Rectangle e Ellipse so derivadas de Shape,
Shape *ps1 = new Rectangle; ps1->draw(); Shape *ps2 = new Ellipse; ps2->draw(); ps1->Shape::draw();
131
Slide 131
No h diferena entre pilotar um Avio ModeloA ou um Avio ModeloB; outros poderiam ser diferentes:
class Aviao { public: virtual void voePara(string& destino); ... }; class ModeloA : public Aviao { ... }; class ModeloB : public Aviao ( ... };
Slide 132
ilmr
Obtida com mtodos virtuais normais Classe derivada pode optar entre usar a implementao padro oferecida pela superclasse ou denir a prpria implementao, especializada Potencial problema de manuteno
Se a hierarquia crescer (novas classes derivadas) e o padro no mais for aplicvel
133
Slide 133
Slide 134
ilmr
Problema no ter uma implementao padro, mas permitir que a classe derivada a utilize sem dizer explicitamente que ir faz-lo
135
Slide 135
Slide 136
ilmr
Comportamento no pode ser alterado em classes derivadas Situao obtida com uso das funes no-virtuais Dene interface e implementao mandatria Mtodo no-virtual nunca deve ser redenido em classes derivadas
137
Slide 137
Slide 138
ilmr
Mtodos no virtuais so ligados em tempo de compilao Mesmo que atravs de ponteiros, a implementao utilizada ser a do tipo do ponteiro e no a do tipo do objeto na execuo O mesmo ocorre para valores padro de funes virtuais
valores padro so ligados estaticamente pode invocar corpo denido na classe derivada com valores padres denidos na superclasse concluso: no devem ser redenidos
139
Slide 139
Slide 140
ilmr
Para modelar expresses do tipo tem um (objeto de outra classe) ou implementado usando (outro tipo de objeto)
class Pessoa { ... private: string nome; // Pessoa tem um nome Endereco end; // e tem um endereco ... };
Exemplo: implementar uma coleo do tipo conjunto usando uma estrutura de dados do tipo lista um conjunto no uma lista
conjuntos no podem ter elementos duplicados, listas podem herana pblica no uma boa opo
141
Slide 141
Slide 142
ilmr
143
Herana ou templates
Slide 143
Slide 144
ilmr
Na denio de um conjunto de classes com pequenas diferenas entre si, qual mecanismo usar? herana: fatorar parte comum em superclasse (abstrata), derivar as classes concretas e em cada uma denir a especializao da classe template: denir o cdigo para a classe genrica em termos de um tipo parametrizado e instanciar, para cada tipo desejado, uma verso da denio da classe especializada Usar herana quando o tipo do objeto muda o comportamento dos mtodos, usar template quando comportamento invariante com o tipo parametrizado
template<class T> class Stack { public: Stack(); ~Stack(); void push(const T& obj); T pop(); bool empty() const; private: struct StackNode { T data; StackNode *next; StackNode(const T& newData, StackNode *nextNode) : data(newData), next(nextNode) { } }; StackNode *top; Stack(const Stack& rhs); Stack& operator=(const Stack& rhs); };
145
Slide 145
[--- template<class T> ---] Stack<T>::Stack() : top(0) {} void Stack::push(const T& obj) { top = new StackNode(obj, top); } T Stack<T>::pop() { StackNode *topOfStack = top; top = top->next; T data = topOfStack->data; delete topOfStack; return data; } Stack<T>::~Stack() { while(top) { StackNode *toDie = top; top = top->next; delete toDie; } } bool Stack<T>::empty() const { return top == 0; }
Slide 146
ilmr
Ponteiros genricos (void*) oferecem outra alternativa que permite ter o mesmo comportamento para diferentes tipos de objetos sem a replicao de cdigo que templates geram Dois passos 1. criar a classe que manipula os ponteiros genricos 2. criar classes que enforam a converso correta dos ponteiros
147
Slide 147
Slide 148
ilmr
149
Slide 149
Slide 150
ilmr
No h custo adicional no uso de IntStack todos os mtodos so inline Nada impede que cliente use diretamente objetos da classe GenericStack Alternativa: evitar manipulao direta de GenericStack protegendo sua criao e interface
151
Slide 151
Slide 152
ilmr
153
Herana mltipla
Slide 153
Slide 154
ilmr
No h uma posio clara na comunidade de orientao a objetos sobre os benefcios da herana mltipla Por que deve ser evitada (ou, pelo menos, usada com muito cuidado. . . )? Ambigidade potencial Mltiplas ocorrncias da base
Ambigidade potencial
Base1
faz(): int
Base2
faz():void
D erivada
155
Slide 155
class Derivada: public Base1, public Base2 { ... // sem faz() }; Derivada d; d.faz();
// erro de compilao
Slide 156
class Derivada: public Base1, public Base2 { ... // sem faz() }; Derivada d; int i = d.faz();
ilmr
157
Para resolver ambigidade, apenas atravs da qualicao dos membros (referncias explcitas classe base):
d.Base1::faz(); d.Base2::faz();
ilmr
Slide 158
Slide 157
Porque modicaes na visibilidade de membros das classes no deveria modicar o signicado de programas Se a abordagem anterior resolvesse o problema, apenas modicao na visibilidade mudaria o comportamento do programa sem modicar invocao ou corpo dos mtodos
Se mtodos fossem virtuais, no teria como explorar redenies mesmo que objeto fosse de uma classe derivada da base, a qualicao faz com que o mtodo invocado seja exatamente o especicado.
159
E se dois mtodos, com os mesmos tipos de argumentos, fossem virtuais e a classe derivada quisesse redenir os dois?
Slide 159
Slide 160
ilmr
no h como fazer diretamente Apenas um mtodo pode existir numa classe com um dado nome e lista de tipos de argumentos possvel atravs da criao de classes auxiliares, sem correspondncia com a modelagem da aplicao
class AuxBase1: public Base1 { public: virtual int faz1() = 0; virtual int faz() { return faz1(); } }; class AuxBase2: public Base2 { public: virtual void faz2() = 0; virtual void faz() { faz2(); } }; class Derivada: public Base1, public Base2 { public: virtual int faz1(); virtual void faz2(); }; Derivada *d = new Derivada; Base1 *p1 = d; Base2 *p2 = d; p1->faz(); // chama faz1 p2->faz(); // chama faz2
161
C om um
Slide 161
Base1 Base2
D erivada
Slide 162
ilmr
Classe base virtual impe penalidades de acesso (tipicamente, implementao por ponteiros na estrutura interna) Mas e se Comum, Base1 e Base2 existissem antes e independentemente de Derivada (por exemplo, em uma biblioteca)? bom projeto requer viso proftica. . .
163
Slide 163
Na herana mltipla, lista de inicializao do construtor est na classe que mais derivada da base pode estar distante na hierarquia de classes pode variar a posio com evoluo da hierarquia
ilmr
Slide 164
165
Em herana simples, sem bases virtuais, construtores de classe em nvel repassam informao para construtores da classe no nvel
Slide 165
Slide 166
ilmr
Evitar grafos de hierarquia na forma de diamantes Evita problemas associados a classes bases virtuais seguro combinar herana pblica de interface com herana privada de implementao Rever hierarquia: herana mltipla mesmo a melhor soluo?
167
Atividades
Analisar as implementaes fornecidas em C++ com usos dos padres de projeto Adaptador, Decorador, Mediador, Singleton e TemplateMethod. Para cada um deles, descreva Slide 167 1. Qual o problema que est sendo abordado; 2. Que alternativas de implementao so consideradas; 3. Que construes de C++ so relevantes para a implementao; 4. Quais os potenciais problemas ou decincias da implementao; 5. Se as tcnicas indicadas poderiam ser teis na implementao de outros padres.
Slide 168
Concluses
ilmr
169
Slide 169
1. Frederick P. Brooks, Jr. No Silver Bullet: Essence and accidents of software engineering. IEEE Computer, pp.1019, April 1987. Disponvel em http://www.virtualschool.edu/mon/SoftwareEngineering/ BrooksNoSilverBullet.html.
Slide 170
2. Phillip G. Armour. The Five Orders of Ignorance. Communications of the ACM 43(10), pp.1720, October 2000. 3. William H. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J Mowbray. Antipatterns: Refactoring software, architectures, and projects in crisis. John Wiley & Sons, 1998. 4. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of reusable object-oriented software. Addison-Wesley, 1995.
ilmr
Origem dos maiores problemas na programao em C++ Falta de compreenso do paradigma de orientao a objetos Vcios no desenvolvimento de software Problemas no projeto Mal uso dos recursos da linguagem Para o ltimo item, soluo passa por Reconhecer as mensagens implcitas associadas a cada recurso Estar atento s situaes de risco Aplicar solues reconhecidas
171
5. Ralph E. Johnson. Frameworks=Components+Patterns. Communications of tha ACM 40(10), pp.3942, October 1997. 6. W. Pree. Design patterns for object-oriented software development. Addison-Wesley, 1995. 7. H. A. Schmid. Framework Design by Systematic Generalization. Building Application Frameworks: Object-Oriented Foundations of Framework Design, Mohamed E. Fayad, Douglas C. Schmidt e Ralph E. Johnson (Eds.). John Wiley & Sons, 1999, Cap. 15, pp.353378. 8. Scott Meyers. Effective C++: 50 specic ways to improve your programs and designs, 2nd edition. Addison-Wesley, 1998.
Slide 171
ilmr
171