Guia rápido

A arquitetura de um sistema descreve seus principais componentes, seus relacionamentos (estruturas) e como eles interagem uns com os outros. A arquitetura e o design de software incluem vários fatores contribuintes, como estratégia de negócios, atributos de qualidade, dinâmica humana, design e ambiente de TI.

Podemos separar a Arquitetura e o Design de Software em duas fases distintas: Arquitetura e Design de Software. DentroArchitecture, as decisões não funcionais são lançadas e separadas pelos requisitos funcionais. Em Design, os requisitos funcionais são cumpridos.

Arquitetura de software

Arquitetura serve como um blueprint for a system. Ele fornece uma abstração para gerenciar a complexidade do sistema e estabelecer um mecanismo de comunicação e coordenação entre os componentes.

• Define um structured solution para atender a todos os requisitos técnicos e operacionais, enquanto otimiza os atributos de qualidade comuns como desempenho e segurança.

• Além disso, envolve um conjunto de decisões significativas sobre a organização relacionadas ao desenvolvimento de software e cada uma dessas decisões pode ter um impacto considerável na qualidade, capacidade de manutenção, desempenho e sucesso geral do produto final. Essas decisões incluem:

  • Seleção dos elementos estruturais e suas interfaces que compõem o sistema.

  • Comportamento conforme especificado nas colaborações entre esses elementos.

  • Composição desses elementos estruturais e comportamentais em um grande subsistema.

  • As decisões arquitetônicas se alinham aos objetivos de negócios.

  • Os estilos arquitetônicos guiam a organização.

Design de software

O design do software fornece um design planque descreve os elementos de um sistema, como eles se encaixam e funcionam juntos para atender aos requisitos do sistema. Os objetivos de ter um plano de design são os seguintes -

• Para negociar requisitos de sistema e definir expectativas com clientes, marketing e pessoal de gestão.

• Atue como um modelo durante o processo de desenvolvimento.

• Oriente as tarefas de implementação, incluindo design detalhado, codificação, integração e teste.

Vem antes do design detalhado, codificação, integração e teste e depois da análise de domínio, análise de requisitos e análise de risco.

Objetivos da Arquitetura

O objetivo principal da arquitetura é identificar os requisitos que afetam a estrutura do aplicativo. Uma arquitetura bem definida reduz os riscos de negócios associados à construção de uma solução técnica e constrói uma ponte entre os requisitos de negócios e técnicos.

Alguns dos outros objetivos são os seguintes -

• Exponha a estrutura do sistema, mas oculte seus detalhes de implementação.

• Realize todos os casos de uso e cenários.

• Tente atender aos requisitos de várias partes interessadas.

• Lidar com requisitos funcionais e de qualidade.

• Reduza a meta de propriedade e melhore a posição da organização no mercado.

• Melhore a qualidade e funcionalidade oferecida pelo sistema.

• Melhore a confiança externa na organização ou no sistema.

Limitações

A arquitetura de software ainda é uma disciplina emergente na engenharia de software. Tem as seguintes limitações -

• Falta de ferramentas e formas padronizadas de representar a arquitetura.

• Falta de métodos de análise para prever se a arquitetura resultará em uma implementação que atenda aos requisitos.

• Falta de consciência da importância do projeto arquitetônico para o desenvolvimento de software.

• Falta de compreensão da função do arquiteto de software e comunicação deficiente entre as partes interessadas.

• Falta de compreensão do processo de design, experiência em design e avaliação do design.

Papel do arquiteto de software

Um arquiteto de software fornece uma solução que a equipe técnica pode criar e projetar para todo o aplicativo. Um arquiteto de software deve ter experiência nas seguintes áreas -

Experiência em design

• Especialista em design de software, incluindo diversos métodos e abordagens, como design orientado a objetos, design orientado a eventos, etc.

• Liderar a equipe de desenvolvimento e coordenar os esforços de desenvolvimento para a integridade do design.

• Deve ser capaz de revisar as propostas de design e compensar entre si.

Experiência de Domínio

• Especialista no sistema em desenvolvimento e plano de evolução do software.

• Auxiliar no processo de investigação de requisitos, garantindo integridade e consistência.

• Coordenar a definição do modelo de domínio para o sistema em desenvolvimento.

Experiência em tecnologia

• Especialista nas tecnologias disponíveis que auxiliam na implantação do sistema.

• Coordenar a seleção de linguagem de programação, framework, plataformas, bancos de dados, etc.

Expertise Metodológica

• Especialista em metodologias de desenvolvimento de software que podem ser adotadas durante o SDLC (Software Development Life Cycle).

• Escolha as abordagens apropriadas para o desenvolvimento que ajudam toda a equipe.

Papel oculto do arquiteto de software

• Facilita o trabalho técnico entre os membros da equipe e reforça a relação de confiança na equipe.

• Especialista em informação que compartilha conhecimento e possui vasta experiência.

• Proteja os membros da equipe de forças externas que os distrairiam e agregariam menos valor ao projeto.

Entregáveis ​​do arquiteto

• Um conjunto de metas funcionais claras, completas, consistentes e alcançáveis

• Uma descrição funcional do sistema, com pelo menos duas camadas de decomposição

• Um conceito para o sistema

• Um projeto na forma do sistema, com pelo menos duas camadas de decomposição

• Uma noção do tempo, atributos do operador e os planos de implementação e operação

• Um documento ou processo que garante a decomposição funcional é seguido, e a forma das interfaces é controlada

Atributos de Qualidade

Qualidade é uma medida de excelência ou o estado de estar livre de deficiências ou defeitos. Atributos de qualidade são as propriedades do sistema separadas da funcionalidade do sistema.

A implementação de atributos de qualidade torna mais fácil diferenciar um sistema bom de um mau. Atributos são fatores gerais que afetam o comportamento do tempo de execução, o design do sistema e a experiência do usuário.

Eles podem ser classificados como -

Atributos de qualidade estática

Refletir a estrutura de um sistema e organização, diretamente relacionada à arquitetura, design e código-fonte. Eles são invisíveis para o usuário final, mas afetam o custo de desenvolvimento e manutenção, por exemplo: modularidade, testabilidade, manutenção, etc.

Atributos de qualidade dinâmicos

Refletir o comportamento do sistema durante sua execução. Eles estão diretamente relacionados à arquitetura, design, código-fonte, configuração, parâmetros de implantação, ambiente e plataforma do sistema.

Eles são visíveis para o usuário final e existem em tempo de execução, por exemplo, rendimento, robustez, escalabilidade, etc.

Cenários de Qualidade

Os cenários de qualidade especificam como evitar que uma falha se torne uma falha. Eles podem ser divididos em seis partes com base nas especificações de seus atributos -

• Source - Uma entidade interna ou externa, como pessoas, hardware, software ou infraestrutura física que gera o estímulo.

• Stimulus - Uma condição que precisa ser considerada quando chega a um sistema.

• Environment - O estímulo ocorre dentro de certas condições.

• Artifact - Um sistema inteiro ou parte dele, como processadores, canais de comunicação, armazenamento persistente, processos etc.

• Response - Uma atividade realizada após a chegada do estímulo, como detectar falhas, recuperar da falha, desativar a fonte do evento, etc.

• Response measure - Deve medir as respostas ocorridas para que os requisitos possam ser testados.

Atributos de qualidade comuns

A tabela a seguir lista os atributos de qualidade comuns que uma arquitetura de software deve ter -

Categoria	Atributo de Qualidade	Descrição
Qualidades de Design	Integridade Conceitual	Define a consistência e coerência do design geral. Isso inclui a maneira como os componentes ou módulos são projetados.
	Capacidade de Manutenção	Capacidade do sistema de sofrer alterações com certa facilidade.
	Reutilização	Define a capacidade de componentes e subsistemas adequados para uso em outros aplicativos.
Qualidades de tempo de execução	Interoperabilidade	Capacidade de um sistema ou diferentes sistemas operarem com sucesso, comunicando e trocando informações com outros sistemas externos escritos e executados por terceiros.
	Gerenciabilidade	Define como é fácil para os administradores do sistema gerenciarem o aplicativo.
	Confiabilidade	Capacidade de um sistema permanecer operacional ao longo do tempo.
	Escalabilidade	Capacidade de um sistema de lidar com o aumento de carga sem afetar o desempenho do sistema ou a capacidade de ser prontamente ampliado.
	Segurança	Capacidade de um sistema de evitar ações maliciosas ou acidentais fora dos usos projetados.
	atuação	Indicação da capacidade de resposta de um sistema para executar qualquer ação em um determinado intervalo de tempo.
	Disponibilidade	Define a proporção de tempo em que o sistema está funcional e funcionando. Ele pode ser medido como uma porcentagem do tempo total de inatividade do sistema em um período predefinido.
Qualidades do sistema	Suportabilidade	Capacidade do sistema de fornecer informações úteis para identificar e resolver problemas quando ele não funciona corretamente.
	Testabilidade	Medida de como é fácil criar critérios de teste para o sistema e seus componentes.
Qualidades do usuário	Usabilidade	Define o quão bem o aplicativo atende aos requisitos do usuário e consumidor por ser intuitivo.
Qualidade da Arquitetura	Exatidão	Responsabilidade por satisfazer todos os requisitos do sistema.
Qualidade fora do tempo de execução	Portabilidade	Capacidade do sistema de funcionar em diferentes ambientes de computação.
	Integralidade	Capacidade de fazer componentes desenvolvidos separadamente do sistema funcionarem corretamente juntos.
	Modificabilidade	Facilidade com que cada sistema de software pode acomodar alterações em seu software.
Atributos de qualidade de negócios	Custo e cronograma	Custo do sistema em relação ao tempo de lançamento no mercado, vida útil esperada do projeto e utilização do legado.
	Marketability	Uso do sistema com relação à competição de mercado.

A arquitetura de software é descrita como a organização de um sistema, onde o sistema representa um conjunto de componentes que realizam as funções definidas.

Estilo arquitetônico

o architectural style, também chamado de architectural pattern, é um conjunto de princípios que moldam um aplicativo. Ele define uma estrutura abstrata para uma família de sistema em termos do padrão de organização estrutural.

O estilo arquitetônico é responsável por -

• Fornece um léxico de componentes e conectores com regras sobre como eles podem ser combinados.

• Melhore o particionamento e permita a reutilização do design, fornecendo soluções para problemas que ocorrem com frequência.

• Descreva uma maneira particular de configurar uma coleção de componentes (um módulo com interfaces bem definidas, reutilizáveis ​​e substituíveis) e conectores (link de comunicação entre módulos).

O software que é construído para sistemas baseados em computador exibe um dos muitos estilos arquitetônicos. Cada estilo descreve uma categoria de sistema que abrange -

• Um conjunto de tipos de componentes que executam uma função exigida pelo sistema.

• Um conjunto de conectores (chamada de sub-rotina, chamada de procedimento remoto, fluxo de dados e soquete) que permite a comunicação, coordenação e cooperação entre diferentes componentes.

• Restrições semânticas que definem como os componentes podem ser integrados para formar o sistema.

• Um layout topológico dos componentes, indicando seus inter-relacionamentos em tempo de execução.

Projeto Arquitetônico Comum

A tabela a seguir lista os estilos arquitetônicos que podem ser organizados por sua área de foco principal -

Categoria	Projeto arquitetônico	Descrição
Comunicação	Bus de mensagens	Prescreve o uso de um sistema de software que pode receber e enviar mensagens usando um ou mais canais de comunicação.
	Arquitetura Orientada a Serviços (SOA)	Define os aplicativos que expõem e consomem funcionalidade como um serviço usando contratos e mensagens.
Desdobramento, desenvolvimento	Servidor cliente	Separe o sistema em dois aplicativos, onde o cliente faz solicitações ao servidor.
	3-tier ou N-tier	Separa a funcionalidade em segmentos separados, com cada segmento sendo uma camada localizada em um computador fisicamente separado.
Domínio	Design Orientado por Domínio	Focado na modelagem de um domínio de negócios e definição de objetos de negócios com base em entidades dentro do domínio de negócios.
Estrutura	Com base em componente	Divida o design do aplicativo em componentes funcionais ou lógicos reutilizáveis ​​que expõem interfaces de comunicação bem definidas.
	Em camadas	Divida as preocupações do aplicativo em grupos empilhados (camadas).
	Orientado a Objeto	Com base na divisão de responsabilidades de um aplicativo ou sistema em objetos, cada um contendo os dados e o comportamento relevante para o objeto.

Tipos de Arquitetura

Existem quatro tipos de arquitetura do ponto de vista de uma empresa e, coletivamente, essas arquiteturas são referidas como enterprise architecture.

• Business architecture - Define a estratégia de negócios, governança, organização e processos-chave de negócios em uma empresa e se concentra na análise e design de processos de negócios.

• Application (software) architecture - Serve como o modelo para sistemas de aplicativos individuais, suas interações e seus relacionamentos com os processos de negócios da organização.

• Information architecture - Define os ativos de dados lógicos e físicos e os recursos de gerenciamento de dados.

• Information technology (IT) architecture - Define os blocos de construção de hardware e software que constituem o sistema de informações geral da organização.

Processo de Design de Arquitetura

O processo de design de arquitetura concentra-se na decomposição de um sistema em diferentes componentes e suas interações para satisfazer requisitos funcionais e não funcionais. As principais entradas para o design de arquitetura de software são -

• Os requisitos produzidos pelas tarefas de análise.

• A arquitetura de hardware (o arquiteto de software, por sua vez, fornece requisitos para o arquiteto de sistema, que configura a arquitetura de hardware).

O resultado ou saída do processo de design de arquitetura é um architectural description. O processo básico de design de arquitetura é composto das seguintes etapas -

Entenda o problema

• Esta é a etapa mais importante porque afeta a qualidade do design que se segue.

• Sem uma compreensão clara do problema, não é possível criar uma solução eficaz.

• Muitos projetos e produtos de software são considerados falhas porque não resolveram realmente um problema de negócios válido ou tiveram um retorno sobre o investimento (ROI) reconhecível.

Identifique os elementos de design e seus relacionamentos

• Nesta fase, construa uma linha de base para definir os limites e o contexto do sistema.

