ARQUITETURAS E PADRÕES DE SOFTWARE II

Prévia do material em texto

Arquitetura e Padrões 
de Software
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel 
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
Projeto Orientado a Objetos a Diagramas Arquiteturais UML
Projeto Orientado a Objetos a 
Diagramas Arquiteturais UML
• Entender a aplicação de princípios e diretrizes de projeto orientado a objetos e representa­
ções dos diagramas arquiteturais utilizando notações UML.
OBJETIVO DE APRENDIZADO 
• Modelo de Objetos.
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
Modelo de Objetos
Ao estudar modelagem de objetos, é de suma importância compreender os significa-
dos de modelo e de objeto, ao mesmo tempo que é indispensável não se ater ao paradig-
ma orientado a objetos, isto é, um paradigma de programação para o desenvolvimento 
de sistemas de software orientados a objetos. Esse paradigma oferece princípios impor-
tantes para a modelagem de sistemas de software.
Qual a relação do paradigma orientado a objetos com a modelagem de sistemas 
de software?
Segundo Bezerra (2015), o paradigma da orientação a objetos pode ser visto como 
uma forma de resolução de problemas, permitindo visualizar um sistema de software 
como uma coleção de agentes interconectados denominados objetos, sendo que cada 
objeto deve ser responsável por realizar tarefas específicas. Para que um objeto execute 
determinadas tarefas de sua responsabilidade, provavelmente será preciso que ele inte-
raja com outros objetos, resultando na realização de uma tarefa computacional. Esse 
paradigma, adotado como técnica para a modelagem de sistemas, possibilita reduzir a 
diferença semântica entre o mundo real e os modelos construídos que visam representar 
essa realidade.
“Uma habilidade crucial no desenvolvimento OO é atribuir, habilmente, responsabili-
dades aos objetos de software” (LARMAN, 2007, p. 34). Dentre as diversas atividades 
na análise e projeto orientado a objetos, essa é atividade mais importante, pois requer a 
execução dos objetos, seja ao modelar um diagrama UML, ou ao programar um código 
e, consequentemente, influencia a robustez, manutenibilidade e reutilização de compo-
nentes do produto de software. Essa habilidade de atribuição de responsabilidades aos 
objetos é difícil de ser dominada, mas de grande importância para o desenvolvimento 
orientado a objetos (LARMAN, 2007). 
Os modelos que representam sistemas de software são equivalentes aos modelos que re­
presentam entidades concretas?
Antes de mais nada, é importante entender que os modelos possibilitam uma com-
preensão maior de algo que deve ser construído. Se a entidade a ser construída é algo 
físico, ou seja, um produto tangível como um carro, uma máquina, ou uma casa, os 
modelos podem ser elaborados de modo semelhante, tanto na forma quanto no forma-
to, porém em menor escala. Contudo, se a entidade a ser construída é um software, o 
modelo precisa ter uma forma diferente, pois se trata de um produto intangível, sendo 
assim, o modelo dever ser capaz de representar sua arquitetura, as informações que o 
software deve transformar e as devidas funções para realizar essa transformação, além 
de explicitar os requisitos que os usuários desejam para o sistema de software. Os mo-
delos de software precisam cumprir seus objetivos em diferentes níveis de abstração, 
descrevendo inicialmente o software sob a perspectiva dos stakeholders para depois 
descrevê-lo em um nível mais detalhado tecnicamente (PRESSMAN; MAXIM, 2016).
8
9
Importante!
Os modelos que apresentam uma perspectiva dos stakeholders como uma representa­
ção dos requisitos também são chamados de modelos de visão de alto nível. Os modelos 
que apresentam uma perspectiva mais técnica, como uma representação do projeto 
(design) também são chamados de modelos de visão de baixo nível. 
Não existe um único modelo correto, mais de um modelo pode ser adequado para um 
contexto particular. “O objetivo de qualquer modelo é transmitir informações. Para tan­
to, use um formato consistente. Considere o fato de não estar lá para explicá­lo. Ele deve 
ser autoexplicativo” (PRESSMAN; MAXIM, 2016, p.114).
Uma vez que o paradigma orientado a objetos foi relacionado à modelagem de siste-
mas, vamos agora lembrar brevemente o que é um objeto.
O mundo real é formado por coisas, podendo ser um cliente, uma loja, uma venda, 
um pedido, um fornecedor, entre outras. No paradigma da orientação a objetos, essas 
coisas do mundo real são chamadas de objetos. É natural as pessoas agruparem objetos, 
provavelmente porque esse processo mental de agrupamento ajuda na compreensão 
dessas coisas da realidade. Na terminologia da orientação a objetos, cada ideia agrupada 
é chamada de classe de objetos, ou simplesmente classe. Uma classe é uma estrutura 
que descreve os atributos e operações (métodos) comuns a um grupo de objetos. Sendo 
assim, pode-se entender uma classe como sendo um molde estrutural a partir do qual os 
objetos são construídos, ou simplesmente instanciados (BEZERRA, 2015).
A Figura 1 exibe uma visualização do paradigma da orientação a objetos enfatizando 
a representação de objetos. Nesse exemplo de sistema de software de controle de voo, o 
objeto avião se refere a um conceito do domínio do problema. Sendo visto como objeto 
do software, para que ele cumpra suas responsabilidades, o avião pode ter determinadas 
propriedades, como um atributo numDaCauda (número de identificação pintado num 
avião, tipicamente na cauda) e um método obterHistoricoDoVoo. Já numa linguagem de 
programação orientada a objetos, Java, por exemplo, o objeto de software em questão 
é implementado como uma classe Avião (LARMAN, 2007).
Figura 1 – A orientação a objetos enfatizando a representação de objetos
Fonte: Adaptado de LARMAN, 2007, p.35
Além de objeto, classe e instância, outros conceitos importantes para a compreen-
são do paradigma orientado a objetos são operação, mensagem e estado. De acordo 
com Bezerra (2015), a operação define uma ação que um objeto sabe realizar quando 
9
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
é solicitado. Um objeto pode ter diversas operações, mas vale ressaltar que ele não as 
executa de modo aleatório, portanto, para uma operação ser executada, é preciso haver 
um estímulo enviado a esse objeto. Se esse objeto é uma entidade ativa que representa 
uma abstração de algo do mundo real, faz sentido afirmar que ele tem condições de 
responder aos estímulos enviados a ele. Quando o objeto recebe esse estímulo, significa 
que esse objeto recebe uma mensagem solicitando que ele realize alguma operação.
Quando os objetos de um sistema estão trocando mensagens, o significado disso é 
que esses objetos estão colaborando entre si, objetivando a execução de uma determinada 
tarefa dentro do sistema de software no qual eles estão inseridos. Já o estado de um 
 objeto se refere ao conjunto de valores de seus atributos em um determinado momento 
