ARQUITETURA E DESENVOLVIMENTO

NA PLATAFORMA .NET
.NET Visão Arquitetural e Boas Práticas

Profª Flávio Secchieri Mariotti

profflavio.mariotti@fiap.com.br

2018
Bibliografia Complementar

Software Architecture in Practice, Third Edition

by Rick Kazman, Paul Clements, Len Bass
Publisher: Addison-Wesley
Release Date: 2012

Designing Software Architectures: A Practical

Approach
by Rick Kazman, Humberto Cervantes
Publisher: Addison-Wesley
Release Date: 2016
 ARQUITETO DE SOFTWARE
Avaliação da Arquitetura de Software
Discussão inicial

Como avaliar e dizer se uma arquitetura de software é

“boa” ou “ruim”?
A arquitetura de software não é inerentemente da definição boa ou ruim.
Isto é, um projeto de arquitetura de software não possui elementos inerentes que
o tornem "boa arquitetura" ou “ruim arquitetura". A arquitetura de software é
projetada para atender a um conjunto de requisitos e atributos de qualidades que
são usados para resolver um problema de um ou mais interessados.
Lista padrão de Atributos de Qualidade

Os arquitetos não têm escassez de listas de atributos de qualidade para

sistemas de software. O padrão com o título de pause-and-take-a-breath
de “ISO/IEC FCD 25010: Systems and software engineering—
Systems and software product Quality Requirements and Evaluation
(SQuaRE)—System and software quality models” é um bom exemplo .

O padrão divide os atributos de qualidade entre aqueles que suportam

um modelo de “qualidade em uso” e aqueles que suportam um modelo
de “qualidade do produto”. Essa divisão é um pouco exagerada em
alguns lugares, mas, mesmo assim, começa uma marcha de divisão e
conquista através de um conjunto de qualidades completo.
ISO/IEC FCD 25010

The ISO/IEC FCD 25010 product quality standard

Fatores de avaliação

A avaliação pode ser feita de algumas formas, entre elas:

▪ Avaliação pelo arquiteto dentro do processo de design arquitetural

▪ Avaliação por pares dentro do processo de design arquitetural

▪ Análise por outsiders, uma vez que a arquitetura foi projetada

 ATAM
Architecture Tradeoff Analysis Method
Motivação

A avaliação é essencial para análise da arquitetura, que é o processo de

determinar se a arquitetura é adequada ao objetivo a que se destina. A
arquitetura é um contribuinte tão importante para o sucesso de um projeto de
engenharia de software que faz sentido pausar e garantir que a arquitetura
projetada será capaz de fornecer tudo o que se espera dela.

Esse é o papel da avaliação.

ATAM

Architecture Tradeoff Analysis Method é usado há mais de

uma década para avaliar arquiteturas de software em
domínios de inúmeros setores, desde manufatura, varejo,
financeiro e digital.

O ATAM foi projetado para que os avaliadores não precisem

estar familiarizados com a arquitetura ou seus objetivos de
negócio, além disso, o sistema não precisa estar construído
e pode haver um grande número de partes interessadas.

https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=513908
Participantes

O ATAM exige a participação e cooperação mútua de três grupos:

▪ A equipe de avaliação: este grupo é externo ao projeto cuja arquitetura está

sendo avaliada. Geralmente consiste de três a cinco pessoas. Cada membro
da equipe recebe um número de funções específicas para exercer durante a
avaliação. A equipe de avaliação pode ser uma unidade permanente na qual
avaliações de arquitetura são realizadas regularmente, seus membros podem
ser escolhidos de um grupo de pessoas experientes para a ocasião. Eles
podem trabalhar para a mesma organização que a equipe de desenvolvimento
cuja arquitetura está em discussão, ou podem ser consultores externos. Em
qualquer caso, eles precisam ser reconhecidos como outsiders, isto é,
imparciais, sem agendas ou conflitos de interesses.
Participantes

Equipe de Avaliação

Papéis Responsabilidades

define a avaliação, coordena com o cliente, garantindo que as necessidades do

Líder de equipe
cliente sejam atendidas, assegura que o relatório final é produzido e entregue.

executa a avaliação, facilita a elaboração de cenários, administra o processo de

Líder de
seleção / priorização de cenários, facilita a avaliação de cenários em relação à
avaliação
arquitetura, facilita a análise no local

