A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
“Design Patterns” Docente : Eng.ª Maria Fernanda Pedro Grupo: José André nº 3308 Luis Nelas nº 3498 Pedro Lamy nº 3640

2 Conteúdos da Apresentação
História Design Patterns – O que são? Objectivos dos Design Patterns Como Documentar Design Patterns Design Patterns e as suas diferentes categorias Exemplo de um Design Pattern Conclusão

3 História Os Patterns têm a sua origem num conceito arquitectónico criado por Christopher Alexander (1978). Na altura, os arquitectos aperceberam-se da necessidade de partilhar informações sobre conceitos de design. Christopher Alexander afirmou que um pattern descreve um problema que se repete várias vezes num determinado meio, e em seguida descreve o núcleo da sua solução, de modo que esta solução possa ser usada milhares de vezes. Em 1987, Kent Beck e Ward Cunningham começaram a explorar a ideia de aplicar os patterns à programação. Em 1995, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, mais conhecidos como ‘Gang of Four’, publicaram o livro “Design Patterns: Elements of Reusable Object-Oriented Software”, que tratava pela primeira vez do tema ‘Design Patterns’ associado ao design de software.

4 Design Patterns – O que são?
Documentos de soluções genéricas e reutilizáveis aplicados a problemas recorrentes. Conjunto de classes e objectos que farão parte de uma solução abstracta e que serão particularizados conforme a situação. Descrições de soluções que funcionaram e se tornaram receitas para situações similares.

5 Objectivos dos Design Patterns
Criar designs object-oriented (OO) reutilizáveis. Acelerar o processo de desenvolvimento de software. Oferecer ao utilizador soluções generalizadas, devidamente documentadas. Dar a possibilidade dos utilizadores interagirem, usando nomes bem conhecidos e perceptíveis, com o pattern de modo a ser melhorado tornando-o mais eficiente.

6 Como Documentar Design Patterns
Nome e classificação Identifica o pattern. Propósito Tipo de problema que o pattern trata. Motivação Um cenário que ilustra o problema e como o pattern o resolve. Aplicabilidade Situações em que este pattern pode ser aplicado. Estrutura Representação gráfica das classes do pattern. Participantes Classes que participam no pattern e respectivas responsabilidades.

7 Como Documentar Design Patterns(2)
Colaborações Como os participantes interagem para cumprir as suas responsabilidades. Consequências Resultados e efeitos causados pelo uso do pattern. Implementação Dicas e técnicas que o designer deve saber, e possíveis armadilhas para as quais deve estar preparado. Exemplos Fragmentos de código que ilustram como o pattern deve ser implementado. Utilizações conhecidas Exemplos de utilização do pattern em sistemas já implementados. Patterns relacionados Patterns fortemente relacionados com o pattern em questão e principais diferenças.

8 Design Patterns e suas Diferentes Categorias
Existem 23 categorias diferentes de design patterns que podem ser subdivididas quanto: Ao seu propósito: Criação - Descreve a melhor maneira de criar um objecto. Estrutural - Diz respeito à composição de objectos e classes. Comportamental - Caracteriza o modo como classes e objectos interagem e compartilham responsabilidades.

9 Design Patterns e suas Diferentes Categorias(2)
E quanto ao seu âmbito: Classes - Tratam do relacionamento entre classes e subclasses. Estas relações são estabelecidas através de heranças, portanto são estáticas, fixas quando compiladas. Objectos - Tratam relacionamentos entre objectos que podem ser alterados em tempo de execução.

10 Design Patterns e suas Diferentes Categorias(3)
Fig1 – As 23 categorias do Design Patterns subdivididas

11 Design Patterns vs. Frameworks
Devido às semelhanças entre Design Patterns e Frameworks, as pessoas tendem a questionar se ambas diferem em algum ponto. Podemos identificar 3 pontos fundamentais em que os Design Patterns e as Frameworks diferem: Os Design Patterns são mais abstractos que as Frameworks As Frameworks podem ser embebidas em código, já os Design Patterns, apenas os seus exemplos podem ser embebidos em código. Os Design Patterns são elementos arquitectónicos mais pequenos que as Frameworks Uma Framework pode conter vários Design Patterns, o contrário nem sempre é verdade. Os Design Patterns são menos especializados que as Frameworks As Frameworks estão sempre relacionadas com um domínio particular da aplicação, enquanto que as Design Patterns são mais genéricas e podem ser aplicadas a vários domínios de uma aplicação.

12 Exemplo de Design Patterns
Singleton Nome : Singleton. Classificação: Pattern de criação. Propósito: Garantir que uma classe só tenha uma única instância e criar um ponto de acesso global a essa instância. Motivação: Garantir que apenas um objecto exista, independentemente do número de requisições que receber para criá-lo. Aplicabilidade: Usa-se quando tem que haver exactamente uma instância de uma classe e tem que estar acessível a clientes de um ponto de acesso reconhecido.

13 Exemplo de um Design Pattern (2)
Estrutura:

14 Exemplo de um Design Pattern (3)
Participantes Singleton - Define uma operação de instância que deixa os clientes acederem à sua instância única. Instância é uma operação da classe. - Responsável por criar e manter a sua própria, e única, instância. Consequências Acesso controlado à instância única. Espaço de nomes reduzido. Permite refinamento de operações e representação. Permite um número variável de instancias. Mais flexível do que operações de classes. Implementação Garantir a existência de uma única instância. Criando subclasses da classe Singleton. Exemplos Disponível em

15 Conclusão Podemos concluir, através do estudo dos Design Patterns, que estes: • Melhoram a qualidade do software produzido. • Melhoram a produtividade ao nível do desenho. • São soluções conhecidas para problemas conhecidos. • Possuem um vocabulário próprio para discutir o domínio do problema. No entanto pode ter alguns efeitos negativos: • Aumento desnecessário da complexidade do desenho. • Perda de eficiência (incremento dos níveis de mudança de direcção). • Podem limitar a criatividade.

16 Bibliografia Livros Internet
Gamma, Helm, Johnson, Vlissides – Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, 1995 Buschmann, Meunier, Rohnert, Sommerlad, Stal – Pattern-Oriented Software Architecture: A System of Patterns, J. Wiley and Sons Ltd., 1996 Internet


Carregar ppt "Engenharia de Software"

Apresentações semelhantes


Anúncios Google