Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho Engenharia de Software Projeto de Arquitetura

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Engenharia de Software

Projeto de Arquitetura


A arquitetura

“Desde que o primeiro programa foi dividido

em módulos, os sistemas passaram a ter

arquiteturas.”

Mary Shaw e David Garlan

Software Architecture: Perspectives on an Emerging Discipline


Aspectos de uma arquitetura

• Nos requisitos, a arquitetura aparece assim:– “Nossa aplicação deve operar via Web nas plataformas Unix,

Macintosh, OS/2 e Windows.”– “O produto deve ser compatível com CORBA.”– “O sistema deve garantir excelente tempo de resposta em

todas as configurações cliente-servidor.”– “Camelot é baseado no modelo cliente-servidor e usa

chamada remota a procedimentos.”– “Abstrações em camadas e a decomposição do sistema

oferecem uniformidade aos clientes do sistema.”– “Escolhemos uma abordagem distribuída, orientada a

objetos.”– “Um compilador paralelo faz um pipeline da execução das

fases de compilação.”



• Às vezes, a arquitetura aparece em um diagrama de caixas e linhas

Sistema de Simulação AcústicaSistema de Simulação Acústica

Processo de ControleProcesso de Controle

Modelo de RuídoModelo de Ruído Modelo de ReverberaçãoModelo de ReverberaçãoModelo de PerdaModelo de Perda

O que podemos extrair deste diagrama?



• O que podemos extrair?– O sistema consiste de quatro componentes– Três dos componentes têm mais em comum que

o Processo de Controle (por que?)– Os componentes relacionam-se de alguma forma



Modelo de Ruído

Modelo de Ruído

Modelo de Reverberação


Modelo de Perda

Modelo de Perda



• Qual a natureza dos componentes?– Por que existe a separação?– São executados em momentos diferentes?– Os componentes são módulos a serem desenvolvidos de

forma quase independentes?– Os componentes são hardware, objetos, módulos,

processos ou programas distribuídos?



Modelo de Ruído

Modelo de Ruído



Modelo de Perda

Modelo de Perda



• O significam as conexões?– Controle?– Envio de dados?– Uso (Processo de Controle usa Modelo de Ruído)?– Sincronização?– Ou uma combinação das anteriores?– E quais são os mecanismos de tal comunicação?



Modelo de Ruído

Modelo de Ruído



Modelo de Perda

Modelo de Perda



• O significa a hierarquia?– Por que Processo de Controle está em um nível acima?– O Processo de Controle chama os demais? E estes podem

chamar o Processo de Controle?

• Como a arquitetura opera em tempo de execução?– Qual o fluxo dos dados e do controle através do sistema?



Modelo de Ruído

Modelo de Ruído



Modelo de Perda

Modelo de Perda



Diagramas como este não são suficientes para descrever a arquitetura do sistema



Modelo de Ruído

Modelo de Ruído



Modelo de Perda

Modelo de Perda


O que é arquitetura?

“A arquitetura é composta de estruturas do sistema que incluem

• Componentes de software

• Suas propriedades visíveis externamente

• O relacionamento entre os componentes.”

Len Bass, Paul Clements e Rick Kazman

Software Architecture in Practice



“A arquitetura define o sistema em termos de componentes computacionais e interações entre

tais componentes.”





“A arquitetura está relacionada com– Organização do sistema em termos de componentes– Estruturas globais de controle– Protocolos de comunicação– Sincronização e acesso a dados– Alocação de funcionalidades aos elementos de projeto– Composição dos elementos de projeto– Distribuição física– Escalabilidade e desempenho– Evolução do sistema– Seleção entre alternativas sobre decisões de projeto.”





“Uma arquitetura é composta de

• Uma coleção de componentes, conexões e restrições.

• Uma coleção de declarações de stakeholders sobre suas necessidades

• As razões que justifiquem que os componentes, suas conexões e restrições satisfazem as necessidades dos stakeholders.”

Barry Boehm



“A arquitetura forma a espinha dorsal para se construir sistemas de software com sucesso.”

Software Engineering Institute (SEI)

Carnegie Mellon


Como descrever uma arquitetura?

• Nas definições apresentadas, temos em comum– Componentes– Relacionamentos entre os componentes– Propriedades destes componentes e relacionamentos



• Além disso, tais elementos tratam de vários aspectos– “Espinha dorsal do sistema”

– “Organização do sistema em termos de componentes”

– “Estruturas globais de controle”

– “Protocolos de comunicação”

– “Interações entre componentes”

– “Distribuição física”

– “Escalabilidade e desempenho”

– “Evolução do sistema”



• Porém, tais componentes e relacionamentos podem representar diferentes conceitos

