Modelos de Arquitetura

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 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 visão da arquitetura representa os requisitos funcionais e não funcionais do aplicativo de software.

  • ADL (Architecture Description Language) - ADL define a arquitetura de 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 esboço 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. Também é usado para modelar sistemas que não sejam 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 fazer 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 sequê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 seqüência de chamadas em um sistema para realizar 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 sequência, exceto que ele enfoca a 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 todas as partes interessadas. 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 opiniõ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.

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 de 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.