Arquitetura de Software

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

1 Arquitetura de Software
Silvia Regina Vergilio

2 Atividades de Projeto Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos. Descreve a organização fundamental do sistema, identificando seus diversos módulos (e sua relações entre si e com o ambiente) para que se alcancem os objetivos propostos pelo cliente – Projeto da arquitetura do software. Projeto Detalhado: descrição detalhada/ refinamento de cada módulo, visando à codificação e especificação dos programas Embora haja esta definição, na prática ambas atividades podem ser realizadas em paralelo. realizar ambas as atividades em paralelo, concebendo assim um produto de design que permitirá tanto o alcance dos requisitos de qualidade (que normalmente é tarefa da arquitetura), quanto a construção precisa do sistema por meio de seus detalhes. Vamos entretanto focalizar ambas atividades em separado. Primeiro vamos ver o projeto da arquitetura de software.

3 Projeto da Arquitetura de Software
Arranjo do sistema para fazer corresponder os requisitos – tanto funcionais quanto não funcionais - aos subsistemas e componentes. Especificações e implementações calcadas apenas em requisitos não garantem o bom andamento do projeto e nem a robustez do sistema. O dinamismo dos requisitos traz impactos nas definições e especificações já estabelecidas. As organizações buscam soluções e adaptações para estes impactos.

4 Arquitetura Toda obra da humanidade apresenta um projeto arquitetural.
O projeto arquitetural precede a etapa de construção da obra. O projeto arquitetural determina as partes de uma construção e como estas devem interagir. A arquitetura garante a unidade da obra, ou seja, a consistência entre as suas partes.

5 O que é arquitetura de software?
do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor) tekhne – arte ou habilidade do dicionário: 1. Arte de projetar e construir prédios, edifícios ou outras estruturas; arquitetônica. 2 Constituição do edifício. 3 Contextura de um todo. 4 Intenção, projeto.

6 O que é arquitetura de Software?
O conceito de Arquitetura de Software surgiu nos anos 60 (com Dijkstra), mas se tornou popular nos anos 90. Perry e Wolf (92) Arquitetura = {Elementos, Organização, Decisões} É um conjunto de elementos arquiteturais (de dados, de processamento, de conexão) que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições. D.E. Perry and A. L. Wolf. Foundations for the study of software architecture. SIGSOFT Software Engineering Notes, 17(4):408211;52, October 1992. Elementos de processamento: : são elementos que usam ou transformam informação; Elementos de dados: : são elementos que contêm a informação a ser usada e transformada; e Elementos de conexão: : são elementos que ligam elementos de qualquer tipo entre si. Já a organização dita as relações entre os elementos arquiteturais. Essas relações possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relações devem ser ponderadas de modo a indicar sua importância no processo de seleção de alternativas. Exemplo 4.3 col, pag 59. Um elemento de dados muito presente no SASF e em sistemas de informação em geral é o banco de dados. Ele é o responsável por guardar e recuperar dados no sistema: informaçao textual, videos, fotos. Por isso, consideramos um elemento de dados para cada tipo. Assim, temos o banco de dados responsável por informações textuais, o banco de dados responsável por imagens e o banco de dados responsável por vídeos. Essa separação de responsabilidades permite que a implementa ção de cada elemento de dados disponha de serviços diferenciados ou mesmo tire proveito da natureza de seus dados para atender a algum atributo de qualidade (desempenho, escalabilidade, etc.). Dessa maneira, o elemento responsável por texto pode ser otimizado para busca por palavras-chave, enquanto o responsável por vídeos pode ser otimizado para recuperar grandes massas de dados a cada requisição. Por outro lado, também faz sentido dividir logicamente os elementos de dados em: elemento de dados de usuários e de dados de lmes. Vale notar que essa divisão é ortogonal à divisão em elementos de texto, imagens e vídeos e, portanto, o elemento de dados de usuários pode ser composto por um elemento de dados textuais e outro elemento de dados de imagens, da mesma maneira que o elemento de dados de filmes pode conter o elemento de dados textuais, de imagens e de vídeos. Como exemplo de elemento de processamento, citamos a lógica de negócio do SASF. Ela contém as regras de negócio que compõem o SASF. Note que podemos ainda dividir esse elemento de processamento em elementos mais especializados: o elemento de processamento responsável por criar, editar, recuperar e remover usuários, o responsável por criar, editar, recuperar e remover informações de filmes, o responsável pelo aluguel de lmes e o responsável por controlar a sessão de streaming, entre outros. Essa divisão, assim como a divisão dos elementos de dados, pode ser feita em prol do atendimento aos atributos de qualidade 2. No entanto, um elemento não é capaz de criar, editar, recuperar ou remover usuários sem se comunicar com os dados dos usuários. Da mesma maneira, o elemento responsável por manipular as informações dos lmes deve se comunicar com os elementos que guardam os dados dos lmes. Ou ainda, para controlar a sessão de streaming, o responsável deve obter o lme do elemento de dados que contém os lmes completos. Essa comunicação é feita pelos diversos elementos de conexão do SASF. Entre eles, podemos citar: o driver JDBC 3, que permite a comunicação com o banco de dados respons ável pelos usuários; o protocolo FTP, para transferência de vídeos; o protocolo HTTP, para transferências a partir do banco de imagens; ou o REST 4, que é uma especialização do HTTP e é usado para comunicação entre elementos de processamento.