• Decomposição do sistema em seus componentes principais com base nos requisitos funcionais. A decomposição pode ser modelada usando uma matriz de estrutura de design (DSM), que mostra as dependências entre os elementos de design sem especificar a granularidade dos elementos.

• Nesta etapa, a primeira validação da arquitetura é feita descrevendo uma série de instâncias do sistema e esta etapa é referida como projeto de arquitetura baseado em funcionalidade.

Avalie o projeto de arquitetura

• Cada atributo de qualidade recebe uma estimativa, de modo que, para reunir medidas qualitativas ou dados quantitativos, o projeto é avaliado.

• Envolve a avaliação da arquitetura quanto à conformidade com os requisitos de atributos de qualidade da arquitetura.

• Se todos os atributos de qualidade estimados estiverem de acordo com o padrão exigido, o processo de projeto arquitetônico estará concluído.

• Caso contrário, a terceira fase do projeto de arquitetura de software é inserida: transformação da arquitetura. Se o atributo de qualidade observado não atender aos seus requisitos, um novo design deve ser criado.

Transforme o projeto de arquitetura

• Esta etapa é realizada após uma avaliação do projeto arquitetônico. O projeto arquitetônico deve ser alterado até que satisfaça completamente os requisitos de atributo de qualidade.

• Preocupa-se em selecionar soluções de design para melhorar os atributos de qualidade, preservando a funcionalidade do domínio.

• Um design é transformado pela aplicação de operadores, estilos ou padrões de design. Para transformação, pegue o design existente e aplique o operador de design, como decomposição, replicação, compactação, abstração e compartilhamento de recursos.

• O design é avaliado novamente e o mesmo processo é repetido várias vezes, se necessário, e até mesmo executado recursivamente.

• As transformações (ou seja, soluções de otimização de atributos de qualidade) geralmente melhoram um ou alguns atributos de qualidade, enquanto afetam outros negativamente

Princípios Chave de Arquitetura

A seguir estão os princípios-chave a serem considerados ao projetar uma arquitetura -

Construir para mudar em vez de construir para durar

Considere como o aplicativo pode precisar mudar ao longo do tempo para lidar com novos requisitos e desafios e construir a flexibilidade para oferecer suporte a isso.

Reduza o risco e modelo para analisar

Use ferramentas de design, visualizações, sistemas de modelagem como UML para capturar requisitos e decisões de design. Os impactos também podem ser analisados. Não formalize o modelo a ponto de suprimir a capacidade de iterar e adaptar o design facilmente.

Use modelos e visualizações como uma ferramenta de comunicação e colaboração

A comunicação eficiente do design, das decisões e das mudanças contínuas no design é crítica para uma boa arquitetura. Use modelos, visualizações e outras visualizações da arquitetura para comunicar e compartilhar o design de forma eficiente com todas as partes interessadas. Isso permite a comunicação rápida de alterações no design.

Identifique e compreenda as principais decisões de engenharia e áreas onde os erros são cometidos com mais frequência. Invista em tomar decisões importantes da primeira vez para tornar o design mais flexível e com menos probabilidade de ser interrompido por mudanças.

Use uma abordagem incremental e iterativa

Comece com a arquitetura de linha de base e, em seguida, desenvolva as arquiteturas candidatas por meio de testes iterativos para melhorar a arquitetura. Adicione iterativamente detalhes ao design em vários passes para obter a imagem grande ou certa e, em seguida, concentre-se nos detalhes.

Princípios Chave de Design

A seguir estão os princípios de design a serem considerados para minimizar custos, requisitos de manutenção e maximizar extensibilidade e usabilidade da arquitetura -

Separação de preocupações

Divida os componentes do sistema em recursos específicos para que não haja sobreposição entre as funcionalidades dos componentes. Isso fornecerá alta coesão e baixo acoplamento. Esta abordagem evita a interdependência entre os componentes do sistema, o que ajuda a manter o sistema fácil.

Princípio de Responsabilidade Única

Cada módulo de um sistema deve ter uma responsabilidade específica, o que ajuda o usuário a compreender claramente o sistema. Também deve ajudar na integração do componente com outros componentes.

Princípio do mínimo conhecimento

Qualquer componente ou objeto não deve ter conhecimento sobre os detalhes internos de outros componentes. Essa abordagem evita a interdependência e ajuda na manutenção.

Minimize grande design inicial

Minimize o design grande antecipadamente se os requisitos de um aplicativo não forem claros. Se houver a possibilidade de modificar os requisitos, evite fazer um design grande para todo o sistema.

Não repita a funcionalidade

Não repetir a funcionalidade especifica que a funcionalidade dos componentes não deve ser repetida e, portanto, uma parte do código deve ser implementada em apenas um componente. A duplicação da funcionalidade em um aplicativo pode dificultar a implementação de alterações, diminuir a clareza e introduzir possíveis inconsistências.

Prefira composição em vez de herança ao reutilizar a funcionalidade

A herança cria dependência entre as classes filhas e pais e, portanto, bloqueia o uso gratuito das classes filhas. Em contraste, a composição fornece um grande nível de liberdade e reduz as hierarquias de herança.

Identificar componentes e agrupá-los em camadas lógicas

Componentes de identidade e a área de preocupação que são necessários no sistema para satisfazer os requisitos. Em seguida, agrupe esses componentes relacionados em uma camada lógica, o que ajudará o usuário a entender a estrutura do sistema em um alto nível. Evite misturar componentes de diferentes tipos de interesses na mesma camada.

Defina o protocolo de comunicação entre as camadas

Entenda como os componentes se comunicarão entre si, o que requer um conhecimento completo dos cenários de implantação e do ambiente de produção.

Definir formato de dados para uma camada

Vários componentes irão interagir entre si por meio do formato de dados. Não misture os formatos de dados para que os aplicativos sejam fáceis de implementar, estender e manter. Tente manter o mesmo formato de dados para uma camada, de modo que vários componentes não precisem codificar / decodificar os dados enquanto se comunicam uns com os outros. Ele reduz a sobrecarga de processamento.

Os componentes do serviço do sistema devem ser abstratos

O código relacionado à segurança, comunicações ou serviços do sistema, como registro, criação de perfil e configuração, deve ser abstraído em componentes separados. Não misture esse código com a lógica de negócios, pois é fácil estender o design e mantê-lo.

Projetar exceções e mecanismo de tratamento de exceções

Definir exceções com antecedência, ajuda os componentes a gerenciar erros ou situações indesejadas de maneira elegante. O gerenciamento de exceções será o mesmo em todo o sistema.

Convenções de Nomenclatura

As convenções de nomenclatura devem ser definidas com antecedência. Eles fornecem um modelo consistente que ajuda os usuários a entender o sistema facilmente. É mais fácil para os membros da equipe validar o código escrito por outros e, portanto, aumentará a capacidade de manutenção.

A arquitetura de software envolve a estrutura de alto nível de abstração do sistema de software, por meio de decomposição e composição, com estilo arquitetônico e atributos de qualidade. Um projeto de arquitetura de software deve estar em conformidade com os principais requisitos de funcionalidade e desempenho do sistema, bem como satisfazer os requisitos não funcionais, como confiabilidade, escalabilidade, portabilidade e disponibilidade.

Uma arquitetura de software deve descrever seu grupo de componentes, suas conexões, interações entre eles e a configuração de implantação de todos os componentes.

Uma arquitetura de software pode ser definida de várias maneiras -

• UML (Unified Modeling Language) - UML é uma das soluções orientadas a objetos usadas na modelagem e design de software.

• Architecture View Model (4+1 view model) - O modelo de visualização da arquitetura representa os requisitos funcionais e não funcionais do aplicativo de software.

• ADL (Architecture Description Language) - ADL define a arquitetura do software formal e semanticamente.

UML

UML significa Unified Modeling Language. É uma linguagem pictórica usada para fazer projetos de software. A UML foi criada pelo Object Management Group (OMG). O rascunho da especificação UML 1.0 foi proposto ao OMG em janeiro de 1997. Ele serve como um padrão para a análise de requisitos de software e documentos de design que são a base para o desenvolvimento de um software.

UML pode ser descrita como uma linguagem de modelagem visual de propósito geral para visualizar, especificar, construir e documentar um sistema de software. Embora a UML seja geralmente usada para modelar o sistema de software, ela não é limitada dentro desse limite. Ele também é usado para modelar sistemas que não são de software, como fluxos de processo em uma unidade de manufatura.

Os elementos são como componentes que podem ser associados de diferentes maneiras para formar uma imagem UML completa, que é conhecida como diagram. Portanto, é muito importante entender os diferentes diagramas para implementar o conhecimento em sistemas da vida real. Temos duas grandes categorias de diagramas e eles são divididos em subcategorias, ou seja,Structural Diagrams e Behavioral Diagrams.

Diagramas Estruturais

Os diagramas estruturais representam os aspectos estáticos de um sistema. Esses aspectos estáticos representam as partes de um diagrama que formam a estrutura principal e, portanto, é estável.

Essas partes estáticas são representadas por classes, interfaces, objetos, componentes e nós. Os diagramas estruturais podem ser subdivididos da seguinte forma -

• Diagrama de classes
• Diagrama de objeto
• Diagrama de componentes
• Diagrama de implantação
• Diagrama de pacote
• Estrutura composta

A tabela a seguir fornece uma breve descrição desses diagramas -

Sr. Não.	Diagrama e Descrição
1	Class Representa a orientação do objeto de um sistema. Mostra como as classes estão estaticamente relacionadas.
2	Object Representa um conjunto de objetos e seus relacionamentos em tempo de execução e também representa a visão estática do sistema.
3	Component Descreve todos os componentes, seu inter-relacionamento, interações e interface do sistema.
4	Composite structure Descreve a estrutura interna do componente, incluindo todas as classes, interfaces do componente, etc.
5	Package Descreve a estrutura e organização do pacote. Abrange classes no pacote e pacotes dentro de outro pacote.
6	Deployment Os diagramas de implantação são um conjunto de nós e seus relacionamentos. Esses nós são entidades físicas onde os componentes são implantados.

Diagramas Comportamentais

Os diagramas comportamentais basicamente capturam o aspecto dinâmico de um sistema. Os aspectos dinâmicos são basicamente as partes mutáveis ​​/ móveis de um sistema. UML tem os seguintes tipos de diagramas comportamentais -

• Diagrama de casos de uso
• Diagrama de sequência
• Diagrama de comunicação
• Diagrama de gráfico de estado
• Diagrama de atividades
• Visão geral da interação
• Diagrama de seqüência de tempo

A tabela a seguir fornece uma breve descrição desses diagramas -

Sr. Não.	Diagrama e Descrição
1	Use case Descreve as relações entre as funcionalidades e seus controladores internos / externos. Esses controladores são conhecidos como atores.
2	Activity Descreve o fluxo de controle em um sistema. Consiste em atividades e links. O fluxo pode ser sequencial, simultâneo ou ramificado.
3	State Machine/state chart Representa a mudança de estado impulsionada por eventos de um sistema. Basicamente, descreve a mudança de estado de uma classe, interface, etc. Usado para visualizar a reação de um sistema por fatores internos / externos.
4	Sequence Visualiza a sequência de chamadas em um sistema para executar uma funcionalidade específica.
5	Interaction Overview Combina diagramas de atividade e sequência para fornecer uma visão geral do fluxo de controle do sistema e do processo de negócios.
6	Communication O mesmo que o diagrama de seqüência, exceto que ele se concentra na função do objeto. Cada comunicação está associada a uma ordem de sequência, número mais as mensagens anteriores.
7	Time Sequenced Descreve as mudanças por mensagens de estado, condição e eventos.

Modelo de vista de arquitetura

Um modelo é uma descrição completa, básica e simplificada da arquitetura de software, composta de várias visualizações de uma perspectiva ou ponto de vista específico.

Uma visão é uma representação de um sistema inteiro da perspectiva de um conjunto relacionado de interesses. É usado para descrever o sistema do ponto de vista de diferentes partes interessadas, como usuários finais, desenvolvedores, gerentes de projeto e testadores.

4 + 1 modelo de visualização

O Modelo de Visualização 4 + 1 foi projetado por Philippe Kruchten para descrever a arquitetura de um sistema intensivo de software baseado no uso de visualizações múltiplas e simultâneas. É ummultiple viewmodelo que aborda diferentes recursos e preocupações do sistema. Ele padroniza os documentos de design do software e torna o design fácil de entender por todas as partes interessadas.

É um método de verificação de arquitetura para estudar e documentar o projeto de arquitetura de software e cobre todos os aspectos da arquitetura de software para todos os envolvidos. Ele fornece quatro visualizações essenciais -

• The logical view or conceptual view - Descreve o modelo de objeto do projeto.

• The process view - Descreve as atividades do sistema, captura os aspectos de simultaneidade e sincronização do projeto.

• The physical view - Descreve o mapeamento do software no hardware e reflete seu aspecto distribuído.

• The development view - Descreve a organização ou estrutura estática do software em seu ambiente de desenvolvimento.

Este modelo de visão pode ser estendido adicionando mais uma visão chamada scenario view ou use case viewpara usuários finais ou clientes de sistemas de software. É coerente com outras quatro visualizações e são utilizadas para ilustrar a arquitetura servindo como visualização “mais um”, (4 + 1) modelo de visualização. A figura a seguir descreve a arquitetura do software usando o modelo de cinco visualizações simultâneas (4 + 1).

Por que é chamado de 4 + 1 em vez de 5?

o use case viewtem um significado especial, pois detalha os requisitos de alto nível de um sistema, enquanto outras visualizações detalham - como esses requisitos são realizados. Quando todas as outras quatro visualizações são concluídas, é efetivamente redundante. No entanto, todas as outras visualizações não seriam possíveis sem ele. A imagem e a tabela a seguir mostram a visualização 4 + 1 em detalhes -

	Lógico	Processo	Desenvolvimento	Fisica	Cenário
