Arquitetura de Sistemas

Prévia do material em texto

AULA 1 - INTRO À ARQUITETURA DE SISTEMAS 
 
ARQUITETURA DE SISTEMAS → Cria uma estrutura conceitual que fornece uma visão geral do sistema, 
tanto para o cliente quanto para a equipe de desenvolvimento, antes que o processo de construção seja 
iniciado. Um modelo é estabelecido, definindo os componentes do sistema e suas interações. 
● É um elemento crucial para o sucesso do desenvolvimento de um sistema computacional. Ela 
(arquitetura) tem como objetivo principal FACILITAR COMUNICAÇÃO E COLABORAÇÃO entre 
todas as partes envolvidas no processo, desde os clientes e usuários finais até os desenvolvedores e 
as equipes de projeto. 
● A escolha dos princípios de arquitetura está diretamente relacionada ao tipo de sistema que será 
desenvolvido. Cada tipo de sistema pode demandar uma abordagem arquitetural específica. 
 
A ARQUITETURA DE SISTEMAS é uma SUBÁREA da ENGENHARIA DE SOFTWARE, que se refere à 
estrutura interna do sistema, explicando como um software se organiza, funciona, além da forma como é 
implementado. 
OBS: Ao se considerar a arquitetura de um sistema, são analisados principalmente os REQUISITOS 
apontados pela equipe responsável pelo levantamento de requisitos. Analisar detalhadamente os requisitos 
contribui para que a escolha da arquitetura esteja de acordo com os objetivos do desenvolvimento do 
sistema. 
● Basicamente, se preocupa em satisfazer os requisitos do cliente e apresentar para ele uma ideia 
concreta do projeto. 
 
A ARQUITETURA DE SISTEMAS é importante por três motivos: 
● As diversas representações da arquitetura de software permitem a comunicação entre todas as 
partes envolvidas no desenvolvimento de um sistema computacional. 
● Porque a arquitetura implica em decisões durante a fase inicial que impactam todo o 
desenvolvimento do projeto e o produto final de software. 
● Por fim, a arquitetura se constitui como um modelo mental de como o sistema será estruturado e 
como os seus componentes trabalharão em conjunto. 
A ESCOLHA DA ARQUITETURA pode contribuir para que o projeto: 
● Nasça alinhado aos requisitos para os quais ele será desenvolvido. 
● Sejam detalhados e desenvolvidos componentes que poderão ser reutilizados mais tarde (viabiliza a 
reusabilidade de software para sistemas com requisitos semelhantes). 
● Além de garantir a manutenção de cada um desses componentes de forma mais simples 
Dessa forma, o arquiteto de software terá, dentre outras funções, a responsabilidade de mapear quais são 
esses componentes e como eles vão interagir com os outros elementos do sistema. Além disso, o arquiteto 
precisa ser capaz de identificar os componentes e saber quais deles podem ser reutilizados, melhorando o 
tempo de desenvolvimento. 
 
Há 3 ELEMENTOS FUNDAMENTAIS para qualquer projeto de arquitetura de sistemas: 
COMPONENTES: Unidades principais do sistema; podem ser caracterizados por módulos de software 
com responsabilidades específicas dentro do sistema. 
PROPRIEDADES: Elementos que se referem às particularidades de cada componente. 
CONECTORES: Caracterizados por todas as formas de conexão entre os componentes de um 
sistema. Eles podem ser caracterizados por chamadas de métodos, envio e requisição de mensagens 
e outras formas que garantem a interação entre os componentes do sistema. 
 Outro elemento fundamental é a definição do: 
● GÊNERO ARQUITETURAL: Uma categoria particular de sistemas; nesse sentido, inclui toda a 
variedade de produtos de software, como aplicativos, sistemas comerciais, de escritório e tantos 
outros. Cada um desses gêneros de arquitetura demandam a existência de estruturas específicas a 
serem modeladas e desenvolvidas. 
Exemplos de gêneros de arquitetura de sistemas: 
Inteligência artificial, Dispositivos, Governo, Sistemas operacionais, Comercial, Esportes e 
entretenimento, Industriais, Plataformas, Comunicações, Financeiros, Legais, Científicos, Autoria de 
conteúdo, Jogos, Médicos, Transportes, Serviços públicos, Ferramentas 
 
A partir da definição do gênero, define-se o: 
● ESTILO DE ARQUITETURA: É um template para a construção que irá nortear o projeto. 
○ Ou seja, é por meio da definição de estilos que se podem considerar as características 
personalizadas a serem acrescentadas ao produto que será desenvolvido. Nesse sentido, 
o estilo arquitetônico de um sistema define o conjunto de componentes, as conexões entre 
eles, as restrições e os modelos semânticos que permitem que o projetista compreenda as 
propriedades gerais de um sistema. 
● Exemplos de Estilos de Arquitetura: 
○ Centralizada em Dados; Fluxo de Dados; Chamadas e Retornos; Orientadas a Objetos; 
Cliente-Servidor. 
 
A partir da escolha da arquitetura do sistema, ficarão evidenciadas as CAMADAS que o sistema terá. Se a 
arquitetura for de um sistema operacional, obviamente as camadas serão diferentes de um software de 
gestão empresarial. Entre as camadas comuns em um software, temos: 
● INTERFACE (camada mais externa); 
● CAMADA DE NEGÓCIOS; 
● CAMADA CENTRAL (camada mais próxima à linguagem de máquina). 
Definir a arquitetura e as camadas de um sistema pode contribuir também para que os próximos projetos de 
software sejam desenvolvidos de forma mais rápida e com menor número de erros. Isso ocorre porque essas 
camadas podem ser reaproveitadas para outros sistemas similares. 
 
Existem duas principais Arquiteturas de Desenvolvimento de Software: 
ARQUITETURA MONOLÍTICA → Essa abordagem de estrutura de sistemas é baseada no princípio de que 
todos os processos/funções dentro de uma mesma solução são altamente acoplados/unidos, 
dependentes, compartilham de uma única base de dados e executam todos os processos como se 
fosse um único serviço. 
● A arquitetura monolítica é um SISTEMA ÚNICO, ou seja, todas as funções estão em um único 
pacote a ser distribuído ao cliente. 
● Por ser uma estrutura tradicional, é mais conhecida e utilizada em soluções aplicadas no mercado. 
EXEMPLO: 
● Imagine o aplicativo do seu banco. Nele existem diversas funcionalidades, como: transferências, 
pagamentos, investimentos, entre outros. Em um sistema de arquitetura monolítica todas estas 
funcionalidades e seus processos estão altamente acoplados/unidos, utilizando o mesmo banco de 
dados. Dessa forma, todas as funções do sistema são implementadas em um único processo e caso 
seja necessário realizar uma atualização ou aplicação em uma única funcionalidade do sistema, todo 
o aplicativo precisaria sair do ar. 
VANTAGENS: 
● Estruturação simplificada: Por ser um projeto único, a estruturação é a mesma para todas as partes 
do sistema; 
● Poucos recursos tecnológicos: Um sistema monolítico requer menos recursos tecnológicos, em 
geral necessitando de dois ou três recursos, como por exemplo, servidor de aplicação, servidor de 
banco de dados e servidor de e-mail; 
● Um único profissional técnico: Apesar de não recomendado, mas uma aplicação monolítica pode 
ser desenvolvida utilizando apenas um profissional, dado o contexto em que, apresentação e 
processamento podem ser feitos utilizando uma única linguagem de programação; 
● Baixa integração: Não há necessidade de realizar integração entre módulos distintos dentro do 
mesmo sistema, tais “integrações” são feitas dentro do código-fonte; 
DESVANTAGENS 
● Manutenção: A aplicação se torna cada vez maior, o código será cada vez mais difícil de entender e o 
desafio de fazer alterações rápidas e ter que subir para o servidor só cresce; 
● Linha de código: Uma linha de código que subiu errada pode quebrar todo o sistema e ele ficar 
totalmente inoperante; 
● Difícil de testar: Dado o alto acoplamento dos objetos de negócio, realizar testes é complexo, pois as 
funções e características acabam por ser contaminar com necessidades de outros módulos do 
sistema; 
● Difícil de escalonar: Por ser uma aplicação única, o escalonamento/escalabilidade só pode ser feito 
do sistema como um todo, isso significa, escalonar inclusive partes do sistema que estão 
super-dimensionadas; 
● Linguagens de programação:viável financeiramente, utilizando os ativos do software, além da preocupação em 
manter a imagem da organização 
CONCEITOS LIGADOS AO DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS 
Adendo: Código que implementa um interesse. 
Aspecto: Uma abstração de programa que define o interesse transversal. Inclui a definição de um ponto de 
corte e do adendo associado com esse interesse. 
Ponto de junção: Evento em um programa em execução em que o adendo associado com um aspecto pode 
ser executado. 
● É como um ponto existente no fluxo de realização de um programa, que tem como referência os 
elementos em que serão inseridos os aspectos. Esses pontos são empregados, dentre outros motivos, 
para a chamada e a execução dos métodos e dos construtores, a inicialização, a referência a campos 
e a execução de tratamento de exceções 
Modelo de ponto de junção: Conjunto de eventos que podem ser referenciados em um ponto de corte. 
Ponto de corte: Uma declaração, inclusa em um aspecto, que define os pontos de junção em que o adendo 
de aspecto associado deve ser executado. 
● São os requisitos presentes em um aspecto em que são apresentados os pontos de junção nos quais 
se quer encerrar a execução de um programa, visando à interceptação de um aspecto, por meio da 
alteração do comportamento desse programa. Eles possuem assinaturas de práticas que podem ser 
localizadas visando a modificar o ciclo de execução original do programa e à introdução de adendos, 
que são as novas chamadas. 
Composição: A incorporação do código de adendo em ponto de junção específico por um compositor de 
aspectos. 
VERIFICAÇÃO e VALIDAÇÃO → Consistem no processo de exposição de um programa para visualizar 
se ele atende à sua especificação, assim como às prioridades dos stakeholders. 
VALIDAÇÃO ESTÁTICA: Visa à avaliação manual ou de forma automatizada em relação ao 
código-fonte utilizado no programa. 
VALIDAÇÃO DINÂMICA: É empregada para descobrir falhas no programa ou para demonstrar a 
capacidade do programa de atender aos seus requisitos. 
PROCEDIMENTO DE TESTE: Tende a ser direcionado pelo conhecimento do código-fonte do programa, 
caso a verificação de falhas seja o principal objetivo. 
MEDIÇÕES: (Métricas) de cobertura de testes servem para demonstrar o nível de eficiência deles. Isso 
ocorre quando as declarações do código-fonte forem realizadas. 
 
Não existe grande diferença entre os procedimentos de teste realizados em sistemas orientados a aspectos e 
aqueles realizados em outros sistemas. Os testes são projetados para apresentar a capacidade do sistema 
de atender aos requisitos. 
Se compararmos com a orientação a objetos, verificaremos que esta trata do conjunto de atributos e classes 
que compõem um sistema de informação. Porém, a utilização de aspectos traz uma série de problemas 
reais, e o código-fonte do programa é utilizado para reconhecer potenciais de falhas. 
 
AULA 12 - PROJETO DE SOFTWARE WebApps 
 
Devido, principalmente, à sua natureza dinâmica, os PROJETOS DE WebApp foram desenvolvidos por muito 
tempo sem qualquer preocupação em seguir métodos de desenvolvimento que garantisse a organização e a 
qualidade do software. Contudo, essa situação apresentou-se como um grande problema. Se um projeto 
pequeno pode mostrar-se quase impraticável, projetos de porte maior são, realmente, impraticáveis sem um 
projeto adequado. 
Em busca de uma solução capaz de oferecer o devido controle e agilidade para os projetos de WebApps, 
pesquisadores propuseram uma sequência metodológica de tarefas, atividades e objetivos que podem, 
inclusive, ser adaptados de processos de softwares tradicionais e que, se seguidos, elevam 
consideravelmente as chances de sucesso do projeto. 
● Uma característica essencial de uma aplicação web é seu dinamismo. As necessidades de uma 
aplicação web podem mudar em pouquíssimo tempo, levando à necessidade de projetos que tomem 
cada vez menos tempo e aplicações cada vez mais adaptáveis às necessidades atuais de seus 
usuários. 
 
A primeira atividade que deve ser realizada no planejamento de uma aplicação Web é responder as 
perguntas a seguir: 
1. Qual é a motivação da WebApp, ou seja, quais são as necessidades do negócio? 
2. Quais são os objetivos que devem ser atendidos pela WebApp? 
3. Quem vai usar a WebApp? 
Para ter sucesso, você precisa definir respostas simples e sucintas para essas questões; a partir delas, você 
poderá especificar as metas para o projeto de sua aplicação Web: 
1. Metas Informacionais: Cuja finalidade é o fornecimento de conteúdo específico ou informações ao 
usuário final; 
2. Metas Aplicativas: Cuja intenção é a realização de alguma tarefa dentro da WebApp. 
Uma vez que as metas tenham sido estabelecidas, você pode definir o perfil de seus usuários. Após ser 
definido o perfil, você poderá levantar quais são as características mais relevantes para o atendimento das 
expectativas do usuário da sua WebApp. 
LEVANTAMENTO DE REQUISITOS PARA APLICAÇÕES WEB 
Diversas técnicas de levantamento de requisitos da engenharia de software — aplicadas no desenvolvimento 
de aplicações tradicionais — podem ser também aplicadas no desenvolvimento de WebApps. Contudo, 
deve-se atentar aos diferentes contextos dos sistemas tradicionais e dos WebApps. O dinamismo das 
aplicações para Web talvez seja a sua principal característica, pois métodos que requerem tempo para serem 
aplicados não são considerados a melhor escolha. 
Qualquer modelo tradicional pode ser adaptado, não somente os modelos ágeis e desde que seus objetivos 
sejam modificados para os objetivos de um projeto de WebApp. 
 
Para isso, basta que os seus objetivos sejam adaptados: 
● Identificar requisitos de conteúdo; 
● Identificar requisitos funcionais; 
● Definir os cenários de interação para diferentes classes de usuários. 
 
A obtenção dos requisitos para a aplicação Web pode ser conduzida da seguinte forma: 
1. Solicite aos interessados para definirem as categorias de usuários e desenvolverem descrições 
de cada uma delas. 
● “Qual é o objetivo global do usuário quando ele utiliza a WebApp?” 
● Qual é o conhecimento e a sofisticação do usuário em relação ao conteúdo e à funcionalidade 
da WebApp? 
● Como o usuário chegará até a WebApp? 
● Quais são as características genéricas da WebApp que poderiam agradar/desagradar ao 
usuário? 
2. Procure manter uma comunicação ativa com os interessados, para definir quais serão os 
requisitos básicos da WebApp. 
● Pode-se escolher uma técnica para reunir um grupo formado por usuários e pessoas 
interessadas no WebApp a fim de levantar os requisitos mais gerenciáveis. 
3. Analise a informação coletada e a utilize para realizar conferências com os interessados. 
● À medida que a informação é coletada, você deve categorizá-la por classe de usuário e tipo de 
transação; depois, ela deve ser avaliada quanto à sua relevância. 
4. Defina os CASOS DE USO, que vão descrever os cenários de interação para cada uma das 
categorias de usuários. 
● Deverão descrever como uma categoria de usuários vai interagir com a aplicação Web ao 
realizar uma operação específica. Você não pode esquecer que os casos de uso devem 
descrever a interação sob o ponto de vista do usuário. 
OBJETIVOS DE UM PROJETO WebApp 
Simplicidade: entenda que uma aplicação deve fazer uso moderado de qualquer um de seus recursos, como 
conteúdo, aspectos visuais, animações, etc. 
Consistência: é um objetivo aplicável a qualquer elemento do projeto. O conteúdo deve ser construído com 
consistência, o design gráfico deve apresentar aspectos semelhantes em todas as partes da aplicação Web, 
e assim por diante. 
Identidade: o design, isto é, a apresentação gráfica de uma aplicação Web deve ser coerente com o domínio 
da aplicação para a qual está sendo desenvolvida. Uma aplicação de e-commerce certamente terá aspectos 
diferentes de uma aplicação de e-learning. 
Robustez: O usuário espera que o conteúdo da WebApp seja robusto e relevante às suas necessidades. 
Caso os elementos estejam faltando,ou seja, sejam insuficientes, então, é provável que a WebApp fracasse. 
Navegabilidade: a navegação deve ser projetada para ser intuitiva e previsível. Isso significa que o usuário 
deve saber navegar pela WebApp sem ter que buscar links ou instruções de navegação. 
Apelo visual: de todas as categorias de software possíveis, as aplicações Web são inquestionavelmente as 
mais visuais, dinâmicas e estéticas. Contudo, a beleza de uma WebApp é algo que varia de acordo com a 
ótica de quem vê; sendo assim, o indicado é o equilíbrio entre os componentes. 
Compatibilidade: uma aplicação Web deve ser utilizada em uma variedade de ambientes e deve ser 
projetada para ser executada perfeitamente em cada um deles. 
 
