Arquitetura de Software Material Apoio AOL 4

Prévia do material em texto

Frameworks arquiteturais
Desde as décadas de 80 e 90, a tecnologia da informação vem sofrendo evoluções constantes em seus conceitos e sua estrutura e, em conjunto com outras transformações, como a computação pessoal, vem causando uma transformação em como as organizações interagem com esta área, trazendo uma quantidade considerável de sistemas de informação, muito deles sendo feitos dentro dos próprios departamentos, no coração das áreas de negócio sem grandes preocupações com interoperabilidade e reuso de funcionalidades comuns a diversos setores.
Basicamente, nesta mesma época, nascia a arquitetura de software corporativa, criada por John Zachman onde foi publicado o primeiro framework intitulado Zachman Framework. Neste framework, a proposta era repartir a organização corporativa em uma matriz separada em seis dimensões:
· 1
O quê?
· 2
Como?
· 3
Onde?
· 4
Quem?
· 5
Quando?
· 6
Por quê?
Com estas dimensões definidas, o framework propôs que as linhas da matriz iriam referenciar os diferentes pontos de vista e níveis de detalhe relativos às informações organizacionais:
Tabela 1. Zachman Framework dimensões e estrutura.
Posteriormente, o framework de Zachman foi classificado como uma ontologia, ou seja, um esquema de metamodelo que auxilia na estruturação de elementos arquitetônicos como documentos de design, especificações e outros elementos presentes neste tipo de estrutura. Apesar disto, o Zachman Framework serviu de base e inspiração para todos os outros frameworks que viriam após ele. No Diagrama 1, temos um breve resumo do conjunto de frameworks que surgiram após a criação do Zachman Framework:
Diagrama 1. Frameworks Arquiteturais. Fonte: ARCHITECTONICS, 2014. (Adaptado).
Como visto, vários frameworks vieram ao mercado com propostas complementares e abordando mais questões, permitindo a melhor organização da visão arquitetural e os seus relacionamentos. Outras características positivas que vieram com estes frameworks foram:
· Padronização dos termos e linguagens organizacionais;
· Aumento na produtividade;
· Maior organização das informações.
Além disso, incluem o alinhamento estratégico da organização com seus processos de negócio, aplicações, dados e tecnologia. Todos esses artefatos e visões normalmente são apoiados e suportados por algum tipo de ferramentas de gestão da arquitetura corporativa dentro da organização.
Baseado nestas informações e na Figura 2, podemos entender que vários outros frameworks vieram para enriquecer este ambiente arquitetural de construção de soluções em software. Neste contexto, iremos abordar os três frameworks mais conhecidos e que serviram de base para várias arquiteturas e outros frameworks: DoDAF (Department of Defense Architecture Framework), FEAF (Federal Enterprise Architecture Framework) e TOGAF (The Open Group Architecture Framework).
FRAMEWORK DoDAF
O framework arquitetural do departamento de defesa norte-americano (DoDAF) é uma estrutura de arquitetura criada para o Departamento de Defesa dos Estados Unidos (DoD), que visa fornecer uma visão de infraestrutura para apreciação das partes interessadas, especificadas por meio de pontos de vista organizados em várias visualizações. Essas visões são artefatos para visualizar, compreender e assimilar o amplo escopo e as complexidades de uma descrição de arquitetura através de meios conceituais tabulares, estruturais, e vários outros.
Este framework de arquitetura é especialmente adequado para grandes sistemas com desafios complexos de integração e interoperabilidade, e é aparentemente único em seu emprego de visões operacionais. Essas visões oferecem uma percepção geral e detalhes direcionados às partes interessadas específicas dentro de seu domínio e em interação com outros domínios nos quais o sistema irá interagir.
O framework DoDAF realiza uma classificação dos produtos levando em consideração seus atributos arquiteturais específicos e divide esta classificação três visualizações. Além disso, o DoDAF combina informações de visão geral e de resumo, e definições de terminologia do produto DoDAF em uma visualização chamada Todas as Visualizações (AV). Assim, podemos ter as seguintes visualizações, na versão 1.5 do framework:
Clique nos cards para saber mais
Este tipo de visualização descreve todos os aspectos de funcionalidades do departamento de defesa norte-americano (DoD), incluindo missões de combate e de negócios. Esses aspectos incluem a estrutura e o comportamento dos componentes que constituem um ambiente operacional, seus relacionamentos e dependências, tarefas e atividades, elementos operacionais (nós), o tipo e a frequência de troca de informações e fluxos entre os nós.
Este tipo de visualização descreve a estrutura interna e o comportamento dos componentes que irão suportar as funções do departamento de defesa. Além disso, esta visualização descreve os relacionamentos entre recursos do sistema e a Visualização Operacional.
Este tipo de visualização descreve os padrões e regras que governam a organização, como as interações e as dependências entre estados existentes e futuros dos sistemas descritos pela SV (Visualização do Sistema).
Os produtos de todas as visualizações mencionadas fornecem informações que se aplicam à descrição da arquitetura inteira de um ambiente operacional. Apesar de não fornecerem uma perspectiva completa do sistema, as visualizações descrevem informações importantes e essênciais como o escopo, propósito, uso pretendido, objetivos da missão e estratégias do ambiente operacional e um dicionário de termos.
Com estas informações, podemos resumir a integração destes contextos de visualizações disponibilizado pelo DoDAF conforme vemos na Figura 1.
Figura 1. Visão geral DoDAF 1.5.
O DoDAF foi projetado para atender às necessidades específicas de negócios e operacionais do DoD. Ele define uma maneira de representar uma arquitetura corporativa que permite que as partes interessadas se concentrem em áreas específicas de interesse na empresa, enquanto mantém a visão do panorama geral. Para auxiliar os tomadores de decisão, o DoDAF fornece os meios de abstrair informações essenciais da complexidade subjacente e apresentá-las de maneira a manter coerência e consistência.
Um dos principais objetivos é apresentar essas informações de uma forma que seja compreensível para as muitas comunidades de partes interessadas envolvidas no desenvolvimento, fornecimento e manutenção de capacidades em apoio à missão das partes interessadas. Isso é feito dividindo o espaço do problema em partes gerenciáveis, de acordo com o ponto de vista da parte interessada, mas definido como modelos descritos pelo DoDAF.
Desta forma, para contemplar todas as informações necessárias de serem tratadas neste framework, uma nova versão do DoDAF foi lançada em 2009 para melhorar o suporte das visualizações de informações e estruturas necessárias da arquitetura corporativa presente no departamento de defesa norte-americano. Assim, a evolução da estrutura do novo framework ficou conforme mostra a Figura 2.
Figura 2. Evolução DoDAF V1.5 para V2.0. (Adaptado).
Assim sendo, podemos ver que o DoDAF é um framework arquitetural com estrutura baseada em metamodelos cujo onde seu núcleo é baseado em visões e estruturas bem detalhadas de seus produtos e elementos que participam do contexto arquitetural. Apesar disto, este tipo de framework foi amplamente criticado e seus resultados foram muito questionados em relação a seu custo-benefício, bem como à sua efetividade na aplicação em casos reais.
Em um artigo publicado no British Computer Society (BCS), em 2016, o autor Svyatoslav Kotusev apresenta uma análise histórica relativa a este framework, dizendo o quão espetacular foram os investimentos neste framework de arquitetura corporativa que, em contrapartida, apresentou tantos resultados insatisfatórios.
Mesmo assim, o DoDAF foi muito importante para a identificação de uma série de características e processos que puderam ser analisados e compreendidos de forma que pudessem ser evoluídos e aproveitados em frameworks futuros,que apresentam uma série de melhorias e aprimoramentos.
DICA
O artigo "Enterprise Architecture Frameworks: The Fad of the Century", do autor Svyatoslav Kotusev, apresenta argumentos e fatos interessantes sobre os problemas oriundos do DoDAF e de seus custos. Além disso, apresenta pontos importantes que auxiliam na compreensão dos problemas e nas correções que podem ser aplicadas em futuros frameworks.
SAIBA MAIS
FRAMEWORK FEAF
Em setembro de 1999, o Conselho Federal de CIO publicou a Federal Enterprise Architecture Framework (FEAF) Versão 1.1 para desenvolver uma Arquitetura Corporativa (EA) dentro de qualquer agência federal para um sistema que transcende os múltiplos limites entre agências. Ele se baseia em práticas e projetos de negócios comuns que cruzam fronteiras organizacionais, como, o Modelo de Arquitetura Corporativa do NIST.
O Federal Enterprise Architecture Framework (FEAF) fornece ao governo norte-americano uma abordagem comum para a integração estratégica de negócios e gerenciamento de tecnologia. Essa estrutura e os artefatos associados ajudam no planejamento, na tomada de decisões e no gerenciamento entre as agências.
Em 29 de janeiro de 2013, a Casa Branca lançou a versão 2 do Federal Enterprise Architecture Framework (FEAF-II) para agências governamentais, tornando-a pública cerca de um ano depois. O documento atende aos critérios estabelecidos pela Abordagem Comum, enfatizando que os objetivos estratégicos orientam os serviços de negócios, os quais, por sua vez, fornecem os requisitos para a habilitação de tecnologias. Em seu núcleo está o Modelo de Referência Consolidada (CRM), que equipa as agências OMB e Federal com uma linguagem e estrutura comuns para descrever e analisar os investimentos. Existem seis domínios de sub arquitetura no framework. Esses domínios incluem: estratégia, negócios, dados, aplicações, infraestrutura e segurança.
Desta forma, podemos entender como este framework é estruturado analisando Diagrama 2, que apresenta a macrovisão do processo usado no FEAF.
Clique nos botões para saber mais
Diagrama 2. Macrovisão do processo FEAF. Fonte: OBAMA WHITE HOUSE, 2012. (Adaptado).
A abordagem do FEAF possui quatro pilares que sustentam toda a ideia e os processos utilizados no framework. São eles:
Clique nos botões para saber mais
Service delivery
+
Functional integration
+
Resource optimization
+
Authoritative reference
–
Assim como as plantas de um edifício são a referência oficial de como a estrutura funcionará, a arquitetura corporativa da organização fornece uma visão integrada e consistente de objetivos estratégicos, missão e serviços de suporte, dados e tecnologias de capacitação em toda a organização, incluindo programas, serviços e sistemas.
 
