engenharia de software projeto de arquitetura de software mai/2010

Engenharia de Software

Projeto de Arquitetura de Software

Mai/2010

Processos de Software

Atividades de Processo – Ex. Ciclo Tradicional

Definição de Requisitos

Projeto de Sistema e Software

Implementação e Teste de Unidade

Integração e Teste de Sistema

Operação e Manutenção

Projeto e Implementação de SW

Atividades do Projeto -> Produtos do Projeto

Projeto de Arquitetura -> Arquitetura de Sistema

Especificação Abstrata -> Especificação de Software

Projeto de Interface -> Especificação de Interface

Projeto de Componente -> Especificação de Componente

Projeto de Estrutura de Dados -> Especif. de Estrutura de Dados

Projeto de Algoritmo -> Especificação de Algoritmo

Projeto de Arquitetura

Sistemas grandes são sempre decompostos em subsistemas que fornecem algum conjunto de serviços relacionados.

Processo inicial de projeto consiste em identificar os subsistemas e estabelecer um framework para o controle e comunicação de subsistemas.


Vantagens de projetar e documentar explicitamente uma arquitetura de software:

Comunicação de stakeholders – apresentação em alto nível para discussão com diferentes stakeholders

Análise de Sistema – Explicita decisões de arquitetura para atender requisitos não funcionais.

Reuso em larga escala – Arquitetura de sistema é muitas vezes a mesma para sistemas com requisitos similares.


A arquitetura do sistema afeta o desempenho, facilidade de distribuição e manutenção de um sistema.

O estilo e a estrutura específicos escolhidos podem depender dos requisitos não funcionais do sistema: Desempenho Proteção Segurança Disponibilidade Facilidade de Manutenção


Decisões de Projeto de Arquitetura

Organização de Sistema

Estilos de Decomposição Modular

Modelos de Controle

Arquiteturas de Referência


Existe uma arquitetura genérica de aplicação que possa funcionar como um modelo para o sistema que está sendo projetado? (ex. Sistemas do mesmo Domínio de conhecimento)

Como o sistema será distribuído ao longo de vários processadores? (sistemas grandes x sistemas pessoais)

Qual ou quais estilos de arquitetura são apropriados para o sistema? (cliente servidor, em camadas)

Qual será a abordagem fundamental usada para estruturar o sistema?

Como as unidades estruturais do sistema serão decompostas em módulos?

Qual estratégia será usada para controlar as operações das unidades no sistema?

Como a arquitetura do sistema deve ser documentada?


Produto: Documento de Projeto de Arquitetura

Inclui: Representações gráficas do sistema Texto descritivo associado Como o sistema está estruturado em subsistemas Qual abordagem adotada Como cada subsistema está estruturado em módulos

Decisões de Projeto de Arquitetura Modelos podem ser:

Modelo estático de estrutura (mostra os subsistemas desenvolvidos como unidades separadas)

Modelo dinâmico de processo (mostra como o sistema está organizado em tempo de execução)

Modelo de interface (Define os serviços oferecidos por cada subsistema por meio de suas interfaces públicas)

Modelo de relacionamentos (mostra os relacionamentos entre os subsistemas tal como fluxo de dados)

Modelo de distribuição (mostra como os subsistemas podem ser distribuídos entre computadores / regiões)





Modelos de Controle



A organização reflete a estratégia básica usada pra estruturação.

A organização pode refletir-se diretamente na estrutura do subsistema.


Estilos organizacionais normalmente utilizados:

Modelo de Repositório

Modelo Cliente-servidor

Modelo em Camadas


Os subsistemas que constituem um sistema devem trocar informações de modo que possam trabalhar juntos eficientemente.

Duas maneiras: Todos os dados compartilhados são mantidos em um BD que

pode ser acessado por todos os subsistemas.(Repositório)

Cada subsistema mantém seu próprio BD. Os dados são trocados com outros subsistemas por meio da passagem de mensagens entre eles.

Modelo de Repositório Vantagens:

Maneira eficiente de compartilhamento de grandes quantidades de dados. Não há necessidade de transmitir dados explicitamente de um subsistema para outro.

Porém, os subsistemas devem estar de acordo com o modelo de dados do repositório.

Os subsistemas que produzem dados não precisam saber como esses dados são usados por outros subsistemas.

Evolução pode ser difícil, quando um grande volume de informações é gerado de acordo com o modelo de dados atual.

Atividades de back-up, proteção, controle de acesso e recuperação de erros são centralizadas. Responsabilidade do gerenciador do repositório.

Porém, subsistemas diferentes podem ter requisitos diferentes para políticas de proteção, recuperação e backup.

Modelo de compartilhamento é visível por meio do esquema de repositório.

Distribuição difícil do repositório por uma série de máquinas. Problemas de redundância e inconsistência de dados.





Modelo em Camadas

Modelo Client-Servidor

Modelo em que o sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços.

Os principais componentes são: Conjunto de Servidores que oferem serviços: Servidores de

impressão, de gerenciamento de arquivos ...

Conjunto de Clientes que usam os serviços