Durante o projeto de um WebApp, deve-se também atender a uma série de requisitos de qualidade. São eles: 
Usabilidade: Facilidade de compreensão geral do site, feedback on-line, recursos de ajuda etc. 
Funcionalidade: Abrange a capacidade de busca e recuperação de dados, as características de navegação 
e leitura das informações e as demais características relacionadas ao domínio da aplicação. 
Confiabilidade: Correto processamento dos links, recuperação de erros, validação e recuperação dos dados 
de formulários etc. 
Eficiência: Velocidade de carregamento das páginas, tempo de resposta, velocidade de geração das 
imagens etc. 
Facilidade de manutenção: O site deve ser extensível, adaptável e fácil de corrigir, além de contar com 
outras características que facilitem sua manutenção. 
 
DESENVOLVIMENTO DE UM PROJETO WebApp 
Para conduzir o desenvolvimento de uma aplicação Web, é necessário realizar os seguintes projetos: 
Projeto de Interface 
Um dos maiores desafios de um projeto de interface é determinar o ponto de entrada do usuário, ou seja, de 
onde virá o usuário. No projeto de interface, é definido como tudo será apresentado para o usuário, daí a 
preocupação em saber de onde este vem, pois, dependendo da origem de entrada do usuário, a forma de 
apresentação do WebApp deverá ser diferente. Para isso, deve-se: 
● Estabelecer uma janela para o conteúdo e a funcionalidade fornecidos pela interface; 
● Guiar o usuário com uma série de interações com a WebApp; 
● Organizar as opções de navegação e conteúdo disponíveis para o usuário. 
Projeto Estético 
● Também chamado de projeto gráfico, trata-se do esforço artístico que complementa os aspectos 
técnicos do projeto. Com o projeto estético, você deve atrair o usuário para um mundo que envolve 
elementos físicos e intelectuais. Assuma-o como um requisito, tentando responder a seguinte 
pergunta: “qual é o visual que os usuários desejam?”. Um projeto estético envolve também 
questões relacionadas ao layout e ao design gráfico. 
Projeto de Conteúdo 
● No projeto de conteúdo, a preocupação maior está no que será inserido em cada componente, e como 
serão apresentados. 
Projeto de Arquitetura 
● Está diretamente relacionado aos objetivos estabelecidos para uma WebApp, ao conteúdo que deve 
ser apresentado, aos usuários que vão visitar a página e à filosofia de navegação que será 
estabelecida. 
● Permite definir quais serão as regras de navegação em um WebApp, ou seja, por quais caminhos o 
usuário poderá seguir uma vez que estiver dentro da aplicação web. 
● TIPOS DE ARQUITETURAS DE CONTEÚDO 
 
 
O LINEAR é utilizado para 
determinar um fluxo pré-definido, 
ótimo em casos de tutoriais, 
quando se deseja direcionar o 
usuário. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
O modelo em GRADE permite 
que componentes 
"semelhantes" ou "de um 
mesmo grupo" sejam 
organizados em conjuntos. 
 
 
 
 
 
 
 
 
HIERÁRQUICA 
O usuário pode descer por 
uma hierarquia de 
componentes, podendo 
sempre que necessário subir 
na hierarquia ou visitar os 
componentes que estão no 
mesmo nível ou níveis 
inferiores do ramo hierárquico 
que decidiu seguir. 
 
 
 
 
 
Em um modelo de ESTRELA, 
a navegação é aberta, o 
usuário pode seguir de 
qualquer ponto para qualquer 
outro ponto, o que pode causar 
confusão. 
 
 
 
 
 
Projeto de Navegação 
● Uma vez que a arquitetura da WebApp está estabelecida, com todos os seus componentes 
identificados e desenvolvidos, deve-se, então, definir quais serão os percursos de navegação que 
permitirão que o usuário chegue a uma determinada informação. Isso é feito identificando-se qual será 
a semântica de navegação para os diferentes grupos de usuários da WebApp, bem como 
definindo-se a mecânica para obtenção da navegação. 
● Essa etapa se inicia com a definição da hierarquia dos usuários e dos casos de uso relativos, que 
permitam ilustrar as diferentes necessidades de navegação de cada grupo de usuários (que podem 
ser representados por um ator, em um diagrama de casos de uso). À medida que um usuário interage 
com uma WebApp, surge uma série de novas unidades semânticas de navegação (NSU, do inglês 
navigation semantic unit), que são conjuntos de informações estruturadas de navegação e que 
colaboram para o cumprimento de um subconjunto de requisitos do usuário. 
● Os elementos que compõem uma NSU são chamados de modos de navegação (WoN, do inglês way 
of navigation) e representam o melhor percurso de navegação para que se possa atingir uma 
determinada meta de um usuário específico (o melhor caminho que um usuário pode seguir dentro de 
uma aplicação para realizar a tarefa que ele deseja dentro desta aplicação). Os WoN, por sua vez, são 
compostos de objetos conhecidos como nós de navegação (navigation nodes), que são interligados 
por links de navegação. 
● À medida que se prossegue com o projeto, é preciso também definir qual será a mecânica de 
navegação. Essa é uma atividade que envolve a utilização de links, menus, barras, botões, imagens 
clicáveis e diversos outros recursos capazes de orientar a navegação do usuário pela WebApp. 
● Ou seja, no projeto de navegação, é determinado como será o fluxo de transição entre os 
componentes, seja do ponto de vista do usuário, seja dos componentes. (O caminho a ser 
seguido entre as telas do webapp para realizar cada tarefa que ele se propõe a fornecer). 
Projeto em Nível de Componentes 
Na etapa projeto de componentes, a preocupação está na definição de quais serão e o que fará cada um dos 
componentes do WebApp. 
 
AULA 13 - MODELAGEM ÁGIL 
Nos processos de desenvolvimento clássicos, os softwares eram entregues fora de prazo, com baixa 
qualidade, preço muito acima do acordado e geralmente não atendiam todas as funcionalidades desejadas 
por seus clientes. Dessa forma, as práticas de gerenciamento de projetos de software precisaram se adaptar 
às novas exigências do mercado, relacionadas, sobretudo, a entregar valor ao cliente de maneira otimizada, 
transparente e colaborativa. 
Assim, foi criada a MODELAGEM ÁGIL → Uma metodologia baseada na prática para modelagem e 
documentação eficaz de sistemas baseados em software. Em outras palavras, é um conjunto de valores, 
princípios e práticas para modelagem de software que pode ser aplicado em um projeto de desenvolvimento 
de uma maneira efetiva e leve. 
METODOLOGIA ÁGIL X METODOLOGIA TRADICIONAL 
METODOLOGIA TRADICIONAL → Não tem muita flexibilidade em relação a mudanças, uma vez que suas 
etapas do processo de desenvolvimento devem ser executadas uma após a outra, ou seja, uma tarefa não 
pode ser iniciada enquanto a anterior não for concluída. Prioriza a ideia inicial do projeto. 
● Ex: Modelo Cascata 
METODOLOGIA ÁGIL → Apresenta maior flexibilidade, versatilidade e dinamismo no seu 
desenvolvimento, atentando-se mais à entrega de valor para o software do que ao planejamento inicial. 
● Prioriza os benefícios para o cliente, trazendo um desenvolvimento mais flexível para os times de 
desenvolvimento, já que, se for necessário mudar, a mudança é feita, mesmo que mude a idealização 
inicial de alguma funcionalidade do projeto. 
 MÉTODO ÁGIL MÉTODO TRADICIONAL 
TRANSPARÊNCIA 
O cliente acompanha de perto as atividades 
realizadas durante todo o processo de 
desenvolvimento.O cliente passa muito tempo sem saber o 
que está sendo feito e como está o 
processo de desenvolvimento. 
TESTES São realizados vários testes e muitos feedbacks, 
o que gera um resultado final. 
Todo o projeto é criado para somente ao 
final realizar testes, aumentando o risco 
de falhas não previstas. 
PRINCÍPIOS DA MODELAGEM ÁGIL 
● Indivíduos e interações, em vez de processos e ferramentas; 
● Software funcionando, em vez de uma documentação abrangente; 
● Colaboração do cliente, em vez de negociação de contratos; 
● Respostas a modificações, em vez de seguir um plano. 
Princípios mais significativos: 
Modele com um Objetivo: Deve-se ter um objetivo antes de criar um modelo, comunicando informações ao 
cliente, por exemplo. Uma vez identificado o objetivo, ficará mais claro o tipo de notação a ser utilizado e o 
nível de detalhamento necessário. O princípio-chave “modele com um objetivo” visa a estimular a criação 
somente de artefatos e modelos que realmente vão colaborar para o projeto. Evite criar documentos 
desnecessários, que contemplem um único processo que necessita de tais documentações, mesmo que 
ninguém precise delas; estes jamais serão usados. Ao criar qualquer documento, questione-se para quem 
está sendo produzido esse documento. Pesquise sobre o que exatamente será necessário no documento. O 
documento só tem validade se ele se destina a alguém; caso contrário, questione sua relevância. Uma 
modelagem com um propósito nos permite criar uma documentação leve, útil e fácil de manter. 
Use Modelos Múltiplos: Há diferentes modelos e notações que podem ser usados para descrever software. 
Portanto, para propiciar uma ideia necessária, cada modelo deve apresentar um aspecto diferente do 
sistema, e somente aqueles que valorizem esses modelos para a solução pretendida devem ser usados. 
Viaje Leve: Em atividades de análise e modelagem, é saudável que seus modelos ou artefatos não 
contenham todos os detalhes, pois, em uma sessão de modelagem, o principal objetivo é esclarecer ou obter 
novas ideias. Logo, ao longo do desenvolvimento da engenharia de software, conserve apenas aqueles 
modelos que terão valor no longo prazo e despache o restante. Toda vez que se escolhe por manter um 
modelo, troca-se a agilidade pela conveniência de ter aquela informação acessível para a equipe de uma 
forma abstrata. 
Conteúdo é mais importante do que a representação: Um modelo sintaticamente perfeito pode produzir 
menor efeito qualitativo em conteúdo do que um modelo que tem notações falhas, mas fornece conteúdo 
valioso para seu público-alvo. 
Tenha conhecimento e domínio dos modelos e das ferramentas que for utilizar: Aproprie-se de cada 
modelo e ferramenta, para compreender seus pontos fortes e fracos. 
Adapte localmente: Mantenha-se sempre em contexto. Ou seja, a abordagem de modelagem deve ser 
adaptada às necessidades da equipe ágil. 
 
PRÁTICAS UTILIZADAS NA MODELAGEM ÁGIL 
TRABALHO EM EQUIPE: Modele em Conjunto 
● Permite uma comunicação eficaz com a equipe e os envolvidos no projeto. O processo de 
desenvolvimento de um software é um processo crítico para ser feito por uma única pessoa. Quando 
você modela com um propósito, deseja-se que o modelo comunique suas ideias aos demais 
interessados no projeto, com o intuito de criar um pensamento comum em relação ao projeto. O ideal 
é que se modele em conjunto, pois duas ou mais cabeças podem trabalhar melhor do que uma e gerar 
os melhores modelos. O trabalho em equipe possibilita transmitir a visão exata do assunto discutido. É 
melhor desenhar um diagrama em conjunto com o seu cliente e os demais interessados no software 
(para compartilhar pensamentos e aprendizados) do que apresentar para o cliente um diagrama já 
pronto, que provavelmente não atenderá a todas as suas necessidades. 
VALIDAÇÃO: Prove com código 
● O maior objetivo do uso dos modelos é obter uma abstração de alto nível, que dê uma visão da 
solução dos problemas, mas que seja implementável em código, sempre. Isso porque, se essas 
DOCUMENTAÇÃO Criada sempre que for necessária e de forma 
prática e planejada. 
Para todo projeto são feitas 
documentações pré-definidas, às vezes 
desnecessárias. 
CONTROLE Na ocorrência de erros, rapidamente é tomada 
uma providência para corrigir o problema. 
Há dificuldade para tratar problemas não 
previstos. 
EQUIPE Colaborativa (que se auto-organiza e se ajuda) Competitiva (Cada um faz o seu) 
LIDERANÇA Cooperativa (O líder ajuda a todos) Autoconfiante e delegativa 
soluções não forem passíveis de uma implementação condizente com as restrições de arquitetura, 
nada será aproveitado, e a modelagem terá sido inútil. Para determinar se esses modelos realmente 
funcionarão, você deverá validá-los, escrevendo o código correspondente. 
SIMPLICIDADE: Use Ferramentas Simples 
● Utilizar ferramentas simples, como quadro branco, papel e caneta, é muito importante, pois permite 
até que o próprio cliente crie modelos de forma simples, sem que se sinta intimidado pelo uso de 
modelos e ferramentas computadorizadas. 
MODELAGEM ITERATIVA E INCREMENTAL: Modelo em Pequenos Incrementos 
● Organiza um esforço maior em partições menores, que são liberadas rapidamente, de preferência em 
incrementos de várias semanas, um mês ou dois meses. 
● Essa prática aumenta sua agilidade, permitindo que você entregue o software nas mãos do cliente 
com mais rapidez e, assim, obtenha um retorno concreto e rápido dele sobre o projeto. Com o 
desenvolvimento incremental, você modela um pouco, codifica um pouco, testa um pouco e, depois, 
entrega um pouco. A maioria das sessões de modelagem, reuniões improvisadas de pessoas para 
explorar um ou mais problemas, duram cerca de 10 ou 20 minutos. 
● Quanto mais tempo você passar sem retorno concreto, maiores são as chances de que sua 
modelagem não corresponda às necessidades do cliente, sendo, portanto, um esforço desperdiçado 
FERRAMENTAS DE MÉTODOS ÁGEIS 
SCRUM: Utiliza ciclos chamados de sprints, que representam um prazo dentro do qual um conjunto de 
atividades deve ser executado. As funcionalidades a serem implementadas em um projeto são mantidas em 
uma lista, que é conhecida como product backlog (lista de funcionalidades desejadas de um produto). 
● No início de cada sprint, é realizada uma reunião de planejamento, na qual o product owner (membro 
de um time que utiliza Scrum) dá prioridade aos itens do product backlog. A equipe, com base na 
prioridade escolhida, seleciona as atividades que ela será capaz de implementar durante o sprint que 
será iniciado. Diariamente é feita uma breve reunião, com o objetivo de difundir o conhecimento sobre 
o que foi produzido no dia anterior, identificar dificuldades e priorizar o trabalho no dia que se inicia. 
● No fim de uma sprint, a equipe apresenta as funcionalidades implementadas em uma reunião de 
revisão do sprint e o ciclo se reinicia no planejamento da próxima sprint. 
PROGRAMAÇÃO EXTREMA (XP): É um metodologia que tem como objetivo criar sistemas com alta 
qualidade, com base em uma interação próxima com os clientes, testagem constante para obter feedbacks e 
ciclos de desenvolvimento curtos. 
● A XP é uma metodologia leve para times de tamanho pequeno a médio que desenvolvem software 
perante requisitos vagos que se modificam rapidamente. 
OPENUP: Possui os seguintes princípios. 
● Balancear prioridades competidoras, para maximizar o valor aos envolvidos do projeto. 
● Colaborar para alinhar interesses e compartilhar entendimento. 
● Focar cedo na arquitetura, para minimizar riscos e organizar o desenvolvimento. 
● Evoluir para continuamente obter feedback e melhorar. 
KANBAN: O termo “Kanban” é de origem japonesa e significa “sinalização” ou “cartão” e propõe o uso de 
cartões (post-its) em um quadro ou mural para indicar e acompanhar o andamento da produção dentro da 
indústria. Trata-se de um sistema visual que busca gerenciar o trabalho conforme ele se move pelo processo. 
Os post-its são divididos em 3 estágios no mural: “A fazer”,“Trabalho em progresso” e “Feito”, as atividades 
começam no primeiro estágio e vão caminhando até o último para que todos possam ver o progresso. 
 