grava cenários no quadro branco ou formulário de cenário (template) durante a

Responsável pelo elucidação do cenário, captura a ideia e o contexto acordado de cada cenário,
cenários interrompendo a discussão quando necessário até que o contexto exato seja
anotado

Responsável pelo registra os cenários brutos, questões que motivam cada cenário e a resolução de
processo e cada cenário quando aplicados à arquitetura, também pode gerar uma lista
conformidade impressa dos cenários adotados e distribuir para todos os participantes.

levanta questões de interesse de arquitetura, geralmente relacionadas aos

Provocador /
atributos de qualidade nos quais o membro normalmente tem experiência (esse
Questionador
membro normalmente é rotativo)
Participantes

▪ Tomadores de decisão do projeto: essas pessoas têm o poder de falar em

nome do projeto ou autoridade para impor mudanças nele. Membros que
geralmente incluem o gerente de projeto, e se houver um cliente identificável
que esteja pagando a conta, pode estar presente (ou representado) também
por esse agente. O arquiteto deve estar sempre envolvido, uma regra
fundamental da avaliação da arquitetura é que o arquiteto participe
voluntariamente ou não.
▪ Partes interessadas na arquitetura: são membros cuja capacidade de fazer
o trabalho depende da arquitetura definida, promovendo modificabilidade,
infraestrutura, segurança, alta confiabilidade ou algo parecido. As partes
interessadas incluem desenvolvedores, testadores, integradores,
mantenedores, engenheiros de desempenho, analistas de infraestrutura,
especialistas de segurança, usuários e etc. Seu trabalho durante uma
avaliação é articular as metas específicas de atributo de qualidade que a
arquitetura deve atender para que o sistema seja considerado um sucesso.
Ao contrário da equipe de avaliação e dos tomadores de decisão do
projeto, as partes interessadas não participam de todo o exercício.
Entregáveis do ATAM

Como em qualquer processo de teste, o benefício deriva da preparação para o

teste. Na preparação para um exercício ATAM, os responsáveis ​pelas decisões
do projeto devem preparar o seguinte outputs:

1. Uma apresentação concisa da arquitetura. Um dos requisitos do ATAM

é que a arquitetura seja apresentada em uma hora, o que leva a uma
apresentação objetiva, porém compreensível.

2. Articulação dos objetivos de negócio. Frequentemente, as metas de

negócios apresentadas no ATAM estão sendo vistas por alguns dos
participantes reunidos pela primeira vez, e estas são capturadas nos
resultados. Essa descrição das metas de negócios sobrevive à avaliação e
se torna parte do legado do projeto.

O ATAM usa cenários de atributos de qualidade priorizados como base para

avaliar a arquitetura e, se esses cenários ainda não existirem, eles são
gerados pelos participantes como parte do processo.
Entregáveis do ATAM

3. Requisitos de atributos de qualidade priorizados expressos como

cenários de atributos de qualidade. A saída principal do ATAM é um conjunto
de questões preocupantes sobre a arquitetura. Também chamados de riscos.

4. Conjunto de riscos e não-riscos. Risco é definido no ATAM como uma

decisão arquitetural que pode levar a consequências indesejáveis ​em relação
aos requisitos de atributos de qualidade declarados. Da mesma forma, um
nonrisk é uma decisão arquitetônica que, após análise, é considerada segura. Os
riscos identificados formam a base para um plano arquitetural de mitigação de
riscos.

5. Conjunto de temas de risco. Quando a análise é concluída, a equipe de

avaliação examina o conjunto completo de riscos descobertos para procurar
temas abrangentes que identifiquem os pontos fracos sistêmicos na arquitetura
ou até mesmo no processo e na equipe de arquitetura. Se não forem tratados,
esses temas de risco ameaçarão as metas de negócios do projeto.
Entregáveis do ATAM

6. Mapa de decisões arquiteturais para requisitos de qualidade. As

decisões arquiteturais podem ser interpretadas em termos das qualidades
que elas sustentam ou dificultam. Para cada cenário de atributo de qualidade
examinado durante o exercício do ATAM, as decisões de arquitetura que
ajudam a alcançá-lo são determinadas e capturadas. Isso pode servir como
uma declaração de lógica/justificativa para essas decisões.

7. Um conjunto de pontos de compromisso e sensibilidade