Quando o EA é reconhecido como referência oficial para o design e para a documentação de sistemas e serviços, as questões de propriedade, gerenciamento, recursos e metas de desempenho podem ser resolvidas de maneira mais consistente e eficaz.
 
Outras características e estruturas estão presentes na estrutura deste framework para auxiliar no suporte ao complexo universo arquitetural presente em uma solução de software. Apesar disto, o framework FEAF apresentou diversas características que resultaram em vários problemas na sua utilização e em seus resultados.
 
O artigo "Why Doesn’t the Federal Enterprise Architecture Work?", do autor Stanley B. Gaver (participante do projeto FEAF), apresenta uma série de fatores e características que demonstram que este processo ainda precisa de várias melhorias e que seus resultados ainda são fracos ou ausentes em sua utilização dentro do governo federal. Ele menciona que este framework ainda não apresentou resultados úteis e que, além disto, algumas partes significativas do framework falharam completamente em suas funcionalidades.
FRAMEWORK TOGAF
O TOGAF é um framework criado pelo Open Group que tem como um de seus objetivos auxiliar na construção de arquiteturas corporativas, oferecendo uma estrutura de alto nível para o desenvolvimento de soluções de software. Através deste framework é possível realizar a organização do processo de desenvolvimento utilizando uma metodologia sistemática que promove a redução de erros e a saúde do cronograma e do orçamento. Além disso, um dos objetivos é manter o alinhamento da TI com a área de negócios para que a qualidade seja aprimorada e os resultados sejam mais adequados às exigências.
Assim como outros frameworks disponíveis no mercado, o TOGAF teve um papel muito importante, ajudando várias corporações a alinharem suas metas específicas de TI com as metas de negócio, da mesma forma que proporcionou uma melhor integração da TI com outros departamentos presentes na corporação. Outra característica agregada a este framework é a capacidade de identificar e organizar os requisitos junto ao início do projeto, mantendo-o dinâmico e com poucos erros.
Benefícios da utilização do TOGAF
A adoção de um framework como o TOGAF traz vários benefícios diretos e indiretos para a organização e auxilia na promoção da organização e manutenibilidade do ciclo de desenvolvimento de software. Algumas características diretas que podemos alcançar ao utilizar o TOGAF são:
· Melhor entendimento da visão de negócio;
· Melhor entendimento de como a arquitetura interage com o negócio;
· Exposição mais clara dos custos, benefícios e riscos associados com possíveis planos de ação;
· Oportunidade de dividir os custos de mudanças com outros gestores de negócio;
· Oportunidade de desenvolver componentes arquiteturais compartilhados e reutilizáveis;
· Redução da complexidade de negócio;
· Melhor processo de planejamento estratégico e de investimento de valores através da aplicação antecipada das fases de ADM;
· Templates para auxiliar a gestão arquitetural e treinamentos.
Alguns benefícios indiretos, oriundos da utilização do TOGAF, são:
· O negócio se torna mais ágil e dinâmico, absorvendo as mudanças de forma mais rápida;
· Definição mais efetiva das capacidades associadas ao negócio;
· Redução do custo de gestão.
Estrutura do TOGAF
O TOGAF foi baseado em um framework chamado TAFIM (Framework de Arquitetura Técnica para Gerenciamento de Informações), criado pelo departamento de defesa norte-americano, na década de 1990.
O ADM (Arhitecture Development Method) é o elemento central da arquitetura que define o framework TOGAF, ajudando as corporações a estabelecerem um processo concreto ao redor do ciclo de vida da arquitetura corporativa. A estrutura do ADM pode ser modificada e atualizada de forma que se flexibilize para absorver necessidades especiais definidas pelas organizações, melhorando a aderência da arquitetura do sistema ao negócio. A ADM ajuda as empresas a desenvolverem processos que envolvem vários pontos de verificação e estabelecem requisitos para que o processo possa ser repetido com erros mínimos.
Diagrama 3. Visão geral do ADM TOGAF. Fonte: OPENGROUP, [s.d.]. Acesso em: 16/09/2019. (Adaptado).
Como podemos observar, trata-se de um processo iterativo. A fase preliminar (Preliminary) é o momento onde realizamos o “pontapé inicial” da arquitetura, estabelecendo sua equipe e definindo a metodologia e as customizações a serem usadas na estrutura arquitetural. É neste momento que as ferramentas de repositório são selecionadas, os processos de governança arquitetural são definidos e obtemos o patrocínio necessário para o esforço de arquitetura. A partir deste ponto, as fases são executadas de forma interativa no ADM:
Visão da arquitetura 
Como a fase preliminar é responsável por estabelecer o processo de arquitetura, a fase de visão da arquitetura é responsável pelo planejamento do projeto arquitetural que será executado na interação corrente do ADM. A ideia é estabelecer uma visão prévia da arquitetura em relação às metas estratégicas de negócio, que serão utilizadas como os parâmetros de entrada desta fase.
Nesta, será gerado o documento de visão arquitetural, que irá expor o objetivo de se utilizar determinada arquitetura para atender as metas estratégicas,juntamente com um plano de projeto para explicar a execução desta interação.
Arquitetura de negócio
Neste momento, utilizamos os processos de negócio da empresa para criar uma visão atual e futura destes processos. Esta fase se equipara à segunda linha do Zachman Framework (Conceitos de Modelo de Negócio), da mesma forma que a fase anterior está associada a primeira linha deste mesmo framework (Gabinete de Estratégias – Administração).
Nesta fase, teremos o detalhamento das necessidades de quais processos de negócio serão necessários para o atendimento das metas estratégicas, bem como uma gap analysis que irá nos informar qual a diferença entre a situação atual e a futura da nossa arquitetura.
Arquiteturas de sistemas de informação
Aqui, será verificado quais sistemas externos e dados serão necessários para suportar a visão futura dos processos e da arquitetura expressa na fase anterior. Também será realizada outra gap analysis para acompanhar a diferença restante entre a situação atual e a futura.
Arquitetura de tecnologia
Aqui, iremos documentar a necessidades futuras visando a parte te infraestrutura tecnológica para atender as definições de sistema e as informações levantadas na fase anterior. Também será realizada outra gap analysis para acompanhar a diferença restante entre a situação atual e a futura.
Oportunidades e soluções e planejamento da migração
Neste momento, são consolidadas as gap analysis das fases anteriores, e é são identificados os projetos necessários de se realizar para que esta diferença não exista mais.
O resultado, neste caso, é um portfólio de projetos que irá ser utilizado para alcançar a arquitetura desejada.
Governança da implementação
Nesta fase, a principal atividade é a realização de revisões de conformidade, que são auditorias realizadas nos projetos identificados, a fim de garantir que estejam sendo executados de acordo com a arquitetura proposta.
Gestão de mudanças na arquitetura
Aqui, o objetivo é acompanhar e adequá-la a relevância da arquitetura implantada na fase anterior às necessidades estratégicas da organização. Alterações no ambiente de negócios e na estratégia exigirão mudanças na arquitetura, e o processo usado nesta fase deve ser capaz de separar pequenas de grandes mudanças. As grandes mudanças, tipicamente, exigirão a reentrada no ciclo do ADM, ou seja, o estabelecimento de um novo projeto, a ser iniciado novamente.
Gestão de requisitos
Esta atividade encontra-se, literalmente, no centro do ADM, significando que cada uma das demais fases do ADM, ao mesmo tempo, gera novos requisitos de arquitetura e utiliza como entrada os requisitos de arquitetura previamente identificados.
O TOGAF é atualmente o framework padrão para arquitetura corporativa, sendo de longe o mais utilizado para este fim. De fato, mesmo naquelas organizações onde se pratica apenas arquitetura de TI (e não corporativa, o que necessariamente inclui a estratégia corporativa e os processos de negócio), ele tem sido a opção escolhida.
ASSISTA
Confira o vídeo disponibilizado pela eVolve a respeito da apresentação do TOGAF, mostrando como é possível utilizar um repositório dentro da arquitetura corporativa.
Projetando para atender requisitos não funcionais
Em engenharia de software existe uma estreita relação entre os requisitos não-funcionais (NFRs) e as arquiteturas de software (SAs). Já em 1994, Rick Kazman e Len Bass afirmaram que a arquitetura de software está intimamente ligada à realização do NFR. Essa ideia permeou o desenvolvimento de software ao longo dos anos e explica por que os projetos de desenvolvimento investem muito no preenchimento de NFRs.
Esta afirmação torna-se mais concreta quando consideramos como o conceito de arquitetura de software evoluiu de uma representação estrutural simples para um ponto de vista centrado nas decisões e definições críticas e importantes de um projeto. Nessa perspectiva, os NFRs servem como critérios de seleção para escolher entre um conjunto de projetos e implementações. Por exemplo, podemos justificar a escolha de um estilo arquitetônico em camadas em termos de capacidade de manutenção ou portabilidade, ou a escolha de uma determinada tecnologia de banco de dados em termos de eficiência.
Os arquitetos de software devem lidar continuamente com os NFRs como parte de sua responsabilidade de desenhar e projetar uma arquitetura de software. Os arquitetos devem entender os NFRs de um sistema e como as decisões de arquitetura afetam o cumprimento de NFRs.
Diagrama 4. Tipos de requisitos não funcionais.  Fonte: SOMMERVILLE, 2011. (Adaptado).
REQUISITOS NÃO FUNCIONAIS E SUA RELAÇÃO COM ARQUITETURA
O levantamento de requisitos obtém os requisitos de sistemas das partes interessadas e de outras fontes e realiza o seu refinamento. Tanto os pesquisadores quanto os profissionais consideram essa uma das partes mais desafiadoras da engenharia de requisitos.
Numerosas técnicas (pesquisas, oficinas de criatividade, etc.) ajudam a expressar os requisitos de maneira precisa e inequívoca. Essas técnicas pressupõem que as partes interessadas do lado do cliente (usuários finais, gerentes e assim por diante) contribuem mais para o levantamento.
Mas quando falamos de requisitos não funcionais, a natureza abstrata pode dificultar a sua visualização e entendimento. Desta forma, podemos entender que o levantamento do requisito não funcional é um processo interativo que se expande ao longo do ciclo de vida do sistema. Isso pode ocorrer porque parte do comportamento esperado do sistema não pode ser descoberto até que um determinado marco (normalmente, um protótipo) seja alcançado. Também, não podemos considerar os requisitos não funcionais completos após o primeiro desenvolvimento. Eles exigirão manutenção para corrigir algum mau comportamento que originalmente era esperado. Alguns requisitos não funcionais, como aqueles relacionados à segurança, podem ser completamente verificados até que o sistema seja implantado em seu ambiente esperado e surjam condições inesperadas.
CONTEXTUALIZANDO
Os requisitos não funcionais abordam aspectos de qualidade importantes em sistemas de software. Se tais requisitos não são levados em consideração, então o sistema de software poderá ser inconsistente e de baixa qualidade. Sendo assim, conclui-se que quanto mais cedo forem definidos os critérios arquiteturais, mais cedo o projetista pode identificar o estilo, ou a combinação de estilos, mais apropriada ao sistema considerado.
// 10 Requisitos não funcionais críticos em arquitetura de software:
Escalabilidade
Em um modelo de negócios sob demanda é extremamente difícil prever a carga do sistema. Ao mesmo tempo, não é possível planejar um cenário de pico de carga, pois isso consumiria altos níveis de custo e resultaria no uso ineficiente de recursos. Portanto, o software deve ser projetado para dimensionar e reduzir dinamicamente os níveis de custo com base na carga em tempo real no sistema. É nesse ponto que os arquitetos de software precisarão saber utilizar o modelo de nuvem para aproveitar o modelo de consumo de recursos sob demanda.
Performance
Com o constante aumento na velocidade da internet e na disponibilidade de largura de banda há uma tendência geral de se esperar uma resposta rápida de aplicativos baseados na Internet. Os usuários de software esperam o mesmo, independentemente do tipo de aplicativo ou do volume de processamento que acontece por trás das telas. Portanto, os arquitetos terão que considerar conscientemente os possíveis gargalos de desempenho e implementar projetos que podem ajudar a alavancar conceitos como processamento assíncrono, arquitetura de microsserviços, disponibilidade de múltiplos dados e outros.
Disponibilidade
Provavelmente o mais importante de todos os requisitos não funcionais. É primordial que o software esteja disponível on-line para outros requisitos entrarem. A disponibilidade do software é a maior preocupação, especialmente se o software aborda uma solução crítica para os negócios. O tempo de inatividade não planejado do softwarepode levar a grandes perdas para os clientes e, consequentemente, pode arruinar os negócios do provedor de software. Os arquitetos terão que entender o SLA, que é direcionado, e projetar o modelo de implantação de forma que não haja nenhum ponto de falha. Eles também devem considerar os fatores RTO (Recovery Time Objective – objetivo de tempo de recuperação) e RPO (Recovery Point Objective – objetivo de ponto de recuperação) ao projetar sua estratégia de disponibilidade.
Interoperabilidade
Estamos vivendo em um mundo altamente conectado e isso só vai aumentar nos próximos anos. Os clientes são muito detalhistas em escolher softwares que não apenas abordem os recursos esperados, mas também sua capacidade de combinar bem com a configuração existente. Isso leva a uma situação em que o software terá que conversar com um conjunto diferente de sistemas internos e externos. Os arquitetos terão que projetar o software como um sistema aberto com ganchos suficientes para que a integração não seja apenas viável, mas também possa ser concluída com o mínimo de esforço.
Auditoria
Do ponto de vista de um provedor de software, a propriedade do sistema e seu funcionamento são suas atribuições. Portanto, é responsabilidade do fornecedor do software implementar as medidas apropriadas para rastrear o uso do sistema e os eventos que ocorrem nele. Essas informações serão críticas para fins de diagnóstico e resolução de conflitos com clientes. O projeto de auditoria deve garantir que todas as ações do usuário e do sistema sejam registradas e armazenadas adequadamente, de modo que seja fácil rastrear e identificar a sequência exata de eventos que ocorreram no sistema. Também é importante armazenar a alteração de dados (dados antigos versus novos dados) junto com o registro de data e hora e os detalhes do usuário que induziram a alteração.
Configurabilidade
O modelo SaaS de entrega de aplicativos traz a complexidade de abordar vários requisitos, às vezes conflitantes. Muitos aplicativos SaaS continuam a permanecer no modelo de hospedagem/inquilino único devido a esse motivo. No entanto, quando analisados e projetados com cuidado, cada camada do aplicativo SaaS pode ser construída com opções configuráveis suficientes, o que pode ajudar a alcançar os requisitos específicos do cliente por meio da configurabilidade, em vez da codificação. As camadas padrões que devem ser consideradas para configuração são: UI; branding; autenticação; funções/privilégios; regras de negócios; processos de negócios; integração e banco de dados.
Segurança
A segurança de um aplicativo deve ser encarada como um mecanismo integrado abrangente que conecta a assinatura, segurança no nível de inquilino, restrições de uso, restrições de dados, criptografia, privilégios de usuário e nível de função. Adotar uma visão holística de todos esses aspectos no design da arquitetura de segurança é a etapa principal para um aplicativo bem-sucedido. Ter isso consolidado como um mecanismo unificado não apenas ajuda na capacidade de gerenciamento do sistema, mas também facilita as mudanças de uma maneira sistemática.
Extensibilidade
Aplicativos raramente são usados fora da caixa pelos clientes. Embora os clientes entendam que os aplicativos não podem ser drasticamente personalizados para atender à necessidades específicas, eles ainda desejam fazer essas pequenas alterações que ajudarão a adequar o aplicativo aos detalhes do nível prático de implementação.
 
