Ou um prédio de 6 andares... Arquitectura de Sistemas de Software Ademar Aguiar www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 1 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 4 Arquitectar uma pequena cabana parece-nos fácil... Ou um arranha-céus de 452 metros de altura... Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 2 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 5 Menos fácil será arquitectar uma casa... 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 de Sistemas de Software, LEIC/MEI, 2003/2004 3 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 6 1
Arquitectura & Engenharias tradicionais Uma Definição As engenharias tradicionais têm arquitecturas estáveis Edifícios, aviões, automóveis, barcos, pontes, etc. Estas arquitecturas evoluíram ao longo do tempo Por tentativa-e-erro Por reutilização e refinamento de soluções comprovadamente boas Nestes domínios foram conseguidos diversos avanços de engenharia Normalização de métodos de engenharia Produção de novos materiais Definição de novos processos de engenharia Alguns exemplos da Arquitectura Civil Casas, hospitais, lojas, hóteis, aeroportos, fábricas, estádios, cinemas 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) Especificação de comportamentos envolvendo colaborações entre esses elementos Como é feita a composição dos elementos estruturais e comportamentais em subsistemas maiores Explicita o estilo arquitectónico que guia a organização do sistema. Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 7 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 10 Arquitectura de Software Arquitectar software é diferente (mais dificil?)... Invisibilidade Natureza temporal complexa de compreender e com possibilidade de evoluir ao longo do tempo Não obedece a leis físicas Tem que ser facilmente adaptável Evolução rápida das tecnologias subjacentes Mas o papel da arquitectura é o mesmo Controlar complexidade do sistema Garantir a integridade do sistema Assegurar as qualidades do sistema Melhorar a predictabilidade Equilibra forças influenciando o desenvolvimento do sistema e a sua evolução (LEIC MEI)/AS Arquitecturas de Sistemas de Software Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 8 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 11 Níveis de Desenho de Software Pré-requisitos Arquitectura Código-fonte módulos interligações algoritmos estruturas de dados Que módulos? Como os interligar? Que estruturas de dados? Que algoritmos? Que gestão de memória? Que instruções utilizar? Mínimos Conhecimentos de engenharia de software Conhecimentos de orientação por objectos Preferenciais Experiência de programação OO (Java ou C++ ou...) Conhecimentos de UML Executável pilhas de rotinas alocação de registos código-máquina Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 9 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 12 2
Objectivos Estilos de Arquitectura Ensinar a desenhar, compreender e avaliar arquitecturas de sistemas de software, tanto ao nível de macroarquitectura como de micro-arquitectura Familiarizar os alunos com os conceitos fundamentais de arquitectura de software: as propriedades e aplicabilidade dos diferentes estilos de arquitectura existentes os padrões de desenho mais populares componentes de software arquitecturas reutilizáveis e as relações destes conceitos todos com a reutilização de software Pipes & Filters Object-orientation Event-based Layered Systems Repositories Interpreters Process Control... Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 13 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 16 Capacidades Exemplos do Estilo Layered System 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 um mesmo problema e avaliar de forma justificada qual a melhor, quer em termos de desenho, quer em termos de reutilização. 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. 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. 2 camadas 3 camadas mais camadas Graphical User Interface Relational Database Graphical User Interface Business Object Model Relational Database Graphical User Interface Business Object Model Relational Database Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 14 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 17 Conteúdos Questões Noções fundamentais Estilos clássicos de arquitectura Micro-arquitecturas: design patterns Macro-arquitecturas: frameworks Técnicas e ferramentas 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? Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 15 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 18 3
Padrões de Software... Existem problemas e soluções recorrentes também em Eng. Software: Arquitectura Análise Desenho Codificação 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]. Os padrões são micro-arquitecturas Descrevem mecanismos abstractos de cooperação entre objectos por forma a resolver um problema recorrente. 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, 2003/2004 19 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 22 Exemplo: : estrutura e exemplo Pretende-se visualizar um conjunto de dados (modelo) através de duas formas distintas (vistas) que estejam sempre coerentes com o modelo. 60 Vistas (observers) Modelo (subject) 20, 30, 40, 50 40 20 0 1 3 Trim. Trim. Subject applicationdata propagatechange() attach() detach() setdata() getdata() class Modelo { // colecção de vistas registadas private Vector vistas; // registar novos observers public attach (Vista vista) { vistas.add(vista); // anular registo de observers existentes public detach(vista vista) { vistas.remove(vista); public propagatechange() { Iterator iterator = vistas.iterator(); while(iterator.hasnext()) iterator.next().update(); observers * update() service() interface Vista { public void update(); public class VistaTipoPie implement Vista {... public void update() { public class VistaTipoBarras implement Vista {... public void update() { Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 20 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 23 : colaborações Nome: [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. anobject asubject : an1 : Subject attach(me) changedata update( ) getdata1 update( ) an2 : attach(me) getdata2 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 21 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 24 4
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,, State, Strategy,Template Method,Visitor, Master-Slave, Publisher-Subscriber, Blackboard, Reactor, Reflection,...... Frameworks Orientadas por Objectos As frameworks são uma poderosa ténica 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 abstraction Callbacks Hooks Plugins... Framework code Framework code Application Code 1 Application Code 3 Application Code 2 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 25 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 28 Questões O que é um padrão de software? Quais são os padrões de software mais populares? Aplicação Framework Aplicacional Diversos componentes Como se utilizam os padrões de software? Como se documenta um padrão de software? Framework Aplicacional Aplicação Bibliotecas de Classes Bibliotecas de Classes Bibliotecas de Procedimentos Bibliotecas de Procedimentos Sistema Operativo Sistema Operativo Aplicação OO convencional Aplicação OO com frameworks Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 26 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 29 Frameworks Orientadas por Objectos Exemplo: JUnit 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]. Frameworks fornecem uma solução inicial para um problema cuja solução normalmente requer muito tempo para desenvolver de raiz. 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. As frameworks são macro-arquitecturas Macro-arquitecturas que interligam diversos padrões e que também incluem normalmente a infraestrutura que suporta a sua integração. As frameworks possuem partes inalteráveis e partes configuráveis pelo utilizador através de mecanismos de herança (white-box) e/ou composição (black-box). Exemplos populares: MacApp, MVC, NEXTSTEP, MFC, J2EE (Swing, Enterprise JavaBeans,...), SanFrancisco, JUnit,.NET, Struts, etc. Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 27 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 30 5
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 análise, documentação, desenho, ou implementação de arquitecturas. Sessões de atendimento colectivas 12 sessões x 1-3 horas = 12-36 horas Diagnóstico & Caracterização Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 31 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 34 Bibliografia Tecnologias Software Architecture: Perspectives on an Emerging Discipline de Mary Shaw e David Garlan, publicados por Prentice Hall em 1996. Software Architecture in Practice de Len Bass, Paul Clements e Rick Kazman, 2ª edição, publicados por Addison-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. Linguagens de programação C, Pascal C++, Java, C# Programação Orientada por objectos Herança, polimorfismo, associação dinâmica, templates/hooks Análise e desenho OO Booch, OMT, UML Padrões de software GoF, POSA Arquitecturas comerciais J2EE.NET CORBA MacApp Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 32 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 35 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 do tipo 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%) Questões? Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 33 Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 36 6