Descrição	Mostra o componente (Objeto) do sistema, bem como sua interação	Mostra os processos / regras de fluxo de trabalho do sistema e como esses processos se comunicam, com foco na visão dinâmica do sistema	Dá vistas de blocos de construção do sistema e descreve a organização estática dos módulos do sistema	Mostra a instalação, configuração e implantação do aplicativo de software	Mostra que o design está completo por meio de validação e ilustração
Visualizador / titular da aposta	Usuário final, analistas e designer	Integradores e desenvolvedores	Programador e gerentes de projeto de software	Engenheiro de sistema, operadores, administradores de sistema e instaladores de sistema	Todas as visões de seus pontos de vista e avaliadores
Considerar	Requisitos funcionais	Requisitos não Funcionais	Organização do módulo de software (reutilização de gerenciamento de software, restrição de ferramentas)	Requisito não funcional em relação ao hardware subjacente	Consistência e validade do sistema
UML - Diagrama	Classe, estado, objeto, sequência, diagrama de comunicação	Diagrama de atividades	Componente, diagrama de pacote	Diagrama de implantação	Diagrama de casos de uso

Linguagens de descrição de arquitetura (ADLs)

Um ADL é uma linguagem que fornece sintaxe e semântica para definir uma arquitetura de software. É uma especificação de notação que fornece recursos para modelar a arquitetura conceitual de um sistema de software, diferenciada da implementação do sistema.

Os ADLs devem oferecer suporte aos componentes da arquitetura, suas conexões, interfaces e configurações que são o bloco de construção da descrição da arquitetura. É uma forma de expressão para uso em descrições de arquitetura e fornece a capacidade de decompor componentes, combinar os componentes e definir as interfaces dos componentes.

Uma linguagem de descrição de arquitetura é uma linguagem de especificação formal, que descreve os recursos do software, como processos, threads, dados e subprogramas, bem como componentes de hardware, como processadores, dispositivos, barramentos e memória.

É difícil classificar ou diferenciar uma ADL e uma linguagem de programação ou linguagem de modelagem. No entanto, existem os seguintes requisitos para que um idioma seja classificado como ADL -

• Deve ser apropriado para comunicar a arquitetura a todas as partes interessadas.

• Deve ser adequado para tarefas de criação, refinamento e validação de arquitetura.

• Ele deve fornecer uma base para implementação adicional, portanto, deve ser capaz de adicionar informações à especificação ADL para permitir que a especificação final do sistema seja derivada da ADL.

• Deve ter a capacidade de representar a maioria dos estilos arquitetônicos comuns.

• Deve oferecer suporte a recursos analíticos ou fornecer implementações de protótipo de geração rápida.

O paradigma orientado a objetos (OO) tomou sua forma a partir do conceito inicial de uma nova abordagem de programação, enquanto o interesse em métodos de design e análise veio muito mais tarde. O paradigma de análise e design OO é o resultado lógico da ampla adoção de linguagens de programação OO.

• A primeira linguagem orientada a objetos foi Simula (Simulação de sistemas reais) que foi desenvolvido em 1960 por pesquisadores do Norwegian Computing Center.

• Em 1970, Alan Kay e seu grupo de pesquisa na Xerox PARC criou um computador pessoal chamado Dynabook e a primeira linguagem de programação orientada a objetos (OOPL) - Smalltalk, para programar o Dynabook.

• Nos anos 1980, Grady Boochpublicou um artigo intitulado Object Oriented Design que apresentou principalmente um design para a linguagem de programação, Ada. Nas edições seguintes, ele estendeu suas idéias para um método completo de design orientado a objetos.

• Na década de 1990, Coad incorporou idéias comportamentais aos métodos orientados a objetos.

As outras inovações significativas foram Object Modeling Techniques (OMT) por James Rum Baugh e Engenharia de Software Orientada a Objetos (OOSE) por Ivar Jacobson.

Introdução ao Paradigma OO

O paradigma OO é uma metodologia significativa para o desenvolvimento de qualquer software. A maioria dos estilos ou padrões de arquitetura, como tubo e filtro, repositório de dados e baseado em componente, podem ser implementados usando este paradigma.

Conceitos básicos e terminologias de sistemas orientados a objetos -

Objeto

Um objeto é um elemento do mundo real em um ambiente orientado a objetos que pode ter uma existência física ou conceitual. Cada objeto tem -

• Identidade que o distingue de outros objetos no sistema.

• Estado que determina as propriedades características de um objeto, bem como os valores das propriedades que o objeto contém.

• Comportamento que representa atividades externamente visíveis realizadas por um objeto em termos de mudanças em seu estado.

Os objetos podem ser modelados de acordo com as necessidades da aplicação. Um objeto pode ter uma existência física, como um cliente, um carro, etc .; ou uma existência conceitual intangível, como um projeto, um processo, etc.

Classe

Uma classe representa uma coleção de objetos com as mesmas propriedades características que exibem um comportamento comum. Ele fornece o blueprint ou a descrição dos objetos que podem ser criados a partir dele. A criação de um objeto como membro de uma classe é chamada de instanciação. Assim, um objeto é uminstance de uma classe.

Os constituintes de uma classe são -

• Um conjunto de atributos para os objetos que devem ser instanciados da classe. Geralmente, diferentes objetos de uma classe têm alguma diferença nos valores dos atributos. Os atributos geralmente são chamados de dados de classe.

• Um conjunto de operações que retratam o comportamento dos objetos da classe. As operações também são chamadas de funções ou métodos.

Example

Vamos considerar uma classe simples, Circle, que representa o círculo da figura geométrica em um espaço bidimensional. Os atributos desta classe podem ser identificados da seguinte forma -

• x – coord, para denotar a coordenada x do centro
• coord y, para denotar a coordenada y do centro
• a, para denotar o raio do círculo

Algumas de suas operações podem ser definidas da seguinte forma -

• findArea (), um método para calcular a área
• findCircumference (), um método para calcular a circunferência
• scale (), um método para aumentar ou diminuir o raio

Encapsulamento

Encapsulamento é o processo de vincular atributos e métodos dentro de uma classe. Por meio do encapsulamento, os detalhes internos de uma classe podem ser ocultados de fora. Ele permite que os elementos da classe sejam acessados ​​de fora apenas por meio da interface fornecida pela classe.

Polimorfismo

Polimorfismo é originalmente uma palavra grega que significa a capacidade de assumir várias formas. No paradigma orientado a objetos, o polimorfismo implica o uso de operações de maneiras diferentes, dependendo das instâncias nas quais estão operando. O polimorfismo permite que objetos com diferentes estruturas internas tenham uma interface externa comum. O polimorfismo é particularmente eficaz ao implementar a herança.

Example

Vamos considerar duas classes, Circle e Square, cada uma com um método findArea (). Embora o nome e a finalidade dos métodos nas classes sejam os mesmos, a implementação interna, ou seja, o procedimento de cálculo de uma área é diferente para cada classe. Quando um objeto da classe Circle invoca seu método findArea (), a operação encontra a área do círculo sem nenhum conflito com o método findArea () da classe Square.

Relationships

Para descrever um sistema, tanto a especificação dinâmica (comportamental) quanto a estática (lógica) de um sistema devem ser fornecidas. A especificação dinâmica descreve os relacionamentos entre objetos, por exemplo, passagem de mensagens. E a especificação estática descreve os relacionamentos entre as classes, por exemplo, agregação, associação e herança.

Passagem de mensagens

Qualquer aplicação requer uma série de objetos interagindo de maneira harmoniosa. Os objetos em um sistema podem se comunicar uns com os outros usando a passagem de mensagens. Suponha que um sistema tenha dois objetos - obj1 e obj2. O objeto obj1 envia uma mensagem ao objeto obj2, se obj1 deseja que obj2 execute um de seus métodos.

Composição ou Agregação

Agregação ou composição é um relacionamento entre classes pelo qual uma classe pode ser composta de qualquer combinação de objetos de outras classes. Ele permite que os objetos sejam colocados diretamente no corpo de outras classes. A agregação é referida como um relacionamento “parte de” ou “tem um”, com a capacidade de navegar do todo para suas partes. Um objeto agregado é um objeto composto por um ou mais outros objetos.

Associação

Associação é um grupo de links com estrutura e comportamento comuns. A associação representa o relacionamento entre objetos de uma ou mais classes. Um link pode ser definido como uma instância de uma associação. O grau de uma associação denota o número de classes envolvidas em uma conexão. O grau pode ser unário, binário ou ternário.

• Uma relação unária conecta objetos da mesma classe.
• Um relacionamento binário conecta objetos de duas classes.
• Um relacionamento ternário conecta objetos de três ou mais classes.

Herança

É um mecanismo que permite que novas classes sejam criadas a partir de classes existentes, estendendo e refinando seus recursos. As classes existentes são chamadas de classes base / classes pai / superclasses, e as novas classes são chamadas de classes derivadas / classes filho / subclasses.

A subclasse pode herdar ou derivar os atributos e métodos da (s) superclasse (s), desde que a superclasse assim o permita. Além disso, a subclasse pode adicionar seus próprios atributos e métodos e pode modificar qualquer um dos métodos da superclasse. Herança define um relacionamento “é um”.

Example

De uma classe Mamífero, várias classes podem ser derivadas, como Humano, Gato, Cão, Vaca, etc. Humanos, gatos, cães e vacas têm características distintas de mamíferos. Além disso, cada um tem suas características particulares. Pode-se dizer que uma vaca “é - um” mamífero.

Análise OO

Na fase de análise orientada a objetos do desenvolvimento de software, os requisitos do sistema são determinados, as classes são identificadas e os relacionamentos entre as classes são reconhecidos. O objetivo da análise OO é entender o domínio da aplicação e os requisitos específicos do sistema. O resultado desta fase é a especificação de requisitos e análise inicial da estrutura lógica e viabilidade de um sistema.

As três técnicas de análise usadas em conjunto para análise orientada a objetos são modelagem de objetos, modelagem dinâmica e modelagem funcional.

Modelagem de Objetos

A modelagem de objetos desenvolve a estrutura estática do sistema de software em termos de objetos. Ele identifica os objetos, as classes nas quais os objetos podem ser agrupados e os relacionamentos entre os objetos. Também identifica os principais atributos e operações que caracterizam cada classe.

O processo de modelagem de objetos pode ser visualizado nas seguintes etapas -

• Identificar objetos e agrupar em classes
• Identifique as relações entre as classes
• Crie um diagrama de modelo de objeto de usuário
• Definir atributos de objeto de usuário
• Defina as operações que devem ser realizadas nas aulas

Modelagem Dinâmica

Depois que o comportamento estático do sistema é analisado, seu comportamento em relação ao tempo e às mudanças externas precisa ser examinado. Este é o objetivo da modelagem dinâmica.

A Modelagem Dinâmica pode ser definida como "uma maneira de descrever como um objeto individual responde a eventos, sejam eventos internos acionados por outros objetos ou eventos externos acionados pelo mundo exterior."

O processo de modelagem dinâmica pode ser visualizado nas seguintes etapas -

• Identifique os estados de cada objeto
• Identificar eventos e analisar a aplicabilidade das ações
• Construir um diagrama de modelo dinâmico, composto por diagramas de transição de estado
• Expresse cada estado em termos de atributos de objeto
• Valide os diagramas de transição de estado desenhados

Modelagem Funcional

A modelagem funcional é o componente final da análise orientada a objetos. O modelo funcional mostra os processos que são executados dentro de um objeto e como os dados mudam, conforme se movem entre os métodos. Ele especifica o significado das operações de uma modelagem de objeto e as ações de uma modelagem dinâmica. O modelo funcional corresponde ao diagrama de fluxo de dados da análise estruturada tradicional.

O processo de modelagem funcional pode ser visualizado nas seguintes etapas -

• Identifique todas as entradas e saídas
• Construir diagramas de fluxo de dados mostrando dependências funcionais
• Indique o propósito de cada função
• Identifique as restrições
• Especifique os critérios de otimização

Design Orientado a Objetos

Após a fase de análise, o modelo conceitual é desenvolvido em um modelo orientado a objetos usando design orientado a objetos (OOD). No OOD, os conceitos independentes de tecnologia no modelo de análise são mapeados em classes de implementação, as restrições são identificadas e as interfaces são projetadas, resultando em um modelo para o domínio da solução. O objetivo principal do projeto OO é desenvolver a arquitetura estrutural de um sistema.

Os estágios do design orientado a objetos podem ser identificados como -

• Definindo o contexto do sistema
• Projetando a arquitetura do sistema
• Identificação dos objetos no sistema
• Construção de modelos de design
• Especificação de interfaces de objetos

O Projeto OO pode ser dividido em duas fases - Projeto Conceitual e Projeto Detalhado.

Conceptual design

Nesta etapa, são identificadas todas as classes necessárias para a construção do sistema. Além disso, responsabilidades específicas são atribuídas a cada classe. O diagrama de classes é usado para esclarecer os relacionamentos entre as classes e o diagrama de interação é usado para mostrar o fluxo de eventos. Também é conhecido comohigh-level design.

Detailed design

Neste estágio, atributos e operações são atribuídos a cada classe com base em seu diagrama de interação. O diagrama da máquina de estado é desenvolvido para descrever os detalhes adicionais do projeto. Também é conhecido comolow-level design.

Princípios de design

A seguir estão os principais princípios de design -

Principle of Decoupling

É difícil manter um sistema com um conjunto de classes altamente interdependentes, pois a modificação em uma classe pode resultar em atualizações em cascata de outras classes. Em um projeto OO, o acoplamento estreito pode ser eliminado pela introdução de novas classes ou herança.

Ensuring Cohesion

Uma classe coesa executa um conjunto de funções intimamente relacionadas. A falta de coesão significa - uma classe executa funções não relacionadas, embora não afete a operação de todo o sistema. Isso torna toda a estrutura do software difícil de gerenciar, expandir, manter e mudar.

Open-closed Principle

De acordo com este princípio, um sistema deve ser capaz de se estender para atender aos novos requisitos. A implementação existente e o código do sistema não devem ser modificados como resultado de uma expansão do sistema. Além disso, as seguintes diretrizes devem ser seguidas no princípio aberto-fechado -

• Para cada classe concreta, interfaces e implementações separadas devem ser mantidas.

• Em um ambiente multithread, mantenha os atributos privados.

• Minimize o uso de variáveis ​​globais e variáveis ​​de classe.

Na arquitetura de fluxo de dados, todo o sistema de software é visto como uma série de transformações em peças consecutivas ou conjunto de dados de entrada, onde os dados e as operações são independentes uns dos outros. Nesta abordagem, os dados entram no sistema e então fluem pelos módulos um por vez até que sejam atribuídos a algum destino final (saída ou armazenamento de dados).