identificados (tradeoff points). Essas são decisões de arquitetura que têm
um efeito marcado em um ou mais atributos de qualidade.

As saídas do ATAM são usadas para criar um relatório final escrito que recapitula
o método, resume os procedimentos, apresenta os cenários e suas respectivas
análises, além de catalogar/registrar as descobertas.
Fases do ATAM

As atividades em uma avaliação baseada no ATAM estão distribuídas em quatro

fases:

Fase 0: “Parceria e Preparação”, a liderança da equipe de avaliação e os

principais tomadores de decisões do projeto se encontram informalmente
para elaborar os detalhes do exercício. Os representantes do projeto
informam os avaliadores sobre o projeto, para que a equipe possa ser
suplementada por pessoas que possuam o conhecimento apropriado.
Juntos, os dois grupos concordam com a logística, como o horário e o local
das reuniões, quem traz os flipcharts e quem fornece os aperitivos e o café.
Eles também concordam com uma lista preliminar de partes interessadas, e
negociam quando o relatório final será entregue e para quem. Eles lidam
com formalidades, como uma declaração de trabalho ou acordos de
confidencialidade. A equipe de avaliação examina a documentação da
arquitetura para obter uma compreensão da arquitetura e das principais
abordagens de design que ela compreende. Por fim, o líder da equipe de
avaliação explica as informações que o gerente e o arquiteto deverão
mostrar durante a fase 1 e ajuda-os a construir suas apresentações, se
necessário.
Fases do ATAM

▪ Fase 1 e 2 são as fases de avaliação, onde todos se dedicam a análise de

negócio. Até agora, a equipe de avaliação terá estudado a documentação da
arquitetura e terá uma boa ideia do que é o sistema, das abordagens
arquiteturais gerais adotadas e dos atributos de qualidade que são de suma
importância. Durante a fase 1, a equipe de avaliação se reúne com os
tomadores de decisão do projeto para iniciar a coleta e análise de
informações. Para a fase 2, as partes interessadas da arquitetura participam
dos procedimentos e a análise continua, geralmente por dois dias. Ao
contrário das outras fases, a fase 1 e 2 compreendem um conjunto de etapas
específicas; estes são detalhados nos próximos slides.

▪ Fase 3 é o acompanhamento, no qual a equipe de avaliação produz e entrega

um relatório final por escrito. Ele é primeiramente divulgado aos principais
interessados ​para garantir que não haja erros de compreensão e, após a
conclusão dessa revisão, ele é entregue à pessoa que encomendou a
avaliação.
Fases do ATAM

Fases do ATAM e recomendação de participantes por fase e cronograma

Fase Participantes Duração

Liderança da equipe de
Tempo que for necessário
avaliação e principais
0 - Parceria e preparação (normalmente, algumas
tomadores de decisão do
semanas)
projeto

Equipe de avaliação e
1-2 dias seguidos por um
tomadores de decisão do
1 – Avaliação resultado em 1-3 semanas
projeto

Equipe de avaliação,
2 - Avaliação (continuação) tomadores de decisão do 2 dias
projeto e partes interessadas

Equipe de avaliação e
3 – Follow-up cliente (contratante do 1 semana
serviço)
Passos das fases de avaliação

As fases de análise do ATAM (fase 1 e fase 2) consistem em nove passos. Os

passos de 1 a 6 são realizadas na fase 1 com a equipe de avaliação e os
responsáveis pelas decisões do projeto: geralmente, a equipe de arquitetura, o
gerente de projeto e o patrocinador do projeto. Na fase 2, com todas as partes
interessadas presentes, os passos 1 a 6 são resumidos e as etapas 7 a 9 são
realizadas.

▪ Passo 1: Apresentar o ATAM

O primeiro passo exige que o líder de avaliação apresente o ATAM aos
representantes do projeto reunidos. Esse tempo é usado para explicar o
processo que todos seguirão, para responder perguntas e para definir o
contexto e as expectativas para o restante das atividades. Usando uma
apresentação padrão, o líder descreve as etapas do ATAM em resumo e as
saídas da avaliação.
Passos das fases de avaliação

Passo 2: Apresentar os drivers de negócios