(ou estado). Uma mensagem enviada a um objeto pode ter a capacidade de mudar 
o estado desse objeto. Apenas como exemplo, quando uma mensagem é enviada ao 
 objeto de uma classe Conta Bancária solicitando o saque de uma certa quantia, possivel-
mente o valor do atributo desse objeto relativo ao saldo da conta será modificado, o que 
significa que esse objeto está mudando de estado. Em contrapartida, uma mensagem 
enviada apenas para requisitar o valor atual do saldo do objeto de uma classe Conta 
Bancária não vai alterar o estado desse objeto. A Figura 2 simboliza as interações entre 
os objetos por meio da troca de mensagens para realizar uma tarefa.
Objetivo
Objetivo
Objetivo
Objetivo
Objetivo
Objetivo
Figura 2 – Objetos interagindo por meio da troca de mensagens
Fonte: Adaptado de BEZERRA, 2015, p. 8
E quanto ao conceito de abstração, termo este mencionado anteriormente, o que seria?
Segundo Bezerra (2015), a abstração é um processo mental que permite capturar os 
aspectos de maior interesse e ignorar os menos relevantes de algumacoisa. Esse proces-
so permite gerenciar a complexidade de um objeto, pois se concentra em abstrair suas 
características essenciais. É importante destacar que a abstração de algo depende da 
visão sobre a qual uma coisa é analisada, sendo que um aspecto dentro de um contexto 
particular pode ser importante para um, mas não relevante para outro. O paradigma 
orientado a objetos faz uso intensivo de abstrações. A Figura 3 exibe princípios do 
paradigma da orientação a objetos sendo vistos como aplicações de um princípio mais 
básico, ou seja, o princípio da abstração.
10
11
Orientação a Objetivos
Abstração
Encapsulamento Polimor�smo Generalização(Herança)
Composição
Figura 3 – Princípios do paradigma da orientação a objetos como aplicações de abstração
Fonte: Adaptado de BEZERRA, 2015, p. 9
Vale ressaltar que esta unidade não tem o propósito de explicar cada um desses con-
ceitos, o intuito é apenas enfatizar que os princípios do paradigma orientado a objetos 
são aplicações de um processo de abstração e que tais princípios estabelecem diretrizes 
para a construção de modelos no decorrer das atividades de análise e projeto orientado 
a objetos. 
Importante!
“Conhecer uma linguagem orientada a objetos (como Java) é um primeiro passo ne­
cessário, mas insuficiente, para criar sistemas orientados a objetos. Saber ‘pensar em 
termos de objetos’ é crucial” (LARMAN, 2007, p. 32).
Diante dos conceitos explanados surge a pergunta: como podemos representar os 
modelos de sistemas de software orientados a objetos?
Esta unidade descreveu que a funcionalidade de um sistema de software orientado a 
objetos é fornecida por meio de colaborações entre objetos. Visando um entendimento 
mais concreto, do ponto de visto externo ao sistema, os usuários (atores) visualizam 
saídas de processamento, por exemplo, resultados de cálculos, relatórios produzidos, 
confirmações de requisições realizadas através de interfaces gráficas; do ponto de vista 
interno, os objetos colaboram entre si para produzir os resultados visíveis externamente. 
Essa colaboração pode ser vista tanto de forma dinâmica quanto de forma estática. 
O aspecto dinâmico de uma colaboração entre objetos define a troca de mensagens entre 
esses e a reação aos eventos de sistema iniciados pelos atores, sendo visto pelo modelo de 
interações, representados, por exemplo, pelos diagramas de sequência e de comunicação. 
Já o aspecto estático de uma colaboração define como o sistema está estruturado 
internamente para que as funcionalidades externamente visíveis sejam executadas e os 
respectivos resultados exibidos. Esse aspecto é estático porque não apresenta informa-
ções no que tange às interações entre os objetos ao longo do tempo de execução. Além 
de estático, essa colaboração também é estrutural, porque a estrutura das classes de 
objetos e suas relações são representadas. 
O modelo de objetos representa o aspecto estático e estrutural dos objetos de uma aplica-
ção de software. Vale destacar que os aspectos dinâmicos e estáticos não são independentes, 
11
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
já que a construção de um modelo serve para acrescentar detalhes ao outro, ou seja, os mo-
delos dinâmicos e estáticos colaboram uns com os outros (BEZERRA, 2015).
Certo, mas como representar o modelo de objetos idealizado a partir de abstrações 
das coisas do mundo real?
O diagrama de classes da UML é um diagrama estático e estrutural, e contém nota-
ções propícias para representar o modelo de objetos. Vale lembrar que a UML possui 
uma variedade de diagramas, sendo alguns para representar os aspectos estáticos e es-
truturais e outros para expressar os aspectos dinâmicos e comportamentais do sistema 
de software.
Maiores informações sobre a Linguagem de Modelagem Unificada, do inglês Unified 
Modeling Language (UML) podem ser encontradas em: https://bit.ly/2JONIeR
Classes de Projeto
Vamos iniciar esta seção recordando o conceito de classe. De acordo com Bezerra 
(2015), uma classe é uma abstração das características de um grupo de coisas da reali-
dade. Na maior parte dos casos, as coisas do mundo real são bastante complexas para 
que todas suas propriedades sejam representadas em uma classe, portanto, apenas um 
subconjunto de características pode ser de interesse para a modelagem de um sistema 
de software, ou seja, uma classe deve representar uma abstração das propriedades mais 
relevantes da realidade em questão.
O modelo de objetos é refinado no decorrer do processo de desenvolvimento. Na 
prática, são três níveis consecutivos de detalhamento desse modelo: análise, projeto e 
implementação. O modelo de objetos de análise pode ser representado por meio de um 
diagrama de classes de análise, refletindo conceitos do domínio do problema, sem haver 
preocupação com aspectos técnicos. O modelo de objetos de projeto é refinado a partir 
do modelo de objetos de análise e representado por um diagrama de classes de proje-
to, porém esta versão do diagrama precisa descrever os objetos com detalhes técnicos 
(especificados como objetos de software), visando desse modo atender aos requisitos. 
Finalmente, o modelo de objetos de implementação é a materialização dos objetos de 
software, portanto é representado como classes codificadas em alguma linguagem de 
programação orientada a objetos.
Importante!
Não confunda modelo e diagrama, pois são conceitos distintos. Enquanto um modelo é 
uma representação simplificada de algo complexo do mundo real, um diagrama é uma 
representação visual de um modelo, sendo que um modelo também pode ser represen­
tado de outras formas.
12
13
Os conceitos de análise e projeto têm significados amplos, sendo mais bem qualifica-
dos no contexto estudado como análise e projeto orientado a objetos, respectivamente. 
No que tange à a nálise orientada a objetos, essa atividade tem o intuito de investigar o 
problema e os requisitos, essencialmente investigar os objetos conceituais do domínio 
de negócio. Em r elação ao projeto orientado a objetos, essa atividade tem o objetivo de 
buscar uma solução conceitual, especificamente com a definição dos objetos de software
e como eles devem colaborar para satisfazer aos requisitos. 
Vale lembrar que posteriormente os objetos de software são transformados em códi-
go, ou seja, a implementação representa o verdadeiro e completo projeto de desenvol-
vimento de software. Resumindo, e nquanto a análise deve fazer a coisa certa, o projeto 
deve fazer certo a coisa (LARMAN, 2007).
Importante!
“O primeiro problema do engenheiro em qualquer situação de projeto é descobrir qual é 
realmente o problema” (PRESSMAN; MAXIM, 2016, p. 116).
Em Síntese
• A classe de análise é vista como uma classe de negócio ou classe de domínio; represen­
ta um objeto conceitual do domínio;
• A classe de projeto é vista como uma classe de especificação ou classe de design; repre­
senta um objeto de software;
• A classe de implementação é a classe codificada numa linguagem de programação; 
representa um objeto de software implementado. 
Vamos agora apresentar um exemplo de transformação das classes de análise para 
classes de projeto. Para tal, vamos lidar com um processo de abstração de um cenário 
de locação de carro de um domínio de negócio referente à uma locadora de automó-
veis. A Figura 4 mostra uma versão do diagrama de classes de análise. Repare que este 
diagrama de classes representa, mesmo que de forma simples, os objetos (conceitos) do 
domínio de negócio e seus devidos relacionamentos.
Cliente
cpf
nome
telefone
email
dataRetirada
horaRetirada
dataDevolução
horaDevolução
valorLocação
modelo
chassi
cor
km
valorDiaria
1 1* *
Locacao Carro
Figura 4 – Versão do diagrama de classes de análise
Por sua vez, a Fi gura 5 exibe uma versão do diagrama de classes de projeto a partir 
do refinamento do diagrama de classes de análise mostrado na Figura 4. Repare que 
13
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UMLeste diagrama de classes enfatiza os objetos de software e a colaboração entre eles para 
atender ao cenário de locação de carro. A navegabilidade dos relacionamentos permite 
visualizar o objeto remetente das mensagens e os devidos objetos receptores. As classes 
também exibem seus atributos e operações, sendo cada uma dessas propriedades espe-
cificada com seu tipo e visibilidade. 
Resumindo, o nível de detalhamento da representação das classes de projeto é bem 
maior quando comparado à visão de análise.
Cliente Locacao Carro
• cpf: String
• nome: String
• telefone: String
• email: String
• dataRetirada: Date
• horaRetirada: Time
• dataDevolucao: Date
• horaDevolucao: Time
• valorLocacao: Currency
1 1* *
• modelo: String
• chassi: String
• cor: String
• km: int
• valorDiaria: Currency
+ getCpf() : boolean
+ getValorLocacao() : Currency + getValorDiaria() : Currency
Figura 5 – Uma versão do diagrama de classes de projeto
Na construção de sistemas de software orientados a objetos, o diagrama de classes é 
utilizado durante as atividades de análise e projeto para expressar os principais conceitos 
do software, representando a estrutura das classes em ambos os estágios de desenvol-
vimento. A análise vai se transformando em projeto conforme o desenvolvimento do 
software evolui. 
Em um processo de desenvolvimento iterativo e incremental, como por exemplo, o 
Processo Unificado (PU), a análise antecede o projeto em um primeiro momento, mas 
em uma determinada iteração as atividades de análise e projeto podem estar acontecen-
do concomitantemente. 
De qualquer forma, é importante saber que o modelo de casos de uso e o modelo 
de classes de análise costumam ser dois dos artefatos elaborados durante a atividade 
de análise de uma iteração em um processo iterativo e incremental. Apesar da análise 
 esclarecer o problema a ser resolvido e os requisitos, essa atividade não permite apresen-