As conexões entre os componentes ou módulos podem ser implementadas como fluxo de E / S, buffers de E / S, tubulações ou outros tipos de conexões. Os dados podem ser voados na topologia de grafo com ciclos, em uma estrutura linear sem ciclos, ou em uma estrutura do tipo árvore.

O principal objetivo desta abordagem é atingir as qualidades de reutilização e modificabilidade. É adequado para aplicativos que envolvem uma série bem definida de transformações de dados independentes ou cálculos em entradas e saídas definidas de maneira ordenada, como compiladores e aplicativos de processamento de dados de negócios. Existem três tipos de sequências de execução entre os módulos -

• Sequencial em lote
• Modo de tubulação e filtro ou pipeline não sequencial
• Controle do processo

Sequencial em lote

Sequencial em lote é um modelo clássico de processamento de dados, no qual um subsistema de transformação de dados pode iniciar seu processo somente após o subsistema anterior estar completamente concluído -

• O fluxo de dados transporta um lote de dados como um todo, de um subsistema para outro.

• As comunicações entre os módulos são realizadas através de arquivos intermediários temporários que podem ser removidos por subsistemas sucessivos.

• É aplicável para os aplicativos em que os dados são agrupados e cada subsistema lê arquivos de entrada relacionados e grava arquivos de saída.

• A aplicação típica dessa arquitetura inclui processamento de dados de negócios, como faturamento bancário e de serviços públicos.

Vantagens

• Fornece divisões mais simples em subsistemas.

• Cada subsistema pode ser um programa independente trabalhando em dados de entrada e produzindo dados de saída.

Desvantagens

• Fornece alta latência e baixa taxa de transferência.

• Não fornece simultaneidade e interface interativa.

• O controle externo é necessário para a implementação.

Arquitetura de tubulação e filtro

Essa abordagem enfatiza a transformação incremental de dados por componentes sucessivos. Nessa abordagem, o fluxo de dados é orientado por dados e todo o sistema é decomposto em componentes de fonte de dados, filtros, tubos e coletores de dados.

As conexões entre os módulos são fluxos de dados que são o buffer first-in / first-out que pode ser um fluxo de bytes, caracteres ou qualquer outro tipo desse tipo. A principal característica desta arquitetura é sua execução simultânea e incrementada.

Filtro

Um filtro é um transformador de fluxo de dados independente ou transdutores de fluxo. Ele transforma os dados do fluxo de dados de entrada, os processa e grava o fluxo de dados transformado em um tubo para o próximo filtro processar. Funciona em modo incremental, no qual começa a funcionar assim que os dados chegam pelo tubo conectado. Existem dois tipos de filtros -active filter e passive filter.

Active filter

O filtro ativo permite que os tubos conectados puxem dados e removam os dados transformados. Ele opera com tubo passivo, que fornece mecanismos de leitura / gravação para puxar e empurrar. Este modo é usado no canal UNIX e mecanismo de filtro.

Passive filter

O filtro passivo permite que os tubos conectados enviem e retirem dados. Ele opera com um canal ativo, que extrai dados de um filtro e envia dados para o próximo filtro. Deve fornecer mecanismo de leitura / gravação.

Vantagens

• Fornece simultaneidade e alto rendimento para processamento excessivo de dados.

• Oferece capacidade de reutilização e simplifica a manutenção do sistema.

• Fornece modificabilidade e baixo acoplamento entre filtros.

• Oferece simplicidade, oferecendo divisões claras entre quaisquer dois filtros conectados por tubo.

• Oferece flexibilidade ao suportar execução sequencial e paralela.

Desvantagens

• Não é adequado para interações dinâmicas.

• Um baixo denominador comum é necessário para a transmissão de dados em formatos ASCII.

• Sobrecarga da transformação de dados entre filtros.

• Não fornece uma maneira de os filtros interagirem de forma cooperativa para resolver um problema.

• É difícil configurar essa arquitetura dinamicamente.

Tubo

Pipes não têm estado e carregam fluxos binários ou de caracteres que existem entre dois filtros. Ele pode mover um fluxo de dados de um filtro para outro. Pipes usam pouca informação contextual e não retêm nenhuma informação de estado entre as instanciações.

Arquitetura de Controle de Processo

É um tipo de arquitetura de fluxo de dados em que os dados não são sequenciais em lote nem fluxo em pipeline. O fluxo de dados vem de um conjunto de variáveis, que controla a execução do processo. Ele decompõe todo o sistema em subsistemas ou módulos e os conecta.

Tipos de subsistemas

Uma arquitetura de controle de processo teria um processing unit para alterar as variáveis ​​de controle do processo e um controller unit para calcular a quantidade de alterações.

Uma unidade controladora deve ter os seguintes elementos -

• Controlled Variable- Variável controlada fornece valores para o sistema subjacente e deve ser medida por sensores. Por exemplo, velocidade no sistema de controle de cruzeiro.

• Input Variable- Mede uma entrada para o processo. Por exemplo, a temperatura do ar de retorno no sistema de controle de temperatura

• Manipulated Variable - O valor da variável manipulada é ajustado ou alterado pelo controlador.

• Process Definition - Inclui mecanismos para manipulação de algumas variáveis ​​de processo.

• Sensor - Obtém valores de variáveis ​​de processo pertinentes ao controle e pode ser usado como referência de feedback para recalcular variáveis ​​manipuladas.

• Set Point - É o valor desejado para uma variável controlada.

• Control Algorithm - É usado para decidir como manipular variáveis ​​de processo.

Áreas de aplicação

A arquitetura de controle de processo é adequada nos seguintes domínios -

• Projeto de software de sistema embutido, onde o sistema é manipulado por dados variáveis ​​de controle de processo.

• Aplicações, cujo objetivo é manter as propriedades especificadas das saídas do processo em determinados valores de referência.

• Aplicável para controle de cruzeiro de carro e sistemas de controle de temperatura de edifícios.

• Software de sistema em tempo real para controlar freios antibloqueio de automóveis, usinas nucleares, etc.

Na arquitetura centralizada em dados, os dados são centralizados e acessados ​​frequentemente por outros componentes, que modificam os dados. O objetivo principal deste estilo é atingir a integralidade dos dados. A arquitetura centrada em dados consiste em diferentes componentes que se comunicam por meio de repositórios de dados compartilhados. Os componentes acessam uma estrutura de dados compartilhada e são relativamente independentes, no sentido de que interagem apenas por meio do armazenamento de dados.

Os exemplos mais conhecidos de arquitetura centrada em dados são uma arquitetura de banco de dados, na qual o esquema de banco de dados comum é criado com protocolo de definição de dados - por exemplo, um conjunto de tabelas relacionadas com campos e tipos de dados em um RDBMS.

Outro exemplo de arquiteturas centradas em dados é a arquitetura web que tem um esquema de dados comum (isto é, meta-estrutura da web) e segue o modelo de dados hipermídia e os processos se comunicam por meio do uso de serviços de dados baseados na web compartilhados.

Tipos de Componentes

Existem dois tipos de componentes -

• UMA central dataestrutura ou armazenamento de dados ou repositório de dados, que é responsável por fornecer armazenamento de dados permanente. Ele representa o estado atual.

• UMA data accessor ou uma coleção de componentes independentes que operam no armazenamento central de dados, realizam cálculos e podem colocar de volta os resultados.

As interações ou comunicação entre os acessadores de dados são apenas por meio do armazenamento de dados. Os dados são o único meio de comunicação entre os clientes. O fluxo de controle diferencia a arquitetura em duas categorias -

• Estilo de Arquitetura do Repositório
• Estilo de Arquitetura do Blackboard

Estilo de Arquitetura do Repositório

No estilo de arquitetura de repositório, o armazenamento de dados é passivo e os clientes (componentes de software ou agentes) do armazenamento de dados são ativos, que controlam o fluxo lógico. Os componentes participantes verificam se há alterações no armazenamento de dados.

• O cliente envia uma solicitação ao sistema para realizar ações (por exemplo, inserir dados).

• Os processos computacionais são independentes e acionados por solicitações de entrada.

• Se os tipos de transações em um fluxo de entrada de transações acionam a seleção de processos a serem executados, então é um banco de dados tradicional ou arquitetura de repositório, ou repositório passivo.

• Esta abordagem é amplamente utilizada em SGBD, sistema de informação de biblioteca, repositório de interface em ambientes CORBA, compiladores e CASE (computer aided software engineering).

Vantagens

• Fornece recursos de integridade de dados, backup e restauração.

• Fornece escalabilidade e reutilização de agentes, pois eles não têm comunicação direta entre si.

• Reduz a sobrecarga de dados transitórios entre componentes de software.

Desvantagens

• É mais vulnerável a falhas e a replicação ou duplicação de dados é possível.

• Alta dependência entre a estrutura de dados do armazenamento de dados e seus agentes.

• Mudanças na estrutura de dados afetam fortemente os clientes.

• A evolução dos dados é difícil e cara.

• Custo de mover dados na rede para dados distribuídos.

Estilo de Arquitetura do Blackboard

No estilo Blackboard Architecture, o armazenamento de dados é ativo e seus clientes são passivos. Portanto, o fluxo lógico é determinado pelo status de dados atual no armazenamento de dados. Possui um componente de quadro negro, atuando como um repositório central de dados, e uma representação interna é construída e acionada por diferentes elementos computacionais.

• Vários componentes que agem independentemente na estrutura de dados comum são armazenados no quadro negro.

• Nesse estilo, os componentes interagem apenas por meio do quadro negro. O armazenamento de dados alerta os clientes sempre que houver uma mudança no armazenamento de dados.

• O estado atual da solução é armazenado no quadro negro e o processamento é acionado pelo estado do quadro negro.

• O sistema envia notificações conhecidas como trigger e dados para os clientes quando ocorrerem alterações nos dados.

• Esta abordagem é encontrada em certos aplicativos de IA e aplicativos complexos, como reconhecimento de voz, reconhecimento de imagem, sistema de segurança e sistemas de gerenciamento de recursos de negócios, etc.

• Se o estado atual da estrutura de dados central for o principal gatilho de seleção de processos a serem executados, o repositório pode ser um quadro-negro e essa fonte de dados compartilhada é um agente ativo.

• A principal diferença com os sistemas de banco de dados tradicionais é que a invocação de elementos computacionais em uma arquitetura de quadro negro é acionada pelo estado atual do quadro negro, e não por entradas externas.

Partes do modelo do quadro negro

O modelo do quadro-negro é geralmente apresentado com três partes principais -

Knowledge Sources (KS)

Fontes de conhecimento, também conhecidas como Listeners ou Subscriberssão unidades distintas e independentes. Eles resolvem partes de um problema e agregam resultados parciais. A interação entre as fontes de conhecimento ocorre exclusivamente por meio do quadro negro.

Blackboard Data Structure

Os dados do estado de solução de problemas são organizados em uma hierarquia dependente do aplicativo. As fontes de conhecimento fazem alterações no quadro negro que levam gradativamente a uma solução para o problema.

Control

O controle gerencia tarefas e verifica o estado de trabalho.

Vantagens

• Fornece escalabilidade que fornece fonte de conhecimento fácil de adicionar ou atualizar.

• Fornece simultaneidade que permite que todas as fontes de conhecimento trabalhem em paralelo, pois são independentes umas das outras.

• Suporta experimentação de hipóteses.

• Oferece suporte à reutilização de agentes de fonte de conhecimento.

Desvantagens

• A alteração da estrutura do quadro negro pode ter um impacto significativo em todos os seus agentes, visto que existe uma estreita dependência entre o quadro negro e a fonte de conhecimento.

• Pode ser difícil decidir quando encerrar o raciocínio, pois apenas uma solução aproximada é esperada.

• Problemas na sincronização de vários agentes.

• Principais desafios na concepção e teste do sistema.

A arquitetura hierárquica vê todo o sistema como uma estrutura hierárquica, na qual o sistema de software é decomposto em módulos ou subsistemas lógicos em diferentes níveis da hierarquia. Essa abordagem é normalmente usada no projeto de software de sistema, como protocolos de rede e sistemas operacionais.

No projeto de hierarquia de software do sistema, um subsistema de baixo nível fornece serviços para seus subsistemas de nível superior adjacentes, que invocam os métodos no nível inferior. A camada inferior fornece funcionalidades mais específicas, como serviços de E / S, transações, agendamento, serviços de segurança, etc. A camada intermediária fornece mais funções dependentes de domínio, como lógica de negócios e serviços de processamento de núcleo. E, a camada superior fornece mais funcionalidade abstrata na forma de interface do usuário, como GUIs, recursos de programação de shell, etc.

Também é usado na organização das bibliotecas de classes, como a biblioteca de classes .NET na hierarquia de namespace. Todos os tipos de design podem implementar essa arquitetura hierárquica e, muitas vezes, combinar com outros estilos de arquitetura.

Os estilos arquitetônicos hierárquicos são divididos como -

• Main-subroutine
• Master-slave
• Máquina virtual

Sub-rotina principal

O objetivo deste estilo é reutilizar os módulos e desenvolver livremente módulos individuais ou sub-rotinas. Nesse estilo, um sistema de software é dividido em sub-rotinas usando refinamento de cima para baixo de acordo com a funcionalidade desejada do sistema.

Esses refinamentos conduzem verticalmente até que os módulos decompostos sejam simples o suficiente para ter sua responsabilidade independente e exclusiva. A funcionalidade pode ser reutilizada e compartilhada por vários chamadores nas camadas superiores.

Existem duas maneiras pelas quais os dados são passados ​​como parâmetros para sub-rotinas, a saber -

• Pass by Value - As sub-rotinas usam apenas os dados anteriores, mas não podem modificá-los.

• Pass by Reference - As sub-rotinas usam bem como alteram o valor dos dados referenciados pelo parâmetro.

Vantagens

• Fácil de decompor o sistema com base no refinamento da hierarquia.

• Pode ser usado em um subsistema de design orientado a objetos.

Desvantagens

• Vulnerável, pois contém dados compartilhados globalmente.

• O forte acoplamento pode causar mais efeitos em cascata de mudanças.

