Eng.ª do Software - 7. Desenho arquitectónico

ENGENHARIA DO SOFTWARE I

Manuel Menezes de Sequeira

DCTI, ISCTE-IUL

[email protected], D6.02

As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel

Menezes de Sequeira.

mailto:[email protected]

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE8/Presentations/index.html



Engenharia do Software I 2

Na aula anterior

Gestão de projectosActividades de gestãoPlaneamento de projectosCalendarização de projectosGestão do risco

2009/2010


Desenho arquitectónico

2009/2010


Sumário

Desenho arquitectónicoDecisões no desenho arquitectónicoOrganização de sistemasEstilos de decomposiçãoEstilos de controloArquitecturas de referência

2009/2010


Objectivos Apresentar desenho arquitectónico e discutir sua

importância

Explicar decisões tomadas no desenho arquitectónico

Apresentar três estilos arquitectónicos cobrindo organização, decomposição e controlo

Discutir arquitecturas de referência para comunicar e comparar arquitecturas

2009/2010


Arquitectura de software

Desenho arquitectónico é o processo de desenho queIdentifica subsistemas formando o sistemaIdentifica estrutura de controlo e

comunicação de subsistemasResulta em descrição da arquitectura do

software

2009/2010


Desenho arquitectónico Fase inicial do processo de desenho do sistema

Representa ligação entre processos de especificação e desenho

Frequentemente em paralelo com actividades de especificação

Identifica principais componentes do sistema e sua comunicação

2009/2010


Vantagens da arquitectura explícitaComunicação com partes interessadas

Arquitectura pode ser usada como foco de discussão pelas partes interessadas no sistema.

Análise do sistema Possível aferir se sistema pode cumprir requisitos não funcionais.

Reutilização em grande escala

Arquitectura pode ser reutilizada numa variedade de sistemas.

2009/2010


Características da arquitectura e do sistemaDesempenho Minimiza comunicações e confina operações

críticas. Usa granularidade grossa e não fina para componentes.

Segurança (security)

Usa arquitectura em camadas com activos críticos nas camadas interiores.

Segurança (safety)

Confina características críticas relativamente à segurança a pequeno número de subsistemas.

Disponibilidade Inclui componentes e mecanismos redundantes para ser tolerante a falhas.

Mantenibilidade Usa componentes com granularidade fina e substituíveis.

2009/2010

• Security: segurança face a actos de pessoas, por exemplo fraude, roubo ou acesso ilícito.

• Safety: segurança face a falhas e acontecimentos físicos.


Conflitos arquitectónicos Componentes com granularidade grossa

Melhor desempenhoMenor manutenibilidade

Dados redundantesMelhor disponibilidadeSegurança (security) mais difícil

Características de segurança (safety) confinadasNormalmente maior comunicaçãoMenor desempenho

2009/2010


Estruturação do sistema Foco na decomposição do sistema em

subsistemas interagentes

Desenho arquitectónico normalmente expresso como diagrama de blocos representando vista da estrutura do sistema

Pode desenvolver-se modelos mais específicos mostrando partilha de dados, distribuição e interface entre subsistemas

2009/2010

12Engenharia do Software I

Exemplo: Sistema de controlo de robot de embalamento

2009/2010

Sistema de visão

Sistema de identificação de objectos

Controlador do braço

Controlador da mão

Sistema de selecção de embalagens

Controlador de tapete rolante

Sistema de embalamento


Diagramas de caixas e linhas Muito abstractos, não mostram natureza

de relações entre componentes nem propriedades observáveis de subsistemas

No entanto, úteis para comunicação com partes interessadas e para planeamento de projectos

2009/2010


Decisões no desenho arquitectónico Desenho arquitectónico é processo

criativo

Processo varia com tipo do sistema em desenvolvimento

Mas há conjunto de decisões comuns a todos os processos de desenho

2009/2010


Decisões no desenho arquitectónico Há arquitectura aplicacional genérica

usável? Como distribuir sistema? Que estilos arquitectónicos se apropriam? Que abordagem para estruturar sistema? Como decompor sistema em módulos? Que estratégia de controlo usar? Como avaliar desenho arquitectónico? Como documentar arquitectura?

