Modelo, visões do modelo e além

Big design up-front is dumb. No design up-front is even dumber.
Dave Thomas

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.

C4, Archimate ou UML são exemplos de ADLs

Importante, entretanto, entender que tais representações são “meios de trabalho” para a arquitetura e não a finalidade. Elas ajudam na comunicação e na orquestração das atividades, mas não constituem um fim nelas mesmas.
0
Considerações?x

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 …

Visões de modelo ajudam a explicar as intenções da arquitetura para a realização dos objetivos do negócio, respeito as restrições e atributos de qualidade. São excelentes mecanismos para acelerar a compreensão e promover o alinhamento de propósitos que promove a autonomia de atuação. A utilização de representações, gráficas ou visuais, é um impulso a agilidade!
0
Considerações?x

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

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
0 Comentários
Feedbacks interativos
Ver todos os comentários

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentorias

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Podcast

Arquitetura de Software Online

55 51 9 9942 0609  |  me@elemarjr.com

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

0
Quero saber a sua opinião, deixe seu comentáriox
()
x