7 O que é arquitetura de Software?
Shaw e Garlan (96) – a arquitetura define o que é o sistema em termos de componentes computacionais e, os relacionamentos entre estes componentes, os padrões que guiam a sua composição e restrições. Além da escolha dos algoritmos e estruturas de dados, a arquitetura envolve: decisões sobre as estruturas que formarão o sistema, controle, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, distribuição física dos elementos escalabilidade e desempenho e outros atibutos de qualidade; e seleção de alternativas de projeto. M. Shaw, D. Garlan; Software Architecture. Perspectives on an Emerging Discipline, Prentice Hall, 1996. D. Garlan and Mary Shaw. An introduction to software architecture. Technical Report- CMU-CS-94166,Carnegie Mellon University, January 1994. A visão sobre arquitetura de software de Garlan e Shaw se torna importante por conter três aspectos. O primeiro é por eles serem explícitos em quando devemos aplicar conhecimentos de arquitetura de software  quando lidamos com grandes sistemas. O segundo é por serem claros na separação de tarefas entre design detalhado e design arquitetural  o primeiro se preocupa com algoritmos e estruturas de dados, enquanto o segundo se preocupa com os elementos e organização do sistema como um todo, sendo em relação à estrutura do sistema, controle, comunicação, ou implantação. E, por fim, é por eles citarem que o processo de design da arquitetura precisa se preocupar com atributos de qualidade do sistema  alcançar escalabilidade ou desempenho, por exemplo. Exemplo 4.4 pg 64/70 A arquitetura de um sistema operacional, para atingir atributos de desempenho e portabilidade, deve se preocupar com diversos aspectos que comporão o sistema. É claro que alguns algoritmos serão também respons áveis pelo desempenho do S.O. em questão, como o responsável pela ordenação por prioridade dos processos em execução ou o de alocação de memória para um novo processo; mas a organização do sistema em camadas de abstração (abstração de hardware, sistema de arquivos e drivers, gerência de processos, API do sistema, bibliotecas e aplicações), a comunicação entre elas (uma camada só pode se comunicar com a camada seguinte, ou aplicações e bibliotecas só podem se comunicar com a API do sistema, etc.) e a sincronização (um aplicativo sugere o arquivamento de dados, mas o sistema de arquivo decidirá quando isso será feito) também impactarão no seu desempenho. Note que essa organização também tem impacto na portabilidade: quanto menos acoplado o resto das camadas for da camada de abstração de hardware, mais fácil será de realizar mudanças para que o sistema operacional esteja disponível para uma nova plataforma de hardware  idealmente, só havendo que se reimplementar essa camada.

8 O que é arquitetura de Software?
Bass (98) 2003: é a estrutura (ou estruturas) do sistema, a qual é composta de elementos de software, das propriedades externamente visíveis desses elementos, e dos relacionamentos entre eles; é a abstração do sistema. Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1998., 2nd edition, April 2003. Essa definição é explícita quanto ao papel da abstração na arquitetura (quando fala de propriedades externamente visíveis), e também quanto ao papel das múltiplas visões arquiteturais (estruturas do sistema). Devemos também mencionar o uso do termo elementos de software como as peças fundamentais da arquitetura. Se preocupa tambem com a visão externa do sistema. Ex: destaque para diferentes visões pg 65/71 Na visão em que dividimos o sistema em partes funcionais, podemos perceber aspectos do software como a composição entre elementos ou pontos de reuso. Já na visão em que dividimos o sistema em processos, podemos observar outros aspectos, como propriedades de comunicação e de interação entre as partes do sistema. Por exemplo, na primeira visão, os cadastros de lmes e de usuários podem compor um módulo maior responsável por todos os cadastros. Já na segunda visão, percebemos que a comunicação entre o navegador e o servidor de aplicações é síncrona, enquanto a comunica ção entre o motor de sugestão e o banco de dados é assíncrona em relação às ações dos usuários.