AULA 14 - DOMAIN-DRIVEN DESIGN 
DOMÍNIO DO SISTEMA → É utilizado para denotar ou agrupar um conjunto de sistemas/aplicações ou de 
áreas funcionais dentro dos sistemas, que compartilham um conjunto de características. Uma das principais 
tarefas do desenvolvimento de software é a requisição ou licitação de requisitos do domínio do sistema. 
Nesse ponto, as práticas de modelagem de domínio são amplamente utilizadas, para a produção de um 
modelo de domínio alinhado com as regras de negócio, ou seja, com os requisitos de domínio do sistema. É 
comum o emprego de padrões de modelagem de domínio, como o domain-driven design (DDD, ou projeto 
orientado a domínio), para esse fim. 
MODELAGEM DE DOMÍNIO → É uma etapa criacional onde o desenvolvedor precisa colocar em prática sua 
criatividade atrelada aos conceitos de modelagem de software. 
DDD → Modela o domínio de um software em desenvolvimento visando atingir a implementação dos 
requisitos necessários para o domínio real de negócio do cliente. (Visa atender às necessidades do cliente). 
● É um padrão de modelagem de software com base no paradigma orientado a objetos. Esse padrão 
busca reforçar conceitos e boas práticas relacionadas à OO, visando a expressar a relação entre um 
contexto ou domínio, um problema e uma solução para esse problema, de acordo com as regras que 
definem um domínio específico. 
● O conceito de DDD é uma abordagem de modelagem de software que segue um conjunto de 
práticas com objetivo de facilitar a implementação de complexas regras e processos de 
negócios que tratamos como domínio. 
○ Portanto, o conceito de DDD é um assunto que se refere a design de código. Esse design é 
guiado pelo domínio de sua aplicação, ou seja, uma modelagem de software focado em 
resolver os problemas de complexidade da regra de negócio. 
● DDD dispõe de uma prática amplamente utilizada para testar, de forma unitária, cada classe base do 
domínio da aplicação, o TDD – Test-Driven Development (Desenvolvimento Orientado a Testes). Essa 
abordagem oferece o conceito de codificar um sistema com 100% de cobertura dos testes. 
● TDD - Os desenvolvedores usam testes para guiar o projeto do sistema durante a implementação. 
Com os resultados (falhas ou sucessos), é possível acompanhar o progresso da construção do 
software. O código só poderá ser totalmente implementado se todos os casos de testes forem 
realizados com sucesso, caso ocorra falhas, o código deve ser refatorado e testado novamente. 
BENEFÍCIOS PROMOVIDOS PELO USO DE DDD → Comunicação da equipe (pois utiliza uma linguagem 
ubíqua para comunicação entre seus participantes), extensibilidade (facilita alterações) e testabilidade. 
ASPECTOS QUE DESCREVEM A ESSÊNCIA DE OO: A utilização desse conjunto de características de 
maneira padronizada, ao ponto de a repetibilidade de tais características se tornar uma conduta correta, é 
chamado de boas práticas de programação. 
● Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do 
domínio é algo essencial quando se faz DDD, uma vez que promove um entendimento único sobre as 
regras de negócio do software em questão. 
● Reutilização: os blocos de construção desenvolvidos facilitam o aproveitamento de um mesmo 
conceito de domínio ou um mesmo código em vários momentos do desenvolvimento. 
● Baixo acoplamento: em um modelo bem-feito, refinado e organizado, as várias partes de um sistema 
interagem, sem que haja muita dependência entre módulos ou classes de objetos de conceitos 
distintos. 
● Independência da tecnologia: o DDD não foca em tecnologia, mas, sim, em entender as regras de 
negócio e como elas devem estar refletidas no código e no modelo de domínio. Isso não quer dizer 
que a tecnologia usada não é importante — apenas significa que essa não é uma preocupação do 
DDD. 
BLOCOS OU ARQUITETURA EM CAMADAS DO DDD: 
Uma vez que a equipe de programação se decida por utilizar o DDD, é necessário que, inicialmente, o 
software seja dividido por blocos de responsabilidades. A aplicação é dividida em 4 camadas/blocos: 
INTERFACE DE USUÁRIO: Essa camada tem a responsabilidade de prover a comunicação do usuário com 
a base de dados do software, tanto para receber comandos como para simplesmente verificar resultados na 
tela da aplicação. O usuário não precisa necessariamente ser uma pessoa, podendo até mesmo ser outro 
sistema (Web services, motores de indexação, etc.). Essa camada exibe informações do sistema ao 
usuário (exibe respostas do sistema) e também interpreta comandos do usuário (por meio de entrada 
de dados). 
APLICAÇÃO: Nesta camada, as operações de coordenação da aplicação e de suporte a outras tarefas 
técnicas são o foco principal. Nesse ponto do software, normalmente, é disparada a lógica de negócio que 
está em outra camada, ou simplesmente uma consulta ou chamada de alguma tarefa técnica do BD da 
aplicação, ou seja, o início de uma transação, a execução e o seu respectivo fim. É responsabilidade da 
aplicação buscar qualquer dado que a camada de domínio necessite para iniciar a operação. 
DOMÍNIO: A camada de domínio é a camada em que o DDD foca suas principais práticas e padrões. 
Normalmente, a camada de domínio é considerada o núcleo, abrangendo as regras de negócio do software. 
É aqui que estão todas as regras discutidas nas conversas entre o cliente que usará o software e a equipe 
que o desenvolveu. Nesse ponto, o time de desenvolvimento utiliza um linguajar específico sobre o domínio 
de negócio, usando linguagem ubíqua (linguagem comum, com termos bem-definidos, que fazem parte do 
domínio do negócio e que são usados por todas as pessoas que fazem parte do processo de 
desenvolvimento do software). É essa camada que dá valor à aplicação; ela interage com todas as camadas 
da aplicação, recebe chamadas da camada de aplicação, devolve valores para a camada de interface com o 
usuário (que podem também passar pela camada de aplicação) e dispara requisições para a camada de 
infraestrutura. 
INFRAESTRUTURA: Abrange tudo o que está relacionado aos eventos técnicos do software, como banco de 
dados, bibliotecas, frameworks, persistência de dados, conexões com bancos de dados, envio de mensagens 
por redes, gravação e leitura de discos, etc. Esses detalhes técnicos estão contidos na camada de 
infraestrutura e são separados dos interesses do usuário final. Serve basicamente como uma camada 
isolante, para separar o resto da aplicação desses detalhes. 
Depois de dividir o sistema em blocos, é possível focar na camada de domínio. Essa prática é importante 
porque tratar do domínio já é, por si só, uma tarefa complexa; isolar o domínio possibilita que não seja 
necessário tratar de outras questões, como questões técnicas ou de camada visual, durante o uso do DDD. 
● Além da Reusabilidade de códigos de cada módulo ou componente desenvolvido, a divisão da 
arquitetura do software em camadas facilita o processo de Manutenção do software → A tarefa de 
encontrar um bug sobre a lógica de negócio, quando o domínio do software está isolado em uma 
camada única, é mais simples. Desse modo, podemos observar que uma camada está 
completamente dissociada da outra, limitando a comunicação, que só se torna possível por meio de 
classes abstratas e interfaces. A camada inferior nunca dispara operações na camada superior. 
INCORPORANDO O DDD NO DESENVOLVIMENTO DE SOFTWARE 
Para que um software atenda completamente aos requisitos de domínio, é estritamente necessário que os 
stakeholders, ou seja, todos os interessados no desenvolvimento do software, utilizem uma linguagem única, 
de modo que todos possam entender as características intrínsecas daquele domínio. Essa linguagem é 
conhecida como linguagem ubíqua e consiste em um linguajar comum, com termos bem definidos, que 
fazem parte do domínio do negócio e que são usados por todas as pessoasque fazem parte do processo de 
desenvolvimento de software. 
● EX: durante uma conversa com o cliente sobre o domínio das ações de um caixa de pagamento da 
loja, podem ser utilizados os seguintes termos: “Temos que emitir a fatura para o cliente antes da data 
limite”. Muito provavelmente, teremos uma classe para a entidade “Cliente”, outra classe para a 
entidade “Fatura”, além de um serviço que possibilite o uso de um método “emitir”, delimitado por 
algum atributo com o nome de “data-limite”. 
A ideia por trás do DDD é que a expressão do modelo abstrato do software deve ser uma representação 
perfeita do seu domínio e de suas regras de negócio. Tudo o que existe no negócio deve aparecer no modelo, 
e somente aparece no modelo aquilo que está no negócio 
● Em DDD, uma parte das pessoas que modelam o domínio deve necessariamente ser composta por 
pessoas que “colocam a mão no código” (os chamados hands-on modelers). 
● O processo de amadurecimento de um software desenvolvido com os conceitos do DDD deve ser 
constante. O modelo guiará o desenvolvimento do código, e, ao mesmo tempo, o código ajudará a 
refinar o modelo de domínio e suas regras de negócio. O contato no dia a dia com o código trará uma 
visão apurada aos desenvolvedores a respeito do domínio; diante dessa visão privilegiada, os 
desenvolvedores podem e devem, constantemente, alterar (refatorar) o código, buscando melhorias. 
● REFATORAÇÃO → É o processo de alteração de um sistema de software, de modo que o 
comportamento externo do código não mude, mas que sua estrutura interna seja melhorada. O 
aperfeiçoamento do código minimiza as chances de falhas e torna o código mais fácil de entender e 
modificar. Quando o código apresenta erros ou está muito confuso de se entender, é um sinal de que 
ele precisa ser refatorado. Depois da refatoração, é necessário realizar testes no código para ver se 
ele continua tendo a mesma função, pois o código não pode mudar seu comportamento externo, ele 
precisa apenas ficar mais fácil de compreender e sem falhas. 
 
AULA 15 - ARQUITETURA DE SOFTWARES EMBUTIDOS 
A vida da sociedade, de maneira geral, vem sendo melhorada graças à revolução provocada pelos sistemas 
embutidos (embarcados), que são bem versáteis e usados em equipamentos médicos, eletrodomésticos, 
aparelhos de comunicação, equipamentos de entretenimento, automóveis etc. 
O PROCESSO DE PROJETO PARA SISTEMAS EMBUTIDOS (TEMPO REAL) pertence à área de 
Engenharia de Sistemas. 
● Os softwares embutidos caracterizam-se pela capacidade de um dispositivo exercer controle em uma 
quantidade extensa de sistemas. 
● A definição desse processo consiste em um procedimento que se refere à área da Engenharia de 
Software, cujos profissionais levam em consideração o detalhamento do projeto e o comportamento 
do hardware. Uma das etapas desse processo é responsável por definir quais recursos de sistema 
serão disponibilizados tanto no software quanto no hardware. 
● É importante frisar que o consumo de energia e os custos de hardware são mais críticos nos 
sistemas de tempo real embutidos em produtos de consumo. 
● Outro aspecto desses sistemas é a necessidade de utilização de processadores específicos, 
criados para auxiliar sistemas embutidos, além do hardware especial construído para alguns sistemas. 
● Esses sistemas de tempo real se caracterizam por apresentar um processo de projeto de software em 
que é impraticável a verticalização; ou seja, o uso inicial de um modelo abstrato 
desfragmentado, que desencadeia uma série de etapas, não é viável. Deve-se compreender que 
é na fase inicial do processo que o software de suporte, o timing de sistema e as decisões que 
envolvem hardwares de nível mais baixo são levados em consideração. 
● Esses aspectos restringem uma ação mais flexível dos profissionais responsáveis pelo projeto do 
sistema e indicam a inclusão de requisitos de um software adicional. 
○ Verticalização: É uma metodologia empresarial que centraliza a cadeia de produção. A 
empresa verticalizada realiza desde a produção da matéria-prima até a distribuição dos 
produtos. Ou seja, a verticalização do projeto de software consiste na construção de um 
software de acordo com os requisitos específicos de um setor, indústria ou utilizador. Dessa 
forma, eles serão de uso exclusivo para esse setor, indústria ou utilizador. 
Nesse processo, há dois componentes essenciais: os SENSORES e os ATUADORES, normalmente usados 
em aplicações industriais ou fabricações. 
 
 
 
 
 
 
 
 
 
 
 
 
 