2009/2010


Reutilização de arquitecturas

Sistemas do mesmo domínio têm muitas vezes arquitecturas semelhantes reflectindo conceitos do domínio

Linhas de produto aplicacionais construídas em torno de arquitectura central com variantes satisfazendo requisitos particulares do cliente

2009/2010

Capítulo 13

Capítulo 18


Estilos arquitectónicos Modelo arquitectónico de sistema pode

conformar-se a modelo ou estilo arquitectónico genérico

Conhecer estilos pode simplificar definição de arquitecturas de sistemas

No entanto, muitos dos grandes sistemas são heterogéneos não seguindo estilo arquitectónico único

2009/2010


Modelos arquitectónicos

Documentam desenho arquitectónicoModelo estrutural estático mostrando

principais componentes do sistemaModelo dinâmico da estrutura de processos

do sistemaModelo das interfaces dos subsistemasModelo de relações entre subsistemas (e.g.,

modelo de fluxo de dados)Modelo de distribuição dos subsistemas

pelos computadores

2009/2010


Organização de sistemas

Reflecte estratégia básica usada para estruturar sistema

Três estilos organizacionais muito usadosRepositório partilhado de dadosServiços e servidores partilhadosMáquina abstracta ou estilo em camadas

2009/2010


Modelo de repositório Subsistemas têm de trocar dados

Duas formas possíveisDados em repositório ou base de dados central

partilhados por subsistemasCada subsistema mantém sua base de dados e

passa dados explicitamente a restantes subsistemas

Modelo de repositório partilhado mais comum quando se partilha grandes quantidades de dados

2009/2010


Exemplo: Arquitectura de conjunto de ferramentas CASE

2009/2010

Editor de desenho

Gerador de código

Analisador de desenho

Gerador de relatórios

Editor de programas

Tradutor de desenho

Repositório do projecto


Vantagens do modelo de repositório Eficiente partilhar grandes quantidades de dados

Subsistemas não se preocupam com produção de dados

Gestão centralizada (cópias de segurança, segurança, etc.)

Modelo de partilha publicado como esquema (schema) do repositório

2009/2010


Desvantagens do modelo de repositório Subsistemas têm de acordar modelo de

repositório de dados (compromisso)

Evolução de dados difícil e onerosa

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

Difícil distribuir eficientemente

2009/2010


Modelo cliente-servidor Modelo distribuído de sistema mostrando como

dados e processamento se distribuem por conjunto de componentes

Conjunto de servidores isolados disponibilizando serviços específicos (impressões, gestão de dados, etc.)

Conjunto de clientes usando serviços

Rede para clientes acederem a servidores

2009/2010


Exemplo: Mediateca

2009/2010

Cliente 1 Cliente 1Cliente 1Cliente 1

Servidor de catálogo

Catálogo da mediateca

Servidor de vídeo

Ficheiros de vídeo

Servidor de imagens

Fotografias digitalizadas

Servidor Web

Informação sobre média

Internet


Vantagens do modelocliente-servidor Distribuição de dados óbvia

Utilização eficaz de sistemas em rede

Pode requerer hardware mais barato

Fácil adicionar novos servidores ou actualizar existentes

2009/2010


Desvantagens do modelocliente-servidor Subsistemas com diferentes organizações

de dados, sem modelo partilhado de dados

Troca de dados pode ser ineficiente

Administração separada dos servidores

Pode ser difícil saber servidores e serviços disponíveis, sem registo central de nomes e serviços

2009/2010


Arquitectura Orientada por Serviços (SOA) Arquitectura

distribuída genérica baseada no paradigma pedido/resposta

Exemplos RPC DCOM CORBA Web Services WCF

2009/2010

Capítulo 12

Serviço de directório

Serviço Serviço

Parceiros de negócio

Outros fornecedores

Cliente

Serviço Serviço


Princípios arquitecturais da SOA

Encapsulamento Ligação fraca (loose coupling) Contratualidade Abstracção Reutilizabilidade Componibilidade Autonomia Descobribilidade

2009/2010


