UAB Universidade Federal do ABC Especializao em Tecnologia e Sistemas de Informao Disciplina: Projeto de Sistemas Professor Responsvel: Raphael Y.

. de Camargo (CMCC/UFABC)

Aula 2 Atividade 2 Projeto Arquitetural de um Sistema

1. Introduo
Sistemas computacionais so frequentemente divididos em subsistemas, tanto para facilitar sua implementao quanto a sua posterior manuteno. A determinao de como um sistema deve ser organizado denominado arquitetura do sistema. Em processos de software, o projeto da arquitetura do sistema vem logo aps a engenharia de requisitos. A arquitetura do sistema est diretamente relacionada a seus requisitos no-funcionais, como o desempenho, a segurana, a disponibilidade e a facilidade de manuteno. Deste modo, ela essencial para que o sistema consiga atender a seus requisitos.

2. Organizao do Sistema
Ao desenvolver um sistema, necessrio decidir como este ser estruturado, para ento dividi-lo em subsistemas. Chamamos de organizao do sistema a estratgia utilizada para estruturar o sistema como um todo. Nesta aula, veremos 3 organizaes frequentemente utilizadas em sistemas computacionais, o modelo de repositrio central, o modelo clienteservidor e o modelo de camadas.

2.1 Modelo de Repositrio Central Quando um sistema computacional dividido em mdulos, preciso definir uma maneira para que estes sistemas se comuniquem e compartilhem dados. Uma estratgia de organizao frequentemente utilizada devido sua simplicidade o uso de um repositrio central, como um banco de dados. Este modelo funciona bem quando os dados so gerados por um ou mais mdulos e utilizados por outros mdulos do sistema.

Exemplo: Na nossa loja virtual de eletrnicos, o banco de dados poderia conter a lista de produtos em estoque, a quantidade, o preo e a descrio. Quando o cliente solicita a visualizao do produto, o subsistema que trata desta parte obtm as informaes do produto no banco de dados, j verificando o seu preo e disponibilidade de entrega. Se o cliente resolve comprar o produto, o subsistema de compras subtrai uma unidade no banco de dados. Do mesmo modo, quando mais unidades do produto chegam no controle de estoque, o subsistema de estoque pode atualizar a quantidade disponvel de cada item.

Vantagens: Como vimos no exemplo acima, com um repositrio central (1) muito fcil compartilhar dados entre os subsistemas e, por este motivo, bastante utilizado em sistemas reais. Outra vantagem importante que (2) as atividades de backup e segurana so simplificadas, pois os dados se encontram centralizados em um nico banco de dados. Desvantagens: Mas para que o compartilhamento seja possvel, (1) todos os subsistemas devem compartilhar a mesma organizao dos dados, de modo que uma organizao que seja eficiente para um subsistema pode ser bastante ineficiente para o outro. Alm disso, (2) o repositrio pode ser um gargalo no desempenho do sistema, especialmente quando mltiplos subsistemas tentam acessar um mesmo conjunto de dados. No caso do banco de dados ser distribudo em mltiplos computadores, o controle de consistncia dos dados ainda mais difcil.

2.2 Modelo Cliente-Servidor Neste modelo, o sistema organizado como um conjunto de servidores que oferecem servios ao sistema, como gerenciamento de arquivos, acesso a dados, envio de mensagens, servios web, e outros. Estes servios so acessados por clientes, que fazem a requisio atravs de uma rede de comunicao. Tanto os clientes quanto os servidores so subsistemas do software e no precisam necessariamente estar em mquinas separadas.

Os clientes precisam ter acesso ao endereo do cliente. Duas alternativas frequentemente utilizadas fornecer esta informao antecipadamente ao cliente ou fornecer um servio de catlogo de endereos, onde os clientes podem obter o endereo de um servidor atravs de seu nome. claro que neste caso os clientes precisam saber o endereo do servidor que implementa o catlogo de endereos. Mas neste caso, basta um endereo. Exemplo: Na nossa loja virtual de eletrnicos, poderamos ter vrios servidores, contendo os servios para (1) disponibilizar as informaes para os clientes em forma de uma pgina web, (2) controle de estoque, (3) controle de vendas aos clientes, (4) controle de informaes sobre os produtos, e outros servios. O computador do comprador seria a mquina cliente, que solicitaria as informaes ao servidor (1). Note que o servidor (1) por sua vez ter que solicitar informaes tambm aos servidores (2) e (4) para obter as informaes dos produtos e sua disponibilidade em estoque. A vantagem de usar o modelo cliente servidor que fcil de implement-lo como uma arquitetura distribuda, onde as funcionalidades de acesso ao sistema esto localizadas em mquinas distintas de onde as requisies so processadas. Alm disso, simples adicionar um novo servio, pois basta conectar um novo servidor e modificar os clientes para que comecem a utiliz-lo. A desvantagem est na maior dificuldade de compartilhamento de dados, que deve ser feita explicitamente por troca de mensagens entre os servidores ou entre clientes e servidores. Neste caso, preciso determinar um protocolo comum de comunicao, que especifica em que formato as informaes devem ser transmitidas.

2.3 Modelo de Camadas Neste modelo, os subsistemas so organizados em camadas, onde cada camada um subsistema que fornece servios para as camadas superiores. A idia que quanto mais superior for o nvel de uma camada, maior ser o nvel de abstrao dos servios fornecidos.

