Projeto de Arquitetura - dcce. · PDF filecomponentes estruturais da arquitetura do software....

UNIVERSIDADE ESTADUAL PAULISTAINSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

Slide 1

Projeto de Arquitetura

Engenharia de Software

2o. Semestre de 2006

Projeto de Arquitetura

Estabelece a estrutura global de um sistema de software

Objetivos

Introduzir projeto arquitetural e discutir sua importância.Explicar porque vários modelos são necessários para documentar uma arquitetura de software. Descrever os tipos de modelos arquitetural que podem ser usados.

TópicosEstruturação de sistemaModelos de controleDecomposição modular

Atividades de projeto

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design productsProdutos do projeto

Atividades do projeto

Arquitetura de sistema

Especificaçãode requisitos

Projeto dearquitetura

Especificaçãoabstrata

Projeto deinterface

Projeto decomponentes

Projeto deestruturade dados

Projeto dealgoritmos

Especificação de software

Especificação de interface

Especificação de componentes

Especificaçãode estruturas

de dados

Especificaçãode algoritmos

Produtos do projetoProjeto da Arquitetura do Software: visa a definir os grandes componentes estruturais do software e seus relacionamentos.Projeto de Dados: tem por objetivo projetar a estrutura de armazenamento de dados necessária para implementar o software.Projeto de Interfaces: descreve como o software deverá se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usuário).Projeto Procedimental Detalhado: tem por objetivo refinar e detalhar a descrição procedimental dos componentes estruturais da arquitetura do software.

Arquitetura do SoftwareO processo inicial de projeto, que consiste em identificar os subsistemas é chamado de projeto de arquiteturaprojeto de arquitetura.A saída desse processo de projeto é uma descrição da arquitetura do software.

Arquitetura de um sistema de controle de tráfego aéreo

Slide 8

Fluxo de informações entre subsistemas

Projeto da arquiteturaÉ o primeiro estágio do processo de projeto do sistemaRepresenta a ligação entre a especificação e os processos de projeto.Freqüentemente é realizado em paralelo com algumas atividades de especificaçãoEnvolve a especificação dos componentes principais do sistema e das comunicações desses componentes.

Vantagens de uma arquitetura explícita

Comunicação com os usuáriosArquitetura é uma representação de alto nível do sistema, que pode ser usada como ponto de discussão para diferentes usuários.

Análise de sistemaDecisões do projeto de arquitetura tem um profundo efeito sobre se o sistema pode ou não cumprir requisitos não funcionais importantes (desempenho, confiabilidade, facilidade de manutenção)

Reutilização em larga escalaA arquitetura pode ser reutilizada em sistemas com requisitos similares ou para em um sistema pertencente a uma família de aplicações.

Atividades de Processos de projeto de arquitetura

Estruturação de sistemaO sistema é decomposto em vários subsistemas principais e a comunicação entre esses subsistemas são identificados.

Modelagem de controleÉ estabelecido um modelo geral dos relacionamentos de controle entre as partes do sistema.

Decomposição modularOs subsistemas identificados são decompostos em módulos. O projetista deve decidir sobre o tipo de módulo e suas interconexões.

Subsistemas e módulosUm subsistemasubsistema é um sistema cuja operação não depende de serviços fornecidos por outros subsistema. Um módulomódulo é um componente do sistema que fornece serviços a outros componentes, mas normalmente não é considerado um sistema independente.

Modelos de arquiteturaDiferentes modelos de arquitetura pode ser produzidos durante o processo de projeto.Cada modelo representa diferentes perspectivas na arquitetura.

Modelos de arquiteturaModelo estrutural estáticoModelo estrutural estático mostra os subsistemas ou componentes que devem ser desenvolvidos como unidades separadas.Modelo de processo dinâmicoModelo de processo dinâmico mostra a estrutura do sistema em tempo de execução.Modelo de interfaceModelo de interface que define os serviços oferecidos por cada subsistema.Modelo de relacionamentoModelo de relacionamento que mostram relacionamentos entre subsistemas, tal como o fluxo de dados entre os sistemas.

Estilos de arquiteturaO projeto de arquitetura de um sistema pode ter como base um modelo ou um estilo de arquitetura específico.A maioria dos sistemas de grande porte não seguem um modelo único. Diferentes partes do sistema podem ser projetadas com o uso de diferentes modelos de arquitetura.