Todos os envolvidos na avaliação - os representantes do projeto, bem como os
membros da equipe de avaliação - precisam entender o contexto do sistema e os
principais motivadores do negócio que motivam seu desenvolvimento. Nesta
etapa, um tomador de decisões de projeto (idealmente, o gerente de projeto ou o
cliente dono sistema) apresenta uma visão geral do sistema a partir de uma
perspectiva de negócios. A apresentação deve descrever o seguinte:

▪ As funções mais importantes do sistema

▪ Quaisquer restrições técnicas, gerenciais, econômicas ou políticas
relevantes
▪ Os objetivos e o contexto de negócios relacionados ao projeto
▪ As principais partes interessadas
▪ Os drivers de arquitetura (ou seja, os requisitos significativos de
arquitetura)
Passos das fases de avaliação

Passo 3: Apresentar a arquitetura

Aqui, o arquiteto líder (ou equipe de arquitetura) faz uma apresentação
descrevendo a arquitetura em um nível apropriado de detalhes. O “nível
apropriado” depende de vários fatores: quanto da arquitetura foi projetada e
documentada; quanto tempo está disponível; e a natureza dos requisitos
comportamentais e de qualidade.

Nesta apresentação, o arquiteto aborda restrições técnicas, como sistema

operacional, hardware ou middleware prescrito para uso, e outros sistemas com
os quais o sistema deve interagir. Mais importante, o arquiteto descreve as
abordagens arquiteturais (ou padrões, ou táticas) usadas para atender aos
requisitos.
Passos das fases de avaliação

Passo 4: Identifique as abordagens arquitetônicas

O ATAM se concentra em analisar uma arquitetura, entendendo suas abordagens
arquitetônicas. Os padrões e táticas arquiteturais são úteis pelas maneiras
conhecidas pelas quais cada um afeta determinado atributo de qualidade. Um
padrão em camadas tende a trazer portabilidade e capacidade de manutenção
para um sistema, possivelmente às custas do desempenho. Um padrão de cloud-
based é escalável. A tática de redundância ativa promove alta disponibilidade. E
assim por diante.

Até agora, a equipe de avaliação terá uma boa ideia de quais padrões e táticas o
arquiteto usou para projetar o sistema. Eles terão estudado a documentação da
arquitetura, e eles terão ouvido a apresentação do arquiteto no passo 3. Durante
essa etapa, o arquiteto é solicitado a nomear explicitamente os padrões e táticas
usadas, mas a equipe também deve ser perita em identificar os não
mencionados.

Neste pequeno passo, a equipe de avaliação simplesmente cataloga os padrões

e táticas que foram identificados.
Passos das fases de avaliação

Passo 5: Gerar a Árvore de Atributos de Qualidade

Nesta etapa, os objetivos do atributo de qualidade são articulados
detalhadamente por meio de uma árvore de atributos de qualidade. As árvores
utilitárias, servem para tornar concretos os requisitos, definindo precisamente os
requisitos de atributos de qualidade relevantes que os arquitetos estavam
trabalhando para fornecer.

As metas importantes de atributos de qualidade para a arquitetura em questão

foram nomeadas no passo 2, quando os drivers de negócios foram
apresentados, mas não em especificidade que permitisse a análise. Objetivos
abrangentes, como “modificabilidade” ou “alta taxa de transferência” ou
“capacidade de serem portados para várias plataformas”, estabelecem contexto e
direção importantes e fornecem um pano de fundo no qual informações
subsequentes são apresentadas.

Nesta etapa, a equipe de avaliação trabalha com os responsáveis ​pela tomada

de decisões do projeto para identificar, priorizar e refinar os objetivos mais
importantes do atributo de qualidade do sistema. Eles são expressos como
cenários, que preenchem as folhas da árvore de utilitários.
Passos das fases de avaliação

Exemplo 1. Árvore de atributos de qualidade

Passos das fases de avaliação

Exemplo 2. Árvore de atributos de qualidade

Passos das fases de avaliação

Passo 6: Analise das abordagens arquiteturais