9 Arquitetura de Software – outras definições.
Astudillo (1998): é a interface entre o problema do negócio e a solução técnica. Jazayere et al (2000): conjunto de componentes e seus relacionamentos, que deve satisfazer os requisitos funcionais e não funcionais do sistema. ISO/IEEE Arquitetura é a organização fundamental de um sistema incorporada em seus componentes, seus relacionamentos com o ambiente, e os princípios que conduzem seu design e evolução. Podemos perceber que a definição acima é consistente com as anteriores por também mencionar que arquitetura compreende estrutura (ou elementos ou componentes), relações, e decisões (ou princípios). No entanto, ela vai além adicionando mais uma preocupação à arquitetura: conduzir a evolução do software. Este padrão ainda define um outro termos importante que é o conceito de visões de Arquitetura.

10 Uma Visão da Arquitetura de Software
É uma representação da informação (ou parte dela) contida na arquitetura de forma que se adéque às necessidades de um ou mais interessados. Ela facilita o entendimento por parte do interessado, uma vez que vai filtrar e formatar a informação. Por exemplo, a visão fornecida pelos casos de uso do sistema, pode interessar ao cliente/usuário. A visão de implementação aos programadores, etc. O arquiteto pode usar as diferentes visões para lidar com complexidade. Não podemos esquecer que o próprio arquiteto também pode tirar proveito desse conceito durante o processo de design da arquitetura. Quando um arquiteto faz design, ele usa o conceito de visões arquiteturais para assim endereçar as diferentes preocupações do sistema por vez. Dessa maneira, ele divide o problema de design em problemas menores e, consequentemente, menos complexos: ele endereça cada atributo de qualidade Atacando uma visão por vez, o arquiteto pode, por exemplo: primeiro definir as partições lógicas, ou seja, os módulos funcionais que comporão o sistema e assim considerar uma visão lógica do sistema; definir as partições dinâmicas do sistema, ou seja, quais processos, threads e protocolos estarão presentes no sistema e considerar uma visão de dinâmica; definir as partições do ponto de vista de implementação, ou seja, que classes, pacotes e bibliotecas comporão o sistema - considerar uma visão de desenvolvimento;

11 Arquitetura de Software
O termo arquitetura de software é usado para designar processo e produto. Produto – representação da estrutura de software Área da engenharia de software que trata de produzir as estruturas de software, visando a reduzir complexidade.

12 O Processo de Arquitetura de Software
Elaboração do modelo de negócio – envolve analisar custo, tempo de desenvolvimento, restrições de mercado, interfaces com outros sistemas, etc Entendimento dos requisitos: levantamento de requisitos e modelo do domínio Criação ou seleção de uma arquitetura: identificação dos componentes e suas interações, das dependências de construção e tecnologias que apoiam a implementação.

13 O Processo de Arquitetura de Software
Representação da arquitetura e divulgação: para permitir aos desenvolvedores e testadores o entendimento da arquitetura Implementação da arquitetura, seguindo seus protocolos e estruturas. Análise e avaliação: verificar a adequação da arquitetura, registrando impactos, riscos e dificuldades, o que servirá para evoluçao da arquitetura. A partir destas atividades, pode-se observar que produtos tais como modelo do negócio, modelo do domínio de aplicação, modelo dos componentes computacionais e relacionamentos entre eles e a infra-estrutura tecnológica são considerados modelos de arquitetura. Estes produtos devem refletir e justificar as decisões arquiteturais.

14 O Processo de Arquitetura de Software - Stakeholders
Participantes (interessados) Analista de requisitos – identifica os requisitos Arquiteto de software – cria a arquitetura - pode ser um time com um arquiteto líder. Projetista ou Desenvolvedor – implementa os componentes Outros: cliente/usuário, testador, gerente de projeto, programador, secretários, etc.

15 O Arquiteto de Software
ser capaz de reconhecer estruturas comuns em sistemas já desenvolvidos usar o conhecimento sobre arquiteturas existentes para tomar decisões de projeto em novos sistemas ser capaz de realizar uma descrição formal da arquitetura de um sistema a fim de analisar as propriedades do sistema apresentar a arquitetura para outras pessoas