Senhor de escravos

Esta abordagem aplica o princípio de 'dividir para conquistar' e oferece suporte à computação de falhas e precisão computacional. É uma modificação da arquitetura da sub-rotina principal que fornece confiabilidade do sistema e tolerância a falhas.

Nesta arquitetura, os escravos fornecem serviços duplicados ao mestre, e o mestre escolhe um resultado particular entre os escravos por uma certa estratégia de seleção. Os escravos podem realizar a mesma tarefa funcional por diferentes algoritmos e métodos ou funcionalidade totalmente diferente. Inclui computação paralela na qual todos os escravos podem ser executados em paralelo.

A implementação do padrão Master-Slave segue cinco etapas -

• Especifique como o cálculo da tarefa pode ser dividido em um conjunto de subtarefas iguais e identifique os sub-serviços que são necessários para processar uma subtarefa.

• Especifique como o resultado final de todo o serviço pode ser calculado com a ajuda dos resultados obtidos no processamento de subtarefas individuais.

• Defina uma interface para o sub-serviço identificado na etapa 1. Ela será implementada pelo escravo e usada pelo mestre para delegar o processamento de subtarefas individuais.

• Implemente os componentes escravos de acordo com as especificações desenvolvidas na etapa anterior.

• Implemente o mestre de acordo com as especificações desenvolvidas nas etapas 1 a 3.

Formulários

• Adequado para aplicações onde a confiabilidade do software é um problema crítico.

• Amplamente aplicado nas áreas de computação paralela e distribuída.

Vantagens

• Cálculo mais rápido e escalabilidade fácil.

• Oferece robustez, pois os escravos podem ser duplicados.

• O escravo pode ser implementado de maneira diferente para minimizar os erros semânticos.

Desvantagens

• Sobrecarga de comunicação.

• Nem todos os problemas podem ser divididos.

• Difícil de implementar e problema de portabilidade.

Arquitetura de Máquina Virtual

A arquitetura da Máquina Virtual finge alguma funcionalidade, que não é nativa do hardware e / ou software no qual é implementada. Uma máquina virtual é construída sobre um sistema existente e fornece uma abstração virtual, um conjunto de atributos e operações.

Na arquitetura da máquina virtual, o mestre usa o 'mesmo' subserviço 'do escravo e executa funções como dividir o trabalho, chamar escravos e combinar resultados. Ele permite que os desenvolvedores simulem e testem plataformas, que ainda não foram construídas, e simulem modos de "desastre" que seriam muito complexos, caros ou perigosos para testar com o sistema real.

Na maioria dos casos, uma máquina virtual divide uma linguagem de programação ou ambiente de aplicativo de uma plataforma de execução. O objetivo principal é fornecerportability. A interpretação de um módulo específico por meio de uma máquina virtual pode ser percebida como -

• O mecanismo de interpretação escolhe uma instrução do módulo que está sendo interpretado.

• Com base na instrução, o mecanismo atualiza o estado interno da máquina virtual e o processo acima é repetido.

A figura a seguir mostra a arquitetura de uma infraestrutura VM padrão em uma única máquina física.

o hypervisor, também chamado de virtual machine monitor, é executado no sistema operacional host e aloca recursos correspondentes para cada sistema operacional convidado. Quando o convidado faz uma chamada de sistema, o hipervisor a intercepta e traduz na chamada de sistema correspondente suportada pelo sistema operacional host. O hipervisor controla o acesso de cada máquina virtual à CPU, memória, armazenamento persistente, dispositivos de E / S e rede.

Formulários

A arquitetura da máquina virtual é adequada nos seguintes domínios -

• Adequado para resolver um problema por simulação ou tradução se não houver solução direta.

• Os aplicativos de amostra incluem intérpretes de microprogramação, processamento XML, execução de linguagem de comando de script, execução de sistema baseada em regras, Smalltalk e linguagem de programação digitada por interpretador Java.

• Exemplos comuns de máquinas virtuais são intérpretes, sistemas baseados em regras, shells sintáticos e processadores de linguagem de comando.

Vantagens

• Portabilidade e independência da plataforma da máquina.

• Simplicidade de desenvolvimento de software.

• Oferece flexibilidade por meio da capacidade de interromper e consultar o programa.

• Simulação para modelo de funcionamento de desastres.

• Introduzir modificações em tempo de execução.

Desvantagens

• Execução lenta do intérprete devido à natureza do intérprete.

• Há um custo de desempenho devido à computação adicional envolvida na execução.

Estilo em camadas

Nessa abordagem, o sistema é decomposto em várias camadas superiores e inferiores em uma hierarquia, e cada camada tem sua própria responsabilidade no sistema.

• Cada camada consiste em um grupo de classes relacionadas que são encapsuladas em um pacote, em um componente implantado ou como um grupo de sub-rotinas no formato de biblioteca de métodos ou arquivo de cabeçalho.

• Cada camada fornece serviço para a camada acima dela e atua como um cliente para a camada inferior, ou seja, a solicitação para a camada i +1 invoca os serviços fornecidos pela camada i através da interface da camada i. A resposta pode voltar para a camada i +1 se a tarefa for concluída; caso contrário, a camada i continuamente invoca serviços da camada i -1 abaixo.

Formulários

O estilo em camadas é adequado nas seguintes áreas -

• Aplicativos que envolvem classes distintas de serviços que podem ser organizados hierarquicamente.

• Qualquer aplicativo que pode ser decomposto em partes específicas do aplicativo e específicas da plataforma.

• Aplicativos que têm divisões claras entre serviços principais, serviços críticos e serviços de interface de usuário, etc.

Vantagens

• Projete com base em níveis incrementais de abstração.

• Fornece independência de aprimoramento, pois as alterações na função de uma camada afetam no máximo duas outras camadas.

• Separação da interface padrão e sua implementação.

• Implementado usando tecnologia baseada em componentes que torna o sistema muito mais fácil para permitir o plug-and-play de novos componentes.

• Cada camada pode ser uma máquina abstrata implantada de forma independente, que oferece suporte à portabilidade.

• Fácil de decompor o sistema com base na definição das tarefas de uma maneira de refinamento de cima para baixo

• Diferentes implementações (com interfaces idênticas) da mesma camada podem ser usadas indistintamente

Desvantagens

• Muitos aplicativos ou sistemas não são facilmente estruturados em camadas.

• Baixo desempenho de tempo de execução, pois uma solicitação do cliente ou uma resposta ao cliente deve passar por várias camadas.

• Também há preocupações de desempenho na sobrecarga no empacotamento e armazenamento de dados em buffer por cada camada.

• A abertura da comunicação entre camadas pode causar bloqueios e a “ponte” pode causar um acoplamento rígido.

• Exceções e tratamento de erros são um problema na arquitetura em camadas, uma vez que as falhas em uma camada devem se espalhar para cima, para todas as camadas de chamada

O objetivo principal da arquitetura orientada à interação é separar a interação do usuário da abstração de dados e do processamento de dados de negócios. A arquitetura de software orientada à interação decompõe o sistema em três partições principais -

• Data module - Módulo de dados fornece a abstração de dados e toda a lógica de negócios.

• Control module - Módulo de controle identifica o fluxo de ações de controle e configuração do sistema.

• View presentation module - O módulo de visualização de apresentação é responsável pela apresentação visual ou de áudio da saída de dados e também fornece uma interface para entrada do usuário.

A arquitetura orientada para a interação tem dois estilos principais - Model-View-Controller (MVC) e Presentation-Abstraction-Control(PAC). Tanto o MVC quanto o PAC propõem decomposição de três componentes e são usados ​​para aplicativos interativos, como aplicativos da web com múltiplas conversas e interações do usuário. Eles são diferentes em seu fluxo de controle e organização. PAC é uma arquitetura hierárquica baseada em agente, mas MVC não tem uma estrutura hierárquica clara.

Model-View-Controller (MVC)

O MVC decompõe um determinado aplicativo de software em três partes interconectadas que ajudam a separar as representações internas das informações das informações apresentadas ou aceitas pelo usuário.

Módulo	Função
Modelo	Encapsulamento de dados subjacentes e lógica de negócios
Controlador	Responder à ação do usuário e direcionar o fluxo do aplicativo
Visão	Formata e apresenta os dados do modelo para o usuário.

Modelo

O modelo é um componente central do MVC que gerencia diretamente os dados, a lógica e as restrições de um aplicativo. Ele consiste em componentes de dados, que mantêm os dados brutos do aplicativo e a lógica do aplicativo para a interface.

• É uma interface de usuário independente e captura o comportamento do domínio do problema do aplicativo.

• É a simulação de software específico de domínio ou implementação da estrutura central do aplicativo.

• Quando houver mudança em seu estado, ele notificará sua visualização associada para produzir saída atualizada e o controlador para alterar o conjunto de comandos disponível.

Visão

A visualização pode ser usada para representar qualquer saída de informação na forma gráfica, como diagrama ou gráfico. Consiste em componentes de apresentação que fornecem as representações visuais dos dados

• As visualizações solicitam informações de seu modelo e geram uma representação de saída para o usuário.

• São possíveis várias visualizações das mesmas informações, como um gráfico de barras para gerenciamento e uma visualização tabular para contadores.

Controlador

Um controlador aceita uma entrada e a converte em comandos para o modelo ou vista. Consiste em componentes de processamento de entrada que manipulam a entrada do usuário modificando o modelo.

• Ele atua como uma interface entre os modelos e visualizações associados e os dispositivos de entrada.

• Ele pode enviar comandos ao modelo para atualizar o estado do modelo e à sua vista associada para alterar a apresentação da vista do modelo.

MVC - I

É uma versão simples da arquitetura MVC onde o sistema é dividido em dois subsistemas -

• The Controller-View - A visualização do controlador atua como interface de entrada / saída e o processamento é feito.

• The Model - O modelo fornece todos os dados e serviços de domínio.

MVC-I Architecture

O módulo do modelo notifica o módulo de visualização do controlador sobre quaisquer alterações de dados para que qualquer exibição de dados gráficos seja alterada de acordo. O controlador também executa as ações apropriadas sobre as alterações.

A conexão entre a visão do controlador e o modelo pode ser projetada em um padrão (como mostrado na imagem acima) de assinatura-notificação, em que a visão do controlador assina o modelo e o modelo notifica a visão do controlador de quaisquer alterações.

MVC - II

MVC – II é um aprimoramento da arquitetura MVC-I na qual o módulo de visualização e o módulo controlador são separados. O módulo do modelo desempenha um papel ativo como no MVC-I, fornecendo todas as funcionalidades básicas e dados suportados pelo banco de dados.

O módulo de visualização apresenta dados enquanto o módulo controlador aceita a solicitação de entrada, valida os dados de entrada, inicia o modelo, a visualização, sua conexão e também despacha a tarefa.

MVC-II Architecture

Aplicativos MVC

Os aplicativos MVC são eficazes para aplicativos interativos em que várias visualizações são necessárias para um único modelo de dados e são fáceis de conectar em uma visualização de interface nova ou de alteração.

Os aplicativos MVC são adequados para aplicativos onde há divisões claras entre os módulos, de forma que diferentes profissionais podem ser designados para trabalhar em diferentes aspectos de tais aplicativos simultaneamente.

Advantages

• Existem muitos kits de ferramentas de estrutura de fornecedores MVC disponíveis.

• Múltiplas visualizações sincronizadas com o mesmo modelo de dados.

• Fácil de inserir ou substituir visualizações de interface.

• Usado para desenvolvimento de aplicativos em que profissionais com experiência em gráficos, profissionais de programação e profissionais de desenvolvimento de banco de dados estão trabalhando em uma equipe de projeto designada.

Disadvantages

• Não é adequado para aplicativos orientados a agentes, como aplicativos móveis e robóticos interativos.

• Vários pares de controladores e visualizações com base no mesmo modelo de dados tornam qualquer alteração do modelo de dados cara.

• A divisão entre a Visualização e o Controlador não é clara em alguns casos.

Apresentação-Abstração-Controle (PAC)

No PAC, o sistema é organizado em uma hierarquia de muitos agentes cooperantes (tríades). Ele foi desenvolvido a partir do MVC para oferecer suporte aos requisitos de aplicação de vários agentes, além dos requisitos interativos.

Cada agente possui três componentes -

• The presentation component - Formata a apresentação visual e de áudio dos dados.

• The abstraction component - Recupera e processa os dados.

• The control component - Lida com a tarefa, como o fluxo de controle e comunicação entre os outros dois componentes.

A arquitetura do PAC é semelhante ao MVC, no sentido de que o módulo de apresentação é como o módulo de visualização do MVC. O módulo de abstração se parece com o módulo modelo do MVC e o módulo de controle é como o módulo controlador do MVC, mas eles diferem em seu fluxo de controle e organização.

Não há conexões diretas entre o componente de abstração e o componente de apresentação em cada agente. O componente de controle em cada agente é responsável pelas comunicações com outros agentes.

A figura a seguir mostra um diagrama de blocos para um único agente no design do PAC.

PAC com vários agentes

Em PACs que consistem em vários agentes, o agente de nível superior fornece dados básicos e lógicas de negócios. Os agentes de nível inferior definem dados e apresentações específicas detalhadas. O agente de nível intermediário ou médio atua como coordenador de agentes de nível inferior.

• Cada agente tem seu próprio trabalho específico atribuído.

• Para alguns agentes de nível médio, as apresentações interativas não são necessárias, portanto, eles não têm um componente de apresentação.

• O componente de controle é necessário para todos os agentes por meio dos quais todos os agentes se comunicam entre si.

A figura a seguir mostra os vários agentes que fazem parte do PAC.

Applications

• Eficaz para um sistema interativo em que o sistema pode ser decomposto em vários agentes cooperantes de maneira hierárquica.

• Eficaz quando se espera que o acoplamento entre os agentes seja frouxo, de modo que as alterações em um agente não afetem os outros.

• Eficaz para sistemas distribuídos onde todos os agentes estão distribuídos de forma remota e cada um deles possui suas próprias funcionalidades com dados e interface interativa.

• Adequado para aplicativos com componentes GUI ricos em que cada um deles mantém seus próprios dados atuais e interface interativa e precisa se comunicar com outros componentes.

Vantagens

