arquitectura de sistemas de software - web.fe.up.ptaaguiar/as2004-2005/arquitecturasistemas... ·...
TRANSCRIPT
1Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 11
Arquitectura de Arquitectura de Sistemas de SoftwareSistemas de Software
Ademar Aguiarwww.fe.up.pt/~aaguiar
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 22
Arquitectar...
Arquitectar uma pequena cabana parece-nos fácil...
2Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 33
Arquitectar...
Menos fácil será arquitectar uma casa...
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 44
Arquitectar...
Ou um prédio de 6 andares...
3Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 55
Arquitectar...
Ou um arranha-céus de 88 pisos, 452 metros de altura...
37,000 toneladas de ferro90 seg das caves ao topo
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 66
Arquitectar...
Quais as principais diferenças entre estas construções?• Dimensões• Custos• Prazos• Processo• Competências e equipas• Materiais e tecnologias• Riscos associados• Robustez• Longevidade...
4Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 77
Arquitectura & Engenharias tradicionais
As engenharias tradicionais têm arquitecturas estáveis• Edifícios, aviões, automóveis, barcos, pontes, etc.
As arquitecturas estáveis evoluíram ao longo do tempo• Por tentativa-e-erro
• Por reutilização e refinamento de soluções comprovadamente boas
A engenharia destes domínios conseguiu diversos avanços• Produção e teste de novos materiais
• Definição de novos processos de engenharia
• Normalização de métodos de engenharia
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 88
Software é diferente (mais dificil?)
Invisibilidade das construções• Produto lógico
Natureza temporal complexa de compreender• Sistema discreto
Grandes necessidades de evolução ao longo do tempo• “Emula” sistemas e processos reais
Têm que ser facilmente adaptáveis• Sempre parecidos mas nunca iguais
Evolução rápida das tecnologias subjacentes
Não obedecem a leis físicas da natureza
5Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 99
Arquitectura de Software
O papel da arquitectura é o mesmo• Controlar complexidade do sistema
• Garantir a integridade do sistema
• Assegurar as qualidades do sistema- Escalabilidade, Interoperabilidade, usabilidade, desempenho,
adaptabilidade, custo, prazos, modularidade, etc.
• Melhorar a predictabilidade do desenvolvimento
• Equilibrar forças e estabelecer compromissos que influenciam o desenvolvimento do sistema e a sua evolução futura
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1010
Desenho de Software: níveis principais
Arquitectura
Código-fonte
Executável
módulosinterligações
algoritmosestruturas de dados
pilhas de rotinasalocação de registoscódigo-máquina
Que módulos?Como os interligar?
Que gestão de memória? Que instruções utilizar?
Que estruturas de dados? Que algoritmos?
6Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1111
Arquitectura de Software: definição
A arquitectura de software compreende o conjunto de decisões significativas acerca da organização de um sistema de software
• Definição dos elementos estruturais e interfaces que compõem o sistema (blocos básicos de construção)
• Definição dos mecanismos de composição dos elementos estruturais e comportamentais em subsistemas maiores
• Especificação de comportamentos envolvendo colaborações entre os elementos
• Explicitação do estilo de arquitectura que orienta a organização geral do sistema.
módulos
interfaces conectores
ArquitecturaArquitectura de de SistemasSistemas de Software, LEIC/MEI, 2003/2004de Software, LEIC/MEI, 2003/2004 1212
(LEIC|MEI)/AS
“Arquitecturas de Sistemas de Software”
7Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1313
Pré-requisitos
Mínimos• Conhecimentos de engenharia de software
• Conhecimentos de orientação por objectos (OO)
Preferenciais• Experiência de desenvolvimento de software OO
• Conhecimentos de UML
• Interesse em saber “lidar” com sistemas de média/grande dimensão
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1414
Objectivos
Ensinar a compreender, desenhar e avaliar arquitecturas de sistemas de software, tanto ao nível macro como micro.
Familiarizar os alunos com os conceitos fundamentais de arquitectura de software
• propriedades e aplicabilidade de diferentes estilos de arquitectura• padrões de desenho mais populares
• arquitecturas de software reutilizáveis (frameworks)
• tecnologias de componentes de software
• relações destes conceitos todos com a reutilização de software
8Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1515
Capacidades...
Arquitectura de Software• Reconhecer os principais estilos de arquitectura existentes para
sistemas de software.
• Descrever uma arquitectura de forma precisa.
• Idealizar diferentes arquitecturas alternativas para resolver ummesmo problema e avaliar de forma justificada qual a melhor, quer em termos de desenho, quer em termos de reutilização.
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1616
Capacidades...
Micro-arquitecturas: design patterns• Reconhecer e compreender diversos padrões de desenho.
• Conhecer e aplicar diversos métodos e técnicas de reutilização de software.
9Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1717
Capacidades
Macro-arquitecturas: frameworks• Construir um sistema de software de média dimensão de acordo
com uma especificação de requisitos e uma especificação de arquitectura, seleccionando e aplicando padrões de desenho e utilizando um método de desenvolvimento baseado em componentes.
• Utilizar definições e ferramentas de desenvolvimento existentes para tornar mais expedita a realização das tarefas anteriores.
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1818
Conteúdos
Noções fundamentais
Estilos de arquitectura clássicos
Micro-arquitecturas: design patterns
Macro-arquitecturas: frameworks
Técnicas e ferramentas relacionadas
10Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 1919
Estilos de ArquitecturaPipes & Filters
• Exemplo: comandos do sistema operativo Unix
Object-orientation• Exemplo: quase tudo
Event-based• Exemplo: interfaces gráficas
Layered Systems• Exemplo: aplicações empresariais para a web
Repositories• Exemplo: sistemas de informação e bases de dados
Interpreters• Exemplo: compiladores, shell de comandos
Process Control• Exemplo: sistemas distribuídos (RPC, DCE, Web Services, ...)
GraphicalUserInterface
BusinessObjectModel
RelationalDatabase
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2020
Questões
Quais são os estilos de arquitectura mais utilizados no desenvolvimento de sistemas de software?
O que é um estilo de arquitectura e que propriedades cada estilo tem?
Que aplicações são mais adequadas a cada um dos estilos?
Qual a vantagem de conhecer os diversos estilos?
11Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2121
Padrões de Software
Existem problemas recorrentes em Engenharia de Software • Arquitectura• Análise• Desenho• Codificação
Os padrões são “micro-arquitecturas”• Descrevem soluções genéricas comprovadamente boas para resolver
problemas recorrentes em determinados contextos.• Descrevem mecanismos abstractos de cooperação entre objectos por forma
a resolver um problema recorrente.
“GoF book”: 1º livro sobre Padrões de Software• Foi apresentado na OOPSLA’94, e é uma co-autoria de um grupo de quatro
indivíduos conhecido pelo Gang of Four (GoF).• Documenta 23 padrões que descrevem soluções reconhecidamente boas
para problemas recorrentes de desenho orientado por objectos [Gamma95].
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2222
Padrões de Software
Abstract Factory, Builder, Singleton, Factory Method, Prototype, Adapter,Bridge, Composite, Decorator, Proxy,Chain of Responsability, Command, Flyweight, Interpreter, Iterator,Mediator, Memento, Observer, State,Strategy, Template Method, Visitor,Master-Slave, Publisher-Subscriber,Blackboard, Reactor, Reflection, ... ...
12Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2323
Questões
O que é um padrão de software?
Quais são os padrões de software mais populares?
Como se utilizam os padrões de software?
Como se documenta um padrão de software?
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2424
Frameworks Orientadas por Objectos
Definição• “An object-oriented framework consists of a collection of cooperating
classes, both abstract and concrete, that embody an abstract design for solutions to a family of related problems” [Gamma et al. 1995].
• As frameworks fornecem uma solução inicial para um problema cuja solução completa normalmente requer muito tempo para desenvolver de raiz.
As frameworks são “macro-arquitecturas”• Interligam diversos padrões e componentes e normalmente incluem
também a infraestrutura que suporta a sua integração.• As frameworks possuem partes inalteráveis e partes configuráveis através
de mecanismos de herança (white-box) e/ou composição (black-box).
Exemplos populares• MacApp, MVC, NEXTSTEP, MFC, Java, J2EE, SanFrancisco, JUnit, .NET, SAP,
etc.
13Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2525
Frameworks Orientadas por Objectos
As frameworks são uma poderosa técnica de reutilização de software que permitem reutilização de código e desenho.
Frameworks + componentes + padrões • tecnologia actualmente existente mais capaz de suportar
reutilização de software em larga-escala.
Application 1
Application 2
Application 3 Application Code 2
Application Code 3
Framework code
Application Code 1
abstraction
CallbacksHooks
Plugins...
Framework code
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2626
Aplicação OO convencional Aplicação OO com frameworks
Sistema Operativo Sistema Operativo
Bibliotecas de Procedimentos Bibliotecas de Procedimentos
Bibliotecas de Classes Bibliotecas de Classes
FrameworkAplicacional Aplicação
FrameworkAplicacional
Diversos componentesAplicação
14Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2727
Componentes da disciplina
Aulas teórico-práticas• 12 aulas x 3 horas = 36 horas
• Apresentação de conhecimentos teóricos
• Estudo de casos
• Desenvolvimento de projectos: OO + UML + documentação.- Grupos de 3-4 elementos- projectos de análise, documentação, desenho, e/ou implementação de
arquitecturas.
Sessões de atendimento colectivas• 12 sessões x 1-3 horas = 12-36 horas
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2828
Avaliação
Avaliação distribuída sem exame final.
Componentes de Avaliação.• 4 questões teóricas para desenvolvimento individual (até 1 página
A4) fora de aulas e avaliação qualitativa “Satisfaz/Não satisfaz”.
• 1 teste individual com consulta, duração de 90 minutos, a meio do semestre.
• 1 projecto semestral em grupo para desenvolvimento de uma arquitectura.
• Avaliação quantititiva individual pelos docentes.
Nota Final• (Questões x 20%)+(Teste x 20%)+(Projecto x 50%) + (Avaliação x 10%)
15Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 2929
Estatísticas 2003/2004 (SiFEUP)
Inscritos/Avaliados/Aprovados• 23 inscritos
• 22 avaliados
• 22 aprovados
Classificações• 16 valores: 6
• 17 valores: 9
• 18 valores: 6
• 19 valores: 1
Inquéritos: apreciação global• Médio (1), Elevado (4), Muito Elevado (1)
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3030
Bibliografia
“Software Architecture: Perspectives on an Emerging Discipline” de Mary Shaw e David Garlan, publicados porPrentice Hall em 1996.
“Software Architecture in Practice” de Len Bass, Paul Clements e Rick Kazman, 2ª edição, publicados porAddison-Wesley em 2003.
“Design Patterns - Elements of Reusable Object-Oriented Software” de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, publicado por Addison Wesley em 1995.
Diversos artigos.
16Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
ArquitecturaArquitectura de de SistemasSistemas de Software, LEIC/MEI, 2003/2004de Software, LEIC/MEI, 2003/2004 3131
Questões?
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3232
17Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3333
Exemplo: “Observer”
0
20
40
60
1°Trim.
3°Trim.
Vistas(observers)
Modelo(subject)
20, 30, 40, 50
Pretende-se visualizar um conjunto de dados (modelo) através de duas formas distintas (vistas) que estejam sempre coerentes com o modelo.
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3434
Observer
Nome: Observer [Buschmann96]Contexto
• Um objecto utiliza informação fornecida por outro objecto.
Problema• A alteração de informação interna a um objecto pode introduzir
inconsistências em eventuais objectos que com ele cooperam.• Para manter a consistência, é necessário estabelecer um
mecanismo de troca de informação entre eles.
Forças• O objecto fornecedor de informação não pode depender dos
detalhes internos dos objectos que com ele cooperam.• Os objectos observadores que dependem da informação do objecto
fornecedor podem não ser todos conhecidos a priori.• Os objectos observadores podem reagir de forma diferente a uma
mesma alteração de informação do objecto fornecedor.
18Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3535
Observer ...
Solução: • Implementar um mecanismo de propagação de alterações entre o
objecto fornecedor de informação - subject - e os objectos que dela dependem - os observers.
• Os observers podem ser registados dinamicamente com este mecanismo.
• Sempre que o subject altera a sua informação, inicia o mecanismo de propagação de alterações para repor a consistência com todos os observers registados.
• As alterações podem ser propagadas invocando uma função comum a todos os observers.
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3636
Observer: estrutura e exemplo
SubjectapplicationData
propagateChange()attach(Observer)detach(Observer)setData()getData()
Observer
update()service()
*observers *
class Modelo {// colecção de vistas registadasprivate Vector vistas; // registar novos observerspublic attach (Vista vista) { vistas.add(vista); }// anular registo de observers existentespublic detach(Vista vista) { vistas.remove(vista); }
public propagateChange() {Iterator iterator = vistas.iterator();while(iterator.hasNext())
iterator.next().update();}
}
interface Vista {public void update();
}
public class VistaTipoPie implement Vista {...public void update() { … }
}
public class VistaTipoBarras implement Vista {
...public void update() { … }
}
19Ademar Aguiar, FEUP, Novembro de 2004
Disciplina de Arquitectura de Sistemas de Software
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3737
Observer: colaborações
aSubject : Subject
anObserver1 : Observer
anObserver2 : Observer
anObject
attach(me)
attach(me)
changeData
update( )
update( )
getData1
getData2
Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005Arquitectura de Sistemas de Software, LEIC/MEI, 2004/2005 3838
Exemplo: JUnit
Framework para testes unitários• JUnit é uma framework open source em Java para testes unitários
utilizada para escrever e executar testes repetitivos.
• É uma instância da arquitectura xUnit para teste.