tar uma visão completa do software para que a implementação tenha início, portanto, é 
durante o projeto de uma iteração que essas definições realmente são feitas. 
A meta do projeto orientado a objetos é encontrar alternativas para que o sistema 
de software a ser construído atenda aos requisitos funcionais e, ao mesmo tempo, às 
restrições definidas pelos requisitos não-funcionais (BEZERRA, 2015).
É claro que o projeto orientado a objetos não se concentra apenas em transformar o 
modelo de classes de análise para o modelo de classes de projeto. O que mais pode ser 
feito durante o projeto orientado a objetos?
As principais atividades a serem realizadas ao longo do projeto orientado a objetos, 
visando a construção do modelo de projeto com detalhes técnicos suficientes para im-
plementar o sistema de software são: 
• Refinamento dos aspectos dinâmicos; 
• Detalhamento dos aspectos estáticos e estruturais;
• Refinamento de aspectos arquiteturais;
14
15
• Definição das estratégias para armazenamento, gerenciamento e persistência 
dos dados;
• Realização do projeto de interface de usuário;
• Definição dos algoritmos a serem utilizados na implementação; 
• Definição dos padrões de , inclusive padrões de projeto a serem aplicados 
 (BEZERRA, 2015).
O modelo de projeto representa propriedades que auxiliam o time de desenvolvi-
mento a construir o software com eficiência, devendo incluir a arquitetura, a interface 
de usuário e os detalhes dos componentes. Enquanto o modelo de análise representa 
os requisitos dos stakeholders, o modelo de projeto oferece uma especificação concreta 
para o desenvolvimento do produto de software (PRESSMAN; MAXIM, 2016).
Importante!
Segundo Richard T. Dué, “O milagre mais comum da engenharia de software é a transição 
da análise para o projeto e do projeto para o código” (PRESSMAN; MAXIM, 2016, p. 225) .
O modelo de requisitos deve fornecer as informações necessárias para definir uma 
especificação completa do projeto de software. O modelo de requisitos, por meio de 
elementos baseados em cenários, elementos comportamentais e do projeto de classes 
de análise influencia diretamente a elaboração do modelo de projeto. 
A Figura 6 ilustra o fluxo de informações em uma visão de alto nível para transformar 
o modelo de requisitos (modelo de análise) no modelo de projeto, especificamente nos 
elementos baseados em classe, no projeto de arquitetura, no projeto de interfaces e no 
projeto de componentes. O fluxo apresentado permite um entendimento da transição da 
análise orientada a objetos para o projeto orientado a objetos. 
Vale destacar que o projeto de classes pode ocorrer paralelamente ao projeto da 
arquitetura de software e o detalhamento dessas classes é feito conforme cada com-
ponente de software é projetado. À medida que a arquitetura evolui, o nível de abstra-
ção é reduzido, pois cada classe de análise é transformada em uma classe de projeto, 
aproximando assim o modelo de projeto à implementação do software (PRESSMAN ; 
MAXIM, 2016).
15
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
Elementos baseados
em cenários
Casos de uso – texto
Diagramas de caso de uso
Diagramas de atividade
Diagramas de raias
Modelo de análise
Modelo de projeto
Projeto de componentes
Projeto de interfaces
Projeto de arquitetura
Elementos baseados em classes
Diagramas de classes
Pacotes de análise
Modelos CRC
Diagramas de colaboração
Diagramas de estados
Diagramas de sequência
Elementos
comportamentais
Projeto de
dados/classes
Figura 6 – Transformando o modelo de requisitos no modelo de projeto
Fonte: Adaptado de PRESSMAN; MAXIM, 2016, p. 226
O projeto orientado a objetos deve fundamentalmente levar em consideração as clas-
ses que vão sustentar os demais elementos do projeto. Uma vez que essa base foi de-
finida, a arquitetura tem condições de ser abstraída e representada de forma abstrata, 
sendo possível então realizar as demais tarefas de projeto (PRESSMAN; MAXIM, 2016).
Diretrizes interessantes e voltadas para a implementação de um Projeto Orientado a Obje­
tos, do inglês Object Oriented Design (OOD), especificamente os princípios SOLID (SRP, OCP, 
LSP, ISP, DIP) podem ser encontradas em: https://bit.ly/2IxB0At
Diagramas Arquiteturais UML
A importância do projeto (design) de software pode ser resumida em uma única 
 palavra: qualidade. 
