Baixe o app para aproveitar ainda mais
Prévia do material em texto
- -1 ARQUITETURA DE SOFTWARE CAPÍTULO 2 - QUAIS SÃO AS ABORDAGENS ALTERNATIVAS E DE ARQUITETURA PARA SISTEMAS E APLICATIVOS MÓVEIS?WEB Fernando Skackauskas Dias - -2 Introdução Com o grande avanço da e dos dispositivos móveis nos últimos anos, os cientistas da computação se viramweb diante de grandes desafios. Quais são as abordagens da arquitetura de que foram elaboradas parasoftware contemplar esses novos modelos de sistemas? Como esses sistemas são tratados no processo de projeto, desenvolvimento e implantação? Existem modelos alternativos de arquitetura de ? Estas questões sesoftware tornam relevantes, visto a convergência de novas mídias e aplicativos para e dispositivos móveis. Oweb desenvolvimento de sistemas está cada vez mais atrelado às inovações tecnológicas, surgindo, assim, novas linguagens e novos modelos de arquitetura em um intervalo cada vez menor de tempo. O que temos é uma tendência de se projetar sistemas mais dependentes da e dos dispositivos móveis, a fim de atender aosweb modelos de negócio contemporâneos. Temos visto que diversos serviços que eram oferecidos em plataformas tradicionais estão migrando paulatinamente para ambiente ou para dispositivos móveis. Mais do que isso:web diversos serviços já nascem nestes ambientes. Um exemplo claro são os aplicativos urbanos para transporte de passageiro. Neste capítulo, veremos como a arquitetura de é modelada para aplicações esoftware web dispositivos móveis, analisaremos quais são as avaliações possíveis das alternativas de projetos, descreveremos como é empregada a linguagem de descrição da arquitetura (ADL) e, por fim, como é feita a verificação de conformidade da arquitetura de . Desejamos um excelente estudo.software 2.1 Projeto de arquitetura para aplicações e web dispositivos móveis Desenvolver sistemas para e dispositivos móveis é uma tarefa complexa, pois essas aplicações sempre agemweb integrando diversos e , além de suportarem bancos de dados componentes distribuídos perfis múltiplos de . Quais as características específicas na criação da arquitetura de para ambiente eusuários software web dispositivos móveis? Quais os modelos próprios para arquiteturas alternativas? Quais as alternativas de arquiteturas existentes? A fim de desenvolver uma arquitetura de para ambiente e aplicativossoftware web móveis, é necessário compreender o nível de aplicações subjacentes, tais como os objetos, os comportamentos dos componentes e as regras de negócios, além de ser necessário adotar arquiteturas de flexíveis parasoftware esses domínios. Nesse sentido, abordagens orientadas a reuso, entre outras, fazem parte do projeto de arquitetura e dispositivos móveis. Veremos, a seguir, como são criados projetos para esses ambientes.web 2.1.1 Projeto de arquitetura para aplicações web O desenvolvimento de aplicações para o ambiente tem crescido consideravelmente nos últimos anos com oweb fortalecimento da internet como uma plataforma de comércio de produtos e serviços, tendo como estratégia a e o aumento da . Além disso, houve uma grande evolução naredução de custos abrangência de atuação capacidade de transmissão de dados, máquinas servidoras em e um avanço enorme nacloud computing capacidade de armazenamento dos dados. Portanto, quais são as diferenças na arquitetura de para estesoftware ambiente? Antes de tudo, é importante ressaltarmos a importância da aplicação de arquitetura de nosoftware desenvolvimento dos sistemas de informação. Segundo Sommerville (2011, p. 5), temos dois motivos para tal: 1. Cada vez mais, indivíduos e sociedades dependem dos sistemas de avançados. Temos desoftware ser capazes de produzir sistemas confiáveis econômica e rapidamente. 2. Geralmente é mais barato, a longo prazo, usar métodos e técnicas da engenharia de para sistemas de , em vezsoftware software - -3 a longo prazo, usar métodos e técnicas da engenharia de para sistemas de , em vezsoftware software de simplesmente escrever os programas como se fossem algum projeto pessoal. Para a maioria dos sistemas, a maior parte do custo é mudar o depois que ele começa a ser usado.software A vantagem deste padrão de arquitetura é a permissão de os dados serem alterados de forma independente da sua representação. Uma descrição resumida do comportamento das aplicações que utilizam o padrão MVC é: o componente Visão envia os eventos para o componente Controlador o qual, por sua vez, modifica o estado do componente Modelo e, a seguir, o componente Visão busca as informações do Modelo. Poderemos acompanhar o funcionamento básico do padrão MVC na figura a seguir. Figura 1 - Modelo MVC demonstrando a relação entre o Modelo, a Visão e o Controlador e os eventos associados aos componentes. Fonte: Elaborada pelo autor, baseado em JÚNIOR; FORTES, 2007. Vimos, na figura anterior, que o componente Visão envia um determinado evento para o componente Controlador que, a partir daí, chama um método que alterará o estado do Modelo. A partir do momento em que o Modelo tem o estado alterado, este componente informa à Visão, por meio do Controlador, o novo estado em que ele se encontra. A partir daí, a Visão procura os dados no Modelo. Concluindo, o modelo MVC é formado pelas entidades que agrupam os dados (apresentados pelo componente Visão, que pode ser uma interface gráfica, por exemplo). Por outro lado, o Controlador pode ser classes que têm métodos que permitem que o componente Modelo seja atualizado a partir dos eventos que foram disparados pelas Visões. Na figura a seguir, demonstraremos um exemplo de interação entre os componentes do padrão MVC em uma aplicação Java. Neste esquema, há a apresentação de como os dados são apresentados no componente Visão: os pontos ‘x’ e ‘y’, o nível de opacidade das informações apresentadas, o estilo da fonte e um texto descritivo. Neste caso, um evento será disparado pelo botão , que está na interface gráfica. A partir do momento em que este evento é disparado,change os dados são enviados para o componente Controlador, no qual estão as classes que possuem os métodos que permitem ao componente Modelo ser atualizado a partir dos eventos disparados pelo componente Visão. - -4 Figura 2 - Exemplo de interação entre os componentes do padrão MVC e suas interações de uma aplicação em linguagem Java. Fonte: SUN, 2007 apud JÚNIOR; FORTES, 2007, p. 6. Outro tipo de padrão de arquitetura largamente utilizado é a , com base no modeloarquitetura em 3 camadas cliente-servidor. Ele se caracteriza no fato de que a interface, a lógica do processamento, o armazenamento e o acesso aos dados ficam em e cada um é , independentemente da tecnologiamódulos independentes atualizado utilizada. Segundo Júnior; Fortes (2007, p. 6, grifos nossos), essas camadas se classificam em: • camada de apresentação: contém toda a interface gráfica e permite a interação com o usuário por meio dos serviços disponíveis ao usuário (sessões e entradas de dados, por exemplo); • camada lógica: contém toda a lógica do negócio, bem como a lógica de transações; • camada de dados: contém os dados que são manipulados pela aplicação, bem como o acesso a dados, atualizações e persistências deles. Apresentaremos, a seguir, uma ilustração gráfica da arquitetura em três camadas, na qual ocorre um sistema de vendas, em que a camada de apresentação realiza uma função de “solicitação do total de vendas” e é onde se encontra a interface com o usuário. A partir do momento do disparo desta solicitação, a camada lógica recebe a solicitação e é realizado o processamento da pesquisa solicitada. Por sua vez, os dados para realizar a pesquisa são obtidos a partir da camada de dados, onde é realizada a recuperação dos dados necessários. Esta camada, por sua vez, retorna para a camada lógica o resultado da pesquisa, passando o resultado do “total de vendas” para a interface do usuário (camada de apresentação), que é a pesquisa solicitada inicialmente. • • • - -5 Figura 3 - Exemplo de interação entre os componentes do padrão de arquitetura em 3 camadase suas interações em uma aplicação comercial. Fonte: Elaborada pelo autor, baseado em JÚNIOR; FORTES, 2007. É possível fazermos uma comparação entre os modelos de arquitetura MVC e em 3 camadas: • arquitetura MVC: tem um , sendo que a Visão emite eventos comportamento de forma triangular para o Controlador, que atualiza o Modelo, e a Visão busca os dados do Modelo para exibir; • arquitetura em 3 camadas: tem um , pois as camadas de apresentação não comportamento linear executam a comunicação de forma direta com a camada de dados passando pela camada lógica. 2.1.2 Projeto de arquitetura para dispositivos móveis As arquiteturas de software para dispositivos móveis consistem, fundamentalmente, em uma aplicação que está hospedada em um servidor e que será acessada por meio de um navegador do dispositivo. Baseando-nos nestes princípios, temos duas possibilidades de arquitetura de software para dispositivos móveis: a distribuída e a centralizada, as quais explicaremos a seguir. • Arquitetura distribuída • • • - -6 centralizada, as quais explicaremos a seguir. • Arquitetura distribuída Tem como característica principal as regras de negócio do (que se encontram na camadadesacoplar software de Modelo) das regras relativas de apresentação (camadas de Visão e Controle). Assim, as aplicações para dispositivos móveis são desacopladas das aplicações corporativas, e a comunicação ocorre por meio dos serviços via . O que temos é que as aplicações para dispositivos móveis agregam exclusivamente as regras deweb visualização e controle. No lado das aplicações corporativas, acoplam-se as regras de negócio. Suas vantagens são: • a publicação da aplicação é independente dos serviços remotos; • o desacoplamento entre a aplicação do dispositivo móvel e as regras de negócio; • é possível reusar as diversas funcionalidades de outras aplicações; • é possível adaptá-la às múltiplas plataformas. Por outro lado, suas são:desvantagens • o desenvolvimento das funcionalidades pode ser dispendioso; • o consumo de serviços remotos pode gerar tempos maiores de resposta. • Arquitetura centralizada Tem como principal característica , em uma única aplicação, todas as camadas e regras do sistema. Aenglobar alteração desta arquitetura está na interface, na qual a estrutura de dispositivo móvel serve para adaptar a interface da aplicação para telas menores e sensíveis ao toque, melhorando a usabilidade dos usuários. A camada de Modelo fica responsável somente para acessar serviços externos. Segundo Pilar (2005, p. 26), o desenvolvimento de para dispositivos móveis é mais complexo do que softwares softwares tradicionais. Isto ocorre devido às características como aplicações em tempo real, memória limitada da tecnologia, canais de entrada e saída limitados, necessidade de ferramentas caras de desenvolvimento, tendo uma forte relação com a dependência de e diferenteshardware processadores. Seguindo as características que mencionamos anteriormente, elas mostram os desafios para o desenvolvimento de dispositivo móvel. Lee (2005) apresenta uma arquitetura específica para o desenvolvimento dos aplicativos, que poderemos visualizar na figura a seguir. • • • • • • • • VOCÊ QUER LER? O crescimento em tamanho e a complexidade dos sistemas de exigem que ossoftware profissionais da área desenvolvam novas topologias para o nível arquitetural. Como exemplo, temos os dispositivos móveis, que têm como principal característica realizar várias tarefas distintas e se conectar com outros aplicativos. Quer ler mais? Leia o artigo de Silva Filho (2010) em: < >.http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593 http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593 - -7 Figura 4 - Exemplo de arquitetura para aplicativos móveis com as camadas físicas e lógicas e suas interações. Fonte: Elaborada pelo autor, baseado em LEE, 2005. Os itens da figura anterior são divididos e conceituados da seguinte forma, segundo Lee (2005, p. 27, grifos nossos): • mobilidade: as aplicações móveis deverão seguir esta principal característica dos dispositivos móveis; • contexto do negócio: é necessário identificar o contexto de negócio do aplicativo; • arquiteturas de aplicação móvel: definir os tipos de arquitetura móvel; • infraestrutura móvel: análise que deve ser realizada ao definir o tipo do dispositivo móvel; • interface com o usuário de cliente móvel: considerar a interface e periféricos que podem ser utilizados pelo usuário; • aplicações clientes móveis: onde se deve definir a arquitetura a ser seguida; • transferência de dados cliente-servidor: definir a forma como ocorreram as trocas de informação; • tornar móveis as arquiteturas de aplicação existentes: verificar a necessidade de transformar ou atualizar; • segurança: é necessário o controle de acesso a usuários e a proteção dos dados; • gerenciamento do desenvolvimento de aplicações móveis: segue as mesmas características do gerenciamento de projetos; • estudos de caso de aplicações móveis: é considerado importante realizar estudos de casos. Ao desenvolvermos aplicativos para dispositivos móveis, pode ser necessária a execução de código na camada do cliente que, nessa situação, é adotada uma arquitetura separada em camadas. Segundo Pilar (2013, p. 30, grifos nossos), estas camadas são descritas como: • camada de aplicação: camada que está no topo do desenvolvimento da hierarquia da • • • • • • • • • • • • - -8 • camada de aplicação: camada que está no topo do desenvolvimento da hierarquia da arquitetura; • camada de middleware: é a camada que suporta diferentes linguagens de programação, como a procedural C, orientada a objetos C++ e Java; • camada do sistema operacional: responsável por cooperar com a aplicação para aperfeiçoar o gerenciamento de processos, procedimentos e tratamento de exceções; • camada de abstração do hardware: é a camada mais próxima do , aquela que fazhardware contato diretamente com o dispositivo; • hardware: dispositivos móveis como , celulares, leitores de , vídeosmartphones e-books games etc. Vários questionamentos podem influenciar na escolha de qual arquitetura devemos utilizar para o desenvolvimento dos sistemas de dispositivos móveis ou , como: o sistema deve ser desenvolvido utilizandoweb tecnologia híbrida ou nativa? Existe tempo hábil para desenvolver duas aplicações nativas, a fim de atender Android e iOS? Qual o conhecimento necessário da equipe? Quanto é o custo de desenvolvimento de aplicações nativas e híbridas? Descobriremos as respostas para esses questionamentos no tópico a seguir. 2.2 Avaliação das alternativas do projeto É necessário, antes de mais nada, levantarmos de maneira clara as diferenças de desenvolvimento dos aplicativos móveis: • aplicativo nativo: tem como característica ser desenvolvido para uma plataforma específica, como a iOS ou a Android. Portanto, ele tem a capacidade de explorar todos os recursos da plataforma, como o GPS ou a câmera, mas nem sempre necessita da internet para funcionar. A desvantagem está em seu desenvolvimento, que é mais complexo e mais dispendioso: é necessário desenvolver um aplicativo para cada tipo de plataforma e não pode haver reuso de código, porque cada plataforma necessita de códigos distintos; • aplicativo híbrido: tem características do aplicativo nativo e da , sendo necessário utilizar os dois web códigos para a criação. Portanto, este modelo pode usar recursos tanto da internet quanto do dispositivo, podendo ser executado em plataformas diferentes, e seu desenvolvimento é mais ágil e com custo menor. Sua maior desvantagem é que ele não consegue acessar as funcionalidades diretamente, sendo necessário usar uma infraestrutura que seja intermediária entre o aplicativo e o dispositivo. No próximo item, abordaremos a questão da (linguagem de descrição daarchitecture description language arquitetura – ADL) que descreve, de forma fundamental, a estrutura das propriedades em alto nível de um sistema –mas sem se atrelar a detalhes de implantação. • • • • • • • VOCÊ SABIA? Existem arquiteturas de específicas para a construção e integração de ambientessoftware virtuais de aprendizagem. O artigo “Potencial da aprendizagem baseada-em-jogos: um caso de estudo na Universidade do Algarve”, de Kikot; Fernandes; Costa (2015), pesquisa a interação de estudantes com um jogo em um ambiente digital. Saiba mais em: <http://www.scielo.mec.pt >./pdf/rist/n16/n16a03.pdf http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf - -9 2.2.1 Linguagem de descrição da arquitetura (ADL) A ADL tem como objetivo representar a arquitetura de um , em que os componentes são definidos, bemsoftware como seu comportamento, seus padrões e seus mecanismos para interação entre eles. Assim, ela modela a arquitetura conceitual de um sistema, sendo que seus elementos básicos são os componentes e os conectores, que incluem regras e diretrizes para arquiteturas. Essa modelagem é necessária, do contrário a descrição da arquitetura se torna uma coleção de elementos e, se não houver uma semântica explícita, não será compreendida a sua utilidade. Shaw e Garlan (1994) apresentam que uma ADL ideal deve fornecer:seis propriedades composição, abstração, reuso, configuração, heterogeneidade e análise. No entanto, devido à sua natureza especializada, autores como Sommerville (2011) consideram que a ADL seja difícil de entender e usar, o que torna complicado avaliar sua utilidade prática na engenharia de .software Sommerville (2011, p. 108) declara que [As ADLs] podem ser usadas como base para o desenvolvimento dirigido a modelos. No entanto, acredito que os modelos e as notações informais, como a UML [ , ou seja, aunified modeling language linguagem de modelagem unificada], continuarão a ser a forma mais comumente usada para documentar arquiteturas de sistema. Portanto, para atender à necessidade de usar a ADL, foram criadas linguagens como: • ADAGE: permite a criação de para sistemas de aviação;frameworks • CE: possibilita a descrição de sistemas de interface com o usuário usando um estilo baseado em mensagens; • Rapide: admite a simulação e a análise de diferentes soluções arquiteturais; • UniCOn: possui um compilador de alto nível com suporte para diferentes tipos de componentes e VOCÊ O CONHECE? Vannevar Bush foi professor do Instituto de Tecnologia de Massachusetts (MIT) na década de 1920 e um dos responsáveis pela criação dos primeiros modelos de formulação matemática para problemas em teoria dos circuitos, dando uma base fundamental para a criação dos primeiros modelos de computadores. Leia mais em Fonseca Filho (2007). VOCÊ QUER VER? O filme (NEWMAN et al., 2000) é bastante interessante para compreender comoCaçada virtual atuam os chamados os éticos ( ). Este longa-metragem mostra a históriahackers ethical hacking real de Kevin Mitnick, que utilizou todo o seu conhecimento em computação para entrar no sistema do FBI e acessar documentos altamente sigilosos, tornando-se o criminoso mais procurado dos Estados Unidos na época. • • • • - -10 • UniCOn: possui um compilador de alto nível com suporte para diferentes tipos de componentes e conectores. 2.3 Verificação de conformidade da arquitetura Após a explanação das arquiteturas específicas para ambiente e dispositivos móveis, podemos questionar:web como é possível verificar a conformidade de uma arquitetura de ? Segundo Chagas (2016), essasoftware verificação é importante para o entendimento do código, o reuso e a manutenibilidade do sistema, podendo ser feita de algumas maneiras: • manualmente; • por meio de , como a Matriz de Dependência Estrutural (DSM), modelos de técnicas e ferramentas reflexão ou testes de .design Porém, segundo Chagas (2016), nenhuma delas leva em consideração os diferentes níveis de abstração para definir regras arquiteturais. Uma das maneiras de se realizar a conformidade arquitetural é comparando o código-fonte à visão arquitetural do sistema ( ) ou então verificando o código-fonte em tempo deforma estática execução ou suas versões ao longo do tempo, comparando-as com a visão arquitetural ( ). Aforma dinâmica verificação de conformidade da arquitetura avalia as dependências entre os componentes. Os resultados da arquitetura, de acordo com Chagas (2016, p. 21, grifos do autor), podem ser divididos em: convergência - é uma relação entre dois componentes que é permitida e foi implementada como pretendida. A convergência indica que a implementação é compatível com a arquitetura planejada; - é uma relação entre dois componentes que não é permitida e não foi implementadadivergência como pretendida. A divergência aponta que a implementação não é compatível com o modelo arquitetural planejado; - é uma relação entre dois componentes que era pretendida, porémausência não foi implementada. A ausência indica que as relações na arquitetura planejada não foram encontradas na implementação. Conforme descrito por Chagas (2016), alguns autores apresentam os modelos de reflexão. Inicialmente, esta técnica tem como propósito ajudar o engenheiro a utilizar um modelo de alto nível de um sistema existente, o qual foi aplicado nos casos em que havia pouca ou nenhuma informação sobre o sistema e a sua arquitetura. Outras regras de verificação de conformidade são as entre elementos arquiteturais as quais, pararestrições Chagas (2016, p. 23), “[...] se dividem em permitir, proibir ou impor alguma relação entre as entidades arquiteturais”. Fundamentalmente, uma regra de relação de conformidade é integrada por um tipo de relação, um componente de origem, um de destino e o tipo da regra de conformidade. Por outro lado, o tipo de regra de • • • VOCÊ QUER LER? A arquitetura orientada a serviço (SOA) é considerada complexa pelos pesquisadores e pela Academia sobre os meios para sua construção. O artigo publicado por Serman (2010) visa trazer o gerenciamento de portfólio de projetos de como uma opção para orientar osoftware desenvolvimento da SOA. Quer ler mais? Acesse: <http://www.scielo.br/pdf/jistm/v7n3/07. >.pdf http://www.scielo.br/pdf/jistm/v7n3/07.pdf http://www.scielo.br/pdf/jistm/v7n3/07.pdf - -11 um componente de origem, um de destino e o tipo da regra de conformidade. Por outro lado, o tipo de regra de conformidade determina se a relação entre os componentes é proibida ou se deve, obrigatoriamente, existir entre os componentes. 2.4 Projeto de componentes Após a aplicação da orientação a objetos no desenvolvimento de sistemas, houve pouco reuso do código. Definimos, portanto, que os componentes são de nível mais alto do que objetos e são definidos porabstrações suas . Geralmente, eles são que objetos individuais e todos os detalhes de implementação sãointerfaces maiores escondidos de outros componentes, conforme citado por Sommerville (2011, p. 315): a engenharia de baseada em componentes (CBSE, do inglês software component-based software ) surgiu na década de 1990 como uma abordagem para de desenvolvimento deengineering softwares sistemas com base no reuso de componentes de .softwares Utilizamos o termo componente, portanto, para nos referir a , como funções, estruturastrechos do código-fonte de dados e classes. Existem outras definições para eles, como de um programa que podeminstâncias de classes ser utilizadas por outras instâncias. Além disso, podemos denominá-los como sendo as de funções ebibliotecas bibliotecas de ligação dinâmica. Sommerville (2011, p. 316) enumera que os fundamentos da engenharia de baseada em componentes são: 1. Os componentessoftware independentes que são completamente especificados por suas interfaces. [...] 2. Os padrões de componentes que facilitam a integração destes. [...] 3. O que fornece suporte de middleware software para a integração de componentes. [...] 4. Um processo de desenvolvimento que é voltado para a engenharia de baseada em componentes. [...]software Portanto, quando desenvolvemos sistemas baseados em componentes, apropriamosas boas práticas da engenharia de . Essa engenharia baseada em componentes, conforme demonstrado por Sommervillesoftware (2011, p. 316), apoia-se em um dos princípios de projeto na construção de compreensíveis e passíveissoftwares de manutenção: 1. Componentes são independentes, então eles não interferem na operação uns dos outros. Detalhes de implementação são ocultados. Implementação dos componentes pode ser alterada sem afetar o restante do sistema. 2. Os componentes comunicam-se por meio de interfaces bem definidas. Se essas interfaces forem mantidas, um componente poderá ser substituído por outro, que forneça funcionalidade adicional ou aumentada. 3. As infraestruturas dos componentes oferecem uma gama de serviços-padrão que podem ser usados em sistemas de aplicações, o que reduz a quantidade de códigos novos a serem desenvolvidos. Segundo Sommerville (2011), o existe para o sistema operacional e para outras ferramentas componente físico do sistema, sendo que ele pode ser armazenado ou transferido. Por outro lado, o possuicomponente lógico uma utilidade para o funcionamento do programa. O é utilizadocomponente de tempo-de-desenvolvimento durante o desenvolvimento do , enquanto o é quando está prontosoftware componente de tempo-de-execução para ser executado pelo sistema. Para Sommerville (2011, p. 317), os componentes têm as seguintes características: - -12 Quadro 1 - Relação dos componentes e as descrições relativas às suas características. Fonte: SOMMERVILLE, 2011, p. 317. Portanto, existem diversas formas de compreendermos o que é um componente. Uma delas é como se ele fosse um provedor de serviços. Quer dizer, quando um sistema precisa de um serviço, é chamado um componente para que seja ofertado o serviço. Não é necessário preocupar onde ele está sendo executado ou em que linguagem foi desenvolvido. - -13 Segundo Sommerville (2011, p. 318), a percepção do componente como um provedor de serviços agrega duas características essenciais de um componente: 1. O componente é uma entidade executável independente que é definida por suas interfaces. Para usá-lo, você não precisa de nenhum conhecimento de seu código-fonte. Ele pode ser referenciado como um serviço externo ou incluído diretamente em um programa. 2. Os serviços oferecidos por um componente são disponibilizados por meio de uma interface, e todas as interações se dão por meio dessa interface. A interface de componente é expressa em termos de operações parametrizadas e seu estado interno nunca é exposto. Assim, o componente tem duas , e elas mostram o serviço que o componente interfaces que se relacionam fornece e os serviços que ele necessita. Segundo Sommerville (2011, p. 318), “a interface ‘ ’ define osprovides serviços prestados pelo componente. Essa interface, essencialmente, é API de componente. Ela define os métodos que podem ser chamados por um usuário do componente [...]”. Em um diagrama de componentes UML (sigla para , isto é, a linguagem de modelagem unificada), a paraunified modeling language interface ‘ ’ provides um componente é indicada por um a partir do ícone de componente. Na figura acírculo no fim de uma linha seguir, demonstramos um modelo genérico de um componente e as interfaces ‘ ’ e ‘ ’.requires provides Figura 5 - Exemplo da representação gráfica das interfaces ‘require’ e ‘provides’ com um componente e suas descrições. Fonte: SOMMERVILLE, 2011, p. 318. Por outro lado, Sommerville (2011, p. 318) nos diz que “a interface ‘ ’ especifica quais serviços devem serrequires CASO Uma universidade de grande porte estava reorganizando o seu portal , que já seweb encontrava em um formato obsoleto. Foram propostas duas metodologias diferentes a serem aplicadas: uma de centrada no usuário e outra de participativo. Este tipo dedesign design abordagem impactaria no modelo de arquitetura de implantação do novo portal. O objetivo era propor uma metodologia para a reestruturação, priorizando a organização e facilidade de uso do . A primeira etapa foi a realização de uma entrevista com os usuários para obter assite necessidades fundamentais. O problema é se seria adotada a metodologia orientada no perfil do usuário ou na tarefa. A metodologia orientada ao perfil do usuário leva a uma arquitetura a um modelo no qual o foco está centrado na interface. Por outro lado, uma metodologia orientada na tarefa faz com que a arquitetura esteja mais centrada no modelo cliente-servidor. - -14 Por outro lado, Sommerville (2011, p. 318) nos diz que “a interface ‘ ’ especifica quais serviços devem serrequires fornecidos por outros componentes no sistema se um componente deve funcionar corretamente. Se eles não estiverem disponíveis, o componente não funcionará. [...]”. Isso não compromete a independência ou a capacidade de implantação de um componente, pois a interface ‘ ’ não define como esses serviçosrequires deverão ser prestados. Em UML, o símbolo de uma é um ,interface ‘ ’requires semicírculo no fim de uma linha a partir do ícone de componente. Na figura a seguir, demonstraremos as interfaces ‘ ’ e ‘ ’ de um componente coletor de dados,requires provides projetado para coletar e reunir informações a partir de um vetor de sensores. Figura 6 - Exemplo da representação gráfica do modelo de um componente coletor de dados. Fonte: SOMMERVILLE, 2011, p. 319. Para Sommerville (2011, p. 318), ele é executado autonomamente para coletar dados durante um período e, sob requisição, fornece dados agrupados para um componente. A interface ‘ ’ inclui métodos para adicionar,requires remover, iniciar, parar e testar sensores. O método retorna os dados do sensor que foramreport coletados e o método fornece informações sobre os sensores conectados.listAll Sommerville (2011) ainda nos informa que existe o serviço externo e um componente como elemento de programa, mas eles são diferentes: o primeiro é uma entidade independente, já o último pode usar esses serviços sem a necessidade de se implementar nenhum suporte adicional exigido por eles. - -15 Um modelo de componente significa uma para a sua implementação, implantação edefinição de normas documentação. Estas normas servem para garantir aos desenvolvedores que os componentes podem interoperar. Para Sommerville (2011, p. 319, grifos nossos), as informações que são necessárias para se utilizar um componentes são: 1. . Os componentes são definidos pela especificação de suas interfaces. O modelo deInterfaces componente especifica como as interfaces devem ser definidas e os elementos, como nomes de operação, parâmetros e exceções, que devem ser incluídos na definição de interface. O modelo também deve especificar a linguagem usada para definir as interfaces de componente. [...] 2. .Uso Para que componentes sejam distribuídos e acessados remotamente, eles precisam ter um nome exclusivo ou identificador associado a eles. Isso deve ser globalmente exclusivo — por exemplo, no EJB, um nome hierárquico é gerado com a raiz baseada em um nome de domínio de internet. [...] 3. . O modelo de componente inclui uma especificação de como componentes devem serImplantação empacotados para implantação como entidades independentes, executáveis. Como os componentes são entidades independentes, eles precisam ser empacotados com todos os de suporte nãosoftwares fornecidos pela infraestrutura de componente ou não serão definidos em uma interface ‘ ’.requires [...] Sommerville (2011) elenca os elementos básicos de um modelo ideal de componentes, conforme demonstraremos na figura a seguir. VOCÊ SABIA? Existe uma proposta de arquitetura de baseada em para osoftware data warehouse desenvolvimento de sistemas distribuídos, auxiliando os desenvolvedores na utilização de arquiteturas alternativas para sistemas específicos. Leia mais no artigo escrito por Milanez; Tait (2012), disponível em: <http://www.periodicosibepes.org.br/index.php/reinfo/article >./view/728 http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728 http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728- -16 Figura 7 - Elementos básicos de um modelo de componentes, demonstrando suas relações e definições. Fonte: SOMMERVILLE, 2011, p. 319. Por outro lado, para componentes implantados como unidades de programa, no lugar de serviços externos, o modelo de componentes define os serviços que são fornecidos pelo . Este, por sua vez, oferecemiddleware suporte para a execução dos componentes, sendo “o que se encontra entre o sistema operacional e ossoftware aplicativos nele executados” (MICROSOFT AZURE, 2018). Segundo Sommerville (2011, p. 320, grifos nossos), podemos dividir os serviços fornecidos por uma implementação de modelo de componente em duas categorias: 1. , que permitem aos componentes se comunicarem e interagirem em umServiços de plataforma ambiente distribuído. Esses são os serviços fundamentais que devem estar disponíveis em todos os sistemas baseados em componentes. 2. , que são serviços comuns, suscetíveisServiços de suporte de serem requeridos por muitos componentes diferentes. Por exemplo, muitos componentes requerem autenticação para garantir que o usuário dos serviços de componente seja autorizado. Na figura a seguir, demonstraremos como acontecem esses serviços. - -17 Figura 8 - Serviços de middleware definidos em um modelo de componente, demonstrando suas relações. Fonte: SOMMERVILLE, 2011, p. 320. Por fim, o tem como responsabilidade implementar os serviços dos componentes e fornecer amiddleware interface para eles. Para fazer o uso dos serviços previstos por uma infraestrutura de modelo de componentes, podemos entender os componentes para serem implantados em um contêiner. Assim, um contêiner implementa os serviços de suporte, adicionando uma definição das interfaces que um componente deve fornecer para integrá-lo com o contêiner. Síntese Concluímos este capítulo compreendendo como as arquiteturas de se adaptam e se modelam às novassoftware tecnologias de sistemas, como ambiente e dispositivos móveis. Vimos que existem alternativas para aweb criação de arquiteturas dependendo da aplicação e do ambiente de negócios no qual ele está inserido. Essas arquiteturas devem se acoplar aos modelos, e não existe uma regra rígida, mas sim um bom senso na criação e definição das linguagens, dos modelos e das características dos sistemas. Neste capítulo, você teve a oportunidade de: • compreender o processo de elaboração de projetos para uma aplicação ;web • elaborar projetos para uma aplicação em dispositivos móveis; • entender como avaliar as alternativas existentes para os diversos modelos; • compreender a aplicação da linguagem de descrição de arquitetura; • verificar a conformidade de uma arquitetura de ;software • compreender como elaboramos os projetos de componentes. • • • • • • - -18 Bibliografia CHAGAS, F. B. . 81 f.Checagem de conformidade arquitetural na modernização orientada a arquitetura 2016. Dissertação (Mestrado em Ciência da Computação), Centro de Ciências Exatas e de Tecnologia, Programa de Pós-Graduação em Ciências da Computação, Universidade Federal de São Carlos. São Carlos: UFSCar, 2016. Disponível em: <https://repositorio.ufscar.br/bitstream/handle/ufscar/8392/DissFBC.pdf? >. Acesso em: 23/5/2018.sequence=1&isAllowed=y FONSECA FILHO, C. : o caminho do pensamento e da tecnologia. História da computação Porto Alegre: PUC-RS, 2007. GARLAN, D.; SHAW, M. . New Jersey: World Scientific PublishingAn introduction to software architecture Company, 1994. JÚNIOR, E. A. O.; FORTES, R. P. M. : processamento no servidor. InstitutoArquitetura de software na web atual de Ciências Matemáticas e de Computação (ICMC), Universidade de São Paulo (USP), São Carlos, 2007. Disponível em: < >. Acesso em:http://conteudo.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_ND_78.pdf 22/5/2018. KIKOT, T.; FERNANDES, S.; COSTA, G. Potencial da aprendizagem baseada-em-jogos: um caso de estudo na Universidade do Algarve. , Rio Tinto, n. 16, ano 3, p. Revista Ibérica de Sistemas e Tecnologias de Informação 17-29, dez. 2015. Disponível em: < >. Acesso em: 23/5/2018.http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf LEE, V. : arquitetura, projeto e desenvolvimento. São Paulo: Pearson Education do Brasil,Aplicações móveis 2005. MICROSOFT AZURE. Microsoft, 2018. Disponível em:O que é middleware? <https://azure.microsoft.com/pt-br >. Acesso em: 23/5/2018. /overview/what-is-middleware MILANEZ, C. A.; TAIT, T. F. C. Uma arquitetura de data warehouse para apoio à gestão de projetos em desenvolvimento distribuído de software. , Curitiba, v. 11, n. 1, Revista Eletrônica de Sistemas de Informação p. 1-17, jan./jun. 2012. Disponível em: <http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728 >. Acesso em: 23/5/2018./pdf MILANEZ, C. A.; TAIT, T. F. C. Uma arquitetura de data warehouse para apoio à gestão de projetos em desenvolvimento distribuído de software. , Curitiba, v. 11, n. 1, Revista Eletrônica de Sistemas de Informação p. 1-17, jan./jun. 2012. Disponível em: <http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728 . Acesso em: 23/5/2018./pdf> PILAR, C. P. . 89 f. 2013.Avaliação das arquiteturas de desenvolvimento para dispositivos móveis Monografia (Trabalho de Conclusão de Curso em Sistemas de Informação), Centro de Computação e Tecnologia da Informação, Universidade de Caxias do Sul. Caxias do Sul: UCS, 2013. Disponível em: <https://repositorio.ucs. br/xmlui/bitstream/handle/11338/1245/TCC%20Carina%20Ponzoni%20Pilar.pdf?sequence=1&isAllowed=y >. Acesso em: 23/5/2018. PRESSMAN, R. : uma abordagem profissional. 8. ed. Porto Alegre: McGraw Hill, 2016.Engenharia de software SERMAN, D. V. Orientação a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a serviços. Journal of Information Systems and Technology Management(JISTEM), São Paulo, v. 7, n. 3, p. 619-638, 2010. Disponível em: < >. Acesso em: 23/5/2018.http://www.scielo.br/pdf/jistm/v7n3/07.pdf SILVA FILHO, A. M. Desenvolvimento de software requer processo e gestão. ,Revista Espaço Acadêmico Maringá, UEM, v. 11, n. 123, p. 46-57, ago. 2011. Disponível em: <http://periodicos.uem.br/ojs/index.php >. Acesso em: 23/5/2018./EspacoAcademico/article/view/14312/7593 SOMMERVILLE, I. . 9. ed. São Paulo: Pearson Prentice Hall, 2011.Engenharia de software https://repositorio.ufscar.br/bitstream/handle/ufscar/8392/DissFBC.pdf?sequence=1&isAllowed=y https://repositorio.ufscar.br/bitstream/handle/ufscar/8392/DissFBC.pdf?sequence=1&isAllowed=y http://conteudo.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_ND_78.pdf http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf https://azure.microsoft.com/pt-br/overview/what-is-middleware https://azure.microsoft.com/pt-br/overview/what-is-middleware http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf> http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf> https://repositorio.ucs.br/xmlui/bitstream/handle/11338/1245/TCC%20Carina%20Ponzoni%20Pilar.pdf?sequence=1&isAllowed=y https://repositorio.ucs.br/xmlui/bitstream/handle/11338/1245/TCC%20Carina%20Ponzoni%20Pilar.pdf?sequence=1&isAllowed=y http://www.scielo.br/pdf/jistm/v7n3/07.pdf http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593 http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593 Introdução 2.1 Projeto de arquitetura para aplicações web e dispositivos móveis 2.1.1 Projeto de arquitetura para aplicações web 2.1.2 Projeto de arquitetura para dispositivos móveis 2.2 Avaliação das alternativas do projeto 2.2.1 Linguagem de descrição da arquitetura (ADL) 2.3 Verificação de conformidade da arquitetura 2.4 Projeto de componentes Síntese Bibliografia
Compartilhar