Arquitetura vs. Requisitos não funcionais.

DesempenhoOperações devem ser distribuídas para um número menor de subsistemas para minimizar a comunicação entre subsistemas

Proteçãousar uma arquitetura em camada com alto nível de validação de proteção às camadas mais internas.

SegurançaIsolar componentes críticos em um pequeno número de subsistemas

Disponibilidade (arquiteturas de sistemas tolerantes a falhas)Incluir componente redundantes na arquitetura.

Facilidade de manutençãoUsar componentes encapsulados de menor granularidade.

Estruturação do sistema (modelos estruturais)

Se preocupa com a decomposição do sistema em subsistemas que interagem.O projeto de arquitetura normalmente é expresso por um diagrama de blocos representando uma visão geral da estrutura do sistema.Modelos mais específicos, que mostram como os subsistemas compartilham dados, estão distribuídos e como atuam como interface entre si podem ser desenvolvidos. (modelo de repositório, modelo cliente-servidor, modelo de máquina abstrata)

Sistema de controle robotizadode embalagem - Diagrama de blocos

V i si ons ys te m

O b j ec ti de nt if i c a t io n

s ys te m

Armc on tro ll er

G r i pp e rc on tro ll er

P a c ka g in gs el e c ti ons ys te m

P a c ki ngs ys te m

C o nve yo rc on tro ll er

Sistemade Visão

Sistema deidentificação de

objetos

Controlador debraço

Controlador de garra

Sistema deseleção deembalagem

Sistema deembalagem

Controlador detransportadora

O modelo de repositórioSubsistemas precisam trocar informações. Isso pode ser feito de duas maneiras:

Dados compartilhados são mantidos em um banco de dados central, que pode ser acessado por todos os subsistemas.Cada subsistema mantém seu próprio banco de dados e são passados explicitamente para outros subsistemas.

Quando grandes quantidades de dados precisam ser compartilhados, o modelo de repositório é usado para organizar os sistemas.Ex. de sistemas: SIG, CAD, CASE, sistema de comando e controle

Arquitetura de um conjunto de ferramentas CASE integrado

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

Tradutor deprojeto

Editor deprojeto

Gerador de código

Analisadorde projeto

Gerador de relatório

Editor deprograma

Repositóriode projeto

Características de um modelo de repositório

VantagensManeira eficiente de compartilhar grandes quantidades de dadosSubsistemas que produzem dados não precisam se preocupar em como os dados são utilizados. Gerenciamento centralizado de atividades, tais como backup, segurança, etc.O modelo de compartilhamento é visível por meio do esquema do repositório, facilitando a integração de novas ferramentas (desde que compatíveis com o modelo de dados estabelecido).

Características de um modelo de repositório

DesvantagensSubsistemas devem concordar com o modelo de dados de repositório. Inevitavelmente um compromisso.A evolução de dados é difícil e cara.Diferentes subsistemas podem ter diferentes requisitos para políticas de proteção, segurança e backup. O modelo de repositório impõe a mesma política.Dificuldade em distribuir o repositório em uma série de máquinas. Pode ser feito, porém pode haver problemas de redundância e inconsistência de dados.

Arquitetura Cliente-ServidorÉ um modelo de sistema distribuído que mostra como os dados e o processamento são distribuídos em uma série de processadores.Conjunto de servidores stand-alone que oferecem serviços a outros subsistemas, tais como impressão, gerenciamento de arquivos, etc.Conjunto de clientes que solicita esses serviços.Rede que permite os clientes acessar esses serviços.

Biblioteca de filmes e fotografias

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth networkRede de banda larga

Cliente 1 Cliente 2 Cliente 4

Servidor decatálogo

catálogo

Servidor devídeo

Arquivos declipes de filmes

Servidor defotografias

Fotografiasdigitalizadas

Servidor dehipertexto

Web dehipertexto

Características de cliente-Servidor

VantagensÉ uma arquitetura distribuída, permitindo o uso efetivo de sistemas de rede com muitos processadores distribuídos.É fácil incluir um novo servidor e integrá-lo com o restante do sistema ou fazer a atualização do servidor de forma transparente.Normalmente requer hardware mais barato