Modelo de máquina abstracta (em camadas) Subsistemas ligados através de interfaces

Organiza sistema em camadas (máquinas virtuais) fornecendo conjunto de serviços

Suporta desenvolvimento incremental de subsistemas: alteração de interface só afecta camada adjacente

Muitas vezes artificial para estruturar sistemas

2009/2010


Exemplo: Sistema de controlo de versões

2009/2010

Gestão de configurações

Gestão de objectos

Bases de dados

Sistema operativo

Camadas de

sistema


Estilos de decomposição modular Decomposição de subsistemas em

módulos

Sem distinção rígida entre organização do sistema e decomposição modular

2009/2010


Subsistemas e módulosSubsistema Sistema cuja operação é independente dos serviços

fornecidos por outros subsistemas.

Módulo Componente de sistema que fornece serviços a outros componentes mas que por si só normalmente não se considera um sistema.

2009/2010


Decomposição modular Nível estrutural em que subsistemas se

decompõem em módulos

Dois modelos abordadosModelo de objectos – Decomposição em objectos em

interacçãoModelo de fluxo de dados – Decomposição em

módulos funcionais transformando entradas em saídas

Tentar adiar decisão sobre concorrência até implementação de módulos

2009/2010


Modelos de objectos Estruturam sistema em conjunto de objectos

fracamente ligados com interfaces bem definidas

Decomposição corresponde a identificar classes de objectos, seus atributos e suas operações

Na implementação, objectos criados via classes e modelo de controlo coordena operações dos objectos

2009/2010


Exemplo: Sistema de processamento de facturas

2009/2010

Customer

- customerNumber- name- address- creditPeriod

Payment

- invoiceNumber- date- amount- customerNumber

Invoice

- invoiceNumber- date- amount- customer

+ issue()+ sendReminder ()+ acceptPayment()+ sendReceipt()

Receipt

- invoiceNumber- date- amount- customerNumber


Vantagens do modelo de objectos Objectos fracamente ligados, implementação

pode mudar sem afectar outros objectos

Objectos podem reflectir entidades reais

Linguagens de implementação orientadas por objectos muito usadas

Mas alterações em interfaces podem causar problemas e entidades complexas podem ser difíceis de representar

2009/2010


Fluxo de dados orientado por funções Transformações funcionais transformam

entradas em saídas

Também conhecido por modelo pipeline ou modelo pipe and filter (shell UNIX)

Variantes muito comuns: se transformações sequenciais, modelo em lote sequencial usado em sistemas de processamento de dados

Mas não apropriado para sistemas interactivos

2009/2010


Exemplo: Sistema de processamento de facturas

2009/2010

Facturas Pagamentos

Ler facturas emitidas

Emitir recibos

Procurar pagamentos

devidos

Emitir lembrete de pagamento

Lembretes

Recibos

Identificar pagamentos


Vantagens do modelo de fluxo de dados Suporta reutilização de transformações

Organização intuitiva para comunicar com partes interessadas

Fácil adicionar novas transformações

Relativamente fácil de implementar em sistemas concorrentes e sequenciais

Mas requer formato comum para transferência de dados e difícil suportar interacção baseada em eventos

2009/2010


Estilos de controlo Focam-se no fluxo de controlo entre

subsistemas

Distintos do modelo de decomposição do sistema

2009/2010


Estilos de controloControlo centralizado Um subsistema tem responsabilidade

global pelo controlo e inicia e termina os outros subsistemas.

Controlo baseado em eventos

Cada subsistema responde a eventos gerados externamente com origem em outros subsistemas ou em ambiente do sistema.

2009/2010


Controlo centralizado

Subsistema de controlo com responsabilidade por gerir execução de outros subsistemas

2009/2010


Controlo centralizadoModelo invocação-retorno

Modelo descendente (top-down) de subrotinas em que controlo começa no topo da hierarquia de subrotinas. Aplicável a sistemas sequenciais.

Modelo de gestor Aplicável a sistemas concorrentes. Um componente do sistema controla paragem, arranque e coordenação de outros processos do sistema. Pode ser implementado em sistemas sequenciais como instrução de selecção múltipla.

2009/2010


