Infra-Estrutura de Software Revisão e conceitos Iniciais Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Baseado nos materiais dos professores Luiz Fernando Sirotheau / Senac/DF Alexandre Vasconcelos / UFPE / Qualiti Software Processes 1 Ementa da Disciplina...especificação, implementaçãoe aquisiçãode soluções de software que façam uma efetiva utilização dos recursos tecnológicos visando lidar com a crescente complexidade dos sistemas em contraste com as restrições de orçamento e cronograma. O conhecimento adquirido no curso permitirá ao aluno ter uma visão geral do mercado de software e entenderos componentesenvolvidos no processo de desenvolvimento de sistemas complexos. 2 Relacionamento Relacionamento Engenharia de Software Infra-Estrutura de Software Banco de Dados Engenharia de Software Infra-Estrutura de Software Banco de Dados Se preocupa com o projeto, implementação, instalação e operação de sistemas que incluem hardware, software e pessoas. (Sommerville) é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles. [Kazman] Definições, estruturas e modelos de SGBD s Modelagem de Sistemas Modelos de processo Requisitos Projetos (estruturado/oo) Métricas Riscos de projetos Teste Qualidade Arquitetura Plataforma Categoria Inventário Diagramas UML Modelo conceitual Modelo Lógico e Fisico SQL Tipos de SGBD s 3 3 4 4
Definição: Software Conjunto de instruções (programa de computador) que, quando executadas, produzem a função e desempenho desejados. Inclui documentação sobre operação e uso dos programas. Software é um elemento de sistema lógico, não físico. Software não se desgasta, mas se deteriora. [Pressman] Definição: Sistema Um conjunto de componentes interrelacionados organizados para atingir um certo objetivo. É organizado para executar certo método, procedimento ou controle ao processar informações. Automatiza ou apóia a realização de atividades humanas através do processamento de informações. 5 6 Definição: Engenhariade Sistemas Um conjunto de componentes inter-relacionados organizados para atingir um certo objetivo. É organizado para executar certo método, procedimento ou controle ao processar informações. Automatiza ou apóia a realização de atividades humanas através do processamento de informações. Definição: Definiçãoe representaçãode umaestruturaparaa composiçãode um sistemaemtermosde seus componentescomputacionais, suaspropriedadese interações. [Pressman] A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles. [Kazman] 7 8
Motivação: O Arquiteto de Software O aumento do tamanho e da complexidade dos softwares A estrutura do software é importante, e adotar a estrutura correta pode trazer benefícios Quem faz? O Arquiteto de Software. 9 10 Motivação: Complexidade dos projetos de software Projetos simples Podem ser construído por uma única pessoa Pouca modelagem Processo de construção simples Técnicas simples Ferramentas simples Motivação: Complexidade dos projetos de software Projetos complexos Exigem arquiteturas Trabalho em equipe com especialistas Mais modelagem Processos bem-definidos Técnicas sofisticadas Ferramentas mais poderosas 11 12
Objetivo e Abordagem Objetivo Diminuir a distância entre o projeto e a implementação do software Arquitetura Arquitetura x Projeto Componentes e conectores X Restrições sobre componentes e conectores Projeto Procedimentos e interfaces Algoritmos e estruturas de dados Composição de componentes Composição procedural 13 14 Definição: A (AS) de um sistema define sua estrutura de alto nível, ou seja, denota sua estrutura organizacional como uma coleção de componentes interativos Descrição mais abstrata no ciclo de vida do software Suprime detalhes da implementação Definição: Define apenas os aspectos estruturais importantes Fornece uma base para as outras fases de desenvolvimento do software A arquitetura pode ser descrita usando-se linhas e caixas de diagramas acompanhados por uma descrição textual. (UML!) Separa as funcionalidades das interações 15 16
Definição: Outras definições Arquitetura de software inclui o conjunto de decisões significantessobrea organizaçãode um software: Seleção dos elementos estruturais e suas interfaces Comportamento entre esses elementos Composiçãodesteselementosestruturaise de comportamento em subsistemas maiores Estilo arquitetural que guia esta organização [Booch] Definição: Mais definições... Arquiteturade software é a estruturade um programaouum sistema, seus relacionamentos e os princípios que guiam o seu projeto e a sua evolução no tempo. [Garlan] A descrição da arquitetura de software é um passo intermediário entre a análise de requisitos e o projeto. Esta descrição consiste de elementos arquiteturais, as interações entre esteselementos, e as restriçõessobreesteselementose sobre as suas interações. [Perry] Uma arquitetura de software é um conjunto de componentes genéricosjuntocom umadescriçãode propriedades, regrasde como estes componentes podem interagir, e estilo de interação destes componentes. [Jackson] 17 18 Definição: E aindamais... Umaarquiteturade software deveconter: a definiçãodos elementos de projeto que compõe o software; a descrição das interaçõesentre esteselementos; ospadrõesde composição dos elementos; e um conjunto de restrições sobre estes padrões. [Shaw] Arquitetura de software é a organização incluindo seus componentes, o relacionamentocomponentese com o ambiente e a evolução dos componentes. [IEEE] AS: Importância Facilitador na comunicação entre todas as partes interessadas no desenvolvimento do software Estabelece as decisões iniciais de projeto que terão impacto profundo no resultado final do software Sendoassim, vale a penafazerum modeloqueé relativamentepequeno, intelectualmenteinteligívelde como o sistema é estruturado e como os componentes trabalham em conjunto Essemodeloé transferívelparaoutrosprojetosde software e representam um conjunto de abstrações que permitem descrever a arquitetura de modo previsível. 19 20
AS: Benefícios Reuso de elementos de projeto permitindo maior rapidez na construção do software Definindo-se uma arquitetura é possível predizer algumas características do software Facilita a comunicação entre os desenvolvedores do software Permite um entendimento maior da evolução do software Possibilidade de análise da descrição da arquitetura nas fases iniciais do desenvolvimento Consistência da configuração, componentes e conectores Completude Propriedades não funcionais Conformidade com um determinado estilo arquitetural AS: Elementos e Componentes Elementos essenciais Componentes Conectores Configuração Componentes Denotados por termos como elementos arquiteturais, componentes genéricos, elementos do projeto.. Modela a computação e o armazenamento de informações Desenvolvido independentemente Exemplos de componentes: Cliente, Servidor e até uma aplicação inteira 21 22 Configuração Componente Conector Módulo Exemplos de componentes e formas de interação Chamada de procedimentos Dados compartilhados Objeto Invocação de método Processo Passagem de mensagem Arquivo de dados Acesso de leitura e escrita Banco de dados Consulta SQL 23 24
Quemé? O Arquiteto de Software Arquitetode software é um papelrecentenaindústriade software. Arquiteto de software NÃO é um desenvolvedor sênior!!! Desenvolvedor é especialista e tático. Arquiteto é generalista e estratégico. "O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos." Habilidades O Arquiteto de Software Liderança técnica Hábil negociador Possui conhecimentos de projeto e programação Possui conhecimentos do domínio da aplicação É capazde tomardecisõese conduzirtimes de projetos Tem amplahabilidadeparagerenciarriscostécnicosde projetos Vitruvius, há aproximadamente 25 anos a.c. 25 26 O Arquiteto de Software Principais tarefas Trabalhar em intensa e forte colaboração com a equipe. Apoiar a equipe na investigação dos pontos de relevância técnica de um projeto. Atuarcomoum coach. Identificar os mecanismos arquiteturais relevantes. Motivar a equipe para a investigação e resolução destes mecanismos. Apoiara equipedo inícioaofimdo projeto. O Arquiteto de Software Atividadese produtos(segundoo RUP) 27 28
O Arquiteto de Software Responsabilidades Atacar os principais riscos cedo e continuamente. Garantirqueo produtoentreguetem valorparao cliente. Manter o foco no software executável. Acomodar as mudanças. Estabelecerumaarquitetura executável no iníciodo projeto. Construir o sistema usando componentes. Trabalhar sob os preceitos da qualidade contínua. Promovero balanceamentodas prioridades: Requisitos, riscos, mercado e arquitetura. O Arquiteto de Software Processosde arquitetura(segundoo RUP) 29 30 Variáveis Produtividadeno desenvolvimento(desdea concepçãoà implantação) Agilidade na manutenção Integração com sistemas legados Escalabilidade Redução do custo de produção, treinamento e suporte ao usuário Agilidade e baixo custo na atualização de versões Segurança Arquiteturas monolíticas Processamento centralizado Terminais Burros Redes de comunicação lentas Metodologia de Desenvolvimento Linguagem Cobol Linguagensde 4a geração(natural) Bancos de dados hierárquicos, rede e "relacional" Análise Estruturada Clássica Características das Aplicações Aplicações corporativas batch e on-line Aplicações com interface com o usuário baseada em caracteres. 31 32
Arquiteturas monolíticas Vantagens Facilidade de gerência da segurança Facilidadede gerênciade usuários Facilidadede gerênciade aplicações Facilidade de integração de sistemas Desvantagens Processamento centralizado (escalabilidade vertical) Alto custo (milhões de dólares/ano) Arquiteturas de hardware, software e comunicação totalmente proprietárias levando à dependência do fornecedor Interface com o usuário limitada, baseada em caractere Usuário sem autonomia 33 Arquiteturas distribuídas Servidoresde serviçoscompartilhados(ex. arquivos, impressão) com boa capacidade de processamento Estaçõesde trabalhocom bompoderde processamentocom aplicações locais, interface gráfica Redescom boa velocidade(10, 100, 1000 Mbps) Metodologia de Desenvolvimento Linguagens Clipper, Pascal, Cobol Gerenciamento de arquivos específico das linguagens; Análise Estruturada Características das Aplicações Aplicações departamentais on-line com até dezenas de usuários Aplicaçõesacessam servidoratravés de mapeamento de unidadesde disco ou protocolos proprietários 34 Arquiteturas distribuídas Vantagens Processamento espalhado permitindo o uso de aplicações nas estações Servidores e estações de baixo custo Arquiteturas de software e comunicação proprietárias mas com recursos de integração entre plataformas Interface com o usuário montada localmente e com recursos gráficos Usuário com autonomia total Desvantagens Dificuldade de gerência da segurança Dificuldade de gerência de usuários Dificuldade de gerência de aplicações Dificuldade de integração de sistemas Aplicações são executadas nas estações de forma independente, podendo acessar arquivos no servidor, mas sobrecarregando muito a rede Arquiteturas cliente-servidor Aplicações divididas em dois módulos: o cliente e o servidor Clientee servidorcomunicam-se atravésde protocolosde comunicação proprietários voltados para serviços Metodologia de Desenvolvimento Linguagens Delphi, Visual Basic, Java, etc Servidores de Banco de Dados Relacional Análise Estruturada e Orientada a Objetos Características das Aplicações Aplicações departamentais on-line e com até dezenas de usuários; Aplicações com interface gráfica com o usuário. Aplicaçãoclientesemregrade negócioe servidorde bancode dados com regra de negócio em Stored Procedures. 35 36
Tipos de Arquiteturas cliente-servidor Arquiteturas cliente-servidor Vantagens Maiorperformance, jáquea regrade negócioestáno próprio banco de dados Desvantagens Soluções de Stored Procedures são proprietárias o que amarra a aplicaçãoaobancode dados Perda de escalabilidade horizontal Desenvolvimento em linguagens de programação proprietárias dos bancosde dados, normalmenteproceduraisoude scripts, com baixa reutilização de código Maior dificuldade de implementação 37 38 AplicaçõesMulti-Camadas(Multi-tier) Consiste numa evolução do modelo cliente servidor introduzindo uma ou mais camadas intermediárias de software. Três Camadas Consiste em três camada de software. Camada de Interface Responsável pela interface com o usuário. CamadadeRegrasde Negócio Responsável pela regras de negócio. CamadadeDados Responsável pelo acesso aos dados (normalmente em banco de dados). 2 camadas 39 40
3 camadas 3 camadas MVC Model (Database) View (client) Controller Modelo: representa os dados da aplicação e as regras de negócio. Controlador: define o comportamento da aplicação. Visão: apresenta os dados aos usuários. 41 42 Multi-camadas Multi-camadas Possuias trêscamadasanteriorescom a adiçãode subcamadasna camadade regrade negócio, normalmenteparaa integraçãocom sistemas legados. Desvantagens Maior dificuldade de implementação. Vantagens Grande facilidade de gerência de segurança, de aplicações e de usuários Grande facilidadede integração de sistemas: administração de componentes Independência de banco de dados Grande escalabilidade horizontal através dacriação de clusters de servidores de aplicação Boa performance Maiorflexibilidadeparaa estruturação daarquiteturadaaplicaçãoe paraincorporaro Prof. MSc. Edilberto Silva usode outrastecnologias edilms@yahoo.com http://www.edilms.eti.br 43 44
Multi-camadas Arquiteturas P2P Umatecnologiaquepermitea qualquerdispositivocom acesso a uma rede prover serviços a outros dispositivos da mesma rede. Um peer emumaredep2p age comoum clientee comoum servidor de uma arquitetura cliente/servidor tradicional Compartilhamento de Recursos: Informações Recursos computacionais: Espaço em disco, Processamento, Recursos de rede AlgumasaplicaçõesP2P: mensageminstantânea, compartilhamento de arquivos, computação distribuída 45 46 Arquiteturas P2P Arquitetura Cliente/Servidor Tradicional Responsabilidades do cliente Enviar pedidos de um serviço qualquer Receberas respostasde um pedidofeitoa um serviço Responsabilidades do Servidor Receber pedidos de serviço Processar os pedidos e executar o serviço requerido Enviar a resposta com os resultados do serviço requerido Arquiteturas P2P Responsabilidades do peer, como cliente Enviarpedidosde serviçoa outrospeers Receberas respostasde pedidosde serviçofeitosa outros peers Responsabilidades do peer, como servidor Receber pedidos de serviço de outros peers Processar os pedidos e executar o serviço requerido Enviar a resposta com os resultados do serviço requerido Propagarospedidosde serviçoa outrospeers 47 48
P2P Arquiteturas P2P híbridas Responsabilidades do Cliente Registrar no servidor seus serviços disponíveis Enviar ao servidor pedidos de busca por serviços e receber respostas contendo listas de peers com os serviços desejados Enviar a outros peers pedidos de serviço e receber as respostas desses pedidos Receberde outrospeers pedidosde serviço, processar e executaro serviço requerido e enviar repostas a quem fez o pedido Responsabilidades do servidor Registrar serviços disponíveis nos peers Receber pedidos de busca por serviços disponíveis, buscar por esses serviços e enviar respostas com as localizações dos serviços desejados 49 50 P2Ps híbridas Arquiteturas P2P Algumas razões Eliminaro gargalode fonteúnica, usandoo P2P paradistribuirdados e fazer o balanceamento de pedidosnarede Eliminaro risco de um únicopontode falha A infraestrutura P2P permite acesso direto aos recursos compartilhados, e isso dá capacidade de manutenção remota Elementos Um peer é o nodoemumaredep2p. É a unidadefundamental de qualquer solução P2P. Cadapeer possuium ID único Cadapeer pertencea um oumaisgrupos(peergroups) Cadapeer podese comunicar com outrospeers de seusgrupose também de outros grupos. 51 52
Arquiteturas P2P Elementos Peer Simples (Simple Peer): É designado a servirum únicousuáriofinal, permitindo a esteprovere consumir serviços da rede. Peer Rendezvous Forneceas localizaçõesnaredeparaa descoberta de outrospeers e de seus recursos disponíveis. Peer Router Forneceum mecanismoparaqueospeers se comuniquem atravésde firewalls ou NATs Peer Group Um grupode peers com um conjuntocomumde interesses ou objetivos. Peer groups podem fornecer aos seus membros serviços que não estão diretamente acessíveis aos outros peers da rede. Bibliografias Referências The Rational Unified Process Made Easy: A Practitioner s Guide to the RUP by Per Kroll, Philipe Krutchen, Addison-Wesley. Applied Software Architeture, by Cristine Hoffmeister, Robert Nord, Dilip Soni, Addison-Wesley. SobreRUP e EUP http://www.enterpriseunifiedprocess.com/ http://www-128.ibm.com/developerworks/rational/library Portais de http://www.opengroup.org/ http://www.research.ibm.com/journal/sj/381/youngs.html http://www.booch.com/architecture/index.jsp http://www.sei.cmu.edu/architecture http://microsoft.com/architecture 53 54