Nesta etapa, a equipe de avaliação examina os cenários mais bem classificados
(conforme identificado na árvore de utilidades), um de cada vez; o arquiteto é
solicitado a explicar como a arquitetura suporta cada um deles. Os membros da
equipe de avaliação - especialmente os questionadores - investigam as
abordagens arquitetônicas usadas pelo arquiteto para realizar o cenário. Ao
longo do caminho, a equipe de avaliação documenta as decisões de arquitetura
relevantes e identifica e cataloga seus riscos, não-riscos, pontos de sensibilidade
e trade-offs. Para abordagens bem conhecidas, a equipe de avaliação pergunta
como o arquiteto superou fraquezas conhecidas na abordagem ou como o
arquiteto obteve a garantia de que a abordagem era suficiente. O objetivo é que
a equipe de avaliação esteja convencida que a abordagem é apropriada para
atender aos requisitos do atributo para os quais ela se destina.

O passo a passo do cenário induz a uma discussão sobre possíveis riscos,

não-riscos, pontos de sensibilidade ou tradeoff.
Passos das fases de avaliação

Exemplos:
▪ A infraestrutura de telecomunicação da região nordeste do brasil pode
impactar na latência de rede e trafego de comunicação do sistema.

▪ O número de clientes de banco de dados simultâneos afetará o número

de transações que um banco de dados pode processar por segundo.
Assim, a atribuição de clientes ao servidor é um ponto de sensibilidade
em relação à resposta medida em transações por segundo.

Estes, por sua vez, podem incentivar uma análise mais profunda, dependendo de como o
arquiteto responde. Por exemplo, se o arquiteto não puder obter o número de clientes e
não puder dizer como o balanceamento de carga será atingido alocando processos ao
hardware, não há muito sentido em uma análise de desempenho sofisticada. Se essas
perguntas puderem ser respondidas, a equipe de avaliação pode realizar pelo menos uma
análise superficial, para determinar se essas decisões arquiteturais são problemáticas em
relação aos requisitos de atributos de qualidade que devem atender.

A análise não pretende ser abrangente. O objetivo é obter informações arquitetônicas

suficientes para estabelecer algum vínculo entre as decisões de arquitetura que foram
feitas e os requisitos do atributo de qualidade que precisam ser satisfeitos.
Passos das fases de avaliação
Análise Arquitetural

Uma transação que persiste os dados para cadastro de uma proposta

Cenário #1
de pagamento requer uma mudança no requisito funcional.

Atributos Modificabilidade
A regra de negócio para funcionalidade proposta de pagamento do
Ambiente
crédito sofreu alterações.

Este requisito está relacionado com o atributo de qualidade que

Estimulo
requer a redução de esforço e custo para as mudanças.

- O mercado de concessão de crédito sofre alterações legislativas

com alta frequência.
Razões
- A necessidade de adequar o negócio ao momento econômico do
pais.

- A granularidade aplicada para criação dos serviços permite que

uma mudança seja aplicada sem que o sistema/módulo seja
afetado em sua totalidade, visto que a alteração deverá ocorrer
Respostas somente no serviço (web servisse) que contém a regra de
proposta de pagamento.
- O esforço para alteração consiste normalmente em alterar um ou
poucos web services.

Exemplo 1. Cenário para atributo de modificabilidade.

Passos das fases de avaliação

Exemplo 2. Cenário para atributo de disponibilidade.

Passos das fases de avaliação

No final da etapa 6, a equipe de avaliação deve ter uma

visão clara dos aspectos mais importantes de toda a
arquitetura, a justificativa para as principais decisões de
design e uma lista de riscos, não-riscos, pontos de
sensibilidade e tradeoff.
Passos das fases de avaliação
Passo 7: Debater e priorizar cenários (Brainstorm)
Nesta etapa, a equipe de avaliação solicita que as partes interessadas façam um brainstorming dos
cenários que sejam operacionalmente significativos em relação aos papéis individuais das partes
interessadas. Um mantenedor provavelmente proporá um cenário de modificabilidade, enquanto um
usuário provavelmente criará um cenário que expresse funcionalidade útil ou facilidade de operação, e
um profissional de garantia de qualidade proporá um cenário sobre o teste do sistema ou a capacidade
de replicar o estado do sistema. sistema que leva a uma falha.

Embora a geração de árvore de utilitários (etapa 5) seja usada principalmente para entender como o
arquiteto percebeu e lidou com os direcionadores de arquitetura de atributos de qualidade, o objetivo do
brainstorming de cenários é tomar o pulso da comunidade de interessados ​mais ampla: entender o que
significa sucesso de sistema para eles. O brainstorming de cenários funciona bem em grupos maiores,
criando uma atmosfera na qual as ideias e pensamentos de uma pessoa estimulam as ideias de outras
pessoas.