16 O Arquiteto de Software
Habilidades: compreender profundamente o domínio e as tecnologias pertinentes dominar técnicas de modelagem e metodologias de desenvolvimento entender as estratégias de negócios da instituição onde atua conhecer produtos, processos e estratégias de concorrentes

17 O Arquiteto de Software
Tarefas: Especificação da arquitetura do software e das bases para o sistema de acordo com os requisitos do cliente. modelagem análise de trade-offs e viabilidade prototipação, simulação e realização de experimentos análise de tendências tecnológicas atuação como mentor de arquitetos novatos

18 Importância da Arquitetura
Como construir uma casa sem a planta? Atua como uma estrutura a fim de checar o atendimento aos requisitos do sistema Suporte na estimação de custos e gerência da complexidade do sistema Suporte ao reúso Reduz o intervalo entre especificação e implementação Permite considerar alternativas arquitetônicas em estágios iniciais do desenvolvimento Reduz riscos associados à construção do software

19 Importância da Arquitetura
A arquitetura – abstração que serve como base para criar um entendimento mútuo, para comunicação entre os participantes. Sua representação serve como guia para o projeto de sua implementação, teste e implantação do sistema.

20 A Definição da Arquitetura
Para o arquiteto, a fase de engenharia de requisitos é subsídio para a definição da arquitetura da qual se obtém: - processo de negócio modelado - planejamento estratégico das versões - requisitos de cada versão, etc.

21 A Definição da Arquitetura
- Deve facilitar reúso em diferentes níveis. É necessário que o sistema possa sofrer alterações de forma localizada, sem afetar outras partes. É necessário que novas funcionalidades sejam adicionadas sem causar impacto nas já existentes. A vida útil do sistema depende de uma boa arquitetura que facilite modificações, e permita sua evolução.

22 A Definição da Arquitetura
A definição está baseada na escolha de alternativas mais adequadas ao domínio da aplicação. É importante reutilizar e adotar estratégias previamente validadas. Utilizam-se frameworks, estilos, padrões e linguagens de descrição de componentes, previamente definidos.

23 Arquitetura: frameworks, padrões e estilos arquiteturais.

24 Conceito de Padrão Um template (formulário) de solução para um problema recorrente que seja comprovadamente útil em um determinado contexto. Um padrão de software é instanciado através da vinculação de valores a seus parâmetros. Os padrões podem existir em várias escalas e níveis de abstração; por exemplo, como padrões de arquitetura, padrões de análise, padrões de projeto, padrões de teste e idiomas ou padrões de implementação. Para merecer ser chamado de padrão, pelo menos três aplicações práticas devem ser evidentes.

25 Histórico Arquiteto ->Christopher Alexander.
Linguagem de padrões em arquitetura. Christopher Alexander --> catálogo com 253 padrões para edificações ligadas a regiões, cidades, transportes, casas, escritórios, paredes, jardins, etc.

26 Definição “um padrão expressa uma solução reutilizável descrita através de três partes: um contexto, um problema e uma solução”. (GAMMA et al., 1995). Contexto: estende o problema a ser solucionado, apresentando situações de ocorrência desses problemas. Problema: determinado por um sistema de forças, onde estas forças estabelecem os aspectos do problema que devem ser considerados. Solução: mostra como resolver o problema recorrente e como balancear as forças associadas a ele.

27 Padrões em ES padrões em ES permitem que desenvolvedores possam recorrer a soluções já existentes para solucionar problemas que normalmente ocorrem em desenvolvimento de software; Surgimento: início dos anos 90; Padrões capturam experiência existente e comprovada em desenvolvimento de software, ajudando a promover boa prática de projeto.