SENSOR → É um dispositivo capaz de detectar/captar ações ou ESTÍMULOS externos e responder em 
consequência. Esses componentes têm a capacidade de transformar grandezas físicas ou químicas em 
grandezas elétricas. Há 2 tipos de estímulos: 
● Estímulos Periódicos: Acontecem em espaços de tempo previstos. Ex: Um sensor, o sistema pode 
analisá-lo dentro de um curto intervalo de tempo e dar uma resposta baseada nesse estímulo. 
● Estímulos Aperiódicos: Se caracterizam por serem imprevisíveis e sem padrão. 
Os estímulos provêm de sensores no ambiente do sistema de softwares, e as respostas são enviadas aos 
atuadores. Sendo assim, a abordagem geral de projeto de software embutido de tempo real é baseada 
em um modelo de ESTÍMULO-RESPOSTA. 
ATUADOR → É um componente eletrônico que converte a energia em movimento. Pode ser utilizado para 
aplicar uma força. Tal componente controla equipamentos/dispositivos, como uma bomba, por exemplo, e, em 
seguida, faz alterações no ambiente do sistema. Os atuadores também podem gerar estímulos, e estes 
geralmente indicam que ocorreu algum problema, que será sanado pelo sistema. 
CAPACIDADE DE RESPOSTA FULL-TIME → Quase tudo ocorre em tempo real. É a principal diferença 
entre os Sistemas Embutidos e os outros sistemas. 
● Analisando-se, por exemplo, os sistemas mais tradicionais, é possível verificar que a principal função 
deles está relacionada ao processamento de dados. São sistemas que não respondem em tempo real, 
e sua correção é estabelecida por meio da especificação das entradas de sistema que monitoram as 
saídas relacionadas. Quando se analisa um sistema de tempo real, observa-se que a correção está 
ligada à resposta para uma determinada entrada e ao tempo suficiente para criar essa resposta. Note 
que, se um sistema demorar muito para dar uma resposta, isso pode levar a uma ineficácia na 
resposta obtida. Imagine, por exemplo, um software embutido com um desempenho lento, que tenha a 
função de controlar um veículo que apresenta um sistema de frenagem. A consequência disso será 
um provável acidente, já que é praticamente impossível deter um carro de imediato. 
Outras características também diferenciam os Sistemas Embutidos dos demais: 
NÃO OPERAM DE MANEIRA CONTÍNUA → Os Sistemas Embutidos são iniciados quando o hardware é 
acionado e devem estar ativos até o seu desligamento. Nesse contexto, os métodos da área de engenharia 
de software tendem a ser empregados para assegurar essa continuidade. É possível acrescentar técnicas de 
atualização que toleram uma reconfiguração mais dinâmica, para que, enquanto estiver no serviço, o sistema 
passe por constantes atualizações. 
IMPREVISIBILIDADE → Nos sistemas embutidos, que oferecem respostas em tempo real, é preciso verificar 
a sua capacidade de tratar de eventos não programados, que podem ocorrer a qualquer instante. Nesse 
cenário, são criados projetos que têm a concorrência como referência — ou seja, diversos processos serão 
realizados simultaneamente. 
Responder aos estímulos que acontecem em momentos distintos é uma das funções do sistema de tempo 
real. Assim, é preciso que você crie uma arquitetura sistêmica capaz de transferir o controle para o 
tratador correto, à medida que os estímulos sejam recebidos. Logo, esse tipo de procedimento não é 
viável em programas denominados sequenciais. 
● Ou seja, quando um estímulo é recebido, é necessário que ele seja direcionado para o atuador 
correto, o que não ocorre em programas sequenciais, poiseles enviam os estímulos passando em 
sequência pelos atuadores, em vez de mandá-los diretamente para o atuador responsável por tratar 
tal estímulo. 
PADRÕES DE ARQUITETURA DE TEMPO REAL 
Esses padrões estabelecem como as arquiteturas de sistemas são organizadas e qual é a sua forma de 
utilização, abordando os seus benefícios e desvantagens. Entretanto, um padrão de arquitetura não pode ser 
analisado como um projeto generalista. Ou seja, o padrão deve ser aplicado para compreender o 
funcionamento de uma arquitetura de maneira geral e possibilitar que você crie o seu próprio projeto 
de arquitetura de maneira específica. Há 3 padrões de arquitetura de tempo real que são muito utilizados: 
● Observar e reagir — Consiste em um padrão utilizado quando uma série de sensores é exposta e 
monitorada habitualmente/esporadicamente. Os sensores são responsáveis por realizar sinais quando 
ocorrer algum evento, para que o sistema responda e esse evento seja tratado. 
● Controle de ambiente — Ocorre quando um sistema acrescenta sensores capazes de disponibilizar 
informações referentes ao ambiente, assim como atuadores habilitados para promover mudanças 
nesse ambiente. É perceptível a emissão de sinais de controle direcionados para os atuadores de 
sistema como uma forma de responder às alterações ambientais verificadas pelo sensor. 
● Pipeline de processo — Configura-se como um padrão aplicado à medida que os dados são 
transformados, passando de uma representação para outra, antes do efetivo processamento. Essa 
mudança é imposta como um conjunto de fases de processamento executadas simultaneamente, 
possibilitando que a manipulação de dados ocorra de maneira acelerada. 
Os padrões descritos podem estar dispostos de maneira combinada; ou seja, é possível observar mais de um 
padrão inserido em um mesmo sistema. 
ANÁLISE DE TIMING: É um recurso utilizado por projetistas de sistemas que se baseia no tempo orientado 
pelos deadlines para criar respostas aos estímulos e estabelecer processamentos. Seu objetivo é definir a 
quantidade de vezes por segundo (ou seja, com que frequência) que cada processo deve ser realizado no 
sistema para assegurar o processamento de todas as entradas e a produção de todas as respostas do 
sistema no tempo de execução estimado correto, além de verificar qual o tempo do processo realizado de 
maneira insatisfatória (Pior tempo de execução, ou seja, fora desse tempo de execução estimado). 
● A análise de timing direcionada para sistemas de tempo real é complexa, na medida em que os 
sistemas lidam com a combinação de estímulos periódicos, aperiódicos e respostas. Para lidar com a 
imprevisibilidade dos estímulos aperiódicos, é preciso realizar pressuposições referentes às 
possibilidades de eles acontecerem e solicitarem serviços a qualquer instante. Existe a possibilidade 
de que esses pressupostos estejam errados, devido ao comportamento inadequado do sistema após a 
entrega. 
Um sistema operacional considerado convencional (como Windows, Linux etc) ocupa espaço e atrasa a 
execução dos programas, devido à sua ampla funcionalidade. 
● É por isso que os aplicativos embutidos são desenvolvidos por meio de um sistema operacional 
que opera em tempo real (RTOS, do inglês real time operating system), que consiste em um 
sistema que disponibiliza os recursos necessários para os sistemas que atuam em full-time. 
Entretanto, os sistemas embutidos considerados mais simples em relação ao seu desenvolvimento 
podem ser aplicados sem um sistema operacional padrão, já que o próprio software apresenta os 
procedimentos de inicialização e desligamento do sistema, além da gestão e programação dos 
processos. 
 
AULA 16 - PRINCÍPIOS DE PROJETO E MODELAGEM SOLID 
Os princípios SOLID propõem boas práticas de programação orientada a objetos, a fim de garantir um 
projeto robusto, que permita reaproveitamento do código e torná-lo mais adaptável, fácil manutenção, 
aumento da testabilidade do código, evolução do projeto e principalmente a QUALIDADE DO 
CÓDIGO-FONTE DO PROJETO. 
SOLID é um acrônimo que representa cinco princípios a serem aplicados à POO, com o objetivo de diminuir 
o acoplamento entre classes, separar a responsabilidade de cada classe e torná-las coesas, visando a 
uma gestão de dependências. 
● Acoplamento: o grau em que uma classe conhece as outras e depende de outras. Se o 
conhecimento da classe A sobre a classe B se der por meio de sua interface, temos um baixo 
acoplamento, o que é favorável ao código. Porém, se a classe A depende de membros da classe B 
que não fazem parte da interface de B, o acoplamento é alto, o que não favorece a aplicação. 
● Coesão: quando há uma classe elaborada de forma que tenha um único e bem focado propósito, 
dizemos que ela tem uma alta coesão, o que é favorável à aplicação. Porém, quando há uma classe 
com propósitos que não pertencem apenas a ela, temos uma baixa coesão, o que não favorece a 
aplicação. 
Os 5 princípios são: 
SRP - Single Responsibility Principle (Princípio da Responsabilidade Única) 
● Define que uma classe deve ter um, e somente um, motivo para mudar, ou seja, que a classe deve ser 
COESA. Cada responsabilidade, ação ou método deve ser de uma classe apenas. 
● É importante separar responsabilidades em diferentes classes, pois a responsabilidade é um eixo para 
mudanças. Se uma classe tem mais de uma razão para mudar, então, a responsabilidade se torna 
acoplada. Alterações em uma responsabilidade podem prejudicar ou inibir a habilidade da classe em 
lidar com outras responsabilidades. 
● Ou seja, uma classe só pode representar um único objeto. Se ela tiver componentes que representam 
outros objetos, ela não está coesa. Ex: 
 
 
 
 
 
 
 
 
 
 
 
antes de aplicar SRP após aplicar o SRP 
● A classe DebitoContaCorrente tem três responsabilidades: 
○ validarSaldo(); emitirComprovante(). 
○ debitarConta(); 
● Isso significa que uma classe é responsável pelas três ações: valida o saldo em conta, debita um valor 
da conta e, por fim, emite o comprovante. Supondo que, por algum motivo, a regra de negócio da 
emissão de comprovante mude, logo, será necessária uma mudança no código da classe 
“DebitoContaCorrente”. Se no momento do refatoramento do código houver um bug, não será apenas 
a função de emissão de comprovantes que será afetada: as outras duas funções também serão 
afetadas, deixando o sistema sem três responsabilidades importantes. O sistema deixaria de fazer o 
débito e a validação de saldo, devido a um problema com o comprovante. Esse problema poderia ser 
facilmente resolvido se o princípio SRP fosse aplicado desde o início do projeto. 
OBS: Se uma classe apresenta mais de uma responsabilidade, ela não está seguindo o SRP, ou seja, ela não 
está coesa, além de dificultar a manutenção e o reuso do código. Tudo isso impede a evolução do projeto. 
 
OCP - Open/Closed Principle (Princípio do Aberto/Fechado) 
● Possibilita estender um comportamento de uma classe sem a necessidade de modificá-lo; 
● Define que as entidades, classes e funções devem ser abertas para extensão, mas fechadas para 
modificação (ou seja, elas não devem ser modificadas - ter seu código alterado - o tempo todo). 
● De certa forma, deve-se permitir acrescentar funções e comportamentos de uma classe, sem alterar 
seu código base. Isso é possível por meio de herança, interface e composição. 
● Ex: A figura abaixo apresenta uma estrutura de dados definindo o tipo de débito para preencher a 
classe “Debito”. 
 
 
Ao analisar a classe “Debito”, podemos perceber que, 
caso surja outro tipo de conta, a classe “Debito” deverá 
ser modificada, adicionando mais estruturas 
condicionais para validar o recebimento dos dados. 
Esse tipo de modificação poderia trazer riscos ao 
projeto, como os tipos de débitos pararem de funcionar 
corretamente. 
 
 
 
 
 
Esse problema poderia ser facilmente resolvido se o 
princípio OCP fosse aplicado desde o início do 
projeto, como mostra o exemplo a seguir: 
 
A figuraao lado apresenta uma abstração, em que a 
classe “Debito” representa a classe Pai, possuindo o 
método — a ação principal — e as classes filhas: 
● DebitoContaCorrente 
● DebitoContaPoupanca 
● DebitoContaInvestimento 
 
Ao analisar a classe “Debito”, podemos perceber que a 
mesma é abstrata, o que significa que não será 
instanciada, mas servirá de modelo para suas classes 
filhas. As classes filhas sobrescrevem os métodos para 
realizarem a sua implementação; elas são conhecidas 
também por classes concretas. Percebe-se que 
qualquer modificação, como uma conta nova, não 
influenciará no funcionamento dos demais tipos de 
conta, pois são classes separadas e concretas. O tipo 
de débito em conta de investimento foi implementado 
sem necessidade de mudanças, usando apenas a 
extensão. Ou seja, o princípio OCP deixou o código 
mais limpo, de fácil manutenção e de acordo com o 
primeiro princípio SOLID, o princípio de 
responsabilidade única. 
 
 
 
LSP - Liskov Substitution Principle (Princípio da Substituição de Liskov) 
● As classes derivadas devem ser substituíveis por suas classes bases. Isso significa que as classes 
filhas (derivadas) podem ser substituídas pela classe pai (superclasse), e a superclasse também pode 
ser substituída por qualquer subclasse. 
● Define que as subclasses devem apresentar o mesmo comportamento que sua superclasse. (Elas 
herdam os métodos das superclasses e os sobrescrevem/sobrepõem, sem alterar a funcionalidade de 
que o cliente precisa). 
● Ex: A figura abaixo apresenta uma abstração, em que a classe “Retangulo” representa a superclasse, 
possuindo dois atributos — base e altura — e um método, e a subclasse “Quadrado” herda base e 
largura. 
 
Ao se analisar a classe “Retangulo”, percebe-se que há 
dois atributos: base e altura. Porém, um quadrado não é 
um retângulo. Ao se fortalecer essa herança, o que vai 
acontecer com a base e a altura? Isso pode gerar 
problemas no resultado final: O quadrado só precisa do 
valor do lado para poder calcular sua área (a=L*L), mas 
como ele herda os atributos de base e altura, isso pode 
gerar confusão em quem vai inserir esses valores, 
podendo até inserir valores diferentes - o que não condiz 
com um quadrado, que deve ter todos os lados iguais. 
Esse problema poderia ser resolvido se o princípio LSP 
fosse aplicado desde o início do projeto. 
 
 
 
Aqui, com o LSP aplicado, apresenta uma abstração, em 
que a classe “FormaGeometrica” representa a superclasse, 
possuindo apenas um método abstrato, e as duas 
subclasses, “Retangulo” e “Quadrado”, sobrescrevem o 
método “calcularArea”. 
 
 
A solução para a herança apresentada no exemplo ao lado 
foi a criação da classe abstrata; o método abstrato foi 
sobrescrito pelas classes “Retangulo” e “Quadrado”, e, 
assim, não foram mantidos métodos novos nas subclasses. 
 
 
 
 
 
 
 
 
 
ISP - Interface Segregation Principle (Princípio da Segregação de Interfaces) 
● Muitas interfaces específicas são melhores do que uma interface única geral; 
● Preocupa-se com a coesão de interfaces visando a poucos comportamentos a fim de manter e evoluir 
o projeto sem dificuldades. 
● Ex: A imagem a seguir apresenta uma abstração, em que a classe Funcionario representa a 
superclasse, possuindo três atributos e três métodos, sendo dois deles abstratos; três subclasses 
herdam os atributos e sobrescrevem os métodos: Vendedor, Representante e AtendenteCaixa. 
No exemplo a seguir, a classe “Representante” herda o método “getSalario()”, mas não o implementa, pois 
um representante não ganha salário, apenas comissão, fazendo com que esse método fique inútil nessa 
classe. O mesmo acontece com a classe “AtendenteCaixa” e o método “getComissao()”. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Nesse exemplo (em cima e ao lado), a herança não 
está sendo usada da forma mais correta, sendo que 
há subclasses que não são realmente especializações 
da superclasse, e existem classes que não necessitam sobrescrever os métodos de todo o funcionário. 
● Na figura abaixo, o princípio ISP é aplicado com uso de interface e herança, em que existem duas 
interfaces, “Assalariado” e “Comissionario”, e uma superclasse abstrata “Funcionario” 
 
A classe “Vendedor” estende “Funcionário” e faz 
uso da interface “Comissionario”; 
A classe “Representante” estende “Funcionario” e 
faz uso da interface “Assalariado”; 
A classe “AtendenteCaixa” estende “Funcionario”. 
Assim, cada um só implementa ou expande aquilo 
que vai usar, sem ocorrer como antes de uma 
classe herdar métodos que não vai usar. 
 
 
DIP - Dependency Inversion Principle (Princípio da Inversão de Dependência) 
● Depende de abstrações e não de implementações; 
● Módulos de alto nível não devem depender de implementações concretas de módulos de baixo nível. 
● Ex: suponha duas classes, “Botao” e “Lampada”, ambas concretas, conforme mostra a figura abaixo. 
A classe “Lampada” tem métodos para ligar e desligar, e a classe “Botao” apresenta uma lógica para 
acionar os botões. 
 
 
 
 
 
 
 
 
Ao analisar o exemplo ao lado, percebe-se que a estrutura criada viola o 
princípio de inversão de dependência, já que a classe concreta “Botao” 
depende de uma classe concreta “Lampada”. O correto, segundo o DIP, 
seria o uso da abstração. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Veja ao lado um exemplo correto, de acordo com o DIP. A 
Figura apresenta uma abstração, em que a classe 
“Dispositivo” representa a Interface, possuindo dois métodos, 
além da classe “Lampada”, a qual implementa “Dispositivo” e 
sobrescreve os métodos, e da classe “Botão”, que utiliza a 
abstração para controlar “Dispositivo” e cria a lógica para 
ligar e desligar.Não há flexibilidade em linguagens de programação. Aquela que for 
escolhida no início do projeto terá que ser seguida, sempre. Se o desenvolvimento de uma nova 
funcionalidade exigir outra linguagem de programação, um sistema novo deverá ser criado somente 
para esta funcionalidade e posteriormente ser integrado ao sistema atual. 
 
ARQUITETURA DE MICROSSERVIÇOS → Este modelo é desenvolvido através de um sistema que consiste, 
basicamente, em construir pequenos SERVIÇOS INDEPENDENTES que são criados para recursos 
específicos, em que cada um realiza uma única função independente. 
● A arquitetura de Microsserviços é uma COLEÇÃO DE SERVIÇOS OU SISTEMAS DISTRIBUÍDOS. 
Ou seja, separa-se as partes em domínios independentes. 
A ideia da arquitetura de microsserviços é separar estes domínios de forma que se tornem únicos dentro do 
contexto do sistema final e, subsequente sejam integrados à medida que a aplicação necessite da sua 
funcionalidade, com isso, um sistema utilizando a arquitetura de microsserviços, são vários pequenos 
sistemas especializados interligados, cada um com seu próprio BD. 
 