• Suporte para multitarefa e multivisualização

• Suporte para reutilização e extensibilidade do agente

• Fácil de conectar um novo agente ou alterar um existente

• Suporte para simultaneidade onde vários agentes estão sendo executados em paralelo em diferentes threads ou diferentes dispositivos ou computadores

Desvantagens

• Sobrecarga devido à ponte de controle entre apresentação e abstração e a comunicação de controles entre os agentes.

• É difícil determinar o número certo de agentes devido ao acoplamento fraco e à alta independência entre os agentes.

• A separação completa de apresentação e abstração por controle em cada agente gera complexidade de desenvolvimento, uma vez que as comunicações entre os agentes só ocorrem entre os controles dos agentes

Na arquitetura distribuída, os componentes são apresentados em diferentes plataformas e vários componentes podem cooperar entre si em uma rede de comunicação para atingir um objetivo ou meta específica.

• Nesta arquitetura, o processamento da informação não está confinado a uma única máquina, mas sim distribuído por vários computadores independentes.

• Um sistema distribuído pode ser demonstrado pela arquitetura cliente-servidor que forma a base para arquiteturas multicamadas; as alternativas são a arquitetura do broker, como CORBA, e a Arquitetura Orientada a Serviços (SOA).

• Existem várias estruturas de tecnologia para suportar arquiteturas distribuídas, incluindo .NET, J2EE, CORBA, serviços da Web .NET, serviços da Web AXIS Java e serviços Globus Grid.

• Middleware é uma infraestrutura que oferece suporte adequado ao desenvolvimento e execução de aplicativos distribuídos. Ele fornece um buffer entre os aplicativos e a rede.

• Ele fica no meio do sistema e gerencia ou oferece suporte aos diferentes componentes de um sistema distribuído. Exemplos são monitores de processamento de transações, conversores de dados e controladores de comunicação, etc.

Middleware como infraestrutura para sistema distribuído

A base de uma arquitetura distribuída é sua transparência, confiabilidade e disponibilidade.

A tabela a seguir lista as diferentes formas de transparência em um sistema distribuído -

Sr. Não.	Transparência e descrição
1	Access Oculta a forma como os recursos são acessados ​​e as diferenças na plataforma de dados.
2	Location Oculta onde os recursos estão localizados.
3	Technology Oculta do usuário diferentes tecnologias, como linguagem de programação e sistema operacional.
4	Migration / Relocation Oculte recursos que podem ser movidos para outro local que estão em uso.
5	Replication Oculte recursos que podem ser copiados em vários locais.
6	Concurrency Oculte recursos que podem ser compartilhados com outros usuários.
7	Failure Oculta falha e recuperação de recursos do usuário.
8	Persistence Oculta se um recurso (software) está na memória ou no disco.

Vantagens

• Resource sharing - Compartilhamento de recursos de hardware e software.

• Openness - Flexibilidade de uso de hardware e software de diferentes fornecedores.

• Concurrency - Processamento simultâneo para melhorar o desempenho.

• Scalability - Maior rendimento ao adicionar novos recursos.

• Fault tolerance - A capacidade de continuar em operação após a ocorrência de uma falha.

Desvantagens

• Complexity - Eles são mais complexos do que sistemas centralizados.

• Security - Mais suscetível a ataques externos.

• Manageability - Mais esforço necessário para o gerenciamento do sistema.

• Unpredictability - Respostas imprevisíveis dependendo da organização do sistema e da carga da rede.

Sistema Centralizado vs. Sistema Distribuído

Critério	Sistema centralizado	Sistema distribuído
Economia	Baixo	Alto
Disponibilidade	Baixo	Alto
Complexidade	Baixo	Alto
Consistência	Simples	Alto
Escalabilidade	Pobre	Boa
Tecnologia	Homogêneo	Heterogêneo
Segurança	Alto	Baixo

Arquitetura Cliente-Servidor

A arquitetura cliente-servidor é a arquitetura de sistema distribuído mais comum, que decompõe o sistema em dois subsistemas principais ou processos lógicos -

• Client - Este é o primeiro processo que emite uma solicitação para o segundo processo, ou seja, o servidor.

• Server - Este é o segundo processo que recebe a solicitação, realiza e envia uma resposta ao cliente.

Nessa arquitetura, o aplicativo é modelado como um conjunto de serviços que são fornecidos por servidores e um conjunto de clientes que usam esses serviços. Os servidores não precisam saber sobre os clientes, mas os clientes devem saber a identidade dos servidores, e o mapeamento de processadores para processos não é necessariamente 1: 1

A arquitetura cliente-servidor pode ser classificada em dois modelos com base na funcionalidade do cliente -

Modelo Thin-Client

No modelo thin-client, todo o processamento do aplicativo e gerenciamento de dados é realizado pelo servidor. O cliente é simplesmente responsável por executar o software de apresentação.

• Usado quando os sistemas legados são migrados para arquiteturas cliente-servidor nas quais o sistema legado atua como um servidor por conta própria com uma interface gráfica implementada em um cliente

• Uma grande desvantagem é que ele coloca uma grande carga de processamento no servidor e na rede.

Modelo de cliente espesso / gordo

No modelo de cliente gordo, o servidor é responsável apenas pelo gerenciamento de dados. O software no cliente implementa a lógica do aplicativo e as interações com o usuário do sistema.

• Mais apropriado para novos sistemas C / S onde as capacidades do sistema do cliente são conhecidas com antecedência

• Mais complexo do que um modelo thin client, especialmente para gerenciamento. Novas versões do aplicativo devem ser instaladas em todos os clientes.

Vantagens

• Separação de responsabilidades, como apresentação da interface do usuário e processamento da lógica de negócios.

• Reutilização de componentes de servidor e potencial para simultaneidade

• Simplifica o design e o desenvolvimento de aplicativos distribuídos

• Facilita a migração ou integração de aplicativos existentes em um ambiente distribuído.

• Também faz uso eficaz dos recursos quando um grande número de clientes acessa um servidor de alto desempenho.

Desvantagens

• Falta de infraestrutura heterogênea para lidar com as mudanças de requisitos.

• Complicações de segurança.

• Disponibilidade e confiabilidade limitadas do servidor.

• Testabilidade e escalabilidade limitadas.

• Clientes gordos com apresentação e lógica de negócios juntas.

Arquitetura multicamadas (arquitetura n-camadas)

A arquitetura multicamadas é uma arquitetura cliente-servidor na qual as funções, como apresentação, processamento de aplicativos e gerenciamento de dados, são fisicamente separadas. Ao separar um aplicativo em camadas, os desenvolvedores obtêm a opção de alterar ou adicionar uma camada específica, em vez de retrabalhar todo o aplicativo. Ele fornece um modelo pelo qual os desenvolvedores podem criar aplicativos flexíveis e reutilizáveis.

O uso mais geral da arquitetura multicamadas é a arquitetura de três camadas. Uma arquitetura de três camadas é normalmente composta de uma camada de apresentação, uma camada de aplicativo e uma camada de armazenamento de dados e pode ser executada em um processador separado.

Camada de Apresentação

A camada de apresentação é o nível superior do aplicativo pelo qual os usuários podem acessar diretamente, como uma página da web ou GUI do sistema operacional (interface gráfica do usuário). A principal função dessa camada é traduzir as tarefas e resultados em algo que o usuário possa entender. Ele se comunica com outras camadas para que coloque os resultados na camada do navegador / cliente e em todas as outras camadas da rede.

Camada de aplicativo (lógica de negócios, camada lógica ou camada intermediária)

A camada de aplicativo coordena o aplicativo, processa os comandos, toma decisões lógicas, avalia e executa cálculos. Ele controla a funcionalidade de um aplicativo executando processamento detalhado. Ele também move e processa dados entre as duas camadas adjacentes.

Camada de dados

Nesta camada, as informações são armazenadas e recuperadas do banco de dados ou sistema de arquivos. As informações são então passadas de volta para processamento e de volta ao usuário. Inclui os mecanismos de persistência de dados (servidores de banco de dados, compartilhamentos de arquivos, etc.) e fornece API (Interface de Programação de Aplicativo) para a camada de aplicativo que fornece métodos de gerenciamento dos dados armazenados.

Advantages

• Melhor desempenho do que uma abordagem thin client e é mais simples de gerenciar do que uma abordagem thick client.

• Aumenta a capacidade de reutilização e escalabilidade - conforme as demandas aumentam, servidores extras podem ser adicionados.

• Fornece suporte multi-threading e também reduz o tráfego de rede.

• Oferece facilidade de manutenção e flexibilidade

Disadvantages

• Testabilidade insatisfatória devido à falta de ferramentas de teste.

• Disponibilidade e confiabilidade de servidor mais críticas.

Estilo de arquitetura do corretor

Broker Architectural Style é uma arquitetura de middleware usada em computação distribuída para coordenar e permitir a comunicação entre servidores e clientes registrados. Aqui, a comunicação de objetos ocorre por meio de um sistema de middleware denominado object request broker (barramento de software).

• O cliente e o servidor não interagem diretamente entre si. O cliente e o servidor têm uma conexão direta com seu proxy, que se comunica com o mediador-corretor.

• Um servidor fornece serviços registrando e publicando suas interfaces com o broker e os clientes podem solicitar os serviços do broker estaticamente ou dinamicamente por consulta.

• CORBA (Common Object Request Broker Architecture) é um bom exemplo de implementação da arquitetura do broker.

Componentes do estilo arquitetônico do corretor

Os componentes do estilo de arquitetura do corretor são discutidos através dos seguintes cabeçalhos -

Broker

O Broker é responsável por coordenar a comunicação, como encaminhar e despachar os resultados e exceções. Pode ser um serviço orientado a invocação, um documento ou um corretor orientado a mensagem para o qual os clientes enviam uma mensagem.

• É responsável por intermediar as solicitações de serviço, localizar um servidor adequado, transmitir solicitações e enviar respostas de volta aos clientes.

• Ele retém as informações de registro dos servidores, incluindo sua funcionalidade e serviços, bem como informações de localização.

• Ele fornece APIs para clientes solicitarem, servidores para responder, registrar ou cancelar o registro de componentes do servidor, transferir mensagens e localizar servidores.

Stub

Os stubs são gerados no momento da compilação estática e, em seguida, implantados no lado do cliente, que é usado como proxy para o cliente. O proxy do lado do cliente atua como um mediador entre o cliente e o corretor e fornece transparência adicional entre eles e o cliente; um objeto remoto parece um local.

O proxy oculta o IPC (comunicação entre processos) no nível do protocolo e realiza o empacotamento dos valores dos parâmetros e o desempacotamento dos resultados do servidor.

Skeleton

O esqueleto é gerado pela compilação da interface de serviço e, em seguida, implementado no lado do servidor, que é usado como um proxy para o servidor. O proxy do lado do servidor encapsula funções de rede específicas do sistema de baixo nível e fornece APIs de alto nível para mediar entre o servidor e o broker.

Ele recebe as solicitações, descompacta as solicitações, desempacota os argumentos do método, chama o serviço adequado e também empacota o resultado antes de enviá-lo de volta ao cliente.

Bridge

Uma ponte pode conectar duas redes diferentes com base em protocolos de comunicação diferentes. Ele medeia diferentes corretores, incluindo DCOM, .NET remoto e corretores Java CORBA.

Bridges são componentes opcionais, que ocultam os detalhes de implementação quando dois brokers interoperam e pegam solicitações e parâmetros em um formato e os traduzem para outro formato.

Broker implementation in CORBA

CORBA é um padrão internacional para Object Request Broker - um middleware para gerenciar as comunicações entre objetos distribuídos definidos pelo OMG (grupo de gerenciamento de objetos).

Arquitetura Orientada a Serviços (SOA)

Um serviço é um componente da funcionalidade de negócios bem definido, autocontido, independente, publicado e disponível para ser usado por meio de uma interface de programação padrão. As conexões entre os serviços são conduzidas por protocolos orientados a mensagens comuns e universais, como o protocolo de serviço da Web SOAP, que pode entregar solicitações e respostas entre serviços de forma flexível.

A arquitetura orientada a serviços é um projeto cliente / servidor que oferece suporte à abordagem de TI orientada para os negócios, na qual um aplicativo consiste em serviços de software e consumidores de serviços de software (também conhecidos como clientes ou solicitantes de serviços).

Recursos de SOA

Uma arquitetura orientada a serviços fornece os seguintes recursos -

• Distributed Deployment - Exponha dados corporativos e lógica de negócios como unidades de funcionalidade chamadas de serviços frouxamente, acopladas, detectáveis, estruturadas, baseadas em padrões, de granulação grossa e sem estado.

• Composability - Monte novos processos de serviços existentes que são expostos em uma granularidade desejada por meio de interfaces de reclamação bem definidas, publicadas e padrão.

• Interoperability - Compartilhe recursos e reutilize serviços compartilhados em uma rede, independentemente dos protocolos subjacentes ou da tecnologia de implementação.

• Reusability - Escolha um provedor de serviços e acesse os recursos existentes expostos como serviços.

Operação SOA

A figura a seguir ilustra como SOA opera -

Advantages

• O acoplamento fraco de orientação a serviços oferece grande flexibilidade para que as empresas façam uso de todos os recursos de serviço disponíveis, independentemente das restrições de plataforma e tecnologia.

• Cada componente de serviço é independente de outros serviços devido ao recurso de serviço sem estado.

• A implementação de um serviço não afetará a aplicação do serviço, desde que a interface exposta não seja alterada.

• Um cliente ou qualquer serviço pode acessar outros serviços, independentemente de sua plataforma, tecnologia, fornecedores ou implementações de linguagem.

• Reutilização de bens e serviços uma vez que os clientes de um serviço apenas precisam de conhecer as suas interfaces públicas, composição do serviço.

• O desenvolvimento de aplicativos de negócios baseados em SOA é muito mais eficiente em termos de tempo e custo.

• Aumenta a escalabilidade e fornece conexão padrão entre sistemas.

• Uso eficiente e eficaz de 'Business Services'.

• A integração se torna muito mais fácil e a interoperabilidade intrínseca aprimorada.

• Complexidade abstrata para desenvolvedores e dinamizar processos de negócios mais próximos dos usuários finais.

