Projeto de Arquitetura - dcce. · PDF filecomponentes estruturais da arquitetura do software....
Transcript of 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
Slide 2
Projeto de Arquitetura
Estabelece a estrutura global de um sistema de software
Slide 3
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.
Slide 4
TópicosEstruturação de sistemaModelos de controleDecomposição modular
Slide 5
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
Slide 6
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.
Slide 7
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
Slide 9
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.
Slide 10
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.
Slide 11
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.
Slide 12
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.
Slide 13
Modelos de arquiteturaDiferentes modelos de arquitetura pode ser produzidos durante o processo de projeto.Cada modelo representa diferentes perspectivas na arquitetura.
Slide 14
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.
Slide 15
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.
Slide 16
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.
Slide 17
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)
Slide 18
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
Slide 19
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
Slide 20
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
Slide 21
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).
Slide 22
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.
Slide 23
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.
Slide 24
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
Slide 25
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
Slide 26
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.
Slide 27
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.
Slide 28
Sistema de gerenciamento de versões (modelo de máquina abstrata)
Gerenciamento de Versões
Gerenciamento de objetos
Sistema de banco de dados
SistemaOperacional
Slide 29
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.
Slide 30
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.
Slide 31
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
Slide 32
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
Slide 33
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.
Slide 34
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
Slide 35
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.
Slide 36
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
Slide 37
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.
Slide 38
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.
Slide 39
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.
Slide 40
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.
Slide 41
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
Slide 42
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
Slide 43
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.
Slide 44
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
Slide 45
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
Slide 46
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).
Slide 47
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
Slide 48
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
Slide 49
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
Slide 50
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
Slide 51
Acoplamento de Componentes
Sem Acoplamento -sem dependência
Baixo Acoplamento - Alto grau de Acoplamento -alguma dependência grande dependência
Slide 52
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.
Slide 53
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
Slide 54
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.
Slide 55
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
____________
Slide 56
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.
Slide 57
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.
Slide 58
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.
Slide 59
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.
Slide 60
Tipos de Coesão
Funcional
Seqüencial
De comunicação
Procedural
Temporal
Lógica
Coincidente
ALTA COESÃO
BAIXA COESÃO
Slide 61
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.
Slide 62
Coesão Coincidente
Função A
Função B Função C
Função D Função E
CoincidentePartes não relacionadas
Slide 63
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).
Slide 64
Coesão Lógica
Função A
Função A´
Função A´´
LógicaFunções similares
Slide 65
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.
Slide 66
Coesão Temporal
Hora de
Hora de + X
Hora de +2X
TemporalRelacionada pelo tempo
Slide 67
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.
Slide 68
Coesão Procedural
Função A
Função B
Função C
ProceduralRelacionadas pelaOrdem das funções
Slide 69
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.
Slide 70
Coesão por Comunicação
Função A
Função B
Função C
Dados
De comunicação
Slide 71
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.
Slide 72
Coesão Seqüencial
Função A
Função B
Função C
Seqüencial
Slide 73
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.
Slide 74
Coesão Funcional
Função A – parte 1
Função A – parte 2
Função A – parte 3
FuncionalSeqüencial com funções completas e relacionadas
Slide 75
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.
Slide 76
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.
Slide 77
Identificação e Tratamento de Exceções
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.
Slide 78
Identificação e Tratamento de Exceções
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.
Slide 79
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
Slide 80
Prevenção de Defeitos e Tolerância a Defeitos
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.
Slide 81
Prevenção de Defeitos e Tolerância a Defeitos
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.
Slide 82
Prevenção de Defeitos e Tolerância a 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.
Slide 83
Prevenção de Defeitos e Tolerância a Defeitos
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.
Slide 84
Prevenção de Defeitos e Tolerância a Defeitos
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)
Slide 85
Prevenção de Defeitos e Tolerância a Defeitos
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:
Slide 86
Prevenção de Defeitos e Tolerância a Defeitos
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.
Slide 87
Prevenção de Defeitos e Tolerância a Defeitos
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.
Slide 88
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.
Slide 89
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)
Slide 90
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)
Slide 91