EXEMPLO: 
● Imagine novamente o aplicativo do seu banco, com as mesmas funcionalidades citadas acima, porém 
desenvolvido através de uma arquitetura de microsserviços. Nesta situação, as transferências, 
pagamentos, investimentos e outras funcionalidades seriam estruturadas independentes, 
desenvolvidas para cumprir exclusivamente suas finalidades específicas, com seu próprio banco de 
dados. 
● Caso seja necessário realizar a manutenção de uma dessas operações, utilizando um controle de 
inversão e monitoramento adequado, as outras funcionalidades do aplicativo continuarão disponíveis 
para uso normalmente. 
VANTAGENS: 
● Altamente testável: Por conter apenas regras negócio específicas do microsserviços realizar testes é 
mais fácil e objetivo; 
● Agilidade: Como são implementados de forma independente é mais fácil gerenciar a correção de 
problemas, lançamentos, manutenção ou desenvolvimento de um outro recurso; 
● Simplicidade e Objetividade: Os serviços são pequenos e limitam-se a resolver um determinado 
problema dentro de um sistema maior, dessa forma, seu código é simples e objetivo; 
● Escalonamento por demanda: É possível escalonar somente os pontos dentro de um sistema em 
que há maior demanda por consumo de recursos. 
● Foco no negócio: É possível dividir cada serviço em equipes, focadas em trabalhar nas demandas de 
negócio para seu respectivo serviço. 
● Linguagem de programação: É possível criar cada micro serviço em uma linguagem de 
programação diferente. 
DESVANTAGENS 
● Estruturação complexa: dado seu conceito distribuído, a estruturação do projeto é mais complexa 
que na monolítica, demandando integrações mesmo para funcionalidades simples; 
● Definição da abrangência do microsserviço: a divisão dos serviços deve ser feita com muita 
atenção e cuidado, “nunca se chegará à divisão perfeita, pois, neste modelo, o alinhamento ao 
negócio é que dita as possibilidades de divisões ou re-divisões”; 
● Múltiplos profissionais: diferentemente do sistema monolítico, em uma arquitetura de 
microsserviços, será difícil utilizar somente um profissional, no geral, é necessário uma equipe que 
contemple os conhecimentos de front-end, back-end, DevOps e negócio, e em alguns casos, 
empresas maiores, há necessidade do conhecimento de compliance e segurança. 
● Vários recursos tecnológicos: dada sua estruturação complexa, diversas ferramentas são 
necessárias para publicar e executar um sistema em microsserviço. 
 
AULA 2 - DESCRIÇÃO DE ARQUITETURA DE SISTEMAS 
 
O DESENVOLVIMENTO DE SISTEMAS é uma atividade essencial no mundo tecnológico atual, permitindo a 
criação de softwares e aplicativos que atendam às necessidades específicas das pessoas e das 
empresas. 
● Esse processo se inicia com uma fase crucial de alinhamento entre a equipe de desenvolvimento e 
os representantes dos usuários ou stakeholders, responsáveis por descrever suas necessidades e 
expectativas em relação ao software a ser criado. 
A ARQUITETURA DE UM SISTEMA desempenha um papel fundamental no desenvolvimento de qualquer 
aplicação ou software. 
● É a base estrutural que define como os componentes do sistema interagem e se relacionam entre si, 
garantindo a integridade, a eficiência e a escalabilidade do projeto. 
● Nesse contexto, a DESCRIÇÃO adequada da arquitetura torna-se crucial para o sucesso do 
desenvolvimento, pois orienta a equipe em relação às decisões técnicas e funcionais a serem 
tomadas ao longo do projeto. 
● Um exemplo dessa DESCRIÇÃO é o DIAGRAMA DE CONTEXTO ARQUITETURAL. 
 
DIAGRAMAS DE CONTEXTO ARQUITETURAL → É utilizado para mapear e modelar a maneira como o 
software vai interagir com entidades externas. Nesse contexto, o sistema que está sendo desenvolvido é 
representado como o centro do processo e são chamados de SISTEMA-ALVO, e são expressas no diagrama 
as relações com os sistemas apresentados a seguir. 
● SISTEMAS SUPERIORES: Consistem em sistemas que usam o sistema-alvo. 
● SISTEMAS SUBORDINADOS: Sistemas que são utilizados pelo sistema-alvo. 
● SISTEMAS DE MESMO NÍVEL (PARES): Consistem em sistemas que compartilham informação com 
o sistema-alvo. 
● ATORES: Consistem em entidades externas, pessoas ou dispositivos que utilizam/interagem com o 
sistema-alvo, produzindo ou consumindo informações. 
 
 
 
 
Representa o fluxo de informação para dentro 
e para fora do sistema, a interface do usuário 
e o apoio de processamento relevante. Cada 
uma das entidades se comunica com o 
sistema-alvo por meio de uma interface. 
 
 
 
 
 
 
 
 
 
Os pequenos retângulos sombreados no 
diagrama consistem nas interfaces pelas 
quais cada entidade externa se comunica 
com o sistema-alvo. É por meio delas que os 
dados devem fluir tanto para dentro quanto 
para fora do sistema-alvo. Faz parte do 
projeto de arquitetura especificar os detalhes 
de cada interface. 
 
 
Os ARQUÉTIPOS, por sua vez, oferecem modelos ou padrões que descrevem soluções arquiteturais 
testadas e comprovadas para problemas recorrentes. 
● Eles fornecem diretrizes valiosas para o projeto arquitetural, ajudando a criar sistemas mais eficientes, 
escaláveis e de fácil manutenção. 
 
COMPONENTES E INSTÂNCIAS DA ARQUITETURA 
COMPONENTES → Define um comportamento do sistema. 
● À medida que a Arquitetura de Software é refinada em componentes, a estrutura do sistema começa a 
ficar mais clara. 
INSTÂNCIA → Representação real desse comportamento 
● As instâncias são representações reais, utilizadas em um problema específico para demonstrar que a 
estrutura e os componentes definidos estão apropriados. Elas são desenvolvidas para “provar” o 
funcionamento de um componente em um contexto real de utilização. 
 
ADL (LINGUAGEM DE DESCRIÇÃO DE ARQUITETURA) → São ferramentas essenciais para a descrição 
e representação de arquiteturas de sistemas de software. 
● Elas fornecem uma notação padronizada e uma sintaxe específica para expressar os elementos e 
relacionamentos arquiteturais, facilitando a compreensão e a comunicação entre os membros da 
equipe de desenvolvimento. 
● As ADLs possuem elementos básicos, que são os componentes e os conectores. É neles que são 
incluídas as regras e diretrizes para a criação de arquiteturas bem-formadas. 
● No contexto das ADL, existe uma variedade de linguagens disponíveis, cada uma com seus objetivos 
e conteúdo específico que permitem criar. Essas linguagens podem ser agrupadas em uma taxonomia 
com base nesses critérios, facilitando a seleção adequada para cada caso de uso. 
 
AULA 3 - PROJETO DOS COMPONENTES DA ARQUITETURA DE SISTEMAS 
 
COMPONENTES → É um bloco construtivo modular para software de computador, é uma unidade de 
software independente, que encapsula, dentro de si, seu projeto e sua implementação e oferece serviços 
para o meio externo, por meio de INTERFACES bem definidas. 
● Componentes de Software é o termo utilizado para descrever o elemento desoftware que 
encapsula uma série de funcionalidades. 
● Um componente é uma unidade independente, que pode ser utilizado com outros componentes para 
formar um sistema mais complexo. 
Dá para considerar que um componente é como um PROVEDOR DE SERVIÇOS INDEPENDENTE: 
● Quando um sistema necessita de algum serviço, ele chama um componente para fornecer esse 
serviço, sem se preocupar com o local em que esse componente está sendo executado ou a 
linguagem de programação usada para desenvolver o componente. 
● Os serviços oferecidos por um componente são disponibilizados por meio de uma interface, e 
todas as interações ocorrem por essa interface. 
BENEFÍCIOS DOS COMPONENTES DE SOFTWARE: 
● REUTILIZAÇÃO DE CÓDIGO: Significa que um componente pode ser utilizado em diferentes 
projetos, economizando tempo e esforço na programação. 
○ A maioria dos componentes reusados não é desenvolvida especialmente, mas se baseia em 
componentes existentes já implementados e usados em sistemas. Na maioria das vezes, os 
componentes desenvolvidos não são imediatamente reutilizáveis. Eles incluem características 
e interfaces específicas de uma aplicação improváveis de serem necessárias em outras 
aplicações. Assim, é necessário adaptar, ampliar esses componentes e criar uma versão mais 
genérica e, portanto, mais reusável. 
● MANUTENÇÃO: Facilitam a manutenção do sistema, pois as atualizações e correções podem ser 
aplicadas apenas no componente afetado, sem a necessidade de modificar todo o sistema. 
● MODULARIDADE: Os componentes podem ser desenvolvidos e testados de forma independente, o 
que facilita a identificação e correção de erros. Além disso, a modularidade permite que diferentes 
equipes de desenvolvimento trabalhem em paralelo, acelerando o processo de desenvolvimento de 
software. 
 
CARACTERÍSTICAS DE UM COMPONENTE DE SOFTWARE: 
● PADRONIZADO → Um componente precisa estar de acordo com algum modelo padronizado. 
● INDEPENDENTE; 
● PASSÍVEL DE COMPOSIÇÃO → Todas as interações externas devem ocorrer por meio de interfaces 
publicamente definidas. Além disso, o componente deve fornecer acesso externo às informações 
sobre si próprio, como seus métodos e atributos. 
● IMPLANTÁVEL → Um componente deve ser autocontido e deve ser capaz de operar como uma 
entidade independente sobre uma plataforma de componente que implementa o modelo de 
componente; 
● DOCUMENTADO. 
 
Os componentes são definidos por suas interfaces e podem ser imaginados como se tivessem duas 
interfaces relacionadas: 
 
 
 
 
 
 
 
 
 
Interface REQUIRES → Especifica 
quais serviços devem ser fornecidos por 
outros componentes no sistema. Se 
esses componentes não estiverem 
disponíveis, o componente não 
funcionará. 
Interface PROVIDES → Define os 
serviços fornecidos pelo componente. 
Trata-se da interface de programação 
de aplicações (API, do inglês application 
programming interface), que define os 
métodos que podem ser chamados pelo 
usuário do componente. 
 
MODELO DE COMPONENTE → É a DEFINIÇÃO DE PADRÕES para implementação, documentação e 
implantação de componentes. Esses padrões servem para os desenvolvedores se assegurarem de que os 
componentes podem operar entre si. Eles se destinam também aos fornecedores de infraestrutura de 
execução de componentes, que fornecem middleware para apoiar a operação de componentes. 
● MIDDLEWARE → É um software que diferentes aplicações usam para se comunicar umas com as 
outras. Ele atua como uma ponte entre diversas tecnologias, ferramentas e bancos de dados para 
integrá-los perfeitamente em uma única rede ou único sistema complexo. É uma camada que fica 
entre a aplicação e o sistema operacional, fornecendo uma abstração da programação. Ele 
mascara as divergências entre redes, hardware, sistemas operacionais que rodam nos computadores 
e linguagens de programação, permitindo que diferentes aplicações possam se comunicar 
ultrapassando os desafios de suas divergências. 
PROJETO DE COMPONENTES → Um conjunto completo de componentes de software é definido durante o 
projeto de arquitetura. Depois, o PROJETO DE COMPONENTES é uma etapa essencial no processo de 
desenvolvimento de software que define as estruturas de dados, os algoritmos, as características das 
interfaces e os mecanismos de comunicação alocados em cada componente do software. 
● O PDC representa o software para garantir a revisão dos detalhes do projeto no que diz respeito à 
correção e à consistência com outras representações do projeto (como os projetos de interfaces, a 
arquitetura e os dados, que são as bases do PDC). Ele AVALIA A EFICIÊNCIA DAS ESTRUTURAS 
DE DADOS, DAS INTERFACES E DOS ALGORITMOS para deixá-las alinhadas. 
● O processo para o PDC abrange atividades que reduzem lentamente a abstração com o qual um 
software é representado. Em suma, o PDC REPRESENTA O SOFTWARE EM UM NÍVEL DE 
ABSTRAÇÃO PRÓXIMO AO CÓDIGO. 
O intuito é transformar informações de modelos de arquitetura e requisitos em uma representação de projeto 
que nos dê detalhes suficientes para orientar a atividade da construção, ou seja, a codificação e os testes. 
 
COMPONENTIZAÇÃO → Tem como ideia central projetar componentes que possam ser facilmente 
integrados em diferentes sistemas, proporcionando agilidade no processo de desenvolvimento e permitindo a 
criação de soluções mais flexíveis e escaláveis. (Reutilização de componentes) 
 
Unidades de softwares reutilizadas: 
● Reúso do sistema da aplicação: todo o sistema pode ser reusado por incorporação a outros 
sistemas sem mudanças, pela configuração da aplicação para diferentes clientes ou pelo 
desenvolvimento de um conjunto de aplicações com uma arquitetura comum, mas adaptada a clientes 
específicos. 
● Reúso de componentes: componentes de uma aplicação que variam desde subsistemas a simples 
objetos podem ser reusados. 
● Reúso de objetos e funções: componentes de software que implementam uma única função, como 
uma função matemática ou uma classe de objeto, podem ser reusados. 
 
AULA 4 - PROJETO DE INTERFACE DA ARQUITETURA DE SISTEMAS 
Uma INTERFACE → É a chave para garantir a usabilidade de tais dispositivos, é o elo de comunicação 
entre humanos e máquinas, permitindo-lhes interagir de forma eficaz e intuitiva. No desenvolvimento de 
uma interface, diversos aspectos precisam ser analisados cuidadosamente, como as tarefas que serão 
realizadas por meio dela, os usuários que a utilizarão e o ambiente no qual estará inserida, entre outras 
variáveis relevantes. 
A INTERAÇÃO é a comunicação entre o ser humano e a máquina e a INTERFACE é o meio que permite 
essa comunicação. 
Usabilidade: Eficiência e a facilidade de se empregar as funcionalidades desses mecanismos a fim de 
resolver problemas cotidianos 
● Um programa com boa usabilidade é aquele que oferece uma interface intuitiva, possibilitando a 
execução de tarefas de forma eficiente e sem frustrações pela falta de compreensão sobre como 
proceder. 
 
Padrões que se aplicam ao design de interfaces na área de Engenharia de Software: 
AFFORDANCES → Representam PADRÕES CONHECIDOS que facilitam a usabilidade. 
● Elas estão presentes em diversos objetos e elementos que usamos no dia a dia, como botões, ícones 
e menus, e são aplicadas de forma similar no design de interfaces. 
● O conhecimento dos conceitos de affordance é essencial para o desenvolvimento de interfaces 
intuitivas; 
● Padrões conhecidos e coerentes facilitam interações e reduzem dificuldades. 
TIPOS DE AFFORDANCES: 
● EXPLÍCITA: Representada por elementos com linguagem verbal, como textos ou mensagens que 
indicam claramente ações possíveis, como “Clique aqui” para um link. 
● CONVENCIONAL: Utilizando elementos familiares, como palavras sublinhadas em azul, que sugerem 
links para outras páginas com mais informações. 
● METAFÓRICA: Emprega objetos ou elementos reais como referência, a exemplo do ícone de lixeira 
para indicar a ação de deletar. 
● OCULTA: Disfarçada inicialmente, revela-se quando determinada condição é atendida, comoopções 
de zoom que aparecem apenas quando o cursor passa sobre uma imagem. 
 
O MODELO DE USUÁRIO, em suma, estabelece o perfil dos usuários finais do sistema, realizando um 
levantamento de suas características (por exemplo, idade, gênero, níveis de educação, dentre outros). Em 
sua maioria, os profissionais da equipe de projeto estão empenhados em satisfazer os usuários, e esse 
modelo ajuda na percepção de quem verdadeiramente são esses usuários. 
● Temos que identificar os usuários, visto que estes são os clientes do engenheiro e vão efetivamente 
utilizar as ferramentas. Além disso, é preciso identificar as tarefas que esses usuários realizam no 
desempenho de suas funções e, por último, os requisitos do ambiente onde esse usuário 
desempenha suas funções. 
O MODELO MENTAL é uma imagem do 
sistema delineada na mente dos usuários. 
Dependendo do nível de conhecimento do 
usuário, essa imagem pode ser muito 
superficial; usuários com experiências mais 
variadas podem gerar um modelo mental mais 
completo. 
 