DesvantagensA falta de um modelo de referência compartilhada para dados pode significar dificuldade em prever problemas na integração de dados.Gerenciamento redundante em cada servidor (backup e recuperação).Não existe um registro central de nomes e serviços - pode ser difícil encontrar quais servidores e serviços estão disponíveis

Modelo de máquina abstrata (Camadas)

Usado para modelar a interface de subsistemasOrganiza o sistema em um conjunto de camadas (ou máquinas abstratas), cada uma das quais fornece um conjunto de serviços para a próxima camada.A abordagem em camadas apóia o desenvolvimento gradativo de sistemas.Também facilita mudanças e apresenta portabilidade. Uma desvantagem é que pode ser difícil estruturar sistemas dessa maneira.

Modelo de máquina abstrata(cont)

Camada externa pode não ser dependente apenas de sua camada imediatamente anteriorDesempenho pode ser comprometido se houver muitas camadas.

Sistema de gerenciamento de versões (modelo de máquina abstrata)

Gerenciamento de Versões

Gerenciamento de objetos

Sistema de banco de dados

SistemaOperacional

Modelos de controleModelos estruturais estão preocupados com a decomposição de sistemas em subsistemas.Os modelos de controle estão preocupados com a dinâmica ( fluxo de controle) entre os subsistemas.Modelos de controle complementam o modelo estrutural.Abordagens principais de controle:

Controle centralizado - Um subsistema tem a responsabilidade geral pelo controle e inicia e interrompe os outros.Controle baseado em eventos - Cada subsistema pode responder a eventos gerados externamente. Esses eventos poder provir de outros subsistemas ou do ambiente do sistema.

Controle centralizadoUm subsistema é o controlador e tem a responsabilidade de gerenciar a execução dos outros subsistemas.Dividem-se em duas classes:

Modelo retorno de chamadasModelo de controle de subrotina top-down onde o controle começa no topo da hierarquia de subrotina e passa para níveis inferiores na árvore. Aplicável a sistemas seqüenciais.

Modelo gerenciadorAplicável a sistemas concorrentes. Um componente do sistema controla o início, a interrupção e a coordenação de outro processos de sistema. Pode ser implementado em sistemas seqüenciais como um comando case.

Modelo de retorno de chamadas

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

ProgramaPrincipal

Rotina 1 Rotina 2 Rotina 3

Rotina 1.1 Rotina 1.2 Rotina 3.1 Rotina 3.2

Modelo de controle centralizadopara sistema de tempo real

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

SensorprocessesProcessosde sensor

Processosde atuador

Controladordo sistema

Interfaces com ousuários

Processoscomputacionais

Manipulador de defeitos

Controle baseado a eventos São dirigidos por eventos gerados externamente A ocorrência do evento está fora do controle do processo que manipula esse evento.Dois modelos de controle principais:

Modelos de transmissão. Um evento é transmitido para todos os subsistemas. Qualquer subsistema que puder manipular esse evento responderá a ele.Modelos dirigidos por interrupções. Usados em sistemas de tempo real, onde interrupções são detectadas por um manipulador de interrupções e passados para algum outro componente para processamento.

Modelo de controle com base em transmissão (broadcasting seletiva)

Sub-system1

Event and messa ge handler

Sub-system2

Sub-system3

Sub-system4

Subsistema 1

Subsistema 2

Subsistema 3

Subsistema 4

Manipulador de eventos e mensagens

Modelo de controle com base em transmissão (broadcasting seletiva)

Eficazes na integração de subsistemas distribuídos em diferentes computadores em rede.Subsistemas registram interesses em eventos específicos. Quando esses ocorrem, o controle é transferido para o subsistema que pode manipular o evento.A política de controle não está incluída no evento e no manipulador de mensagens. Os subsistemas decidem quais eventos interessam a eles.

Modelo orientado a interrupção

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

Interrupções

Vetor deinterrupções

Interrupções

Manipulador1

Processo 1

Processo 2

Processo 3

Processo 4

Manipulador2

Manipulador3

Manipulador4

Modelo orientado a interrupçãoUsado em sistemas de tempo-real onde a resposta rápida a um evento é essencial.Existem um número conhecido de tipos de interrupções, com um manipulador definido para cada tipoCada tipo é associado com a localização de memória do manipulador e um comutador de hardware provoca a transferência de controle para o seu manipulador.Permite resposta rápida, mas a programação é complexa e sua validação é difícil.

