As práticas de arquitetura de software, com frequência, estão associadas a elaboração e manutenção de representações, gráficas ou textuais, usando notação livre ou uma ADL, destacando aspectos relevantes para o atendimento dos objetivos de negócio, respeito às restrições e alcance de atributos de qualidade, com menor custo e risco.
Definição: ADL (Architectural Description Language)
As linguagens de descrição de arquitetura (ADLs) fornecem meios de modelar e analisar arquiteturas de software, visando melhorar aspectos de qualidade interna e externa.
Elas podem ter forma textual descritiva (formal ou informal), gráfica ou ambas.
A finalidade da arquitetura de software é maximizar a entrega de valor para o negócio, SE NECESSÁRIO, com software funcionando.
Modelo, visões do modelo, modelagem e repositório da arquitetura
As representações geradas nas práticas de arquitetura contém “conceitos arquiteturais” relevantes ao design, como os elementos que irão compôr os sistemas e forma como eles devem se relacionar. O conjunto de todos os “conceitos arquiteturais” que podem ser utilizados para descrever a arquitetura de um software compreende o modelo arquitetural.
Definição: Modelo arquitetural
Conjunto de todos “conceitos arquiteturais” – incluindo módulos, componentes, relacionamentos e propriedades – que podem ou poderão ser utilizados na descrição da arquitetura de um software.
Representações arquiteturais, sejam elas gráficas ou textuais, apresentam “recortes” do modelo da arquitetura, colocando em destaque algum aspecto e finalidade relevante – geralmente, quanto mais explícita a finalidade, melhor.
 | Muitas representações arquiteturais pecam por ter finalidade muito abrangente ou indefinida. Antes de produzir um diagrama, por exemplo, responda duas perguntas: 1) a quem se destina essa informação?” e 2) “qual é a finalidade desejada (outcome)?” |
