Arquitetura de Software

Transcrição

1 Frameworks Wanderson Câmara dos Santos, Elves 1 wanderson@crea-rn.org.br,elveskiss@yahoo.com.br 1 Departamento Acadêmico de Tecnologia da Informação Centro Federal de Educação Tecnológica do Rio Grande do Norte 24/10/2007 / FrameWorks

2 Sumário

3 Um FrameWork define o Comportamento de uma coleção de Objetos, provendo um caminho para reuso ambos design e código.

4 Onde está a maior dificuldade? I Onde está a maior dificuldade? Solução "Design de Interface e uma Construção funcional constituem a parte crítica do software e é mais difícil de criar e recriar do que código propriamente dito."(peter Deutsch):Adaptado

5 Solução I Onde está a maior dificuldade? Solução Temos que fornecer formas de re-uso que vão além de código: re-uso de análise, design, código.

6 I Definição 1 Um framework captura a funcionalidade comum a várias aplicações 2 As aplicações devem ter algo razoavelmente grande em comum: pertencem a um mesmo domínio de problema

7 Definição Definição O FrameWork é um conjunto de blocos de software pré fabricados que programadores podem se utilizar, extender ou configurar para soluções específicas de computação.

8 Diferenças entre um Framework e uma Biblioteca de Classes OO I 1 Numa biblioteca de classes, cada classe é única e independente das outras 2 Num framework, as dependências/colaborações estão embutidas (wired-in interconnections) 3 Com biblioteca, as aplicações criam as colaborações

9 Diferenças entre um Framework e umabiblioteca de Classes OO I 1 Vê-se portanto que um framework impõe um modelo de colaboração (o resultado da análise e design) ao qual você deve se adaptar 2 Já que a comunicação entre objetos já está definida, o projetista de aplicações não precisa saber quando chamar cada método: é o framework que faz isso 3 Não se pode embutir conhecimento do domínio (análise + design) numa biblioteca de classes 4 O framework é usado de acordo com o Hollywood Principle ("Don t call us, we ll call you")

10 Diferenças entre um Framework e umabiblioteca de Classes OO public class MeuMouseListener implements MouseListen public void mouseclicked(mouseevent event) {... } public void mousepressed(mouseevent event) {... }... }

11 Diferenças entre um Framework e umabiblioteca de Classes OO MeuMouseListener mouselistener = new MeuMouseListener(); JButton meubotão = new JButton("clique aqui"); /** * O seguinte método estabelece a interação * entre o objeto * meubotão e o objeto mouselistener */ meubotão.addmouselistener(mouselistener);

12 Design patterns são mais abstratos do que frameworks Design patterns são elementos arquiteturais menores do que frameworks Design patterns são menos especializados do que frameworks Aparentemente, os dois consistem de classes, interfaces e colaborações prontas

13 Design patterns são mais abstratos do que frameworks Design patterns são elementos arquiteturais menores do que frameworks Design patterns são menos especializados do que frameworks Design patterns são mais abstratos do que frameworks I 1 Um framework inclui código, um design pattern não (só um exemplo do uso de um pattern) 2 Devido à presença de código, um framework pode ser estudado a nível de código, executado, e reusado diretamente 3

14 Design patterns são mais abstratos do que frameworks Design patterns são elementos arquiteturais menores do que frameworks Design patterns são menos especializados do que frameworks Design patterns são elementos arquiteturais menores do que frameworks 1 Um framework típico contém vários design patterns mas o contrário nunca ocorre 2 Exemplo: Design patterns são frequentemente usados para documentar frameworks

15 Design patterns são mais abstratos do que frameworks Design patterns são elementos arquiteturais menores do que frameworks Design patterns são menos especializados do que frameworks Design patterns são menos especializados do que frameworks Frameworks sempre têm um domínio de aplicação particular enquanto design patterns não ditam uma arquitetura de aplicação particular

16 Um framework deve ser reusável I Um framework deve ser reusável Deve ser extensível Deve ser de uso seguro Deve ser eficiente Deve ser completo 1 É o propósito final! 2 Para ser reusável, deve primeiro ser usável

17 Deve ser extensível Um framework deve ser reusável Deve ser extensível Deve ser de uso seguro Deve ser eficiente Deve ser completo O framework contém funcionalidade abstrata (sem implementação) que deve ser completada

18 Deve ser de uso seguro Um framework deve ser reusável Deve ser extensível Deve ser de uso seguro Deve ser eficiente Deve ser completo O desenvolvedor de aplicações não pode destruir o framework

19 Deve ser eficiente Um framework deve ser reusável Deve ser extensível Deve ser de uso seguro Deve ser eficiente Deve ser completo Devido a seu uso em muitas situações, algumas das quais poderão necessitar de eficiência

20 Deve ser completo Um framework deve ser reusável Deve ser extensível Deve ser de uso seguro Deve ser eficiente Deve ser completo Para endereçar o domínio do problema pretendido