Decomposição e ModularidadeProjetar um sistema é determinar um conjunto de componentes e interfaces entre os componentes.Todo método de projeto envolve algum tipo de decomposição: começando de uma descrição de alto nível dos principais elementos do sistema e, depois refinando essa descrição, criando uma descrição mais detalhada dos componentes que compõem a solução.

Decomposição e ModularidadeManeiras de se criar projetos:

Decomposição Modular – a base é a atribuição de funções aos componentes. Parte-se de uma descrição de alto nível das funções que serão implementadas e cria explicações de nível inferior de sobre como cada componente será organizado e relacionado com outros componentes.Decomposição orientada a dados – essa abordagem tem como base as estruturas de dados externas. A descrição de alto nível retrata as estruturas gerais de dados, e as descrições de nível inferior fornecem detalhes sobre quais elementos de dados serão envolvidos e como estarão relacionados.

Decomposição e ModularidadeManeiras de criar projetos:

Decomposição orientada a eventos – nessa abordagem, o projeto tem como base os eventos com os quais o sistema deve lidar e utiliza as informações de sobre como os eventos modificam o estado do sistema. A descrição de alto nível registra os vários estados, e a descrição de nível inferior explicam como ocorrem as transformações de estado.Decomposição orientada a objetos – nessa abordagem são identificadas classes de objetos e o relacionamento entre elas. Em um nível superior, é descrito cada tipo de objeto. Em níveis inferiores, os atributos e as ações dos objetos são discutidos, e o projeto explica como os objetos relacionam entre si para que as funcionalidades do sistema sejam cumpridas.

Decomposição e ModularidadeIndependente da abordagem de projeto, cada tipo de decomposição separa o projeto em suas partes componentes denominadas módulos ou componentes.Sistema Modular:

cada atividade do sistema é realizada por exatamente um componente.As entradas e saídas de cada componente são bem definidas

Decomposição e ModularidadeComponente bem definido:

Todas as suas entradas são essenciais à sua função.Todas as suas saídas são produzidas por suas ações

Modularidade é uma característica de um bom projetoProjeto Modular:

Componentes com entradas e saídas claramente definidasComponentes com propósitos claramente especificados

Modularidade e Níveis de abstração

Na decomposição do projeto, os componentes de um determinado nível aperfeiçoam os componentes do nível acima.Níveis de Abstração: ajudam a entender o problema.Níveis Superiores e mais abstratos ocultam os detalhes dos componentes funcionais e de dados.

Utilizando a abstração Exemplo: reorganizar os elementos de uma lista

1o) Nível de Abtração:

Reorganizar L em ordem decrescente

2o) Nível de Abtração: um algoritmo específico:

Do While I esta entre 1 e (tam de L) -1:

Atribua MENOR ao índice do menor valor em L(I), ... L(tam de L)

Troque L(I) e L(MENOR)

ENDDO

Utilizando a abstração Exemplo: reorganizar os elementos de uma lista

3o) Nível de Abstração: um algoritmo detalhado:

Do While I esta entre 1 e (tam de L) -1:

Atribua MENOR ao valor atual de I

Do While J está entre I+1 e (tamanho de L)-1:

IF L(MENOR) é maior que L(J) ENTÃO Atribua a MENOR o valor de J END IF

END DO

Atribua a TEMP o valor de L(LOW)

Atribua a L(MENOR) o valor de L(I)

Atribua a L(I) o valor de TEMP

END DO

Modularidade e Níveis de abstração

Modularidade -> oculta os detalhes -> componentes ocultam, um dos outros, detalhes internos de processamento.Vantagens:

Decisões de projeto ficam escondidas, facilitando modificações de componentes sem afetar o projeto como um todo.Componentes modulares em diversos níveis de abstração mostram diferentes visões do sistema.Permitem o gerenciamento da complexidade.Capacidade de projetar componentes diferentes de diferentes maneiras. (Uso de OO para interfaces e DTE para projeto de componentes que precisam de segurança).

Características de um Bom Projeto

Um bom projeto de software garante a qualidade de um produto de software.Atributos de qualidade encontrados em projetos de alta qualidade:

Facilidade de entendimentoFacilidade de implementaçãoFacilidade de realização de testesFacilidade de modificações e de tradução corretas das especificações de requisitosCapacidade de se fazer modificações

Atributos que refletem na qualidade do Projeto

Independência dos ComponentesIdentificação e tratamento de exceçõesPrevenção de defeitos e tolerância a defeitos

Independência dos ComponentesAbstração e ocultação de informação permitem examinar como os componentes estão relacionados entre si.É preciso construir projetos de maneira que os componentes sejam independentes entre si:

Facilita o entendimento de seu funcionamentoFacilita as modificações

Para reconhecer e medir o grau de independência dos componentes em um projeto, utiliza-se os dois conceitos:

ACOPLAMENTOCOESÃO

Independência dos Componentes:ACOPLAMENTOACOPLAMENTO

Diz-se que dois componentes tem alto grau de acoplamento quando existe uma grande dependência entre eles.Componentes pouco associados tem alguma dependência, mas suas interconexões são pequenas e controladas.Componentes sem acoplamento não apresentam nenhuma interconexão entre si

Acoplamento de Componentes

Sem Acoplamento -sem dependência

Baixo Acoplamento - Alto grau de Acoplamento -alguma dependência grande dependência

Exemplos de dependência entre componentes

Referências que um componente faz a outro. Ex. o componente A chama o componente B, de modo que o componente A depende de B para completar suas funções;Quantidade de dados que são fornecidos de um componente a outro. Pode-se ter desde um parâmetro, o conteúdo de um vetor ou um bloco de dados.Grau de controle que um componente exerce sobre outro. Ex. A pode fornecer um indicador (flag) de controle para B.

Tipos de Acoplamento

Acoplamento por conteúdo

Acoplamento comum

Acoplamento por controle

Acoplamento por identificação

Acoplamento por dados

ALTO ACOPLAMENTO

ACOPLAMENTO FROUXO

BAIXO ACOPLAMENTO

Acoplamento por conteúdoAcoplamento menos desejávelUm componente modifica um item de dados interno em outro componente.Um componente se ramifica no meio de outro componente. Ex:

B

A

C

D E

Componente B

____________

____________

Ir para D1

____________

Componente D

____________

____________

Ir para D1

____________

D1:

_____________

_____________B se ramifica em D.

Acoplamento comumGlobal:

A1

A2

A3

Variáveis:

V1

V2

Existe quando o projeto está organizado de modo que os dados estejam acessíveis a partir de um repositório de dados comum:

Dificuldade em determinar qual componente é responsável pela definição de uma variável com um determinado valor.

Área de dados comum e nomes das variáveis

Componente X

____________

____________

Mudar V1 para zero

____________

Componente Y

____________

____________

Incrementar V1

____________

Componente Z

____________

____________

V1=V2 + A1

____________

Acoplamento por controleQuando um componente fornece parâmetros (flags) para controlar a atividade de outro componente.É impossível para o componente controlado funcionar sem a orientação do componente que o controla.

Acoplamento por identificação e acoplamento por dados

Acoplamento por identificação:Quando uma estrutura de dados é utilizada para fornecer informações de um componente para outro, e a própria estrutura de dados é fornecida.

Acoplamento por dados:Quando apenas os dados são fornecidos.É o mais desejável, por ser mais simples e com menor possibilidade de erros.

Acoplamento e a Abordagem Orientada a Objeto

O pequeno grau de acoplamento é um benefício automático do paradigma orientado a objeto.Os componentes, em um projeto orientado a objetos, geralmente têm baixo grau de acoplamento:

Definição de componente que é um objeto contém as definições das ações realizadas por ele e nele.

Independência dos Componentes:COESÃO

Não mede interdependência dos componentes, mas refere-se ao elemento de ligação interno com o qual o componente é construído.

Um componente é coeso se todos os seus elementos estiverem relacionados à realização da mesma tarefa e forem essenciais a ela.

Tipos de Coesão

Funcional

Seqüencial

De comunicação

Procedural

Temporal

Lógica

Coincidente

ALTA COESÃO

BAIXA COESÃO

Coesão CoincidenteMais baixo grau de coesão.Encontrado em um componente cujas partes não estão relacionadas entre siAs funções não relacionadas são encontradas no mesmo componente por razões de conveniência ou por acaso.