Os “recortes do modelo” são conhecidos como “visões do modelo”. Elas ajudam a explicitar aspectos da condição atual real (AS-IS) ou parte do futuro ideal imaginado (TO-BE), ou ainda de alguma configuração intermediária (parte do roadmap) entre esses dois momentos.
Definição: Visão do modelo
Representação contendo um “recorte” do modelo arquitetural destacando algum aspecto relevante no AS-IS, TO-BE ou em algum estágio do roadmap.
Quanto mais visões coerentes com modelo forem produzidas, mais abrangente será explicitação do modelo em si. O esforço para criar e manter as diversas “visões do modelo” é reconhecido como modelagem.
Definição: Modelagem arquitetural
Esforço despendido para produção de representações arquiteturais (visões do modelo), utilizando ou ampliando coerentemente o conjunto de conceitos expostos no modelo da arquitetura.
| O volume de visões de modelo que deve ser produzido depende, invariavelmente, do tamanho do escopo a atender e do equilíbrio das tolerâncias a riscos e custos ao longo do tempo. |
Idealmente, todas as visões do modelo são armazenadas de forma organizada constituindo o repositório da arquitetura. Boas ferramentas permitem inferências e análises do modelo através das visões mantidas no repositório.
Definição: Repositório da arquitetura
Conjunto organizado de todas as representações (visões de modelo), gráficas ou textuais, construídas utilizando conceitos descritos no modelo da arquitetura.
Que ADL utilizar?
A escolha de que ADL utilizar, principalmente em representações gráficas, dependerá de diversos fatores: incluindo público destino, qualificação das pessoas desempenhando atividades relacionadas a arquitetura e preferências.
Frequentemente, pessoas sem “formação” para práticas em arquitetura optam por utilizar notações informais em ferramentas alternativas (PowerPoint, por exemplo). O problema de tais notações é a possibilidade de falhas de entendimento e ambiguidades. A grande vantagem é, eventualmente, serem mais lúdicas e, consequentemente, compreensíveis para pessoas de áreas não-tecnicas.
| Evite utilizar notações informais para “documentar” a arquitetura. Recorra a elas, principalmente, para reuniões com pessoas “não-técnicas”. |
Como opção frequente, inclusive por sua simplicidade, há o C4 model. Tal ADL destaca-se por possuir representação gráfica e textual, entretanto, é limitada quanto as ideias que consegue representar.
| Se não está habituado a utilizar ADLs formais, comece com C4 model. |
Para cenários mais complexos, onde há necessidade de mais “vocabulário”, o ideal é utilizar linguagens mais formais como UML e Archimate.
| Não se limite a utilizar uma única ADL. Considere complexidade daquilo que deseja comunicar e familiaridade do time. Não desconsidere UML precocemente! |
Pensando em “módulos”
Do conjunto de objetivos do negócio, restrições e atributos de qualidade que precisam ser satisfeitos por uma implementação de software, infere-se uma relação de responsabilidades que precisam ser atendidas.
Definição: Responsabilidade
Uma responsabilidade descreve a “expectativa de contribuição” de algum “conceito arquitetural” para o software como um todo, incluindo ações que deverá executar, informações que deverá controlar e manter, decisões que precisará realizar, ou qualquer outro papel que precisará desempenhar no atendimento dos objetivos de negócio, imposição de restrições ou atributos de qualidade.
O trabalho fundamental das práticas de arquitetura é decompor as responsabilidades de um software em “unidades de implementação”, identificadas como módulos. O nível de granularidade dos módulos dependerá da complexidade e das preferências de quem está elaborando o design de arquitetura (o arquiteto).
Definição: Módulo
Um módulo é a “unidade de implementação” no software responsável por atender um conjunto coerente de responsabilidades. Essa “unidade de implementação” poderá ser uma classe, coleção de classes, camada, aspecto ou qualquer outra unidade aceita de decomposição, conforme o paradigma vigente.
Módulos, obviamente, não “vivem” em isolamento.
As relações comuns entre módulos incluem is-part-of, depends-on e is-a. Is-part-of são explicitações de relações entre “módulos/submódulo” (partes) e módulos agregadores (todo). Agregações e composições são relações is-part-of.
Na visão do modelo, representada no diagrama acima, temos uma “abordagem modular” indicado a existência de uma colaboração que agrega módulos de “compras” e de “orçamentação” e que tem em sua composição uma API.
Definição: Composição e Agregação
Composição é uma relação todo/parte que expressa uma dependência de existência: se um composto é excluído, suas partes (normalmente) também são excluídas.
Agregação também é uma relação todo/parte, porém, ao contrário da composição, não implica em dependência de existência entre os elementos agregadores e agregados.
Depends-on são explicitações de relações entre módulos consumidores e fornecedores.
Ainda na visão do modelo, representada também no diagrama anterior, percebemos que o website de vendas de viagens é “servido” (tem dependência) por uma API (dependendo dela).
Ja na visão do modelo indicada no diagrama acima, temos o indicativo de que o módulo de venda de produtos “aciona” o módulo de cobrança de clientes.
Por fim, is-a são explicitações de relações de realização ou especialização entre dois módulos.
Na visão do modelo indicada no diagrama acima, temos o indicativo de que o serviço de pagamentos pode ser realizado através do Paypal, Apple Play ou Google Pay.
Ja na visão do modelo indicada no diagrama acima, temos o indicativo de três “módulos” de pagamento (Visa, Mastercard e AMEX) desenvolvidos a partir de um “módulo abstrato”.
É improvável que a documentação de arquitetura de qualquer software esteja completa sem pelo menos uma visão do modelo baseada em “módulos”
Pensando em “componentes e conectores”
Um módulo, para cumprir com suas responsabilidades, demandará “conceitos arquiteturais” com alguma presença em tempo de execução – tais como processos e mecanismos de armazenamento. Tais “conceitos arquiteturais” costumam ser designados como “componentes”.
Definição: Componente
Um componente é um elemento computacional ou de armazenamento de dados, perceptível em runtime.
Componentes expõe interfaces de comunicação, frequentemente identificadas como portas, que permite a eles interagir com o ambiente.
Os diversos componentes, para interagir, demandam de algum meio. Os “conceitos arquiteturais” que viabilizam a comunicação entre dois componentes costumam ser designados “conectores”.
Definição: Conector
Um conector é um “meio de interação” entre dois ou mais componentes da arquitetura. Componentes cujo propósito principal é mediar interações entre outros dois ou mais componentes é, por definição, um conector.
Cada conector, em sua definição, explicita possíveis papéis que podem ser assumidos por componentes indicando como as interações deverão acontecer.
No diagrama indicado acima, temos um template para projeto de visões de modelo com componentes e conectores RPC. Na ilustração, fica indicado que componentes são realizados por módulos, expostos através de interfaces para serem consumidos por a) aplicações internas e 2) interfaces consolidadas
Já no diagrama indicado acima, temos um template para a representação de dois componentes que se comunicam de maneira assíncrona através de uma fila (que é o conector) em um padrão conhecido como producer/consumer.
No diagrama indicado acima, temos um template para a representação da possível comunicação de um componente, para múltiplos outros através de um tópico (que é um conector) em um padrão conhecido como publisher/subscriber.
Quem não comunica …
Na medida certa, a utilização de ADLs formais ajuda a garantir que aspectos importantes, durante a elaboração do design sejam considerados.
// TODO
Antes de avançar para o próximo capítulo recomendo as seguintes atividades:
- Empenhe-se em construir algumas visões de modelo, para seus sistemas, com base nos exemplos e templates indicados nesse capítulo
- Revise conceitos fundamentais de UML