Rede.

Modelo Client-Servidor

Os clientes precisam saber os nomes dos servidores disponíveis e os serviços que eles fornecem.

Os Servidores não precisam saber a identidade dos clientes ou quantos clientes existem.

Essencialmente, um cliente faz um pedido a um servidor e espera até receber uma resposta.

Vantagem: é uma arquitetura distribuída. É fácil adicionar um novo servidor e integrá-lo ao restante do sistema ou atualizar servidores de maneira transparente sem afetar outras partes do sistema.





Modelo em Camadas

Modelo em Camadas

Também chamada modelo de máquina abstrata.

Organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de serviços Ex. Modelo de referência OSI de protocolos de rede.

Cada camada pode ser imaginada como uma máquina abstrata cuja linguagem de máquina é definida pelos serviços fornecidos pela camada.

Desempenho pode ser prejudicado devido aos vários níveis de interpretação de comandos.





Modelos de Controle


Estilos de decomposição modular

Abordagem a ser usada na decomposição de subsistemas em módulos. Não há uma distinção rígida entre a organização do sistema e a decomposição modular. Podemos utilizar os modelos de organização aqui.


Não há uma clara distinção entre subsistema e módulos, mas é útil vê-los da seguinte forma: Um subsistema é um sistema em si cuja operação não depende

de serviços fornecidos por outros subsistemas. Os subsistemas são compostos de módulos e têm interfaces

que são utilizadas para comunicação com outros subsistemas.

Um módulo é normalmente um componente de sistema que fornece um ou mais serviços para outros módulos. Ele faz uso de serviços fornecidos por outros módulos.


Duas estratégias básicas para decompor um subsistema em módulos:Decomposição orientada a objetos

Pipelining orientado a funções

Decomposição orientada a objetos

Nessa abordagem os módulos são objetos que se comunicam.

Vantagens:

Objetos não fortemente acoplados a implementação pode ser modificada sem afetar outros objetos.

Objetos são representações de entidades do mundo real e assim a estrutura do sistema é rapidamente entendida.

Os objetos podem ser reusados.

Decomposição orientada a objetos

Desvantagens:

Para usar serviços, os objetos devem fazer referência explícita ao nome e à interface de outros objetos.

Se uma mudança de interface for necessária para satisfazer propostas de mudança de sistema o efeito dessa mudança sobre todos os usuários do objeto alterado deve ser avaliado.


Duas estratégias básicas para decompor um subsistema em módulos:Decomposição orientada a objetos



Nessa abordagem as transformações funcionais processam suas entradas e produzem saídas.

Os dados fluem de uma para outra função e são transformados ao moverem-se sequencialmente.

Cada etapa do processamento é implementada como uma transformação.

Os dados de entrada fluem através dessas transformações até serem convertidos em saídas.

As transformações podem ser executadas sequencial ou paralelamente.


Vantagens: Apóia o reuso das transformações.

É intuitiva no sentido de que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e saída.

A evolução do sistema pela adição de novas transofmrções é geralmente direta.

Ela é simples de ser implementada tanto quanto um sistema concorrente ou sequencial.


Desvantagens: Não inclui informação sobre a sequencia de operações. Necessita de um formato comum para transferência de dados

que possa ser reconhecido por todas as transformações. Sistemas interativos são difíceis de escrever usando o modelo

de pipelining por causa da necessidade de uma sequência de dados ser processada. Enquanto a entrada e saída de textos simples podem ser modeladas dessa maneira, interfaces gráficas com o usuário têm formatos e controle de entrada/saída mais complexos, baseados em eventos como cliques com o mouse ou seleções de menu.





Modelos de Controle


Modelos de Controle

Existem dois estilos genéricos de controle usados em sistema de software:

Controle centralizado:

Controle baseado em eventos: Cada subsistema pode responder a eventos gerados externamente.

Controle centralizado

Um subsistema tem responsabilidade geral pelo controle e inicia e pára outros subsistemas

Duas classes: Modelo chamada-retorno: O controle começa no topo da

hierarquia de subrotina e, através de chamadas de subrotinas, passa para os níveis mais baixos na árvore. É aplicável somente a sistemas sequenciais.

Modelo gerenciador: Aplicável a sistemas concorrentes. O gerenciador de sistema controla o início a parada e a coordenação de outros processos do sistema.

Controle centralizado A natureza rígida e restritiva desse modelo é, ao mesmo tempo,

um ponto forte e fraco.

Ponto forte porque é relativamente simples analisar fluxos de controle e testar como o sistema responderá a entradas específicas.

Ponto fraco porque, em operação normal, é difícil lidar com as exceções.

Processo controlador do sistema decide quando os processos devem ser iniciados ou interrompidos dependendo das variáveis de estado do sistema. O controlador geralmente está em loop contínuo.

Controle baseado em eventos

Em modelos de controle centralizados, as decisões de controle são geralmente determinadas pelos valores de algumas variáveis de estado de sistema.

Por outro lado, os modelos orientados a eventos são regidos pelos eventos gerados externamente.