Ex: Um componente que verifica a classificação de segurança de um usuário e também imprime a lista de pagamento semanal é coincidentemente coeso.

Coesão Coincidente

Função A

Função B Função C

Função D Função E

CoincidentePartes não relacionadas

Coesão LógicaDiversas funções ou elementos de dados relacionados são colocados no mesmo componente.

Ex: Um componente pode ler todos os tipos de entrada (discos e portas de telecomunicações), independentemente de onde se origina a entrada ou de como ela será utilizada. A “entrada” é o elemento de ligação que mantém esse componente junto (não estão relacionados funcionalmente).

Coesão Lógica

Função A

Função A´

Função A´´

LógicaFunções similares

Coesão TemporalQuando um componente é utilizado para iniciar um sistema ou um conjunto de variáveis. O componente realiza diversas funções em seqüência, e as funções estão relacionadas somente pela sincronia envolvida.Componentes coesos de modo temporal e lógico são difíceis de serem modificados.

Coesão Temporal

Hora de

Hora de + X

Hora de +2X

TemporalRelacionada pelo tempo

Coesão ProceduralQuando várias funções devem ser realizadas em uma certa ordem, e são agrupadas em um componente apenas para assegurar essa ordem.

Ex: Os dados devem ser fornecidos antes de serem verificados e manipulados; três funções em uma seqüência específica são implementadas em um mesmo componente.

Coesão Procedural

Função A

Função B

Função C

ProceduralRelacionadas pelaOrdem das funções

Coesão por ComunicaçãoAssociam se certas funções porque elas operam ou produzem o mesmo conjunto de dados.

Ex. Em algumas situações, dados não relacionados são verificado em conjunto, porque a busca pode ser feita com somente um acesso ao disco.

Esse tipo de coesão destrói a modularidade e a independência funcional do projeto.

Coesão por Comunicação

Função A

Função B

Função C

Dados

De comunicação

Coesão SeqüencialA saída de uma parte de um componente é a entrada para a próxima parte. Como o componente ainda não foi construído com base nas relações funcionais, é possível que o componente não restrinja todo o processamento relacionado à função.

Coesão Seqüencial

Função A

Função B

Função C

Seqüencial

Coesão FuncionalTodo elemento de processamento é essencial para a realização de uma única função e todos os elementos essenciais estão contidos em um componente.Componente funcionalmente coeso realiza somente a função para a qual é designado.

Coesão Funcional

Função A – parte 1



FuncionalSeqüencial com funções completas e relacionadas

Coesão Funcional e Abordagens de Projeto Orientada a Dados, Orientada a Objetos e Orientada a eventos

Objetivo Global: reunir os objetos e ações somente quando tiverem um propósito em comum e perceptível.

Ex. Em um projeto OO, um componente é coeso, se todos os atributos, métodos ou ações forem essenciais para o objeto.

Projetos OO geralmente são coesos, pois o processo de composição faz com que as ações sejam colocadas juntamente com os objetos que elas afetam.

Identificação e Tratamento de Exceções

Envolve criar um projeto assumindo uma postura defensivaDifícil -> a especificação de requisitos diz o que o sistema deve fazer, mas não o que o sistema não deve fazer.Alternativa -> identificar as exceções conhecidas -> situações que são contrárias ao que se quer que o sistema faça.Incluir no projeto o tratamento de exceções de modo que o sistema aborde cada exceção de maneira satisfatória, sem afetar as funções do sistema.


Exceções típicas:Falha em fornecer um serviçoFornecer o serviço ou os dados erradosCorromper os dados

Modos de tratar cada exceção:Tentar novamente: re-estabelecer o sistema ao seu estado anterior e tentar novamente realizar o serviço, usando uma estratégia diferente.Corrigir: voltar o sistema ao estado anterior e corrigir alguns aspectos do sistema e tentar realizar novamente o serviço, utilizando a mesma estratégia.Fazer um relatório: re-estabelecer o sistema ao seu estado anterior, relatar o problema para um componente de tratamento de erros e não realizar o serviço.


Técnicas que identificam as exceções à medida que o código está sendo utilizado:

Soma verificadora e verificação de dígitos: verifica a precisão dos dados e dos cálculos.Links redundantes: incluindo ponteiros para frente e para trás.Registradores de tempo.

Prevenção de Defeitos e Tolerância a Defeitos