Modelo invocação-retorno

2009/2010

Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2

Programa principal

Rotina 1 Rotina 3Rotina 2


Controlo de sistema em tempo real

2009/2010

Processos sensores

Processos actuadores

Processos de computação

Interface com utilizador

Gestor de anomalias

Controlador do sistema


Sistemas guiados por eventos Guiados por eventos gerados externamente

Instante de ocorrência dos eventos fora do controlo dos subsistemas que o processam

Dois principais modelosDifusãoGuiados por interrupções

Outros modelosFolhas de cálculoSistemas de produção

2009/2010


Modelos de sistemas guiados por eventosDifusão Cada evento difundido para todos subsistemas.

Qualquer subsistema pode lidar com evento.

Guiados por interrupções

Usados em sistemas de tempo real.Interrupções detectadas por gestor de interrupções e passadas a outro componente para processamento.

2009/2010


Modelo de difusão Eficaz para integrar subsistemas em diferentes

computadores de uma rede

Subsistemas registam interesse em eventos específicos; quando ocorrem, controlo transferido para subsistemas que com eles podem lidar

Política de controlo não está no gestor de eventos e mensagens; subsistemas decidem que eventos são do seu interesse

No entanto, subsistemas não sabem se e quando um evento será processado

2009/2010


Difusão selectiva

2009/2010

Subsistema 1 Subsistema 4Subsistema 3Subsistema 2

Gestor de mensagens e eventos


Sistemas guiados por interrupções Usados em sistemas de tempo real onde é

essencial responder rápido a eventos

Um gestor definido para cada tipo de interrupções conhecido

Cada tipo associado a posição de memória; comutador hardware transfere para gestor associado

Permitem resposta rápida, mas complexos de programar e difíceis de validar

2009/2010


Controlo guiado por interrupções

2009/2010

Vector de interrupções

Interrupções

Gestor 1 Gestor 2 Gestor 3 Gestor 4

Processo 1 Processo 2 Processo 3 Processo 4


Arquitecturas de referência Modelos arquitectónicos podem ser específicos de

um dado domínio de aplicação

Tipos de modelo específico de domínio Modelos genéricos Modelos de referência

2009/2010


Tipos de modelo específico de domínioModelos genéricos

Abstracções de uma quantidade de sistemas reais que incorporam as principais características desses sistemas. Usualmente são modelos ascendentes (bottom-up).

Modelos de referência

Modelos mais abstractos e idealizados. Informam acerca dessa classe de sistema e facilitam a comparação entre diferentes arquitecturas. São modelos descendentes (top-down).

2009/2010

Capítulo 13


Arquitecturas de referência Modelos de referência derivados do estudo do

domínio de aplicação e não de sistemas existentes

Usados como base para implementação de sistemas ou para comparar sistemas

São padrão de referência para avaliação de sistemas

Modelo OSI é modelo em camadas para sistemas de comunicação

2009/2010


Modelo de referência OSI

2009/2010

Meio de comunicações

Físico

Dados

Rede

Transporte

Sessão

Apresentação

Aplicação

1

2

3

4

5

6

7

Físico

Dados

Rede

Transporte

Sessão

Apresentação

Aplicação

Físico

Dados

Rede


A reter Arquitectura de software é enquadramento

fundamental para estruturar sistemas

Decisões arquitectónicas de desenhoTipo de aplicaçãoDistribuição do sistemaEstilos arquitectónicos

Diferentes modelos arquitectónicosEstruturalDe controloDe decomposição

2009/2010


A reter

Modelos organizacionais de sistemasDe repositórioCliente-servidorDe máquinas abstractas

Modelos de decomposição modularDe objectosDe fluxo de dados

2009/2010


A reter

Modelos de controloControlo centralizadoGuiado por eventos

Arquitecturas de referência usadas para comunicar arquitecturas específicas de domínio e para avaliar e comparar desenhos arquitectónicos

2009/2010


A ler

Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006

Capítulo 11Capítulo 12

2009/2010

Eng.ª do Software - 7. Desenho arquitectónico

Education

Transcript of Eng.ª do Software - 7. Desenho arquitectónico