Através de diferentes visõesAtravés de diferentes visões

• Como descrever aspectos tão diferentes?

Cliente

Servidor

BD

Módulos Hardware

Funções

ObjetosPipesThreads

ClassesProtocolos


Diferentes visões de uma arquitetura

• Os stakeholders envolvidos na construção de um edifício têm diferentes visões

• Cada visão é descrita de forma diferente (plantas, maquetes, esboços, etc)

– Todas se referem ao mesmo edifício

– E nenhuma é completa

Construtora

Cliente

Arquiteto

Decorador

Paisagista Eletricista

Encanador

Pedreiro

Pintor

Marceneiro

Mestre-de-obra

Prefeitura

Engenheiro

Que visão interessa a cada um destes stakeholders?

Que visão interessa a cada um destes stakeholders?


Diferentes visões de uma arquitetura• A arquitetura de software também deve ser descrita

por diferentes visões– Módulos– Lógica– Processos– Físico– Utilização– Chamada– Fluxo de dados– Fluxo de controle– Classes– Casos de uso– Segurança– Implementação– Camadas, etc



• Módulos– Os componentes são módulos do sistema– Os relacionamentos são do tipo “é-submódulo-de”– Esta visão geralmente define produtos e auxilia na

estruturação do planejamento do projeto (por módulos) e em alocação de recursos

• Que módulos desenvolver primeiro?• Que equipes serão alocadas por módulo?



• Lógico– Os componentes são abstrações dos requisitos

funcionais do sistema (tipicamente, funções)– Os relacionamentos são do tipo “compartilha-

dados-com”



• Processos– Os componentes são processos ou threads– Os relacionamentos são do tipo

• “sincroniza-com”• “não-executa-sem”• “não-executa-com”• “preempts”• etc

– É uma visão ortogonal às visões de módulos e lógico

– É útil em análises de escalonamento e desempenho



• Físico– Os componentes são dispositivos de hardware– Os relacionamentos são do tipo “comunica-se

com”– Permite analisar desempenho, disponibilidade e

segurança



• Utilização– Os componentes são procedimentos ou módulos– Os relacionamentos são do tipo

• “usa”• “assume-a-presença-de”

– Auxilia no projeto de sub-sistemas ou sistemas que podem ser facilmente estendidos



• Chamadas– Os componentes são procedimentos– Os relacionamentos são do tipo “invoca”– Permite rastrear o fluxo de execução do sistema e

eventual detecção e eliminação de gargalos



• Fluxo de dados– Os componentes são programas ou módulos– Os relacionamentos são do tipo “pode-enviar-

dados-a”– Os links podem ser rotulados com o nome dos

dados transmitidos– É útil para rastreamento de requisitos



• Fluxo de controle– Os componentes são programas, módulos ou

estados do sistema– Os relacionamentos são do tipo “ativa”– Auxilia na verificação do comportamento temporal– Esta visão é a mesma que a visão de chamadas,

caso o único mecanismo de transferência de controle disponível seja a chamada a função ou procedimentos.



• Classes– Componentes são objetos ou classes– Relacionamentos são do tipo

• “herda-de”• “é-uma-instância-de”

– Eventualmente, uma notação mais complexa como UML é mais eficiente que um modelo (ou visão) simplificada como esta



• Cada projeto vai possuir uma visão dominante– Por exemplo, freqüentemente a visão de módulos

é dominante– As demais visões são moldadas ou adaptadas

para se enquadrarem na visão dominante


Propriedades

• Arquiteturas definem componentes– Porém, omitem seus detalhes privados

(informações não arquiteturais)– Explicita informações de como um componente

• Usa• É usado por• Se relaciona com• Interage com outro componente


Propriedades• Comportam várias visões

• Porém, nenhuma visão isoladamente pode ser considerada “A Arquitetura”

MódulosMódulos

ImplementaçãoImplementação

ProcessosProcessosSegurançaSegurança

FísicoFísicoChamadaChamada

Casos de UsoCasos de UsoCamadasCamadasFluxosFluxos

ClassesClasses

LógicaLógicaUtilizaçãoUtilização


Propriedades• Relembrando: o papel dos componentes, relacionamentos e

até mesmo o contexto da arquitetura mudam em cada visão• Exemplo

– Componentes podem ser• Módulos• Processos• etc

– Relacionamentos• É-submódulo• Sincroniza-com• etc

– Contexto• Em tempo de desenvolvimento• Em tempo de execução• etc


Propriedades• Todo sistema tem arquitetura

– Não significa que esteja bem documentada– Não significa que seja conhecida por todos– Portanto, a arquitetura existe independente de sua