O MODELO DE IMPLEMENTAÇÃO 
combina a aparência e a percepção da 
interface com as informações de apoio que 
descrevem a interface. O fato de o modelo 
de implementação e o modelo mental 
possuírem similaridades indica que os 
usuários se sentirão à vontade com o 
software e vão utilizá-lo de maneira eficaz. 
Em suma, esses modelos citados são 
abstrações das funções que o usuário 
exerce, pensa ou deveria estar realizando; 
ou seja, é possível afirmar que, conhecendo o usuário, você terá a percepção das tarefas que este realiza. 
 
O PROCESSO DE ANÁLISE E PROJETO DE 
UMA INTERFACE pode ser representado 
utilizando um modelo em espiral. A escolha do 
modelo em espiral se dá pelo fato de que cada 
validação junto ao usuário pode gerar a 
descoberta da necessidade de elaboração de 
requisitos adicionais, para que a interface 
contemple os modelos mencionados 
anteriormente. A cada interação, esse conjunto 
de processos pode ser repetido, até que a 
interface seja satisfatória. 
 
AULA 5 - PADRÕES DE PROJETO DE ARQUITETURA DE SISTEMAS 
O objetivo do processo de desenvolvimento de software é satisfazer as necessidades dos clientes/usuários 
do sistema. Para tanto, é preciso analisar os requisitos do sistema e projetar e implementar um código 
padronizado para evitar erros e falhas. 
PADRONIZAR consiste em empregar técnicas e padrões que auxiliam no desenvolvimento e aumentam a 
produtividade, a segurança e a qualidade no projeto. Um PADRÃO é um molde, um exemplo, um protótipo, 
um paradigma ou uma referência de algo a seguir. Um PROJETO é um desenho, uma planta, um 
esquema, um plano ou um programa. 
PADRÃO DE PROJETO → Comumente conhecidos como design patterns, são modelos, isto é, referências 
aplicadas ao projeto, trazendo soluções para problemas específicos do desenvolvimento do projeto 
de software orientado a objetos. 
● Por meio dos design patterns, é possível definir nomes, descrever o problema e a solução a ser 
aplicada ao projeto. Eles trazem exemplos de implementações e uma organização geral de 
classes e objetos. 
● Esses Padrões de Projeto são referências aplicadas ao projeto que trazem soluções para problemas 
específicos encontrados durante o processo de desenvolvimento. Pode-se enxergá-los como soluções 
já testadas para determinados problemas, oferecendo uma base sólida para a criação de software. 
Conhecer e dominar os padrões de projeto possibilita o desenvolvimento de soluções cada vez 
melhores e mais eficientes, além de promover a reutilização de soluções já estabelecidas. 
 
BENEFÍCIOS dos Padrões de Projeto: 
Reutilização de soluções e arquiteturas; Reduzem a complexidade do projeto; 
Tornam o software mais flexível; Padronizam a linguagem de programação utilizada; 
Favorecem a manutenção do código ao longo do tempo. 
 
No entanto, diante de mais de vinte padrões disponíveis para escolha, encontrar o padrão de projeto 
adequado ao software pode ser um desafio. 
● É fundamental seguir critérios bem definidos para solucionar os problemas do projeto de forma 
eficiente, como os critérios a seguir: 
Todo Padrão de Projeto possui: 
● Nome: descreve a essência do padrão; é uma referência para poder escrever o problema do projeto. 
● Objetivo: descreve como o padrão atua, em que modelo de software se aplica. 
● Problema/Aplicabilidade: descreve o problema, em que situação se aplica o padrão. 
○ Surgem durante o desenvolvimento do projeto, podendo ser uma dificuldade em desenvolver 
ou apenas um desafio. 
● Contexto: descreve uma situação que complemente o problema e em que o padrão será aplicado. 
○ Determina qual padrão deve ser aplicado para a resolução do problema. 
● Solução: descreve a solução; é uma descrição abstrata de um problema e de como as classes e os 
objetos o resolverão. 
○ Surge com a escolha do padrão (pattern) adequado ao projeto em questão. 
● Consequências: descreve as vantagens e desvantagens da utilização do padrão; são críticas para a 
avaliação de alternativas de projetos e a compreensão de custos e benefícios para aplicação no 
software desenvolvido. 
 
Os PADRÕES GoF, ou Padrões de Projeto GoF, são um conjunto de 23 padrões. Esses padrões são 
soluções reutilizáveis para problemas comuns de design de software orientado a objetos. Eles facilitam a 
reutilização de soluções, reduzem a complexidade do projeto e promovem boas práticas de programação. 
 
TIPOS DE PADRÕES DE PROJETO: Segue abaixo os 3 grupos de Padrões de Projetos GoF existentes que 
são subdivididos em mais padrões, totalizando 23. 
● CREATIONAL PATTERNS (Padrões de criação) → O objetivo desse tipo de padrão é a abstração da 
instância de objetos. É possível criar um objeto sem se preocupar com o todo envolvido na criação 
desse componente. 
○ Esse padrão abstrai ou adia o processo de criação, tornando o sistema independente de como 
os seus objetos são criados. 
● São 5 PADRÕES DE CRIAÇÃO: 
○ Abstract Factory: fornece uma interface para a criação de conjuntos de objetos relacionados 
ou dependentes, sem precisar especificar sua classe. 
○ Builder: separa a construção de um objeto complexo da sua representação. Possibilita que 
seu processo de construção crie diferentes representações. 
○ Factory Method: define a interface para a criação de um objeto, mas são as subclasses que 
decidem qual classe deve ser instanciada. 
○ Prototype: especifica os tipos de objetos a serem criados usando uma instância prototípica e 
criando objetos copiando esse protótipo. 
○ Singleton: garante que a classe tenha somente uma instância e fornece um ponto global de 
acesso a ela. 
● STRUCTURAL PATTERNS (Padrões de estrutura) → O objetivo desse padrão é a organização e a 
estruturação das classes e dos seus relacionamentos com os objetos. 
○ Ao contrário do padrão de criação, o padrão de estrutura é voltado para os objetos, 
descrevendo maneiras de montá-los, isto é, a maneira como as classes e os objetos serão 
compostos para formar estruturas maiores. A flexibilidade obtida pela composição de objetos 
provém da capacidade de mudar a composição em tempo de execução. 
 
● São 7 PADRÕES DE ESTRUTURA: 
○ Adapter: converte a interface de uma classe em outra interface esperada pelo cliente. O 
Adapter permite que as classes trabalhem em conjunto para promover essa mudança. 
○ Bridge: separa uma abstração da sua implementação, permitindo uma variação individual de 
cada uma. 
○ Composite: compõe objetos em estruturas hierárquicas, como árvores. Trata objetos 
individuais e composições de objetos de forma uniforme. 
○ Decorator: atribui de forma dinâmica responsabilidades adicionais a um objeto. 
○ Façade: fornece uma interface unificada para um conjunto de interfaces em subsistema. 
○ Flyweight: suporta grandes quantidades de objetos de forma eficiente, por meio de 
compartilhamento. 
○ Proxy: fornece um objeto representante (surrogate) ou marcador de outro objeto. 
 
● BEHAVIORAL PATTERNS (Padrões de comportamento) → O objetivo é delegar responsabilidades, 
definindocomo os objetos devem se comportar e se comunicar. Esses padrões se concentram nos 
algoritmos. 
● São 11 PADRÕES COMPORTAMENTAIS: 
○ Chain of Responsibility: evita o acoplamento de remetente de uma solicitação ao 
destinatário, dando chance ao objeto para tratar a solicitação. 
○ Command: encapsula uma solicitação como objeto, permitindo parametrizar clientes com 
diferentes solicitações, enfileirando ou registrando os “logs” de solicitações. 
○ Interpreter: define para a linguagem uma representação gramatical dentro do interpretador. 
○ Iterator: possibilita o acesso sequencial dos elementos de uma agregação de objetos, sem a 
necessidade de expor sua representação subjacente. 
○ Mediator: define um objeto que encapsula a forma como um conjunto de objetos interage. 
○ Memento: captura e externaliza um estado interno do objeto sem violar seu encapsulamento, 
possibilitando restaurar para esse estado — por exemplo, um controle de históricos de ações. 
○ Observer: define uma dependência um-para-muitos entre objetos; quando um objeto muda, 
todos os seus dependentes são notificados e atualizados automaticamente. 
○ State: permite que o objeto altere seu comportamento quando o estado interno for modificado. 
○ Strategy: define uma família de algoritmos, encapsulando cada um e os tornando 
intercambiáveis. 
○ Template Method: define o esqueleto de um algoritmo em uma operação, postergando a 
definição de alguns passos para subclasses. 
○ Visitor: representa uma operação a ser executada sobre os elementos da estrutura de um 
objeto. 
 
AULA 6 - REÚSO DE SOFTWARE 
 
O REÚSO DE SOFTWARE → Consiste na prática de utilizar, em novos sistemas ou projetos, componentes 
de software já existentes (previamente desenvolvidos) a fim de economizar tempo, esforço e recursos, além 
de melhorar a qualidade e a eficiência do desenvolvimento. 
● Desenvolver um software do zero é um processo lento e caro, por isso investe-se em reúso. 
VANTAGENS DE REUTILIZAR: 
● Aumenta a qualidade e produtividade no desenvolvimento de software. 
● Menor tempo de desenvolvimento e exige menos esforço; 
● Redução de erros - uma vez que os componentes já foram testados e validados previamente, então 
reutilizá-los tem uma garantia maior de sucesso do que usar componentes novos ainda não testados; 
● Melhora a manutenção do software. 
DESVANTAGENS: 
● Falta de apoio de ferramenta - os ambientes de desenvolvimento podem não estar preparados para 
reutilização dos componentes (falta de estrutura); 
● Dificuldade em encontrar um componente reutilizável; 
● Custo maior — muitos componentes não são livres de licença; 
● Falta de conhecimento ou maturidade da equipe que está trabalhando no projeto novo. 
 
QUAL TIPO DE REÚSO UTILIZAR? 
● A escolha pela técnica mais apropriada vai depender dos requisitos do sistema, da tecnologia 
disponível, dos dispositivos de ativos reusáveis e do conhecimento e da experiência da equipe 
de desenvolvimento do projeto. 
 
TIPOS DE REÚSO DE SOFTWARE: 
● Código-fonte 
● Bibliotecas: São coleções de código que realizam tarefas específicas, como manipulação de dados e 
criptografia. 
○ Muito utilizado em POO, basta importar uma biblioteca que contém o código de uma função 
específica e é possível desfrutar das funcionalidades dessa biblioteca economizando várias 
linhas de código. 
● FRAMEWORKS: É uma abstração(estrutura sem implementação, é apenas uma “carcaça”) que 
une códigos comuns entre vários projetos de software provendo uma funcionalidade/estrutura 
genérica para criar uma aplicação (é um conjunto de códigos genéricos pré-prontos). Um 
framework pode atingir uma funcionalidade específica, por configuração, durante a programação de 
uma aplicação (essa estrutura pode ser implementada de acordo com com os parâmetros que o 
sistema precisar). 
○ É um kit de ferramentas com inúmeras funcionalidades implementadas, testadas e adaptadas 
para o reúso em outros projetos. 
○ VANTAGENS: 
■ Eficiência: o desenvolvimento é facilitado, uma vez que diversas linhas de código mais 
comuns estão prontas no framework. 
■ Custo: estão disponíveis gratuitamente no modelo open source (aceita alterações) 
■ Segurança: os frameworks são altamente testados, é seguro que vão funcionar. 
■ Apoio técnico: possuem documentação rica em detalhes e com explicação de sua 
aplicação. 
■ Padrões de codificação: Tem um padrão de escrita determinado por ele, o que facilita 
sua legibilidade, entendimento e manutenção. 
○ DESVANTAGENS: 
■ Dependência: Ao utilizar o framework, sua aplicação fica amarrada a ele; caso este 
seja descontinuado ou seja atualizado com quebra de compatibilidade, o projeto deve 
ser reestruturado. 
● Linhas de produto: Reutiliza componentes para criar uma variedade de produtos similares, mas 
adaptados a diferentes necessidades. 
○ Ex: Uma empresa de software que desenvolve sistemas de gerenciamento para diferentes 
setores pode criar uma linha de produtos de software que compartilha um núcleo em comum, 
reutilizando funcionalidades e essenciais, enquanto customiza partes específicas para cada 
setor. 
● Componentes: Envolve a reutilização de composição de componentes reutilizáveis pré-existentes. 
○ Os componentes são entidades executáveis e independentes que realizam tarefas específicas 
e podem ser combinados para construírem sistemas complexos. 
○ EX: Em um sistema de e-commerce, em vez de criar um sistema de carrinho de compras 
complexo, é melhor usar um componente de carrinho de compras (que é executável) que já foi 
desenvolvido e testado, acelerando o desenvolvimento e garantindo uma experiência segura 
de compra para os usuários. 
○ Os componentes precisam ser documentados para avaliar se atendem às necessidades da 
aplicação. Eles são testados, executados e utilizados. Assim, o nível de segurança é mais alto, 
e qualquer falha já é avisada e corrigida. 
● Templates e Geradores de Código: São ferramentas que produzem automaticamente partes do 
código baseado em padrões pré definidos. 
● Design 
 
SOLID → São princípios que garantem que os componentes sejam mais fáceis de manter, de estender e que 
estes não introduzem erros em outros locais do sistema. 
 
AULA 7 - PADRÕES ARQUITETURAIS MCV, MVP e MVVM 
O uso de PADRÕES DE ARQUITETURA é fundamental no desenvolvimento de software e aplicações que 
possuem a presença de um cliente, pois é necessário que estes padrões permitam que o cliente possa 
interagir com os dados e alterá-los, oferecendo formas e diretrizes para a organização da estruturação 
de códigos. Esses padrões proporcionam: 
● Separação clara das responsabilidades entre os componentes do sistema; 
● Facilitação da manutenção e da escalabilidade de softwares; 
● Colaboração entre os membros da equipe de desenvolvimento; 
● Facilita a compreensão (melhor legibilidade do código) e os testes; 
● Deixa o software mais reutilizável. 
 
As arquiteturas MVC, MVP e MVVM são padrões arquiteturais que têm a FUNÇÃO de ORGANIZAR O 
CÓDIGO e dividi-lo em níveis de desenvolvimento (camadas), em que as classes ficam separadas de 
acordo com suas responsabilidade (manipulação de dados e apresentação destes ao cliente) e eles também 
são responsáveis pela INTERCONEXÃO dos componentes de um sistema. Os padrões implementam os 
seguintes componentes ou camadas: 
● Modelo (model) — Armazena as regras de negócio 
○ Apresenta a funcionalidade principal e os dados da aplicação (em geral, dados e 
comportamentos); 
● Visão (view) — Armazena as classes de interface 
○ Trabalha sobre a camada de apresentação ao usuário, é a camada de interfaces gráficas que 
interagem com o usuário; 
● Controlador, Visão-Modelo ou Apresentador — Ligam logicamente as demais camadas 
○ Atua no contexto geral para interligar dados e comportamentos à camada de interface do 
usuário, cada qual com suas responsabilidades e sua implementação lógica. 
MODELO VISÃO CONTROLADOR (MVC - Model View Controller): 
● MODELO: Representa a camada de dados e lógica de negócios da aplicação. Ele cuida damanipulação e da gestão de dados; 
○ A classe Model representa o estado das coisas que têm atributos e operações, como: Produto, 
Pessoa, Usuário, etc. Todos os exemplos como representação das entidades do banco de 
dados. 
○ A comunicação entre o Modelo e a Visão não ocorre diretamente, mas, sim, por meio de 
eventos ou notificações. 
○ Ele representa o estado do aplicativo, mantém os dados e lida com operações de 
armazenamento, recuperação e processamento de informações. 
● VISÃO: É a responsável pela apresentação da interface gráfica ao usuário. Ela exibe os dados do 
modelo e interage com o usuário; 
○ Contém os componentes visuais e o código com a interface a ser mostrada ao usuário. 
Também é responsável pela interação do usuário com a aplicação, como a interação do 
usuário com botões, links, input e outras funções. 
○ Não faz nenhuma pesquisa diretamente no banco, ela apenas recebe, manipula e mostra os 
dados na interface gráfica definida ao usuário. 
● CONTROLADOR: Atua como intermediário entre o modelo e a visão. Ele controla o fluxo de 
informações, processa as entradas do usuário e atualiza o Modelo e a Visão conforme necessário. O 
controlador é o componente que toma decisões de negócios. Ou seja, ele analisa uma solicitação do 
usuário e determina o que será feito a partir disso. 
○ A Visão notifica o Modelo sobre as mudanças de estado 
mediante eventos gerados pelas interações do usuário na 
interface. Já o Controlador atua como um intermediário 
entre o Modelo e a Visão. Ele recebe as interações do 
usuário na interface, processa essas interações e atualiza 
o Modelo, que, por sua vez, notifica a Visão sobre as 
mudanças nos dados. 
○ O controlador é responsável por gerenciar a comunicação entre a visualização e o modelo. A 
visualização é atualizada pelo modelo por meio do controlador. 
OBS: Para uma aplicação muito simples com apenas uma ou duas telas, o MVC pode funcionar bem. Em 
aplicações mais complexas, quando suas atividades e classes de fragmentos tendem a crescer, torna-se 
difícil para o aplicativo evoluir. Esse padrão não facilita a manutenção nem os testes. 
 