É durante o projeto que a qualidade é incorporada à engenharia de software. O pro-
jeto tem o potencial de fornecer representações do software que podem ser avaliadas 
em termos de qualidade. 
O projeto é a maneira pela qual é possível transformar de forma precisa os requisitos 
dos stakeholders em um produto de software, tornando-se uma base para todas as de-
mais atividades de construção do software. 
Não havendo um projeto, surge o risco de se construir um sistema de software instá-
vel, ou seja, um software que tende a apresentar falhas quando pequenas modificações 
forem realizadas, um software difícil de ser testado, um software em que a qualidade não 
pode ser avaliada até chegar em um estágio mais avançado de desenvolvimento, sendo 
assim, quando o tempo já está quase no fim e muito dinheiro já foi gasto (PRESSMAN; 
MAXIM, 2016).
Sabendo da importância do projeto para o desenvolvimento de sistemas de software, 
de que forma o projeto orientado a objetos pode fornecer representações do software 
com condições de serem avaliadas em termos de qualidade?
16
17
A UML é uma linguagem pertinente para representar o modelo de projeto do software. 
A UML “é uma linguagem visual para especificar, construir e documentar os artefatos dos 
sistemas” (OMG, 2003a apud LARMAN, 2007, p. 39). O termo visual nessa definição é o 
ponto chave, já que a UML é uma linguagem diagramática padrão para modelar sistemas 
de software, principalmente sistemas de software orientados a objetos (LARMAN, 2007).
O projeto orientado a objetos resulta em uma descrição computacional do que o 
software deve fazer, de forma coerente, com a descrição realizada na análise, ainda mais 
quando restrições tecnológicas já foramestabelecidas no modelo de requisitos. 
Basicamente, o projeto consiste em duas atividades principais, o projeto de arquite-
tura e o projeto detalhado. N o decorrer do processo de desenvolvimento orientado a 
objetos, o projeto arquitetural consiste em distribuir as classes de objetos do sistema em 
subsistemas e seus componentes. Consiste também em distribuir esses componentes 
fisicamente pelos recursos disponíveis, como, por exemplo, um servidor. N esse caso, 
o s diagramas UML geralmente utilizados, porém não exclusivos, são os diagramas de 
pacotes, de componentes e de implantação. 
Vale recordar que o projeto de arquitetura costuma ser realizado pelo arquiteto de 
software. No projeto detalhado são modeladas as colaborações entre os objetos de cada 
subsistema com o objetivo de realizar suas funcionalidades (BEZERRA, 2015).
Com o intuito de apresentar um diagrama arquitetural, a Figura 7 exibe um diagrama de 
componentes com notações UML. Os componentes são conectados por meio de interfaces 
fornecidas e requeridas que utilizam notações gráficas de ‘bola’ e ‘soquete’, respectivamente. 
No exemplo apresentado, uma caixa registradora se conecta a um componente que 
se refere ao servidor de vendas através de uma interface de mensagens de vendas. Para 
auxiliar a rede, um componente fila de mensagens é introduzido para que a caixa se co-
munique com o servidor quando a rede estiver ativa, e com uma fila quando a rede esti-
ver inativa, desse modo, a fila poderá se comunicar com o servidor quando a rede estiver 
disponível. Como resultado disso, a fila de mensagens fornece a interface de mensagens 
de vendas para se comunicar com a caixa e exigir que essa interface se comunique com 
o servidor. O servidor é dividido em dois componentes principais, o processador de tran-
sações, que implementa a interface de mensagens de vendas e o driver de contabilidade, 
que se comunica com o sistema de contabilidade (FOWLER, 2005).
Figura 7 – Um exemplo de diagrama de componentes
Fonte: Adaptado de FOWLER, 2005, p. 135
17
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
Para visualizar outros exemplos de diagramas UML, você pode explorar o livro “UML Essen-
cial: um breve guia para a linguagem-padrão de modelagem de objetos”, de Martin 
Fowler, na Biblioteca Virtual da Universidade, disponível em: https://bit.ly/2W0gNGx
Um resumo dos diagramas UML pode ser encontrado em: https://bit.ly/3n4UMCp
No que diz respeito à arquitetura de software, como documentar arquiteturas a partir 
das visões arquiteturais utilizando o suporte visual dos diagramas UML?
Na Unidade anterior foram descritas as perspectivas arquiteturais do modelo de vi-
sões arquiteturais 4+1. Vale lembrar que cada visão reflete um ponto de vista arquitetural 
importante de um sistema de software.
Uma arquitetura de software pode ser documentada a partir das visões do modelo 
4+1 e dos diagramas UML, sendo que comentários adicionais no formato textual podem 
complementar a documentação arquitetural. 
O documento de arquitetura de software, do inglês Software Architecture Document 
(DAS), é um artefato importante do Processo Unificado (PU) que descreve as ideias de 
arquitetura, incluindo decisões de análise arquitetural, sendo assim um documento que 
ajuda no aprendizado dos desenvolvedores que necessitam entender as principais ideias 
do software. 
Um aspecto elementar das visões arquiteturais é que elas não descrevem tudo de um 
sistema de software a partir de uma perspectiva, na prática, essas visões apresentam as 
ideias essenciais a partir daquela perspectiva. 
Uma visão de arquitetura é uma estratégia útil de comunicação, ensino e raciocínio, 
descrita de forma textual e por diagramas UML (LARMAN, 2007). A tabela 1 relaciona as 
visões arquiteturais do modelo 4+1 com possíveis representações de diagramas UML para 
documentar arquiteturas no projeto de software. No contexto desta unidade, o modelo de 
projeto foi baseado no Processo Unificado (PU), processo este abordado anteriormente.
Tabela 1 – Relacionamentos entre visões arquiteturais e diagramas UML
Visão Arquitetural Diagramas UML
Lógica
• Diagrama de Pacotes;
• Diagrama de Classes;
• Diagrama de Interação.
Processo
• Diagrama de Classes;
• Diagrama de Interação.
Física • Diagrama de Implantação.
Desenvolvimento
• Diagrama de Pacotes;
• Diagrama de Componentes.
Caso de Uso
• Diagrama de Casos de Uso;
• Diagrama de Interação.
Fonte: Adaptado de LARMAN, 2007, p. 651­653
18
19
Para maiores detalhes sobre documentação da arquitetura de software usando UML e o 
modelo de visões arquiteturais 4+1, você pode explorar o capítulo 39 do livro “Utilizando 
UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao de-
senvolvimento iterativo”, de Craig Larman, na Biblioteca Virtual da Universidade.
Disponível em: https://bit.ly/2W0gNGx
Quanto à agilidade, a UML pode ser usada para projetar e documentar arquiteturas 
em projetos ágeis de desenvolvimento?
A modelagem ágil enfatiza a UML como rascunho, ou seja, os diagramas são repre-
sentados de forma incompleta e informal, muitas vezes desenhados à mão em quadro 
branco, porém buscando explorar o potencial das linguagens visuais para representar 
aspectos complexos do problema ou esboço de soluções. 
O fato de usar a UML como rascunho não significa que ferramentas propícias para 
modelagem não sejam úteis, apenas é uma forma de buscar um alto retorno de investi-
mento no que tange ao tempo que normalmente é curto.
Em suma, usar a UML como rascunho ao invés de modelar diagramas com tantos 
detalhes é uma prática ágil de modelagem. Os arquitetos experientes conhecem o se-
gredo da modelagem cujo propósito essencial é entender, não meramente documentar, 
significando que a modelagem pode e deve prover uma melhor forma de entendimento 
do problema e da solução, sendo assim, a finalidade da UML não é a de construir mui-
tos diagramas ricos em detalhes para serem entregues aos desenvolvedores de software
(LARMAN, 2007).
“Agilistas modelam, mas não gostam de falar sobre isso” (AMBLER, 2002 apud
PRIKLADNICKI; WILLI; MILANI, 2014, p. 164). Essa frase traduz um pouco do que se 
passa na comunidade ágil. 
De modo geral, os desenvolvedores ágeis gostam de falar sobre código, e não sobre 
modelos. Entretanto, pode ter certeza de que uma equipe ágil vencedora adota práticas 
de modelagem ágil, do inglês Agile Modeling (AM). 
Quer se queira ou não, os modelos ajudam na evolução das ideias e na discussão das 
soluções. Não há dúvidas de que profissionais que sabem abstrair soluções a partir de 
desenhos ou diagramas possuem qualidades importantes para o sucesso do projeto. 
A UML também tem seu espaço dentro do mundo ágil, contudo, não é utilizada para 
especificações formais, apenas como uma notação simplificada para representar classes, 
objetos, associações, atividades, estados, entre outros conceitos relevantes, seja na for-
ma de rascunho no papel ou de esboço em um quadro branco ou flipchart. 
Se todos os membros do time ‘falam’ UML, ela passa a ser o idioma adotado no pro-
jeto de desenvolvimento (PRIKLADNICKI; WILLI; MILANI, 2014). Apenas como exem-
plo, a Figura 8 mostra um rascunho no papel de um diagrama de atividades da UML.
19
UNIDADE Projeto Orientado a Objetos a Diagramas Arquiteturais UML
Figura 8 – Exemplo de rascunho de um diagrama de atividades da UML
Fonte: PRIKLADNICKI; WILLI; MILANI, 2014, p. 160
Informações sobre Agile Modeling (AM) contendo práticas eficazes para modelagem e docu­
mentação de sistemas de software podem ser encontradas em: https://bit.ly/2KcOFNJ
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
UML – Unified Modeling Language
https://bit.ly/3n69SHK
Blackboard – Cruzeiro do Sul Virtual
https://bit.ly/2W0gNGx
Agile Modeling
https://bit.ly/2KcOFNJ
 Leitura
Os Princípios de OOD
https://bit.ly/2IxB0At
Referência rápida de UML de Allen Holub
https://bit.ly/3n4UMCp
21
UNIDADE ProjetoOrientado a Objetos a Diagramas Arquiteturais UML
Referências
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3.ed. São 
Paulo: Elsevier, 2015.
FOWLER. M. UML Essencial: um breve guia para a linguagem-padrão de modelagem 
de objetos. 3.ed. Porto Alegre: Bookman, 2005.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman, 2007.
PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: 
AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de 
software. Porto Alegre: Bookman, 2014. 
22