Padrões de Arquitetura de Software. Leandro Tonietto Unisinos fev-09

Transcrição

1 Padrões de Arquitetura de Software Leandro Tonietto Unisinos fev-09

2 Introdução Padrões de projeto de software descrevem a criação, estruturação e relacionamento entre classes e objetos, visando, em geral, reuso de código e otimização de recursos de processamento (processador e memória) Padrões de arquitetura de software descrevem padrões recorrentes para arquitetura do sistema. A arquitetura é base na qual o sistema é definido, implica em questões de ambiente e plataforma de execução. Define o ambiente no qual o sistema é executado e também na forma de comunicação com outros sistemas. 25-fev-09 Leandro Tonietto 2

3 Introdução Exemplos de padrão de arquitetura. MVC é um padrão clássico de arquitetura e define uma separação do sistema em Modelo e Visão. Há ainda a parte de controle, que faz a comunicação entre as duas anteriores. MVC busca uma maior independência entre M e V. SOA é um padrão de arquitetura que prevê uma externalização padrão do resultado do processamento, uma forma padrão de comunicação (protocolo) que pode ser compreendido por sistemas externos, inclusive. 25-fev-09 Leandro Tonietto 3

4 MVC 25-fev-09 Leandro Tonietto 4

5 Criado em 1979 por Trygve Reenskaug (Xerox PARC) Model-View-Controller Model: representa o domínio dos dados. É a parte do modelo: dados, regras e lógica de negócios. View: para de apresentação dos dados; interface. Controller: faz a ligação entre a parte de apresentação e a parte de modelo. Recebe requisições ou chamadas da View e notifica a Model para que mude de estado. Por fim, processa retorno para View. Padrão de arquitetura de software O objetivo do padrão é separar as classes que descrevem o modelo e a lógica de negócios das classes que realizam a interface com o usuário, permitindo que ambas evoluam de forma independente. Com esta separação, é possível conceber uma aplicação que se torne independente da sua apresentação. 25-fev-09 Leandro Tonietto 5

6 Estrutura básica: View Controller Model Dados Camada de apresentação (View) faz requisições por dados ou ações sobre os dados do modelo. O Controller recebe as requisições e repassa para o objeto apropriado da camada de modelo (Model) para atendê-la. Modelo faz as operações sobre os dados e retorna algum tipo de informação ao Controller, que por sua vez devolve informações para exibição na camada de exibição. View faz acesso indireto à Model para apresentação das informações. 25-fev-09 Leandro Tonietto 6

7 Exemplo: Jogo de xadrez on-line (e off-line também!). Imagine que os jogadores podem efetuar jogadas tanto executando um aplicativo com interface gráfica em um computador desktop, quando via website do jogo ou até via celular, utilizando neste caso, uma versão limitada da interface da aplicação. A jogabilidade deve ser executa da mesma forma para cada uma das interfaces possíveis. Neste sentido, um servidor de aplicação (no caso um servidor de xadrez) é quem processa a jogabilidade. Inclusive, o servidor processa outras informações relevantes para manter o serviço em funcionamento, como: persistência de informações, cadastro de usuários, administração do site, gerenciamento de campeonatos e etc. O lado servidor não deve tratar das questões de interação com o usuário (I/O), ele é independente de interface. Ainda, conforme o tipo de requisição ou chamada para execução de ações do jogo, há a necessidade de tratamento dos parâmetros informados pela interface e a chamada correta aos respectivos objetos do modelo. Por exemplo, se a interface solicitou uma jogada, o serviço atende esta requisição e repassa ao motor do jogo. Ou, caso seja feita uma requisição de um novo cadastro, é invocado o objeto de cadastro de usuário em BD, recebendo os parâmetros necessários para completar a ação. Por fim, como conseqüência da separação das camadas, tem-se a vantagem de poder suportar novas interfaces, sem a necessidade de modificação da camada de modelo. Por exemplo, o jogo poderia suportar jogadas via SMS. 25-fev-09 Leandro Tonietto 7

8 Exemplo: Este tipo de aplicação deveria utilizar o padrão MVC para sua arquitetura: Camada de interface é implementada de acordo com a sua lógica de interação: em HTML dinâmico (ou ASP), ou com bibliotecas de interface gráfica ou com API gráfica específica para plataformas móveis. A camada Controller recebe diferentes requisições, faz o tratamento dos parâmetros de execução e encaminha a execução para a parte do modelo. Modelo possui as classes necessárias para o jogo funcionar de acordo com as regras de xadrez e para mantenção do serviço (cadastro, envio de , administração do site e etc.) Por fim, sempre que o modelo computa algum requisição, ele devolve um resultado para o controller. O controller então, repassa o resultado para a camada de interface fazer a apresentação das informações processadas. 25-fev-09 Leandro Tonietto 8

9 Exemplo: Celular Aplicativo gráfico Website do jogo update(move) throws InvalidMove{ if(canmoveto(move)){ updateboard(move); return SUCCESS; } return INVALID(move, error); } ChessController ChessEngine CadastroUsuario AdministracaoSite <html> <form action= ChessController > <input name= move /> <input type= submit /> </form> </html> processrequest(request){ command = getcommand(request)... if(command == play ){ move = getparam(request, move ); result = engine.update(move); if(result == SUCCESS){ send(response, success ); } else { send(response, geterror(result)); } }... } 25-fev-09 Leandro Tonietto 9

10 Exemplo: View Website Model ChessBoard object Graphic application ChessController // process request Move move = new Move(); move.setfrom(get( from )); move.setto(get( to ));... sendresponse(boardstate); DB files users, matches, ranking, fev-09 Leandro Tonietto 10

11 Considerações finais sobre MVC: Pode ser aplicado a qualquer aplicação. Grande vantagem é manter a independência das camadas, de tal forma que é possível surgirem novas formas de apresentação para os dados, sem a necessidade de alteração do modelo. A camada modelo tem a preocupação única e exclusiva de processar os dados e não de se preocupar com a forma como vieram. Camada controller deve entregar parâmetros prontos (já no padrão de recebimento por parte do modelo). Assim como, formatar uma saída padronizada para as interfaces. 25-fev-09 Leandro Tonietto 11

12 Bibliografia [1] GAMMA, Eric; Helm, Richard; Johnson, Ralph and Vlissides, John, Design Patterns. Elements of Reusable Software. Addison- Wesley, Reading, MA, [2] GRAND, Mark. Overview of Design Patterns. _synopses.htm [3] KERIEVSKY, Joshua. A Learning Guide To Design Patterns. Industrial Logic, Inc. Feb, ng.html 25-fev-09 Leandro Tonietto 12