documentação

• O comportamento dos componentes é parte da arquitetura– Tal comportamento é o que permite que outros

componentes saibam como interagir– Também não significa que o comportamento preciso de

todas as interfaces devem ser especificadas• Apenas aspectos de como usar o componente

• Questões que tenham impacto na viabilidade do sistema como um todo (por exemplo, performance)


A importância da arquitetura

“Se o projeto ainda não definiu a arquitetura do sistema, incluindo sua

justificativa, ele não deve prosseguir com o desenvolvimento em larga escala.”

Barry Boehm



• A arquitetura abstrai informações detalhadas do sistema, mas consegue prover informação suficiente para– Análise do sistema como um todo– Tomada de decisões (técnicas ou gerenciais)– Redução de riscos


A importância da arquitetura• Uma bom projeto de arquitetura é um fator determinante

para o sucesso do projeto• A arquitetura ajuda

– Comunicação com os stakeholders• A arquitetura representa uma abstração de alto nível do sistema

comum a todos os stakeholders

• Cria um entendimento mútuo e consensual entre os stakeholders

– Decisões iniciais de projeto• As decisões iniciais de projeto são críticas (infra-estrutura, espinha

dorsal do sistema) e com impacto em todo o ciclo de vida

– Reusabilidade de abstrações• A arquitetura é um artefato relativamente pequeno, fácil de

entender e que pode ser reusado em outros projetos



• A boa arquitetura– Bem documentada e que utiliza uma notação que todos os

stakeholders entendem– Módulos são bem definidos e utilizam os princípios de

• Separation of concerns (separação de interesses)

• Encapsulamento

– Módulos produtores de dados devem ser diferentes de módulos consumidores de dados

– A arquitetura deve ser a mais independente possível de um produto ou tecnologia específica

• Caso tal dependência exista, a arquitetura deve permitir uma mudança fácil e de baixo custo

– A arquitetura deve permitir estender o sistema sem que a complexidade aumente


O Processo de Projeto de Arquitetura

• Estruturação do sistema – O sistema é decomposto em vários subsistemas principais e as

comunicações entre eles são identificadas

• Modelagem de controle– Um modelo do relacionamento de controle entre as diferentes

partes do sistema é estabelecido

• Decomposição modular– Os subsistemas identificados são decompostos em módulos


Subsistemas e Módulos

• Não há uma distinção clara.

Em linhas gerais...– Um subsistema é um sistema também cuja operação é

independente dos serviços providos por outros subsistemas.

– Um módulo é um componente do sistema que provê serviços a

outros componentes mas que normalmente não seria

considerado um sistema separado


Modelos de Arquitetura• Estrutura, controle e decomposição modular podem

ser baseados num modelo ou estilo de arquitetura particular.

• Contudo, a maioria dos sistemas são heterogêneos• O modelo de arquitetura usado afeta

– Desempenho– Robustez – Manutenibilidade

• Alguns domínios de aplicação possuem modelos específicos


Estruturação dos Sistemas

• O projeto de arquitetura pode ser expresso através de

diagramas de bloco apresentando uma visão geral da

estrutura do sistema

• Modelos mais específicos mostram

– Compartilhamento de dados

– Distribuição

– Interface entre os sistemas


Sistema de Controle de um Robô para Empacotamento

Visionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller


O Modelo de Repositório

• Subsistemas compartilham dados de duas formas:

– O dado compartilhado é colocado num banco de dados ou

repositório, podendo ser acessado por todos os subsistemas

– Cada subsistema mantém seu próprio banco de dados e passa

dados para os outros subsistemas

• Quando a quantidade de dados compartilhados é

grande, o modelo de repositório é mais apropriado.


Arquitetura de um Conjunto de Ferramentas CASE

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator


Vantagens do Modelo de Repositório

• Forma eficiente de compartilhar grande quantidades de

dados

• Subsistemas que produzem dados não precisam se

preocupar com como os dados são usados

• Gerenciamento (backup, segurança, etc.) centralizado

• O modelo de compartilhamento é tornado público

através do esquema do repositório


Desvantagens do Modelo de Repositório

• Subsistemas devem concordar no modelo de dados do

repositório. Inevitavelmente um compromisso.

• A evolução dos dados é difícil e cara

• Não há espaço para políticas específicas de

gerenciamento

• Dificuldade de distribuição efetiva de dados em

máquinas distintas


Modelo Cliente-servidor• Modelo de sistema distribuídos que mostra como

dados e processamento é distribuído entre

processadores

• Componentes:– Conjunto de servidores separados que provêm serviços

específicos

– Conjunto de clientes que usam estes serviços