Por exemplo, um cliente pode querer capturar campos adicionais como parte de uma tela de aplicativo padrão. Nesse caso, você deve poder incluir, armazenar e gerenciar os campos adicionais, mas apenas para esse cliente. O restante dos clientes não deve poder ver essa alteração.
Monitoramento
O monitoramento proativo da integridade do aplicativo pode ajudar muito a garantir a disponibilidade do sistema e lidar com os cenários inesperados da produção. Há vários níveis de monitoramento, incluindo o monitoramento do nível do aplicativo, o monitoramento da camada do banco de dados, o monitoramento do uso do aplicativo, o monitoramento de erros, o monitoramento de testes, o monitoramento de eventos e o monitoramento de alertas. É importante projetar a arquitetura de forma que os pontos de dados necessários para o monitoramento mencionado acima estejam facilmente disponíveis. Também é importante acompanhar essas informações em nível de inquilino para que as respostas aos clientes possam ser aceleradas.
Multi-tenancy
Multi-tenancy é uma abordagem de design que facilita uma única instância de um sistema (aplicativo SaaS, por exemplo) para funcionar como instâncias lógicas isoladas servindo aos clientes. As arquiteturas de multi-tenancy são complexas para projetar, mas, uma vez feitas adequadamente, podem ajudar a reduzir significativamente as despesas operacionais em comparação com um único inquilino ou modelo hospedado.
 