Objetivo:Fazer com que o código seja tão livre de defeitos quanto possível, criando a prevenção e a resolução de defeitos no projeto.

Os defeitos devem ser antecipados e resolvidos, minimizando possíveis interrupções e maximizando a segurança


Ocorrência de defeitosEngano(erro humano) => defeito em algum produto do software => falha FALHA – quando o sistema se desvia de seu comportamento esperado.

Em um bom projeto, o projetista deve prever o que pode acontecer e construir o sistema a fim de que ele reaja de maneira aceitável.


Detecção de DefeitosDetecção passiva de defeitos: quanto projeta-se um sistema para que ele funcione até que uma falha ocorra durante a execução.Detecção Ativa de defeitos: procura-se identificar “sintomas” de defeitos, ou tenta-se prever quando as falhas ocorrerão. Não se deve esperar até que o processamento seja concluído para se resolver os defeitos.


Estratégias para Detecção ativa de defeitos:

Política de suspeita mútua -> cada componente do sistema assume que os outros componentes contém defeitos e checam suas entradas e saídas.Utilização de redundância (programação com n versões) -> resultados de dois ou mais processos são comparados para determinar se são coincidentes.


Correção de DefeitosÉ a compensação do sistema para a presença do defeito. Geralmente, a correção do defeito soluciona o dano causado por ele, e também modifica o produto, para eliminar o defeito.


Estratégias para lidar com defeitos:Interromper o sistema quando o defeito o afeta (quando ocorre uma falha).Registrar a existência da falha, anotando o estado do sistema no momento em que ocorreu a falha, e retornar posteriormente para corrigir o dano.Exemplo:

Uma chamada telefônica resulta em uma má conexão, a estratégia do sistema poderia ser “derrubar” a linha e esperar que o usuário tente fazer novamente a chamada (Estratégia impensável para um sistema médico ou de aviação)


Tolerância a defeitos:É o isolamento do dano causado por um defeito.O projetista minimiza os danos causados pelo defeito, resultando em uma pequena interrupção para os usuários.Conveniente ou até mesmo desejável em muitas circunstâncias:


Exemplo de projeto tolerante a defeitos:Software que controla diversas esteiras em uma linha de montagem:

Se ocorrer um defeito em uma das esteiras, o sistema pode acionar um sinal e redirecionar os materiais para as outras esteiras.Depois de consertada, a esteira defeituosa poderá ser colocada novamente na linha de produção.

Sistema bancário pode alternar para um processador backup ou fazer duplicatas dos dados e das transações, no caso de um processador falhar.


Estratégias de tolerância a defeitos:Dependem da habilidade de prever a localização de defeitos e do controle de tempo das falhas.Projetistas devem ser capaz de prever o que pode acontecer de errado.Sistemas complexos são difíceis de serem analisados, e tem maior chance de haver defeitos significativos.O próprio código tolerante a defeitos pode conter defeitos.Existem técnicas que procuram isolar as áreas com prováveis defeitos, em vez de prever o defeito real em si.

Pontos-chaveO projeto do sistema começa em um nível de abstração alto, com decisões importantes sobre a arquitetura do sistema.Podem ser desenvolvidos diferentes modelos de arquitetura: modelo estrutural e modelo de controle.Modelos estruturais Modelos estruturais de sistemas incluem modelo de repositório, modelo cliente-servidor e modelo de máquina abstratas.Modelos de controleModelos de controle incluem os modelos centralizados e os modelos baseados em eventos.

Pontos-chaveA decomposição do sistema é um refinamento do modelo estrutural, mostrando os componentes do sistema com mais detalhes.Tal decomposição deve ser executada tendo em mente os requisitos do sistema, os atributos desejáveis para o projeto e a utilização do sistema a longo prazo (como reutilização ou modificação)

Pontos-chaveA medida que se constrói um sistema, é preciso ter em mente as seguintes características:

ModularidadeNíveis de AbstraçãoAcoplamentoCoesãoTolerância a Defeitos eProjeto de interface com o usuário (será vista nas próximas aulas)

Projeto de Arquitetura - dcce. · PDF filecomponentes estruturais da arquitetura do software....

Documents

Transcript of Projeto de Arquitetura - dcce. · PDF filecomponentes estruturais da arquitetura do software....