Dois modelos de controle orientados a eventos: Modelos de broadcast Modelos orientados a interrupções

Modelos de Broadcast

Um evento é transmitido a todos os subsistemas. Qualquer subsistema programado para manipular esse evento pode responder a ele (ex. mouse, teclado...)

Os subsistemas registram um interesse em eventos específicos. Quando esses eventos ocorrem, o controle é transferido para o subsistema que pode tratar o evento.

A diferença entre este modelo e o modelo centralizado, é que a política de controle não é incorporada ao tratador de eventos e mensagens. Os subsistemas decidem de quais eventos necessitam e o tratador de eventos e mensagens assegura que esses eventos sejam enviados a eles.


A vantagem dessa abordagem de broadcast é que a evolução é relativamente simples.

Um novo subsistema para tratar classes específicas de eventos pode ser integrado por meio do registro de seus eventos no tratador de eventos.

Qualquer subsistema pode ativar qualquer outro subsistema sem saber seu nome ou sua localização.

Os subsistemas podem ser implementados em máquinas distribuídas. Essa distribuição é transparente a outros subsistemas.


Desvantagem é que não se sabe se ou quando os eventos serão tratados.

Quando um subsistema gera um evento, ele não sabe quais outros subsistemas registraram interesse nesse evento. É bem possível que subsistemas diferentes se registrem para os mesmos eventos.

Modelos orientados a interrupções São usados exclusivamente em sistemas de tempo real

nos quais interrupções externas são detectadas por um tratador de interrupções.

Há uma série de tipos de interrupções conhecidas com um tratador definido para cada tipo.

Cada tipo de interrupção está associado ao local de memória em que o endereço de seu tratador está armazenado.

Quando uma interrupção de determinado tipo é recebida, uma chave de hardware transfere o controle imediatamente para seu tratador.

Esse tratador de interrupções pode, então, iniciar ou parar outros processos em resposta ao evento sinalizado pela interrupção.

Arquitetura de Aplicações

Sistemas de aplicações são criados para atender algumas necessidades de negócios ou organizacionais. Todos os negócios tem muito em comum.

Geralmente os sistemas de mesmo tipo possuem arquiteturas similares.

Modelos genéricos de estrutura podem ser usados como: Ponto de partida para o processo de projeto de arquitetura Como checklist do projeto Como uma maneira de organização do trabalho da equipe de

desenvolvimento Como meio de avaliação de componentes para reuso. Como vocabulário para conversar sobre tipos de aplicações.


Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados

Aplicações de Processamento de Transações

Sistema de Processamento de Eventos

Sistema de Processamento de Linguagens

Sistemas de processamento de dados

Esses sistemas enfocam os dados e, geralmente, os bancos de dados são várias vezes maiores que os sistemas em si.

Os Sistemas de processamento de dados são sistemas de processamento em lotes nos quais os dados são entradas e saídas em lotes de um arquivo ou banco de dados em vez de entradas ou saídas para um terminal de usuário.

Esses sistemas selecionam os dados de registros de entrada e, dependendo do valor dos campos nos registros, tomam algumas ações especificadas no programa.

Sistemas de processamento de dados

A arquitetura dos sistemas de processamento de lotes tem três componentes principais: Entrada: coleta as entradas de uma ou mais fontes Processamento: realiza a computação usando essas entradas Saída: gera saídas a serem escritas novamente no banco de

dados e impressas.

Os sistemas de processamento de dados são orientados a funções, em vez de orientados a objetos.

Os diagramas de fluxo de dados, são uma boa maneira de descrever a arquitetura desses sistemas.

Sistemas de processamento de transações

Os Sistemas de processamento de transações são projetados para processar solicitações de informações por usuários de um banco de dados ou solicitações para atualizar o banco de dados.

Alguns desses sistemas são versões interativas de sistemas de processamento de lotes.

Exemplo de transação: Saque em ATM.

Sistemas de processamento de transações

São geralmente sistemas interativos nos quais os usuários enviam solicitações assíncronas de serviço.

Primeiro, um usuário faz uma solicitação para o sistema. A solicitação é processada por alguma lógica específica

da aplicação. Uma transação é passada para um gerenciador de

transações. O gerenciador de transações em geral é incorporado ao

SGBD. Depois que o gerenciador de transações assegurar que

a transação foi concluída adequadamente, ele sinalizará para a aplicação que o processamento foi finalizado.

Sistemas de processamento de eventos

Os Sistemas de processamento de eventos respondem aos eventos do ambiente ou da interface com o usuário do sistema.

Os Sistemas de tempo real também são sistemas de processamento de eventos, porém os eventos são associados a sensores e atuadores do sistema.

Ex.: Processadores de texto, sistemas de apresentação, jogos, sistemas de tempo real.

Sistemas de processamento de linguagens

Os Sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representação dessa linguagem como saída.

Exemplos: Compiladores, Descrição de dados XML em comandos Sistemas de processamento de linguagem natural que tentam

traduzir uma linguagem em outra.

engenharia de software projeto de arquitetura de software mai/2010

Documents