28 Categorias de Padrões Padrões Arquiteturais: expressam
um esquema de organização estrutural fundamental para sistemas de software. (BUSCHMANN et al., 1996) Padrões de Projeto: disponibilizam um esquema para refinamento de subsistemas ou componentes de um sistema de software (GAMMA et al., 1995) Idiomas: descrevem como implementar aspectos particulares de componentes ou de relacionamentos entre eles, usando as características de uma dada linguagem public void runServer() { ServerSocket server; Socket connection; try { connection = server = new ServerSocket(7000, 100); server.accept(); }

29 Padrões de arquiteturas (ou arquiteturais)
São templates prontos que solucionam problemas arquiteturais recorrentes Expressam um esquema fundamental de organização estrutural para sistemas de software. Fornecem um conjunto de subsistemas pré-definidos, especificando suas responsabilidades e incluindo regras e diretrizes para organizar as relações entre eles. Para merecer ser chamado de padrão, pelo menos três aplicações práticas devem ser evidentes.

30 Padrões de arquiteturas
Os templates contêm as seguintes informações: Nome do padrão Contexto Problema Impõe a descrição de vários aspectos problemáticos que devem ser considerados Solução Fundamentos Contexto resultante Exemplos Para merecer ser chamado de padrão, pelo menos três aplicações práticas devem ser evidentes.

31 Nome do Padrão Broker Contexto Ambiente distribuido Problema Como os componentes do sistema devem se comunicar entre si. Solução Crie um intermediári entre um componente-cliente e um componente servidor, o broker. Um cilente envia uma mensaem parao Broker contendo todas as informações apropriads para que a comunicação seja efetuada. O Broker é responsável por completar a conexão

32 Vantagens e Benefícios
Padrões reduzem a complexidade da solução Padrões promovem o reúso Padrões facilitam a geração de alternativas Padrões facilitam a comunicação Padrões reduzem a complexidade da solução ao prover abstrações reusáveis. Um padrão arquitetural já define elementos, serviços e relações arquiteturais, diminuindo assim a quantidade de novos conceitos que devem ser introduzidos à solução. Padrões promovem o reúso. Como padrões arquiteturais são soluções de design para problemas recorrentes, é possível que a implementação (parcial ou total) do padrão já esteja disponível para reúso, facilitando o desenvolvimento. Padrões facilitam a geração de alternativas. Mais de um padrão arquitetural pode resolver o mesmo problema, só que de forma diferente. Portanto, conhecendo diversos padrões, um arquiteto pode avaliar e escolher qual ou quais padrões irão compor a solução do problema, considerandoos benefícios e analisando as desvantagens proporcionadas por eles. Padrões facilitam a comunicação. Padrões arquiteturais facilitam a comunicação da arquitetura porque descrevem conceitos e elementos que estarão presentes no design. Portanto, se uma solução de design contém padrões que são conhecidos por todos os participantes da comunicação, os elementos e conceitos denidos pelos padrões não precisam ser explicitados, uma vez que os participantes já devem conhecê-los também.

33 Estilos de Arquitetura
Uma arquitetura de software, ou somente uma visão de arquitetura, pode ter um atributo chamado estilo de arquitetura, que reduz o conjunto de formulários que podem ser escolhidos e impõe um determinado grau de uniformidade à arquitetura. O estilo pode ser definido por um conjunto de padrões, ou pela escolha de componentes ou conectores específicos que funcionarão como os tijolos básicos da construção.

34 Estilos de Arquitetura
Expressam esquemas de organização estrutural de sistemas, fornecendo um conjunto de componentes do sistema, suas responsabilidades e a forma de interação entre eles. Cada estilo de arquitetura lida com diferentes tipos de atributos de qualidade. Para obter a definição de uma arquitetura a partir dos estilos existentes, basta saber quais os atributos mais relevantes para a solução e confrontá-los com os atributos que o estilo atende. A escolha de um estilo deve ser guiada pelas propriedades gerais que a aplicação requer e mais ainda, pelos requisitos não funcionais como portabilidade e confiabilidade. Além disso, os estilos podem ser combinados entre si para suportar os requisitos necessários e apoiar a definição de uma arquitetura mais adequada para o problema. É necessário observar que a arquitetura não é definida apenas pela adoção de um ou vários estilos. Eles são apenas um primeiro passo para especificar a estrutura fundamental de um sistema.

35 Estilos Arquiteturais
A arquitetura de um sistema pode aderir a um ou mais estilos arquiteturais. Um estilo define os tipos de elementos que podem aparecer em uma arquitetura e as regras que regem a interconexão entre estes elementos. Esses estilos podem simplificar o problema de definição de arquiteturas de sistema. A maioria dos sistemas de grande porte adere a vários estilos Estilos arquiteturais = “modelos arquiteturais”

36 Exemplos de Estilos Arquiteturais
Cliente-Servidor Camadas Filtros e dutos (pipes and filters) Repositório Orientado a eventos (publisher/subscriber) Objetos distribuídos, etc

37 Estilos Arquiteturais e Escolhas de Projeto
Um estilo arquitetural representa um conjunto de escolhas de projeto Conjunto de características comuns a diversos sistemas nos quais as mesmas escolhas foram feitas Padrões arquiteturais Um sistema aderente a determinado estilo “ganha" as características a ele inerentes Estilos podem ser usados para descrever uma determinada arquitetura Foco nas soluções de projeto e não em sua documentação

38 Organização de sistema
Reflete a estratégia básica que é usada para estruturar um sistema. Exemplos: O estilo de repositório de dados compartilhados Estilo de serviços e servidores compartilhados Estilo de máquina virtual ou em camadas Orientado a objetos (ou Objetos Distribuídos) Pipes and Filters ou Pipelining

39 Modelo de referência da Arquitetura
Consiste na decomposição padronizada do problema em partes conhecidas que cooperam entre si em prol de uma solução. Geralmente, estes problemas são de domínio bastante amadurecido e trazem a experiência de analistas de negócio em conjunto com desenvolvedores [Bass98]. O modelo de referência de um determinado domínio surge durante o processo de amadurecimento da solução em função da necessidade de representações mais abstratas que caracterizam o domínio. Pg 23 de Anne.pdf Um modelo de referência consiste na decomposição padronizada do problema em partes conhecidas que cooperam entre si em prol de uma solução. Geralmente, estes problemas são de domínio bastante amadurecido e trazem a experiência de analistas de negócio em conjunto com desenvolvedores [Bass98]. O modelo de referência de um determinado domínio surge durante o processo de amadurecimento da solução em função da necessidade de representações mais abstratas que caracterizam o domínio.

40 Arquitetura de Referência
Consiste em componentes de software e nos relacionamentos entre eles que implementam funcionalidades relativas às partes definidas no modelo de referência. Cada uma destas partes pode ser implementada em apenas um ou vários componentes de software, ou seja, o mapeamento das funcionalidades do modelo de referência em componentes da arquitetura de referência nem sempre é um para um. As arquiteturas de referência são aplicáveis a um domínio particular. Uma arquitetura de referência consiste em componentes de software e os relacionamentos entre eles que implementam funcionalidades relativas às partes definidas no modelo de referência. Cada uma destas partes pode ser implementada em apenas um ou vários componentes de software, ou seja, o mapeamento das funcionalidades do modelo de referência em componentes da arquitetura de referência nem sempre é um para um [Bass98]. As arquiteturas de referência são aplicáveis a um domínio particular. A escolha de um estilo deve ser guiada pelas propriedades gerais que a aplicação requer e mais ainda, pelos requisitos não funcionais como portabilidade e confiabilidade. Além disso, os estilos podem ser combinados entre si para suportar os requisitos necessários e apoiar a definição de uma arquitetura mais adequada para o problema. É necessário observar que a arquitetura não é definida apenas pela adoção de um ou vários estilos. Eles são apenas um primeiro passo para especificar a estrutura fundamental de um sistema.

41 Arquiteturas de Referência
Derivadas de um estudo de domínio de aplicação, ao invés de sistemas existentes. Podem ser usadas como base para a implementação de sistemas ou comparação de sistemas diferentes. Atuam como um padrão com relação ao qual os sistemas podem ser avaliados. Exs. Modelo OSI para sistemas de comunicação Organização tradicional de compiladores em vanguarda e retaguarda (e seus elementos internos)

42 Modelo de referência OSI
Sommerville, I.

43 Frameworks de Arquitetura
Um framework de arquitetura ou uma infra-estrutura de arquitetura é um conjunto de componentes com os quais pode-se criar um determinado tipo de arquitetura. Várias das maiores dificuldades arquiteturais devem ser resolvidas no framework ou na infra-estrutura, geralmente, direcionadas a um domínio específico: comando e controle, sistema de controle, etc.

44 Relacionamento entre eles
Modelo de Referência Arquitetura de Referência Arquitetura de software Arquitetura do sistema Estilos de arquitetura Modelos de referencia agregam soluções do ponto de vista de negócio e arquiteturas do ponto de vista técnico, baseando-se no modelo de negocios, por isto é referente a um determinado domínio. A arquitetura de referencia é composta tb a partir dos estilos de arquitetura. Estes compõem uma arquitetura do software a ser implementada e virará a arquitetura do sistema. Os frameworks oferecem componentes prontos a serem utilizados na implementação. A arquitetura pode envolver a construçao de uma familia de sistemas, que pode envolver Caracteristicas genéricas para os mesmos e pontos de variabilidade --LPS Padrões de arquitetura