Arquitectura de Sistemas de Software - web.fe.up.ptaaguiar/as2004-2005/ArquitecturaSistemas... · Ademar Aguiar, FEUP, Novembro de 2004 2 Disciplina de Arquitectura de Sistemas de

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

[email protected]


Arquitectar...

Arquitectar uma pequena cabana parece-nos fácil...




Arquitectar...

Menos fácil será arquitectar uma casa...


Arquitectar...

Ou um prédio de 6 andares...




Arquitectar...

Ou um arranha-céus de 88 pisos, 452 metros de altura...

37,000 toneladas de ferro90 seg das caves ao topo


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...




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


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




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


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?




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”




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


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




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.


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.




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.


Conteúdos

Noções fundamentais

Estilos de arquitectura clássicos

Micro-arquitecturas: design patterns

Macro-arquitecturas: frameworks

Técnicas e ferramentas relacionadas




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


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?




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].


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, ... ...




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?


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.




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


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




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


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%)




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)


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.



ArquitecturaArquitectura de de SistemasSistemas de Software, LEIC/MEI, 2003/2004de Software, LEIC/MEI, 2003/2004 3131

Questões?





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.


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.




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.


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() { … }

}




Observer: colaborações

aSubject : Subject

anObserver1 : Observer

anObserver2 : Observer

anObject

attach(me)

attach(me)

changeData

update( )

update( )

getData1

getData2


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.

Documents

Arquitectura de Sistemas de Software - web.fe.up.ptaaguiar/as2004-2005/ArquitecturaSistemas... · Ademar Aguiar, FEUP, Novembro de 2004 2 Disciplina de Arquitectura de Sistemas de