A complexidade aumenta ainda mais com conceitos como a hierarquia de inquilinos e inquilinos virtuais, que fornecem mecanismos sofisticados para lidar com vários graus de multi-tenancy. A idéia de multi-tenancy pode ser aplicada à camada da web/aplicativo e à camada do banco de dados. No entanto, também é possível aplicá-lo somente à camada da web/aplicativo, mantendo os bancos de dados isolados entre os inquilinos (clientes).
COMO OS REQUISITOS NÃO FUNCIONAIS INFLUENCIAM DECISÕES ARQUITETURAIS
Como é possível de se entender, os requisitos não funcionais também são considerados requisitos de qualidade e, como tais, são extremamente importantes para suportar as decisões técnicas a serem tomadas e também para suportar as definições que serão tomadas pelas partes em relação ao sistema.
Dentro deste contexto, é possível identificar que os requisitos não funcionais podem influenciar de forma muito clara quatro tipos de decisões arquiteturais presentes no ciclo de vida da fase arquitetural. São eles:
· Padrões arquiteturais de desenho (design patterns);
· Estratégias de Implementação;
· Decisões transversais;
· Plataformas tecnológicas.
RELAÇÃO ENTRE REQUISITOS NÃO FUNCIONAIS E DESIGN PATTERNS
Como vimos até o momento, os requisitos não funcionais se tornaram poderosos direcionadores no processo de desenvolvimento de uma arquitetura de software. Não obstante, os requisitos não funcionais terminam por influenciar, também, os padrões de desenho de software e suas aplicações dentro do contexto arquitetural e de desenvolvimento da solução.
Neste contexto, podemos usar o raciocínio onde explicita-se a estrutura por trás de um padrão de desenho, de forma que o mesmo seja acessível para análise sistemática. Assim, pode-se focar no requisito não funcional que o padrão atende, os trade-offs envolvidos e como os requisitos são cumpridos quando o padrão é aplicado. Este tipo de abordagem visa o seguinte:
// Clarear o papel dos requisitos não funcionais nos padrões de desenho
Requisitos não funcionais discutidos nos padrões de projeto são explicitamente representados. Isso os torna "cidadãos de primeira classe", o que permite analisar e referenciar o papel que desempenham na estrutura de argumentação dos padrões de projeto.
// Prover uma estrutura para caracterizar cada padrão
Os requisitos não funcionais relacionam-se entre si e com as soluções alternativas discutidas nos padrões. Os requisitos são os critérios para avaliar por que aceitar ou rejeitar a solução. Tornar essas relações explícitas permite caracterizar soluções padronizadas em termos de suas propriedades relacionadas aos requisitos não funcionais.
// Suporte sistemático para os padrões durante o design
Os requisitos não funcionais precisam ser abordados sistematicamente durante o projeto. A caracterização de padrões em relação aos requisitos permite notar melhor os requisitos de todo o sistema quando recuperados, selecionados e, em seguida, aplicados os padrões à situação atual do projeto.
// Suporte a engenharia futura e rastreabilidade
Os requisitos não funcionais tornam-se pontos focais a serem abordados pelos padrões. Designers são guiados por elesenquanto lidam com requisitos não funcionais, quando pesquisam, recuperam e elegem padrões. Manter o controle de como os requisitos não funcionais conduzem a aplicação de padrões durante o projeto permite notar como as estruturas do sistema evoluíram e, assim, facilita a rastreabilidade relacionada ao requisito.
Para que os objetivos acima mencionados sejam executados, podemos adotar os seguintes passos como os principais para conseguirmos ter sucesso nesta abordagem:
Clique nos botões para saber mais
Representar os requisitos como objetivos de design
–
Requisitos funcionais e não funcionais são representados como metas a serem atingidas durante o projeto. Requisitos não funcionais são denotados por metas mais leves referentes aos requisitos não funcionais. Estas metas relacionadas aos requisitos não funcionais são usadas para expressar as forças nos padrões de projeto e os requisitos de qualidade a serem alcançados pelo sistema de software pretendido. Nós as chamamos de metas mais leves porque elas normalmente não têm critérios de realização claros. Um estilo qualitativo de raciocínio é usado durante a análise. Os objetivos funcionais representam as funções que o sistema deve alcançar. Elas servem como pontos focais para analisar as funções e estruturas alternativas do sistema durante o processo de design.
Demonstrar os relacionamentos entre os objetivos e os gráficos
+
Identificar objetivos implícitos ou intermediários
+
Demonstrar como as soluções atendem os objetivos
+
Identificar efeitos de correlação não intencionais entre metas e soluções
+
Mostrar como a solução alternativa contribui diferentemente para metas
+
Suporte ao estilo argumentativo de modelagem
+
Razão qualitativa para estabelecer o grau de metarrealização
+
Identificando tipo e tópico em metas
+
Elaborar o sistema em design
+
Como visualizamos nesta parte, temos a capacidade de entender e visualizar como os requisitos funcionais são importantes e possuem um papel definidor dentro do contexto de desenvolvimento de uma arquitetura de software. Este papel, representado pelos requisitos não funcionais, traz para o arquiteto de software uma nova perspectiva de entendimento da arquitetura e das possíveis soluções que serão propostas para atender aos objetivos e necessidades dos clientes.
Além disso, aprendemos que os requisitos não funcionais (ou requisitos de qualidade) são grandes direcionadores e, portanto, devem ser considerados nas tomadas de decisões e nas definições mais críticas do software. Desta forma, temos uma exposição mais direta destes fatores que, definitivamente, irão influenciar a qualidade e a funcionalidade do software em questão.
Assim sendo, aqui temos o link final entre as estruturas arquiteturais, seu funcionamento e como é abordado o processo para que esta estrutura possa ser criada e disponibilizada de forma eficiente e produtiva, permitindo que sejam utilizadas todas as decisões críticas e essenciais da solução, utilizando como base os objetivos apresentados pelas partes, os requisitos de qualidade e as definições realizadas durante este processo.
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?!
SINTETIZANDO
Nesta unidade tivemos a oportunidade de conhecer mais sobre os frameworks arquiteturais e como eles surgiram no mercado para suportar as grandes corporações dentro do ciclo de vida de uma solução de software. Com este conhecimento, temos a capacidade de conseguir padronizar uma série de processos e situações presentes no cotidiano da arquitetura de software de forma que se possa repetir estes processos de forma fácil e ágil.
Neste contexto, tivemos a oportunidade de conhecer o primeiro framework oficial relacionado à arquitetura corporativa, o Zachman Framework, que serviu de base para outros frameworks de mercado, como o DoDAF e o FEA, que também tiveram seu papel no entendimento desta complexa disciplina que é a arquitetura de software.
Junto a isto tivemos a oportunidade de nos aprofundar mais um pouco em um dos assuntos mais importantes que permeiam a confecção de arquiteturas dentro do ciclo de vida do software: os requisitos não funcionais. Nesta unidade, fomos capazes de entender um pouco mais sobre como este tipo de requisito pode influenciar a estrutura arquitetural e as decisões que estão associadas a ela. Também tivemos a oportunidade de entender como os padrões de desenho de software (design patterns) podem ser flexibilizados para suportar de forma mais eficiente os requisitos não funcionais.
Desta forma, espero que todos consigam ver quão grande e complexo é o processo de se criar, desenvolver e implantar uma arquitetura de software dentro de uma corporação e dentro de um ciclo de vida de desenvolvimento de aplicações. Com esta nova visão, temos mais ferramentas e mais conhecimento para conseguirmos defender e aprimorar este processo tão complexo e importante.