Exemplo: Esta organizao muito utilizada em sistemas operacionais, onde no nvel mais baixo fica o hardware, seguido pela camada do ncleo do sistema operacional, que quem realiza a comunicao com o hardware. Na camada seguinte, so oferecidos servios bsicos, como o de envio de mensagens pela rede, gerenciamento de arquivos, escalonamento de processos e outros. Na terceira camada ficam as bibliotecas de sistema, que possuem funes de mais alto nvel que aquelas fornecidas pela camada anterior. Finalmente, na quarta camada, ficam as aplicaes, que utilizam as bibliotecas da camada inferior para interagir com o sistema operacional. Uma vantagem desta abordagem que os sistemas desenvolvidos so facilmente portveis. No caso do sistema operacional, caso o desenvolvedor deseja portar o sistema para uma nova arquitetura, bastaria alterar a camada do ncleo. Alm disso, novas funcionalidades podem ser adicionadas ao sistema simplesmente estendendo alguma das camadas. Finalmente, modificaes no sistema so possveis, bastando alterar a implementao da camada sem alterar sua interface. A desvantagem que nem sempre possvel dividir um sistema em subsistemas organizados em uma rgida distribuio de camadas, especialmente quando pensamos em sistemas que utilizam mltiplos computadores. Outro problema pode ser o desempenho, pois as requisies precisam passar por mltiplas camadas antes de chegar ao hardware.

3. Modelos de Controle
Aps organizar o sistema que ser desenvolvido em subsistemas, preciso determinar como estes subsistemas so controlados. As duas maneiras principais de controle so: (1) controle centralizado, onde um subsistema fica responsvel por controlar o funcionamento dos demais subsistemas e (2) baseado em eventos, onde cada subsistema realiza suas operaes em respostas a eventos provindos do ambiente ou de outros subsistemas.

3.1 Controle Centralizado Neste modelo, um subsistema fica responsvel por controlar o funcionamento dos demais subsistemas. O caso mais simples seria pensarmos em uma nica linha de execuo, onde o subsistema de controle possui um processo, que chama uma funo de em um dos subsistemas chamada. Esta funo realiza algumas operaes internas e em seguida chama outra funo de um segundo subsistema, que por sua vez chama uma terceira funo. Quando esta terceira funo termina sua execuo, o controle volta para a segunda funo e, finalmente, primeira, que pode terminar sua execuo. Exemplo: Um exemplo neste caso seria um sistema que realiza o inventrio de uma empresa. Neste caso, o subsistema de controle sistema chamaria uma funo calculaInventario do subsistema que gerencia as entradas e sadas de itens da loja, que por sua vez chamaria uma funo listaNovosItens para o subsistema de estoque de cada setor da loja. O modelo acima simples de implementar e fcil de entender, mas tem a limitao que apenas uma requisio atendida de cada vez. Uma possibilidade para melhorar o desempenho ter mltiplos processos que executam de modo concorrente, cada um com a sua linha de execuo. No exemplo acima, o controlador central poderia iniciar um processo cada requisio listaNovosItens enviada a cada subsistema de estoque.

3.2 Controle Orientado a Eventos Neste modelo cada subsistema realiza suas operaes sem a necessidade de um controle central, em resposta a eventos provindos do ambiente ou de outros subsistemas. No caso de um editor de textos, o evento pode ser o clique do mouse em um cone. J no caso de um servidor web, o evento pode ser a chegada de uma requisio para que seja devolvida uma pgina web. Exemplo: No caso de nossa loja virtual, o usurio solicita a visualizao de um item clicando em um cone. Isto gera um evento, que faz com que a funo mostraInfo do subsistema de visualizao seja invocada. A mostraInfo, por sua vez, chamaria uma funo obtemEstoque do subsistema de controle de estoque. Este subsistema por sua vez, chamaria uma funo do banco de dados contendo o estoque dos produtos. Enquanto esta requisio est sendo processada, outro usurio pode clicar em outro cone, que gera outro evento que processado em paralelo com o primeiro. Uma abordagem simples enviar os evento gerados a todos os subsistemas (broadcast). Neste caso, cada subsistema verifica se aquele evento relevante e realiza as operaes necessrias. Esta abordagem tem a vantagem de ser simples de implementar. Alm disso, fcil adicionar novos subsistemas a esta arquitetura, dado que os eventos so enviados a todos os subsistemas. A desvantagem est na sobrecarga causada no sistema, tanto de troca de mensagens quanto de processamento. Uma outra abordagem implementar um tratador de eventos que recebe todos os eventos. O tratador mantm uma lista contendo quais subsistemas esto interessados em quais eventos, e reenvia os eventos apenas a estes subsistemas. Isto evita a sobrecarga de cada subsistema ter que processar todos os eventos gerados. De um modo geral, programas interativos so mais facilmente implementados utilizando o controle orientado a eventos, dado que neste caso o que o software deve fazer responder a requisies do usurio. A desvantagem do uso de eventos que os subsistemas no sabem quantos outros subsistemas iro tratar o evento (ou se pelo menos 1 deles iro tratar). Alm disso, preciso tomar cuidado para que no hajam conflitos caso 2 ou mais subsistemas decidam tratar o mesmo evento.