MODELO VISÃO APRESENTADOR (MVP - Model View Presenter): 
● MODELO: Mantém os dados e a lógica de negócios. São os objetos com dados e ações que serão 
manipulados. 
● VISÃO: Responsável pela exibição dos dados ao usuário e pela captura de eventos de interação do 
usuário. 
● APRESENTADOR: Funciona como intermediário entre Modelo e Visão. Diferentemente do MVC, o 
Apresentador controla a lógica de apresentação e interação com o usuário, enquanto o Modelo 
permanece independente. 
○ Sua função é atualizar a visão quando o 
modelo é alterado e sincronizar o modelo em 
relação à visão. 
VANTAGENS: 
● Comparado com o MVC, apresenta maior testabilidade; 
● Alterar layouts é mais fácil; 
DESVANTAGENS: 
● Apresenta dependência entre camadas em duas direções, pois o Presenter tem consciência tanto da 
View, quanto do Model. 
 
MODELO VISÃO VISÃO-MODELO (MVVM - Model View ViewModel): 
● MODELO: Continua sendo a camada que gerencia os dados e a lógica de negócios. 
● VISÃO: É responsável pela apresentação da interface ao usuário. 
● VISÃO-MODELO: Funciona como um adaptador entre o Modelo e a Visão. Ele contém a lógica de 
apresentação, formatação de dados e gerenciamento de estados. O Visão-Modelo é especialmente 
útil em aplicativos com interfaces de usuário complexas e dinâmicas. 
VANTAGEM: 
● Permite o teste unitário entre cada camada sem utilizar ferramentas para teste de interface e tem alta 
manutenibilidade. É ALTAMENTE TESTÁVEL. 
● Essa divisão facilita a manutenção, a escalabilidade e a implementação de novos recursos, pois 
mantém a lógica de apresentação separada da lógica de negócios, permitindo modificações sem uma 
afetar a outra. 
● Além disso, o MVVM é eficaz em termos de desempenho, pois permite uma ligação bidirecional entre a 
View e o ViewModel. Isso significa que as atualizações na View são refletidas no ViewModel e vice-versa, o 
que proporciona uma experiência de usuário mais dinâmica e responsiva. 
DESVANTAGEM: 
● Para uma aplicação com pouquíssima complexidade, talvez a quantidade de código a mais que você 
vai ter que escrever possa diminuir sua produtividade. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
● MVP: A comunicação atua como a View, enquanto o Presenter atua como intermediário entre a View e 
o Modelo. A View envia eventos para o Presenter, que atualiza o Modelo, e então o Presenter atualiza 
a View novamente. 
○ No padrão MVP, o usuário interage com o sistema por meio de telas disponibilizadas pela View. 
As requisições do usuário são pegas na View e repassadas ao Presenter, que faz o pedido ao 
Model. O Model retorna todos os pedidos ao Presenter, que, por fim, encaminha para a View; 
por meio dela, os pedidos chegam ao usuário. 
○ O usuário interage com a interface acessando, por exemplo, um cadastro de usuário. O 
Presenter observa os eventos disparados pela View e requer os dados para efetuar o 
cadastramento, requerendo os mesmos ao Model. O Model retorna todos os dados que 
deverão ser preenchidos para efetuar corretamente o cadastro, como: nome, telefone, e-mail, 
login e senha. O Presenter retorna a View, que atualiza a tela com os campos que o usuário 
deverá preencher. 
○ MVP É UMA VIA DE MÃO DUPLA, DIFERENTE DO MVC, QUE É UM FLUXO SEGUE 
APENAS UM SENTIDO. 
● MVVM: A comunicação atua como a View, enquanto o ViewModel é responsável por gerenciar o 
estado da View e interagir com o Modelo. A View é ligada ao ViewModel por meio de vinculação de 
dados, o que permite que o ViewModel atualize a View diretamente. 
Embora o MVC seja o padrão mais antigo e bem estabelecido, o MVP e o MVVM foram criados como 
variações para suprir as deficiências do MVC. O MVP e o MVVM são projetados para tornar o código mais 
testável e mais fácil de manter, permitindo que a lógica de negócios seja isolada em um único componente. 
Esses padrões de arquitetura são importantes na hora de desenvolvimento de um aplicativo/software, pois, de 
acordo com o padrão utilizado, as necessidades específicas desse projeto em desenvolvimento podem ser 
melhor atendidas ou não. Um padrão arquitetural é uma forma preestabelecida de resolver um problema já 
conhecido; é o uso de uma solução já estudada e documentada para o problema que está na sua frente. 
 
AULA 8 - ARQUITETURAS DE SOFTWARES DISTRIBUÍDOS 
SD → É uma coleção de computadores interconectados por meio de uma rede formando um único sistema. 
Em SISTEMAS DISTRIBUÍDOS, o hardware, o software ou ambos são compartilhados em vários 
computadores, por meio de uma rede, pela qual eles coordenam suas ações e se comunicam a partir 
da troca de mensagens. Esses sistemas possuem algumas características bem peculiares, principalmente 
relacionadas à: 
● CONCORRÊNCIA: O sistema deve ter a capacidade de manipular e gerenciar recursos 
compartilhados, com serviços que disputam recursos atuando ao mesmo tempo. EX: Quando mais de 
um computador/usuário tenta acessar um mesmo recurso ao mesmo tempo, o sistema cria um 
controle para organizar uma fila de acesso de forma que todos consigam acessar o mesmo recurso. 
● INEXISTÊNCIA DE UM RELÓGIO GLOBAL: Se refere às dificuldades originadas das limitações 
que os computadores têm para conciliar seus relógios ao trabalharem em uma mesma rede, o 
que pode levar a problemas de sincronização entre as mensagens. 
● FALHAS INDEPENDENTES 
 
Uma das principais metas de um sistema distribuído é facilitar o acesso aos recursos, conectando 
usuários e aplicações e facilitando o compartilhamento de informações, de forma eficiente e controlada. 
● Um SD é muito mais eficiente em relação a um Sistema Centralizado, uma vez que, no SD, caso haja 
um erro em uma parte do sistema, as funcionalidades dessa parte são realocadas para serem 
realizadas por outra parte desse sistema que está atuando mais próxima e, assim, o sistema continua 
atuando como se nada tivesse acontecido, já no Sistema Centralizado, casotivesse havido um 
problema em uma parte do sistema, toda a rede fica prejudicada. Ou seja, SD SÃO MAIS 
TOLERANTES À FALHAS DO QUE OS SC. 
 
O Sistema Distribuído deve apresentar: 
● TRANSPARÊNCIA → Se refere ao fato de o usuário saber que está trabalhando com um sistema 
distribuído. Atualmente, sabemos que não é possível esconder isso dos usuários, visto que, uma hora 
ou outra, eles serão impactados por alguma questão proveniente das características do sistema, como 
uma demora para receber retorno de uma requisição. 
○ A ABSTRAÇÃO diz respeito aos usuários não notarem que sua aplicação está atuando de 
forma distribuída, ou seja, eles não notam que partes de um programa ou aplicação estão 
executando em diferentes computadores. 
● SISTEMA ABERTO → Deve permitir que outros desenvolvedores possam colaborar com facilidade, 
adicionando novos componentes e melhorando os existentes. E devem, também, devem seguir regras 
padronizadas, por exemplo: A semântica e a sintaxe dos serviços devem ser bem descritas, ou seja, é 
preciso ter bem especificado o formato, o conteúdo e o significado das mensagens transmitidas de um 
computador para o outro. 
● ESCALABILIDADE → Deve permitir o aumento da capacidade de recursos e usuários sem a 
ocorrência de gargalos de desempenho de software e hardware à medida que o sistema escalona. 
Com o tempo, é necessário que o sistema se amplie, mas que ele continue sendo fácil de gerenciar. 
○ Ela pode ser vertical (quando adicionamos mais memória e processamento a um mesmo 
servidor) e horizontal (quando adicionamos mais um servidor para dividir a carga). 
● PROTEÇÃO/SEGURANÇA → Há mais computadores a serem protegidos, e pode haver 
interceptação das informações por meio da rede; além disso, os dados podem ser interceptados, 
modificados ou fabricados por um invasor. Por esse motivo, devemos ter cuidado para que a política 
de proteção abranja todos os computadores e componentes do sistema. 
● QUALIDADE DE SERVIÇO → Pode ser garantida por um conjunto de ferramentas que ajudem a 
assegurar o desempenho das aplicações críticas, com confiabilidade e tempo de resposta que sejam 
aceitáveis para os usuários finais. 
● GERENCIAMENTO DE FALHAS → se um dos computadores armazena um dado crítico para a 
aplicação, devemos replicar esses dados periodicamente (fazer backups em outras máquinas), para 
que os dados possam ser restaurados em caso de falha no computador principal. 
 
A interação entre os computadores em um sistema distribuído é baseada em três paradigmas: 
● Nos dois primeiros, a comunicação é bilateral, dependendo de um remetente e de um destinatário — 
ou seja, trata-se de uma comunicação direta. Já na comunicação indireta, a comunicação ocorre 
usando uma terceira entidade. 
1. Comunicação entre processos 
2. Invocação remota 
3. Comunicação indireta: Possibilita o desacoplamento espacial (quando os remetentes não precisam saber 
quem serão os destinatários) e o desacoplamento temporal (remetentes e destinatários não precisam 
coexistir no tempo). 
 
Sistemas Distribuídos utilizam MIDDLEWARES, que funciona como uma camada de abstração da 
programação para mascarar as diferenças entre os computadores interconectados (principalmente de SO) e 
permitir a comunicação entre eles. 
PADRÕES DE ARQUITETURAS 
● MESTRE-ESCRAVO: É um modelo 
hierárquico apresentando um componente 
central (mestre) que aloca recursos, realiza a 
coordenação, as comunicações, o 
processamento e atribui tarefas individuais e 
mais específicas a outros componentes 
interconectados (escravos). Este é um 
modelo eficiente porque promove a 
distribuição da carga de trabalho e otimiza 
a utilização de recursos. 
○ É o tipo mais apropriado para sistemas que realizam tarefas complexas e necessitam de um 
tempo de resposta sincronizado (de tempo real). 
○ Aqui há apenas um nó primário (mestre) para vários nós secundários (escravos). 
● CLIENTE-SERVIDOR DUAS CAMADAS: As arquiteturas de duas camadas possuem um único 
servidor lógico e clientes que utilizam esse servidor. Possuem: 
○ Camadas lógicas (LAYERS) → Inclui aplicativos, serviços, middleware e Sistema 
Operacional. 
○ Camadas físicas (TIERS) → São as camadas de distribuição, que envolvem todo o nodo de 
processamento. 
 
● Nesse modelo, a lógica de negócios, incluindo as regras de aplicação, normalmente fica no 
SERVIDOR, enquanto o CLIENTE é responsável principalmente pela apresentação dos dados e 
pela interação com o usuário. 
○ Há 2 formas de configurar essa arquitetura: 
○ CLIENTE MAGRO: O cliente trata apenas da camada de apresentação, e as demais são 
responsabilidade do servidor. Normalmente, a apresentação utiliza um navegador Web. 
○ CLIENTE GORDO: o cliente é responsável por executar uma parte ou mesmo todo o 
processamento, enquanto o servidor fica responsável pelo banco de dados e pelo 
gerenciamento dos dados. 
○ EX: Os cientistas de dados desenvolvem aplicações de aprendizado de máquina e se 
beneficiam do uso de GPUs (Unidades de Processamento Gráfico) para acelerar o 
processamento das suas aplicações. Uma das formas de fazer isso, é instalar todo o ambiente 
da linguagem de programação (normalmente Python) em um computador local, que possua 
uma GPU própria. Nesse caso, estamos utilizando uma arquitetura no modelo cliente gordo 
(pois o cliente executa toda parte do processamento). Por outro lado, há a opção de utilizar a 
ferramenta Web disponibilizada gratuitamente pelo Google, a Colaboratory (ou Colab), ou 
ainda montar um servidor com GPUs e fazer acesso remoto. Nesse último caso, o modelo 
utilizado é o cliente magro (pois o cliente usa apenas a camada de apresentação, interface). 
● CLIENTE-SERVIDOR MULTICAMADAS: Nessas arquiteturas, cada camada do sistema é um 
processo separado. Cada camada pode ser executada em um computador diferente, e isso 
permite que os servidores processem muitas transações. São as arquiteturas que possibilitam maior 
escalabilidade, pois é possível adicionar mais computadores para aumentar o poder de 
processamento ou melhorar o tempo de resposta do serviço. Usada em aplicações de grande porte, 
em que o servidor fica responsável por processar uma quantidade muito grande de informações. 
● COMPONENTES DISTRIBUÍDOS: Possibilita que bancos de dados e sistemas diversos sejam 
combinados. Nela, o sistema é formado por um conjunto de componentes, no qual cada um fornece 
uma interface para uma coleção de serviços. Utilizam middlewares para a comunicação entre si. 
○ Essa arquitetura permite maior flexibilidade ao projetista, que não precisa tomar decisões 
de hardware logo no início do projeto. Elas facilitam a adição ou replicação de componentes, e 
sua reconfiguração é mais dinâmica. 
○ Ex: Os containers permitem que você crie ambientes separados, sendo executados sobre o 
mesmo sistema operacional, mas no qual um ambiente pode ficar totalmente isolado do outro, 
cada um tendo suas configurações, ocupando disco, memória e outros recursos de um 
servidor de forma isolada. Eles são a evolução das máquinas virtuais, pois compartilham a 
camada do sistema operacional. 
● PONTO A PONTO (P2P): São sistemas baseados em um modelo não centralizado, em que qualquer 
nó da rede executa uma cópia da aplicação e pode realizar o processamento. Nessas 
arquiteturas, os clientes trocam informações diretamente entre si, e pode haver um servidor que 
apenas se presta ao papel de “apresentar” os clientes uns aos outros. 
● As máquinas atuam como cliente e como servidor ao mesmo tempo. 
 
 
 
 
 
 
 
 
 
 
 
 
AULA 9 - ARQUITETURAS ORIENTADA A SERVIÇOS 
 
A SOA (ARQUITETURA ORIENTADA A SERVIÇOS) → É um conceito fundamental no campo da TI que 
envolve duas principais interações: a exposição e o consumo de serviços (aquilo que, de fato, entrega valor 
para o cliente) por meio de web services. Essa abordagem desempenha um papel crucial na integração de 
sistemas e na disponibilização de funcionalidades de maneira eficiente e flexível. 
● A SOA é projetada para minimizar o acoplamentoentre os serviços. Isso significa que os serviços 
devem ser projetados de forma que tenham baixas dependências lógicas entre si. O acoplamento 
refere-se à dependência entre componentes de software, e uma das metas da SOA é criar sistemas 
de software bem estruturados e flexíveis, através da composição de serviços que sejam 
independentes 
● Não é tão fácil migrar um modelo de arquitetura para a SOA, pois: 
○ A SOA é cara, porque pressupõe mudar a forma de modelar algo que já está pronto; 
○ Nem sempre vale a pena propor uma nova arquitetura para algo que já está em pleno 
funcionamento. 
● BARRAMENTO DE SERVIÇO (ESB) 
→ Trata do projeto, da 
implementação e da implantação de 
serviços, por meio da SOA. 
○ É o coração da SOA, por 
meio dele, podemos prover 
comunicação entre diversos 
sistemas, plataformas, 
aplicações e, inclusive, entre 
tecnologias diferentes. 
○ Atua como MIDDLEWARE. 
 