– Rede que permite que clientes acessem os servidores


Biblioteca de Filmes e Retratos

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network


Vantagens do Modelo Cliente-servidor

• Fácil distribuição de dados

• Faz uso efetivos de sistemas em rede

• Adicionar novos servidores ou atualizar os atuais é fácil

• Modelos de dados otimizados para cada servidor podem

ser utilizados


Desvantagens do Modelo Cliente-servidor

• Troca de dados pode ser ineficiente

• Gerenciamento redundante em cada servidor

• Utilização de novos servidores pode requerer mudanças

no clientes


Modelo de Máquina Abstrata (Camada)

• Modela a interface dos subsistemas

• Organiza o sistema numa série de camadas

– Cada camada provê um conjunto de serviços

– Os serviços de uma camada são implementados usando os

serviços da camada logo abaixo


Sistema de Gerenciamento de Versão

Operatingsystem

Database system

Object management

Version management


Modelo de Máquina Abstrata (Camadas)

• Vantagens– Portável

– Quando uma camada muda, somente a camada adjacente é afetada

– Conveniente para desenvolvimento incremental

• Desvantagens– É difícil estruturar sistemas nesta forma

– Desempenho


Modelos de Controle

• Lidam com fluxo de controle entre subsistemas• Complementam o modelo estrutural• Abordagens

– Controle centralizado• Um subsistema tem responsabilidade geral

– Controle baseado em eventos • Cada subsistema pode responder a eventos gerados por

outros subsistemas ou pelo ambiente


Tipos de Controle Centralizado

• Modelo de retorno de chamada

– Aplicável a sistemas seqüenciais

– Modelo de subrotina top-down

• Modelo de gerente

– Aplicável a sistemas concorrentes

– Um componente do sistema controla a parada, início

e coordenação de outros processo do sistema.


Modelo de Retorno de Chamada (Centralizado)

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Sistema de Controle de Tempo Real (Modelo de Gerente - Centralizado)

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


Tipos de Controle Baseado em Eventos

• Modelo broadcast – Um evento é enviado, em princípio, para todos os

subsistemas. – Qualquer dos subsistemas que trate o evento poderá

fazê-lo.

• Modelo baseado em interrupções – Usado em sistemas de tempo real – Interrupções são detectadas por um gerenciador de

interrupções e repassadas para outro componente para processamento


Modelo Broadcast (Baseado em Eventos)

• Efetivo na integração de subsistemas em diferentes

computadores de uma rede

• Subsistemas registram interesse em eventos

específicos

• A política de controle não está embutida no

controlador de mensagens e eventos.



Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4



• Vantagens

– Evolução simples

– Facilidade de distribuição

• Desvantagens

– Subsistemas não sabem se e quando um evento será

tratado

– Possibilidade de conflito


Modelo Baseado em Interrupções (Baseado em Eventos)

• Usado em sistemas de tempo real onde a resposta

rápida a um evento é essencial

• Existem tipos conhecidos de interrupção com um

tratador (“handler”) definido para cada tipo

• Cada tipo está associado com uma localidade de

memória e um dispositivo de hardware causa a

transferência para seu tratador

• Permite resposta rápida, porém complexo para

programar, difícil de validar e de difícil evolução


Modelo Baseado em Interrupções (Baseado em Eventos)

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


Decomposição Modular

• Outro nível de decomposição onde subsistemas são organizados em módulos

• Modelos de decomposição estrutural se aplicam• Modelos adicionais

– Modelo objeto Sistema é decomposto em objetos que interagem

– Modelo de fluxo de dados • Sistema é decomposto em módulos funcionais

• Se possível, decisões sobre concorrência devem ser retardadas até os módulos serem implementados


Arquiteturas de Domínio Específico

• Tipos de arquiteturas de domínio específico – Modelos genéricos

• Abstrações de sistemas reais• Aplicáveis a uma classe restrita de sistemas • Podem ser usados diretamente

– Modelos de referência • Mais abstratos• Descrevem uma classe maior de sistemas• Usados para informação de conceitos e comparação de

arquiteturas


Modelos Genéricos

• Exemplo conhecido: modelo de um compilador

• Um grande número de outros modelos em

domínios de aplicação mais especializados

existem, mas poucos foram publicados


Arquiteturas de Referência• Modelos de referência são derivados de estudos do

domínio de aplicação

• Arquitetura idealizada

• Não devem ser a diretriz principal para a implementação

• Principal função: padrão contra o qual os sistemas podem ser avaliados

• Exemplo: Modelo OSI, um modelo de camadas para sistemas de comunicação


Modelo OSI de Referência

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Documents

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho Engenharia de Software Projeto de Arquitetura