A lista de cenários priorizados é comparada com os do exercício da árvore de utilitários. Se

eles concordarem, isso indica um bom alinhamento entre o que o arquiteto tinha em
mente e o que as partes interessadas realmente queriam. Se cenários adicionais de
direção forem descobertos - e geralmente são - isso pode ser um risco, se a discrepância
for grande. Isso indicaria que houve algum desacordo nos objetivos importantes do
sistema entre as partes interessadas e o arquiteto.
Passos das fases de avaliação
Passo 8: Analise das abordagens arquiteturais
Depois que os cenários foram coletados e priorizados no passo 7, a equipe de
avaliação orienta o arquiteto no processo de realizar os cenários mais bem
classificados. O arquiteto explica como as decisões relevantes contribuem para a
realização de cada uma delas. Idealmente, essa atividade será conduzida pela
explicação do arquiteto sobre os cenários em termos de abordagens
arquitetônicas discutidas anteriormente.

Neste momento, a equipe de avaliação executa as mesmas atividades da etapa

6, usando os cenários gerados recentemente e com classificação mais alta.
Normalmente, essa etapa pode abranger os cinco a dez principais cenários,
conforme o tempo permitir.
Passos das fases de avaliação
Passo 9: Apresentar Resultados
A equipe de avaliação agrupa os riscos em temas de risco, com base em alguma
preocupação subjacente comum ou deficiência sistêmica. Por exemplo, um grupo
de riscos sobre documentação inadequada ou desatualizada pode ser agrupado
em um tema de risco, declarando que a documentação recebe consideração
insuficiente. Um grupo de riscos sobre a incapacidade do sistema de funcionar
diante de várias falhas de hardware e / ou software pode levar a um tema de
risco sobre a atenção insuficiente à capacidade de backup ou para fornecer alta
disponibilidade.

Para cada tema de risco, a equipe de avaliação identifica quais dos drivers de
negócios listados no passo 2 são afetados. Identificar os temas de risco e, em
seguida, relacioná-los a motivadores específicos, completa o ciclo de avaliação
relacionando os resultados finais com a apresentação inicial, proporcionando
assim um encerramento satisfatório do exercício. Tão importante, eleva os riscos
que foram revelados à atenção da gerência. O que de outra forma teria parecido
a um gerente como uma questão técnica esotérica agora é identificado sem
ambiguidade como uma ameaça a algo que o gerente registra como sendo de
preocupação.
Passos das fases de avaliação
As informações coletadas da avaliação são resumidas e apresentadas às partes
interessadas. Isso assume a forma de uma apresentação verbal com slides. O
líder de avaliação recapitula as etapas do ATAM e todas as informações
coletadas nas etapas do método, incluindo o contexto de negócios, requisitos de
condução, restrições e arquitetura. Em seguida, as seguintes saídas são
apresentadas:

▪ As abordagens arquiteturais documentadas

▪ O conjunto de cenários e sua priorização a partir do brainstorming
▪ A árvore de utilidades
▪ Os riscos descobertos
▪ Os nonrisks documentados
▪ Os pontos de sensibilidade e pontos de troca encontrados
▪ Temas de risco e os drivers de negócios ameaçados por cada um
Conclusão
Se um sistema é importante o suficiente para projetar explicitamente sua
arquitetura, a mesma deve ser avaliada.

O número de avaliações e a extensão de cada avaliação podem variar de projeto

para projeto. Um arquiteto deve realizar uma avaliação durante o processo de
tomada de decisão.

O ATAM é um método abrangente para avaliar arquitetura de software. Funciona

fazendo com que os tomadores de decisão do projeto e os stakeholders
articulem uma lista precisa dos requisitos de atributos de qualidade (na forma de
cenários) e iluminando as decisões arquiteturais relevantes para a realização de
cada cenário de alta prioridade. As decisões podem então ser entendidas em
termos de riscos ou não-riscos para encontrar pontos problemáticos na
arquitetura.
Copyright © 2018 Prof. Flávio Secchieri Mariotti

Todos direitos reservados. Reprodução ou divulgação total ou parcial

deste documento é expressamente proibido sem o consentimento
formal, por escrito, do Professor (autor).