A arquitetura baseada em componentes se concentra na decomposição do projeto em componentes funcionais ou lógicos individuais que representam interfaces de comunicação bem definidas contendo métodos, eventos e propriedades. Ele fornece um nível mais alto de abstração e divide o problema em subproblemas, cada um associado a partições de componentes.

O objetivo principal da arquitetura baseada em componentes é garantir component reusability. Um componente encapsula a funcionalidade e os comportamentos de um elemento de software em uma unidade binária reutilizável e auto-implantável. Existem muitas estruturas de componentes padrão, como COM / DCOM, JavaBean, EJB, CORBA, .NET, serviços da web e serviços de grade. Essas tecnologias são amplamente utilizadas no design de aplicativos GUI de desktop local, como componentes JavaBean gráficos, componentes MS ActiveX e componentes COM que podem ser reutilizados simplesmente arrastando e soltando.

O design de software orientado a componentes tem muitas vantagens sobre as abordagens tradicionais orientadas a objetos, como -

• Tempo de mercado reduzido e custo de desenvolvimento com a reutilização de componentes existentes.

• Maior confiabilidade com a reutilização dos componentes existentes.

O que é um componente?

Um componente é um conjunto modular, portátil, substituível e reutilizável de funcionalidade bem definida que encapsula sua implementação e a exporta como uma interface de nível superior.

Um componente é um objeto de software, destinado a interagir com outros componentes, encapsulando certa funcionalidade ou um conjunto de funcionalidades. Ele tem uma interface obviamente definida e está em conformidade com um comportamento recomendado comum a todos os componentes de uma arquitetura.

Um componente de software pode ser definido como uma unidade de composição com uma interface especificada contratualmente e dependências de contexto explícitas apenas. Ou seja, um componente de software pode ser implantado de forma independente e está sujeito à composição por terceiros.

Vistas de um componente

Um componente pode ter três visualizações diferentes - visualização orientada a objetos, visualização convencional e visualização relacionada ao processo.

Object-oriented view

Um componente é visto como um conjunto de uma ou mais classes cooperantes. Cada classe de domínio de problema (análise) e classe de infraestrutura (design) são explicadas para identificar todos os atributos e operações que se aplicam à sua implementação. Também envolve definir as interfaces que permitem às classes se comunicarem e cooperarem.

Conventional view

Ele é visto como um elemento funcional ou um módulo de um programa que integra a lógica de processamento, as estruturas de dados internas que são necessárias para implementar a lógica de processamento e uma interface que permite que o componente seja chamado e os dados sejam passados ​​para ele.

Process-related view

Nesta visão, em vez de criar cada componente do zero, o sistema está construindo a partir de componentes existentes mantidos em uma biblioteca. Conforme a arquitetura do software é formulada, os componentes são selecionados da biblioteca e usados ​​para preencher a arquitetura.

• Um componente de interface de usuário (IU) inclui grades, botões chamados de controles e componentes de utilitário expõem um subconjunto específico de funções usadas em outros componentes.

• Outros tipos comuns de componentes são aqueles que consomem muitos recursos, não são acessados ​​com frequência e devem ser ativados usando a abordagem just-in-time (JIT).

• Muitos componentes são invisíveis, os quais são distribuídos em aplicativos de negócios corporativos e aplicativos da web da Internet, como Enterprise JavaBean (EJB), componentes .NET e componentes CORBA.

Características dos Componentes

• Reusability- Os componentes geralmente são projetados para serem reutilizados em diferentes situações em diferentes aplicações. No entanto, alguns componentes podem ser projetados para uma tarefa específica.

• Replaceable - Os componentes podem ser substituídos livremente por outros componentes semelhantes.

• Not context specific - Os componentes são projetados para operar em diferentes ambientes e contextos.

• Extensible - Um componente pode ser estendido dos componentes existentes para fornecer um novo comportamento.

• Encapsulated - O componente AA descreve as interfaces, que permitem ao chamador usar sua funcionalidade e não expõe detalhes dos processos internos ou quaisquer variáveis ​​internas ou estado.

• Independent - Os componentes são projetados para ter dependências mínimas de outros componentes.

Princípios do projeto baseado em componentes

Um projeto de nível de componente pode ser representado usando alguma representação intermediária (por exemplo, gráfica, tabular ou baseada em texto) que pode ser traduzida em código-fonte. O projeto de estruturas de dados, interfaces e algoritmos deve estar em conformidade com diretrizes bem estabelecidas para nos ajudar a evitar a introdução de erros.

• O sistema de software é decomposto em unidades de componentes reutilizáveis, coesivas e encapsuladas.

• Cada componente tem sua própria interface que especifica as portas necessárias e as portas fornecidas; cada componente oculta sua implementação detalhada.

• Um componente deve ser estendido sem a necessidade de fazer código interno ou modificações de design nas partes existentes do componente.

• O componente Depende de abstrações não depende de outros componentes concretos, o que aumenta a dificuldade de dispensabilidade.

• Conectores conectavam componentes, especificando e regendo a interação entre os componentes. O tipo de interação é especificado pelas interfaces dos componentes.

• A interação de componentes pode assumir a forma de invocações de método, invocações assíncronas, transmissão, interações dirigidas por mensagem, comunicações de fluxo de dados e outras interações específicas de protocolo.

• Para uma classe de servidor, interfaces especializadas devem ser criadas para atender às principais categorias de clientes. Apenas as operações que são relevantes para uma determinada categoria de clientes devem ser especificadas na interface.

• Um componente pode se estender a outros componentes e ainda oferecer seus próprios pontos de extensão. É o conceito de arquitetura baseada em plug-ins. Isso permite que um plugin ofereça outra API de plugin.

Diretrizes de projeto em nível de componente

Cria uma convenção de nomenclatura para componentes que são especificados como parte do modelo de arquitetura e, em seguida, refina ou elabora como parte do modelo de nível de componente.

• Obtém nomes de componentes arquitetônicos do domínio do problema e garante que eles tenham significado para todos os envolvidos que visualizam o modelo arquitetônico.

• Extrai as entidades de processos de negócios que podem existir independentemente, sem qualquer dependência associada de outras entidades.

• Reconhece e descobre essas entidades independentes como novos componentes.

• Usa nomes de componentes de infraestrutura que refletem seu significado específico de implementação.

• Modela todas as dependências da esquerda para a direita e a herança da parte superior (classe base) para a parte inferior (classes derivadas).

• Modele quaisquer dependências de componentes como interfaces em vez de representá-las como uma dependência direta de componente para componente.

Conduzindo Projeto em Nível de Componente

Reconhece todas as classes de design que correspondem ao domínio do problema, conforme definido no modelo de análise e no modelo de arquitetura.

• Reconhece todas as classes de design que correspondem ao domínio da infraestrutura.

• Descreve todas as classes de design que não são adquiridas como componentes reutilizáveis ​​e especifica os detalhes da mensagem.

• Identifica interfaces apropriadas para cada componente e elabora atributos e define tipos de dados e estruturas de dados necessários para implementá-los.

• Descreve o fluxo de processamento em cada operação em detalhes por meio de pseudocódigo ou diagramas de atividades UML.

• Descreve fontes de dados persistentes (bancos de dados e arquivos) e identifica as classes necessárias para gerenciá-los.

• Desenvolve e elabora representações comportamentais para uma classe ou componente. Isso pode ser feito elaborando os diagramas de estado UML criados para o modelo de análise e examinando todos os casos de uso que são relevantes para a classe de design.

• Elabora diagramas de implantação para fornecer detalhes adicionais de implementação.

• Demonstra a localização dos principais pacotes ou classes de componentes em um sistema usando instâncias de classe e designando hardware específico e ambiente de sistema operacional.

• A decisão final pode ser feita usando princípios e diretrizes de design estabelecidos. Designers experientes consideram todas (ou a maioria) das soluções alternativas de design antes de se decidir pelo modelo de design final.

Vantagens

• Ease of deployment - À medida que novas versões compatíveis se tornam disponíveis, é mais fácil substituir as versões existentes sem impacto nos outros componentes ou no sistema como um todo.

• Reduced cost - O uso de componentes de terceiros permite distribuir os custos de desenvolvimento e manutenção.

• Ease of development - Os componentes implementam interfaces conhecidas para fornecer funcionalidade definida, permitindo o desenvolvimento sem impactar outras partes do sistema.

• Reusable - O uso de componentes reutilizáveis ​​significa que eles podem ser usados ​​para distribuir o custo de desenvolvimento e manutenção em vários aplicativos ou sistemas.

• Modification of technical complexity - Um componente modifica a complexidade por meio do uso de um contêiner de componente e seus serviços.

• Reliability - A confiabilidade geral do sistema aumenta, pois a confiabilidade de cada componente individual aumenta a confiabilidade de todo o sistema por meio da reutilização.

• System maintenance and evolution - Fácil de alterar e atualizar a implementação sem afetar o resto do sistema.

• Independent- Independência e conectividade flexível de componentes. Desenvolvimento independente de componentes por diferentes grupos em paralelo. Produtividade para o desenvolvimento de software e futuro desenvolvimento de software.

A interface do usuário é a primeira impressão de um sistema de software do ponto de vista do usuário. Portanto, qualquer sistema de software deve satisfazer os requisitos do usuário. A IU executa principalmente duas funções -

• Aceitar a entrada do usuário

• Exibindo o resultado

A interface do usuário desempenha um papel crucial em qualquer sistema de software. É possivelmente o único aspecto visível de um sistema de software como -

• Os usuários verão inicialmente a arquitetura da interface de usuário externa do sistema de software sem considerar sua arquitetura interna.

• Uma boa interface de usuário deve atrair o usuário para usar o sistema de software sem erros. Deve ajudar o usuário a entender o sistema de software facilmente, sem informações enganosas. Uma IU ruim pode causar falha de mercado contra a concorrência do sistema de software.

• A IU tem sua sintaxe e semântica. A sintaxe compreende tipos de componentes como textual, ícone, botão etc. e a usabilidade resume a semântica da IU. A qualidade da IU é caracterizada por sua aparência (sintaxe) e sua usabilidade (semântica).

• Existem basicamente dois tipos principais de interface do usuário - a) Textual b) Gráfica.

• O software em diferentes domínios pode exigir um estilo diferente de sua interface de usuário, por exemplo, a calculadora precisa apenas de uma pequena área para exibir números numéricos, mas uma grande área para comandos. Uma página da web precisa de formulários, links, guias, etc.

Interface gráfica do usuário

Uma interface gráfica do usuário é o tipo mais comum de interface do usuário disponível hoje. É muito amigável porque faz uso de imagens, gráficos e ícones - por isso é chamado de 'gráfico'.

Também é conhecido como WIMP interface porque faz uso de -

• Windows - Uma área retangular na tela onde os aplicativos comumente usados ​​são executados.

• Icons - Uma imagem ou símbolo que é usado para representar um aplicativo de software ou dispositivo de hardware.

• Menus - Uma lista de opções na qual o usuário pode escolher o que deseja.

• Pointers- Um símbolo como uma seta que se move pela tela conforme o usuário move o mouse. Ajuda o usuário a selecionar objetos.

Design da interface do usuário

Ele começa com a análise de tarefas que compreende as tarefas primárias do usuário e o domínio do problema. Ele deve ser projetado em termos da terminologia do usuário e do início do trabalho do usuário, e não do programador.

• Para realizar a análise da interface do usuário, o profissional precisa estudar e compreender quatro elementos -

  • o users quem irá interagir com o sistema através da interface

  • o tasks que os usuários finais devem realizar para fazer seu trabalho

  • o content que é apresentado como parte da interface

  • o work environment em que essas tarefas serão realizadas

• Um design de IU adequado ou bom funciona a partir das capacidades e limitações do usuário, não das máquinas. Ao projetar a IU, o conhecimento da natureza do trabalho e do ambiente do usuário também é fundamental.

• A tarefa a ser realizada pode então ser dividida, que é atribuída ao usuário ou máquina, com base no conhecimento das capacidades e limitações de cada um. O design de uma interface de usuário é freqüentemente dividido em quatro níveis diferentes -

  • The conceptual level - Descreve as entidades básicas considerando a visão do usuário do sistema e as ações possíveis sobre elas.

  • The semantic level - Descreve as funções executadas pelo sistema, ou seja, a descrição dos requisitos funcionais do sistema, mas não aborda como o usuário invocará as funções.

  • The syntactic level - Descreve as sequências de entradas e saídas necessárias para invocar as funções descritas.

  • The lexical level - Determina como as entradas e saídas são realmente formadas a partir de operações primitivas de hardware.

• O design da interface do usuário é um processo iterativo, onde toda a iteração explica e refina as informações desenvolvidas nas etapas anteriores. Etapas gerais para o design da interface do usuário

• Define objetos da interface do usuário e ações (operações).

• Define eventos (ações do usuário) que farão com que o estado da interface do usuário seja alterado.

• Indica como o usuário interpreta o estado do sistema a partir das informações fornecidas por meio da interface.

• Descreva cada estado da interface como ele realmente parecerá para o usuário final.

Processo de desenvolvimento de interface de usuário

Ele segue um processo em espiral, conforme mostrado no diagrama a seguir -



Interface analysis

Ele concentra ou se concentra em usuários, tarefas, conteúdo e ambiente de trabalho que irão interagir com o sistema. Define as tarefas orientadas por humanos e por computador que são necessárias para atingir o funcionamento do sistema.

Interface design

Ele define um conjunto de objetos de interface, ações e suas representações de tela que permitem que um usuário execute todas as tarefas definidas de uma maneira que atenda a todos os objetivos de usabilidade definidos para o sistema.

Interface construction

Começa com um protótipo que permite a avaliação de cenários de uso e continua com ferramentas de desenvolvimento para concluir a construção.

Interface validation

Ele se concentra na capacidade da interface de implementar todas as tarefas do usuário corretamente, acomodar todas as variações de tarefas, para atingir todos os requisitos gerais do usuário e o grau em que a interface é fácil de usar e aprender.

User Interface Models

Quando uma interface de usuário é analisada e projetada seguindo quatro modelos são usados ​​-

User profile model

• Criado por um usuário ou engenheiro de software, que estabelece o perfil dos usuários finais do sistema com base na idade, sexo, habilidades físicas, escolaridade, motivação, objetivos e personalidade.