● Embaixo tem-se os provedores dos serviços (servidores), o ESB recebe esses serviços 
e os distribui para os consumidores (clientes) que precisam ter acesso a eles. 
 
A comunicação em um ESB é realizada principalmente por meio de XML e web services. O barramento 
de serviço representa o local onde os serviços estão interconectados (uma centralização) como um 
repositório para consumo. Atua como um intermediário para facilitar a comunicação entre serviços 
distribuídos. O ESB oferece recursos de roteamento, transformação e mediação de mensagens, 
garantindo a integração flexível e confiável entre sistemas heterogêneos. 
● EX: Suponha que um data warehouse (DW) precise acessar um dado em um sistema departamental, 
para prover um serviço. Então, em vez de consultar o dado diretamente (consultar um CPF, por 
exemplo), via componente ou base de dados, a requisição da consulta ocorre diretamente ao ESB, e 
este se comunica com a base, que retorna o dado esperado (ex: o CPF). Logo, o DW é simplesmente 
um consumidor de um serviço de consulta a uma base de dados departamental, via ESB. Ou seja, é 
como se o dado fosse encapsulado para ser acessado pelos serviços disponibilizados no barramento. 
O registro dos serviços implantados ocorre como uma base de dados de informação. Quando um sistema, por 
exemplo, deseja consumir algum serviço, ele busca no registro do serviço (UDDI), a fim de verificar a 
especificação do serviço e localizá-lo. Essa comunicação, por sua vez, ocorre por meio do protocolo SOAP 
(simple object access protocol) ou do estilo arquitetural REST. 
● Logo, temos três colunas principais na SOA: 
○ UDDI, padrão responsável pelo descobrimento, que define como as informações sobre os 
serviços podem ser organizadas; 
■ Funciona como um repositório ou banco de dados de informações de web services. 
○ WSDL, responsável por definir como as interfaces dos web services serão representadas; 
○ SOAP, protocolo responsável pela comunicação e troca de dados entre web services. 
■ Por meio do SOAP, pretende-se garantir a interoperabilidade e a intercomunicação 
entre diferentes sistemas, a partir da utilização de uma linguagem (XML) e de um 
mecanismo de transporte (HTTP) que encapsula o SOAP. 
■ Todo SOAP é definido por 3 elementos: ENVELOPE, HEADER e BODY. 
WEB SERVICES → São Softwares/Tecnologias que permitem que diferentes sistemas se comuniquem e 
compartilhem dados de maneira padronizada pela internet, possibilitando a INTEROPERABILIDADE, ou 
seja, que aplicações independentes escritas em linguagens diferentes e que possuem sistemas operacionais 
diferentes interajam de forma coesa e sem complicações. 
● Funcionam como uma forma de implementar Arquitetura Orientada a Serviços (SOA); 
● São componentes que permitem às aplicações enviar e receber dados em formato XML. Cada 
aplicação pode ter sua própria “linguagem”, que é traduzida para uma linguagem universal, o formato 
XML (que possui os padrões SOAP e REST) e que permite que essas aplicações se comuniquem. 
● MOTIVOS PARA USO: 
○ Padronização no retorno de cada requisição de serviços; 
○ Cada Web Service realiza uma função específica e autônoma; 
○ Deixam as integrações mais simples, permitem que diferentes partes de um sistema possam 
ser integrados sem a necessidade de modificar todo o sistema; 
○ Suportam comunicação assíncrona: onde uma aplicação pode fazer uma solicitação e 
continuar a executar suas tarefas, sem a necessidade de esperar sua solicitação ser atendida 
primeiro. 
○ São seguros, permitem escalabilidade e uma melhor manutenção; 
● EXEMPLO: 
○ Um Cliente, por exemplo, um celular que acessa um URL http://www.server.com/… é 
encaminhado para um Web Service que, por sua vez, consulta um Banco de Dados. O BD 
possui essa informação de acesso que o Cliente está requisitando e envia uma resposta para o 
Web Service, que envia essa resposta para o Cliente em formato XML. 
○ EX2: Em um sistema de uma loja online, quando o Cliente digita o seu CEP, é feita uma 
requisição de qual o endereço aquele CEP se refere, então essa requisição é enviada para o 
Web Service, que a repassa para o BD e o BD atende essa requisição e retorna para o Web 
Service a resposta com o nome da rua referente àquele CEP, o WS, por sua vez, retorna essa 
resposta no formato XML para o Cliente que, por fim, pode ter acesso ao nome de sua rua e o 
valor do frete para seu endereço. 
○ Ou seja, o Cliente só tem acesso ao Web Service, o Web Service é quem se comunica com o 
Banco de Dados. 
● Há 2 tipos de Web Services: 
○ SOAP → Segue um padrão mais antigo; 
■ É um PROTOCOLO (um conjunto de regras que ensinam como fazer algo) rígido que 
sempre usa XML para mandar e receber as mensagens no modelo cliente-servidor e 
definir a estrutura dessas mensagens; 
■ É um protocolo de comunicação independente que pode ser usado em qualquer 
linguagem de programação, em qualquer plataforma e com qualquer protocolo de 
transporte (HTTP, FTP, UDP etc) 
○ REST → Mais utilizado hoje em dia, pois trabalha diretamente sob o protocolo HTTP; 
■ É um ESTILO ARQUITETURAL, não um protocolo. 
■ Ao contrário das alternativas anteriores, REST não é uma interface específica em 
uma SOA como WSDL, UDDI ou SOAP. Em vez disso, REST é um conjunto de 
princípios e restrições de design aplicados a recursos na web. 
■ Tem melhor performance em relação ao SOAP, possui regras menos rígidas do que o 
SOAP; 
■ É mais flexível, já que usa os verbos HTTP como GET, POST, PUT ou DELETE para 
manipular recursos, diferentemente do SOAP que só pode usar o POST para enviar 
requisições. 
■ A quantidade de recursos necessários, como espaço e rede, para enviar um mensagem 
utilizando o REST é muito menor em relação ao SOAP; 
■ O consumo e o provimento dos serviços por meio da web ocorre de maneira mais 
rápida e simples. 
 
Em resumo, um web service é um sistema transformado em um serviço que deverá ser cadastrado e 
disponibilizado em um formato eletrônico padronizado via web. 
● Assim, se o cadastro foi feito no UDDI, as informações foram escritas em XML, a descrição foi 
feita em WSDL, e as trocas de mensagens foram realizadas por meio de SOAP, então temos a 
utilização e a implementação de uma arquitetura orientada a serviços 
 
AULA 10 - PROJETO DE SERVIÇOS WEB 
 
O PROJETO DE SERVIÇOS WEB permeia a utilização da orientação para a exposição e o consumo de 
serviços através da web, utilizando requisições encaminhadas por clientes via interfaces web, para que 
servidores descentralizados enviem respostas. Sendo assim, padronizações foram implementadas para 
que os projetos de serviços web alcancem a interoperabilidade: 
● O funcionamento de serviços na web não depende exclusivamente desta ou daquela tecnologia, mas, 
sim, da orquestração de múltiplas tecnologias (que estão sob o ponto de vista dos servidores 
(back-end, os códigos) e dos consumidores ou usuários (front-end, as interfaces gráficas) dos 
serviços). 
○ BACK-END: É a exposição de serviços na web, partem da orientação via Java; 
○ FRONT-END: É a interface de serviço. O usuário de um serviço acessa umainterface gráfica 
amigável, acreditando que isso tudo é bastante simples, sem perceber toda a infraestrutura de 
serviço web que está por trás. Precisa haver uma interface de serviço para que o usuário 
consiga consumir o serviço. 
 
COMO FUNCIONA UM PROJETO DE SERVIÇO WEB: 
● As REQUISIÇÕES de um CLIENTE são realizadas via web para SERVIDORES (cliente solicita, via 
web, um serviço ao servidor, que deve atendê-lo); 
○ Ou seja, se existe uma requisição, deve existir uma resposta à ela. 
● Existem várias formas de realizar uma requisição e várias formas de receber uma resposta. 
● O modus operandi de serviços web foi organizado em CAMADAS para facilitar a implementação de 
serviços web: 
○ CAMADA WEB: Possui a lógica web. 
○ CAMADA DE NEGÓCIO: Possui a lógica de negócio. 
○ Essa separação foi fundamental para o desenvolvimento de serviços web. 
Então, fica: 
● O Cliente faz uma requisição ao Servidor; 
● O Servidor vai oferecer serviços a esse cliente, e esses serviços retornarão em forma de resposta 
através de protocolos HTTP (protocolos de comunicação cliente-servidor, é a base de qualquer troca 
de dados na Web, o que significa que as requisições são iniciadas pelo destinatário, geralmente um 
navegador da web); 
● Quando essa requisição sai do Cliente, ela percorre uma CAMADA WEB e uma CAMADA DE 
NEGÓCIO; 
● Assim, o serviço já está disponível para ser consumido; 
● Dessa forma, a requisição é encapsulada via HTTP e encaminhada através do protocolo SOAP ou 
REST até o UDDI, que é onde é buscada a descrição do serviço, que está em WSDL; 
● Ou seja, o pacote HTTP, quando sai tanto do cliente, quanto do servidor, precisa ter a descrição sobre 
qual serviço deve retornar. Ex: Eu quero um serviço que retorne nome ou data ou idade. Então, 
necessariamente, quando chego com minha requisição no UDDI, encontro a minha descrição desse 
serviço em WSDL. 
○ UDDI → Repositório onde os serviços ficam com suas descrições armazenadas em WSDL. 
○ Chega-se, então, até o BARRAMENTO DE SERVIÇOS (ESB) e, por exemplo, percebe-se que 
o serviço desejado é o serviço XPTO, que pode estar no próprio barramento, ou numa base de 
dados, ou num sistema etc; 
○ Supõe-se que ele está em um barramento de serviços SOA: 
■ É feita a busca pelo serviço → Ele é retornado pela camada de negócios → Atravessa 
a camada web → Chegando, enfim, ao cliente (seu destino final) 
○ Sendo assim, ao realizar uma requisição, o cliente sempre terá uma resposta, mesmo que ela 
seja negativa ou indicando que aquela requisição não existe. 
○ Ou seja: A resposta do serviço, após verificar a descrição em WSDL no UDDI, é retornada 
através de SOAP ou REST e, por fim, o cliente consome o serviço que foi exposto no 
Barramento de Serviços. 
 
AULA 11 - ENGENHARIA DE SOFTWARE ORIENTADA A ASPECTOS 
Desenvolvimento de SISTEMAS ORIENTADO A ASPECTOS → É como um setor da engenharia de software, 
reunindo um conjunto de normas e métodos capazes de auxiliar em todas as etapas de desenvolvimento. 
ENGENHARIA DE SOFTWARE ORIENTADA A ASPECTOS → É uma teoria apresentada para a criação de 
um software que objetiva solucionar questões relacionadas ao reúso de software, tornando os 
programas mais fáceis de manter e reusar. 
● É um paradigma de programação de computadores que permite aos desenvolvedores de 
software separar e organizar o código de acordo com a sua importância para a aplicação. 
● Ela tem como referência as abstrações (aspectos) que introduzem a atividade de sistema, podendo 
ser solicitada em setores distintos dentro de um programa. Os aspectos encapsulam a atividade que 
convive com outra funcionalidade existente no sistema, sendo que eles são empregados em paralelo 
com outras abstrações. 
● A combinação/composição automática de objetos, aspectos e métodos alinhados com as 
características contidas no código-fonte do programa gera um programa executável orientado a 
aspectos. 
Existe uma complexidade visível na relação entre os atributos e os componentes de um programa na maioria 
dos sistemas considerados de grande porte. Um conjunto de componentes consegue implementar um 
único requisito, sendo que cada componente pode acrescentar elementos de requisitos variados. Na 
prática, isso implica afirmar que a alteração desses requisitos leva ao conhecimento e à mudança de diversos 
componentes. O reúso pode envolver sua alteração para remover um código extra que não esteja associado 
com a funcionalidade central dos componentes (Reusa um componente que realiza funções a mais do que é 
necessário serem realizadas no sistema atual). 
 
IMPLEMENTAÇÃO DO SOFTWARE POR MEIO DE SEPARAÇÃO DE INTERESSES 
É preciso organizar o software, de maneira que cada método ou procedimento realize apenas uma 
atividade, sem a preocupação de atuar em outros elementos do programa. 
● Assim, pode-se compreender cada item que compõe o programa, verificando os seus interesses 
específicos. Havendo a necessidade de alteração, esta será realizada em uma quantidade reduzida 
de elementos. 
É preciso deixar claro que os mecanismos de estruturação de programas apresentam problemas quando 
determinados interesses entram em conflito com outros. Essa transversalidade não pode ser visualizada por 
meio de mecanismos estruturados. Para auxiliar no gerenciamento desses interesses transversais, 
foram introduzidos os conceitos relacionados à engenharia orientada a aspectos. 
 
INTERESSES SÃO PENSADOS COMO UMA FORMA DE ORGANIZAR REQUISITOS. 
● É mais simples acompanhar interesses apresentados na forma de requisitos, de maneira unitária 
ou conjunta, com os elementos de programa relacionados visando a implementação desses 
interesses. 
ENGENHARIA DE REQUISITOS ORIENTADA A INTERESSES 
INTERESSES → Indicam os atributos dos stakeholders. A funcionalidade solicitada por um stakeholders, 
as políticas aplicadas à organização ou a mensuração da qualidade do serviço do sistema são alguns dos 
aspectos em que os interesses podem refletir. Isso implica em uma abordagem direcionada à engenharia de 
requisitos, que reconheça e especifique quais são os interesses distintos dos stakeholders 
 
INTERESSES TRANSVERSAIS → Podem interferir na implementação de outros requisitos inseridos no 
sistema. Interesses que afetam múltiplas classes e/ou métodos que modularizam (organizam por partes, 
separam) outros interesses de um sistema. São direcionados ao sistema de maneira completa. 
● Exemplos de interesses transversais: Qualidade de serviço, Rastreamento, Auditoria, Persistência, 
Distribuição e Tratamento de erros. 
 
Há diferentes TIPOS DE INTERESSES DE STAKEHOLDERS: 
Interesse Funcional → Está ligado a uma determinada funcionalidade a ser acrescida no sistema. 
● Interesses Centrais → Quando os interesses funcionais estão direcionados a atender aos próprios 
objetivos. São interesses funcionais e estão relacionados com o seu objetivo principal. 
● Interesses Funcionais de Ordem Secundária → Se caracterizam por envolver as atividades que 
dividem informações com os interesses centrais. Outra característica é serem solicitados para que o 
sistema consiga atender aos seus atributos não funcionais. Apesar de não abrangerem o sistema 
como um todo, é possível considerar que os interesses funcionais secundários são transversais. 
Normalmente, eles são ligados a conjuntos de interesses centrais que possibilitam a funcionalidade 
apresentada. 
Interesses de Qualidade de Serviço → Estão ligados ao desempenho não funcional do sistema. A 
disponibilidade, o desempenho e a confiabilidade são aspectos presentes nesses interesses. 
Interesses de Políticas → Acrescentam interesses relacionados às normas que envolvem negócios e 
segurança, por estarem em alinhamento com as políticas gerais que administram o uso de um sistema. 
Interesses do Sistema → Aspectos relacionados à manutenção e à configuração. Se relacionam com os 
requisitos do sistema como um todo. 
Interesses Organizacionais → Se alinham às prioridades e metas da organização, acrescentando a 
criação de um sistema