• Considera o conhecimento sintático e semântico do usuário e classifica os usuários como novatos, intermitentes com conhecimento e usuários frequentes com conhecimento.

Design model

• Criado por um engenheiro de software que incorpora representações de dados, arquitetura, interface e procedimentos do software.

• Derivado do modelo de análise dos requisitos e controlado pelas informações da especificação dos requisitos que auxiliam na definição do usuário do sistema.

Implementation model

• Criado pelos implementadores de software que trabalham na aparência da interface combinada com todas as informações de suporte (livros, vídeos, arquivos de ajuda) que descrevem a sintaxe e a semântica do sistema.

• Serve como uma tradução do modelo de design e tenta concordar com o modelo mental do usuário para que ele se sinta confortável com o software e o use de forma eficaz.

User's mental model

• Criado pelo usuário ao interagir com o aplicativo. Ele contém a imagem do sistema que os usuários carregam em suas cabeças.

• Freqüentemente chamada de percepção do sistema do usuário e a correção da descrição dependem do perfil do usuário e da familiaridade geral com o software no domínio do aplicativo.

Considerações de design da interface do usuário

Centrado no usuário

Uma interface de usuário deve ser um produto centrado no usuário que envolve os usuários em todo o ciclo de vida de desenvolvimento de um produto. O protótipo de uma interface de usuário deve estar disponível para os usuários e o feedback dos usuários deve ser incorporado ao produto final.

Simples e intuitivo

A IU oferece simplicidade e intuitividade para que possa ser usada de forma rápida e eficaz sem instruções. A GUI é melhor do que a interface de usuário textual, pois a GUI consiste em menus, janelas e botões e é operada simplesmente com o uso do mouse.

Coloque os usuários no controle

Não force os usuários a concluir sequências predefinidas. Dê-lhes opções - cancelar ou salvar e voltar de onde pararam. Use termos em toda a interface que os usuários possam entender, em vez de termos de sistema ou desenvolvedor.

Fornece aos usuários alguma indicação de que uma ação foi executada, mostrando a eles os resultados da ação ou reconhecendo que a ação foi executada com êxito.

Transparência

A IU deve ser transparente para ajudar os usuários a sentir que estão acessando diretamente o computador e manipulando diretamente os objetos com os quais estão trabalhando. A interface pode se tornar transparente, fornecendo aos usuários objetos de trabalho em vez de objetos do sistema. Por exemplo, os usuários devem entender que a senha do sistema deve ter pelo menos 6 caracteres, não quantos bytes de armazenamento uma senha deve ter.

Use divulgação progressiva

Sempre forneça acesso fácil a recursos comuns e ações usadas com frequência. Oculte recursos e ações menos comuns e permita que os usuários os naveguem. Não tente colocar todas as informações em uma janela principal. Use a janela secundária para obter informações que não sejam informações importantes.

Consistência

A IU mantém a consistência dentro e entre o produto, mantém os mesmos resultados de interação, os comandos e menus da IU devem ter o mesmo formato, as pontuações dos comandos devem ser semelhantes e os parâmetros devem ser passados ​​para todos os comandos da mesma maneira. A IU não deve ter comportamentos que possam surpreender os usuários e deve incluir os mecanismos que permitem aos usuários se recuperarem de seus erros.

Integração

O sistema de software deve integrar-se perfeitamente a outros aplicativos, como o bloco de notas MS e o MS-Office. Ele pode usar comandos da área de transferência diretamente para realizar o intercâmbio de dados.

Orientado a componentes

O design da IU deve ser modular e incorporar arquitetura orientada a componentes para que o design da IU tenha os mesmos requisitos que o design do corpo principal do sistema de software. Os módulos podem ser facilmente modificados e substituídos sem afetar outras partes do sistema.

Customizável

A arquitetura de todo o sistema de software incorpora módulos de plug-in, que permitem que muitas pessoas diferentes estendam o software de forma independente. Ele permite que usuários individuais selecionem entre os vários formulários disponíveis para atender às suas preferências e necessidades pessoais.

Reduz a carga de memória dos usuários

Não force os usuários a lembrar e repetir o que o computador deve fazer por eles. Por exemplo, ao preencher formulários online, os nomes, endereços e números de telefone dos clientes devem ser lembrados pelo sistema assim que o usuário os inserir ou quando o registro do cliente for aberto.

As interfaces de usuário suportam a recuperação de memória de longo prazo, fornecendo aos usuários itens para eles reconhecerem em vez de ter que recuperar informações.

Separação

A UI deve ser separada da lógica do sistema por meio de sua implementação para aumentar a capacidade de reutilização e manutenção.

Abordagem Iterativa e Incremental

É uma abordagem iterativa e incremental que consiste em cinco etapas principais que ajudam a gerar soluções candidatas. Essa solução candidata pode ser posteriormente refinada repetindo essas etapas e, finalmente, criando um design de arquitetura que melhor se adapte ao nosso aplicativo. No final do processo, podemos revisar e comunicar nossa arquitetura a todas as partes interessadas.

É apenas uma abordagem possível. Existem muitas outras abordagens mais formais que definem, revisam e comunicam sua arquitetura.

Identificar o objetivo da arquitetura

Identifique o objetivo da arquitetura que forma o processo de arquitetura e design. Objetivos perfeitos e definidos enfatizam a arquitetura, resolvem os problemas certos no projeto e ajudam a determinar quando a fase atual foi concluída e está pronta para passar para a próxima fase.

Esta etapa inclui as seguintes atividades -

• Identifique seus objetivos de arquitetura no início.
• Identifique o consumidor de nossa arquitetura.
• Identifique as restrições.

Exemplos de atividades de arquitetura incluem construir um protótipo para obter feedback sobre a UI de processamento de pedidos para um aplicativo da Web, construir um aplicativo de rastreamento de pedidos do cliente e projetar a autenticação e arquitetura de autorização para um aplicativo a fim de realizar uma revisão de segurança.

Cenários Chave

Esta etapa coloca ênfase no design que mais importa. Um cenário é uma descrição extensa e abrangente da interação de um usuário com o sistema.

Os cenários principais são aqueles considerados os cenários mais importantes para o sucesso de seu aplicativo. Ajuda a tomar decisões sobre a arquitetura. O objetivo é alcançar um equilíbrio entre os objetivos do usuário, negócio e sistema. Por exemplo, a autenticação do usuário é um cenário-chave porque eles são uma interseção de um atributo de qualidade (segurança) com uma funcionalidade importante (como um usuário faz login em seu sistema).

Visão geral do aplicativo

Crie uma visão geral do aplicativo, o que torna a arquitetura mais tangível, conectando-a às restrições e decisões do mundo real. Consiste nas seguintes atividades -

Identificar o tipo de aplicativo

Identifique o tipo de aplicativo, seja ele um aplicativo móvel, um cliente avançado, um aplicativo avançado da Internet, um serviço, um aplicativo da web ou alguma combinação desses tipos.

Identificar restrições de implantação

Escolha uma topologia de implementação apropriada e resolva os conflitos entre o aplicativo e a infraestrutura de destino.

Identificar estilos de design de arquitetura importantes

Identifique estilos de design de arquitetura importantes, como cliente / servidor, em camadas, barramento de mensagem, design orientado a domínio, etc. para melhorar o particionamento e promover a reutilização de design, fornecendo soluções para problemas recorrentes frequentes. Os aplicativos geralmente usam uma combinação de estilos.

Identifique as tecnologias relevantes

Identifique as tecnologias relevantes considerando o tipo de aplicativo que estamos desenvolvendo, nossas opções preferidas para topologia de implementação de aplicativo e estilos de arquitetura. A escolha de tecnologias também será direcionada por políticas da organização, limitações de infraestrutura, habilidades de recursos e assim por diante.

Principais problemas ou principais pontos de acesso

Ao projetar um aplicativo, os pontos críticos são as zonas onde os erros são cometidos com mais frequência. Identifique os principais problemas com base em atributos de qualidade e interesses transversais. Os problemas potenciais incluem o surgimento de novas tecnologias e requisitos críticos de negócios.

Os atributos de qualidade são os recursos gerais de sua arquitetura que afetam o comportamento do tempo de execução, o design do sistema e a experiência do usuário. Questões transversais são os recursos de nosso design que podem ser aplicados a todas as camadas, componentes e camadas.

Essas também são as áreas em que erros de projeto de alto impacto são cometidos com mais frequência. Exemplos de interesses transversais são autenticação e autorização, comunicação, gerenciamento de configuração, gerenciamento de exceção e validação, etc.

Soluções Candidatas

Depois de definir os pontos de acesso principais, construa a arquitetura de linha de base inicial ou primeiro design de alto nível e, em seguida, comece a preencher os detalhes para gerar a arquitetura candidata.

A arquitetura candidata inclui o tipo de aplicativo, a arquitetura de implantação, o estilo arquitetônico, as opções de tecnologia, os atributos de qualidade e questões transversais. Se a arquitetura candidata for uma melhoria, ela pode se tornar a linha de base a partir da qual novas arquiteturas candidatas podem ser criadas e testadas.

Valide o design da solução candidata em relação aos principais cenários e requisitos que já foram definidos, antes de seguir iterativamente o ciclo e melhorar o design.

Podemos usar picos arquitetônicos para descobrir as áreas específicas do projeto ou para validar novos conceitos. Os picos arquitetônicos são um protótipo de design, que determinam a viabilidade de um caminho de design específico, reduzem o risco e determinam rapidamente a viabilidade de diferentes abordagens. Teste picos arquitetônicos em cenários e pontos de acesso principais.

Revisão de Arquitetura

A revisão da arquitetura é a tarefa mais importante para reduzir o custo de erros e para localizar e corrigir problemas de arquitetura o mais cedo possível. É uma maneira bem estabelecida e econômica de reduzir os custos e as chances de falha do projeto.

• Reveja a arquitetura frequentemente nos principais marcos do projeto e em resposta a outras mudanças arquitetônicas significativas.

• O principal objetivo de uma revisão de arquitetura é determinar a viabilidade de arquiteturas de linha de base e candidatas, que verificam a arquitetura corretamente.

• Vincula os requisitos funcionais e os atributos de qualidade com a solução técnica proposta. Também ajuda a identificar problemas e reconhecer áreas de melhoria

As avaliações baseadas em cenários são um método dominante para revisar um design de arquitetura que se concentra nos cenários que são mais importantes do ponto de vista de negócios e que têm o maior impacto na arquitetura. A seguir estão as metodologias de revisão comuns -

Método de Análise de Arquitetura de Software (SAAM)

Ele foi originalmente projetado para avaliar a modificabilidade, mas posteriormente foi estendido para revisar a arquitetura com relação aos atributos de qualidade.

Método de Análise de Tradeoff de Arquitetura (ATAM)

É uma versão refinada e aprimorada do SAAM, que analisa as decisões arquitetônicas com relação aos requisitos de atributos de qualidade e como eles satisfazem objetivos de qualidade específicos.

Revisão de Projeto Ativa (ADR)

É mais adequado para arquiteturas incompletas ou em andamento, que se concentram mais em um conjunto de problemas ou seções individuais da arquitetura por vez, em vez de realizar uma revisão geral.

Avaliações ativas de designs intermediários (ARID)

Ele combina o aspecto ADR da revisão da arquitetura em andamento com foco em um conjunto de questões e a abordagem ATAM e SAAM de revisão baseada em cenários com foco nos atributos de qualidade.

Método de Análise de Custo-Benefício (CBAM)

Ele se concentra na análise dos custos, benefícios e implicações de cronograma das decisões arquitetônicas.

Análise de Modificabilidade de Nível de Arquitetura (ALMA)

Ele estima a capacidade de modificação da arquitetura para sistemas de informações de negócios (BIS).

Método de Avaliação de Arquitetura Familiar (FAAM)

Ele estima arquiteturas de família de sistemas de informação para interoperabilidade e extensibilidade.

Comunicando o Projeto de Arquitetura

Depois de concluir o design da arquitetura, devemos comunicar o design às outras partes interessadas, que incluem equipe de desenvolvimento, administradores de sistema, operadores, proprietários de negócios e outras partes interessadas.

Existem vários métodos conhecidos a seguir para descrever a arquitetura para outras pessoas: -

4 + 1 modelo

Essa abordagem usa cinco visualizações da arquitetura completa. Entre eles, quatro pontos de vista (ological view, a process view, a physical view, e a development view) descrevem a arquitetura de diferentes abordagens. Uma quinta visualização mostra os cenários e casos de uso do software. Ele permite que os interessados ​​vejam os recursos da arquitetura que os interessam especificamente.

Linguagem de Descrição de Arquitetura (ADL)

Essa abordagem é usada para descrever a arquitetura do software antes da implementação do sistema. Ele aborda as seguintes questões - comportamento, protocolo e conector.

A principal vantagem do ADL é que podemos analisar a arquitetura quanto à integridade, consistência, ambiguidade e desempenho antes de iniciar formalmente o uso do design.

Modelagem Ágil

Esta abordagem segue o conceito de que “o conteúdo é mais importante do que a representação”. Isso garante que os modelos criados sejam simples e fáceis de entender, suficientemente precisos, detalhados e consistentes.

Os documentos do modelo Agile têm como alvo clientes específicos e cumprem os esforços de trabalho desse cliente. A simplicidade do documento garante que haja participação ativa das partes interessadas na modelagem do artefato.

IEEE 1471

IEEE 1471 é o nome abreviado de um padrão formalmente conhecido como ANSI / IEEE 1471-2000, “Prática Recomendada para Descrição de Arquitetura de Sistemas de Software Intensivo”. O IEEE 1471 aprimora o conteúdo de uma descrição arquitetônica, em particular, dando um significado específico para o contexto, visualizações e pontos de vista.

Linguagem de modelagem unificada (UML)

Esta abordagem representa três visões de um modelo de sistema. ofunctional requirements view (requisitos funcionais do sistema do ponto de vista do usuário, incluindo casos de uso); the static structural view(objetos, atributos, relacionamentos e operações, incluindo diagramas de classes); e adynamic behavior view (colaboração entre objetos e mudanças no estado interno dos objetos, incluindo sequência, atividade e diagramas de estado).