Arquitetura de Software

Prévia do material em texto

Arquiteturas e 
Padrões de Software 
Responsável pelo Conteúdo:
 Prof. Me. Wilson Vendramel 
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
Contexto e Visões de Arquitetura
Contexto e Visões de Arquitetura 
 
 
• Entender a importância da arquitetura no desenvolvimento de sistemas de software.
OBJETIVO DE APRENDIZADO 
• Importância da Arquitetura de Software;
• Contexto da Arquitetura de Software;
• Arquitetura no Processo de Desenvolvimento;
• Modelo de Visões Arquiteturais 4+1;
• Processo Unificado.
UNIDADE Contexto e Visões de Arquitetura
Importância da Arquitetura de Software
Desde que o primeiro programa foi dividido em partes menores, isto é, em módulos, 
os sistemas de software passaram a ter arquiteturas e os desenvolvedores se tornaram 
responsáveis pelas interações entre esses módulos, além das características globais do 
software. Historicamente, os desenvolvedores adotavam um ou mais padrões arquite-
turais como estratégia de organização do software, porém esses padrões muitas vezes 
eram usados de maneira informal, fazendo com que as arquiteturas ficassem implíci-
tas no sistema de software construído (SHAW; GARLAN, 1996 apud PRESSMAN, 
 MAXIM, 2016, p. 253). Nos dias atuais, o cenário é diferente, pois uma arquitetura de 
software que vise eficiência precisa estar representada explicitamente nas aplicações de 
software, tornando-se um tema de muito interesse por parte da comunidade de enge-
nharia de software (PRESSMAN; MAXIM, 2016).
Como exercício de reflexão, imagine a arquitetura de um prédio. Quais seriam as proprieda-
des dessa arquitetura? O que você imaginou?
Ao imaginar a arquitetura de um prédio, é possível abstrair várias propriedades (atri-
butos). De forma mais ampla, é bastante provável que você pense em sua estrutura 
física, porém essa arquitetura vai além disso. A arquitetura é a maneira pela qual os di-
versos componentes do prédio são integrados para formar um todo consistente; é como 
a edificação se ajusta ao seu ambiente e se integra a outros edifícios vizinhos; é o prédio 
atingindo seu objetivo e atendendo às necessidades dos proprietários; é o lado estético 
da estrutura que causa um impacto visual e a combinação de cores, texturas e materiais 
para se criar a fachada e o ambiente interno; são detalhes como iluminação, piso e 
posição dos painéis. Em síntese, a arquitetura é arte, mas também algo mais, pois ela 
contempla muitas decisões, desde as menores até as maiores; algumas decisões tomadas 
no começo do projeto e que podem resultar em um impacto profundo sobre todas as 
ações seguintes; outras decisões adiadas até onde for possível, eliminando assim restri-
ções que poderiam levar a uma implementação inadequada de um estilo arquitetural 
(PRESSMAN; MAXIM, 2016).
Uma vez que você refletiu sobre a arquitetura de um prédio surge uma pergunta ele-
mentar: afinal, o que é a arquitetura de software?
Em uma visão mais simples, arquitetura de software é a organização de um sistema 
de software em componentes, também chamados de subsistemas ou módulos, estabe-
lecendo as interações entre esses componentes e as estruturas de dados utilizadas por 
eles. Por outro lado, sob uma ótica mais ampla, os componentes são generalizados para 
representar os principais elementos de um sistema de software e seus relacionamentos. 
A arquitetura não é o software em si, mas uma representação abstrata que permite 
avaliar a efetividade do projeto em relação ao cumprimento dos requisitos, considerando 
alternativas arquiteturais em um estágio em que realizar mudanças de projeto ainda é 
algo relativamente simples e que reduz os riscos relacionados à construção do produto 
8
9
de software. Vale ressaltar que em qualquer representação arquitetural os componentes 
são os elementos fundamentais a serem exibidos (PRESSMAN; MAXIM, 2016).
Certo. Se os componentes representam uma arquitetura de software, o que vem a ser 
um componente?
De acordo com Bezerra (2015), um componente de software pode ser visto como 
uma unidade existente em tempo de execução (runtime), podendo ser usado na constru-
ção de vários sistemas de software e, conforme a necessidade, ser substituído por outro 
componente que possua a mesma funcionalidade. Um componente fornece acesso aos 
seus serviços por meio de uma interface. 
Visando um entendimento mais concreto, o componente, no contexto do paradigma 
orientado a objetos, é um conjunto de diversos objetos, sendo que sua interface é cons-
tituída por um ou mais serviços que as classes desses objetos devem implementar. 
Para Sommerville (2019), um componente é um prestador de serviços reutilizável, visto 
como uma entidade executável independente e definida por suas interfaces, não havendo 
assim a necessidade de conhecer o código-fonte para utilizá-lo. O componente pode ser 
referenciado tanto como um serviço externo quanto inserido diretamente em um pro-
grama. Os serviços oferecidos pelos componentes são apresentados por sua interface, 
propiciando assim as interações entre eles. A interface do componente é definida por 
meio de operações parametrizadas e o seu estado interno não deve ser revelado.
A Figura 1 mostra uma representação abstrata de um componente de software e 
suas interfaces. Em um primeiro momento, os componentes têm duas interfaces relacio-
nadas, as interfaces que refletem os serviços que o componente fornece e as interfaces 
que retratam os serviços que o componente requer para funcionar corretamente. A 
interface “fornece” (provides) estabelece os serviços providos pelo componente, sendo 
que essa interface é a Application Programming Interface (API) do componente, pois 
ela define os serviços que podem ser acessados por um componente consumidor desses 
serviços. A interface “requer” (requires) define os serviços que outros componentes de-
vem prover para que o componente funcione de maneira correta, não comprometendo 
a independência desse componente, já que a interface “requer” não determina como os 
serviços devem ser fornecidos (SOMMERVILLE, 2019).
Interface ‘fornece’Interface ‘requer’
De�ne os serviços
necessários que
devem ser fornecidos
por outros componentes
De�ne os serviços
que são fornecidos 
pelo componente para 
outros componentes
Componente
Figura 1 – Interfaces de componentes
Fonte: Adaptado de SOMMERVILLE, 2019, p. 440
Para ficar mais claro a visualização das interações entre os componentes de software
por meio das interfaces “fornece” e “requer”, a Figura 2 exibe uma representação abstrata 
de uma composição de componentes de software que visam implementar o download
de imagens de uma câmera e o armazenamento dessas imagens em uma biblioteca de 
fotos. Vale ressaltar que o usuário também poderia interagir com esse exemplo de siste-
ma de software para descrever e catalogar a foto.
9
UNIDADE Contexto e Visões de Arquitetura
BibliotecaDeFotos
Adaptador
InterfaceComUsuario
GerenciadorDeImagens
getImagemadicionarItem
recuperar
entradaDoCatalogo
getEntradaDoCatalogo
Figura 2 – Composição da biblioteca de fotos
Fonte: Adaptado de SOMMERVILLE, 2019, p. 455
Por fim, mas não menos importante, há três fatores essenciais que enfatizam a im-
portância da arquitetura de software:
• A arquitetura de software fornece uma representação que simplifica a comunicação 
entre os stakeholders;
• A arquitetura de software evidencia logo no começo do projeto as decisões que podem 
causar um impacto profundo nas atividades seguintes de engenharia de  software;
• A arquitetura de software define um modelo arquitetural relativamente reduzido e 
passível de compreensão de como é a estrutura do software e como seus componen-
tes vão interagir entre si (BASS; CLEMENTS; KAZMAN, 2003 apud PRESSMAN; 
MAXIM, 2016, p. 254-255).
Outras informações a respeito da importância da arquitetura de software. 
Disponível em: https://bit.ly/3lH4yKr
Contexto da Arquitetura de Software
O projeto de arquitetura é um processo engenhoso que busca projetar a organização 
do software para atenderaos requisitos funcionais e não funcionais de um sistema de 
software. Não existe um processo de projeto padronizado; tudo depende do tipo de 
aplicação de software a ser desenvolvida, da experiência do arquiteto de software e da 
especificidade dos requisitos do sistema de software. 
Diante disso, é melhor considerar o projeto de arquitetura como um conjunto de 
decisões que devem ser tomadas, ao invés de entender o projeto arquitetural como uma 
 sequência de tarefas. Ao longo do projeto arquitetural, os arquitetos precisam tomar uma 
série de decisões estruturais que influenciam diretamente o desenvolvimento do produto 
de software. De acordo com o conhecimento e experiência, os arquitetos devem buscar 
responder questões fundamentais relacionadas às decisões arquiteturais, conforme mos-
tra a Figura 3 (SOMMERVILLE, 2019).
10
11
1. Existe uma arquitetura de
aplicação genérica que possa agir 
como um template para o sistema
que está sendo projetado?
4. Qual será a abordagem
fundamental utilizada para
estruturar o sistema?
2. Como o sistema será
distribuido entre os núcleos
ou processadores do hardware?
3. Quais padrões ou estilos
de arquitetura poderiam
ser utilizados?
5. Qual estratégia será utilizada 
para controlar a operação dos 
componentes no sistema?
6. Como os componentes
estruturais no sistema serão
decompostos em
subcomponentes?
7. Qual é a melhor organização
da arquitetura para entregar
os requisitos não funcionais
do sistema?
8. Como a arquitetura
do sistema deve ser
documentada?
?
Figura 3 – Decisões de projeto de arquitetura
Fonte: Adaptado de SOMMERVILLE, 2019, p. 150
A arquitetura de um sistema de software pode ser definida a partir de um deter-
minado padrão ou estilo arquitetural. Os padrões arquiteturais retratam a essência de 
uma arquitetura geralmente utilizada em diferentes aplicações de software. Ao tomar 
decisões relacionadas com a arquitetura de software, é importante saber da existência 
dos padrões mais conhecidos, em qual parte da arquitetura eles podem ser aplicados, 
além das vantagens e desvantagens de utilização de cada um deles. Por conta da relação 
entre os atributos de qualidade do sistema de software e sua arquitetura, a escolha do 
estilo arquitetural vai depender dos requisitos não funcionais exigidos pelo produto de
software, tais como desempenho, segurança, segurança da informação, disponibilidade 
e manutenibilidade (SOMMERVILLE, 2019).
Diante de tantas decisões arquiteturais a serem tomadas, qual profissional do time de 
desenvolvimento tem condições de desempenhar esse papel de tanta responsabilidade 
em um projeto de sistema de software?
Um profissional geralmente encontrado em grandes times de desenvolvimento de 
produtos de software complexos é o arquiteto de software. Esse profissional tem o papel 
de projetar a arquitetura do sistema como um todo, já que ele é o responsável por tomar 
decisões sobre quais subsistemas (componentes ou módulos) devem compor o software
e quais devem ser as interfaces entre esses subsistemas. Além de decisões globais, o 
arquiteto também deve ter a capacidade de tomar decisões técnicas detalhadas, que 
tendem a influenciar os requisitos não funcionais exigidos para o sistema de software
(BEZERRA, 2015).
Importante!
Não confunda as responsabilidades de um arquiteto de software com as um gerente de 
projeto. Ambos trabalham em conjunto na execução do plano de projeto de software, 
mas enquanto o arquiteto tem uma responsabilidade de cunho mais técnico, o gerente 
de projeto tem uma responsabilidade de ordem mais gerencial.
11
UNIDADE Contexto e Visões de Arquitetura
Informações sobre o papel do arquiteto de software, disponível em: https://bit.ly/3f6MTsW
Além da importância das competências técnicas (hard skills), é crucial que um 
 arquiteto de software também tenha outras qualidades como liderança, comunicação e 
empatia, isto é, competências comportamentais (soft skills). O conjunto de habilidades 
técnicas e comportamentais descreve de forma mais completa e consistente o verdadeiro 
papel do arquiteto de software na prática.
Informações importantes sobre as qualidades de um arquiteto de software. 
Disponível em: https://bit.ly/35EvS6t
Arquitetura no Processo 
de Desenvolvimento
Antes de entender a influência da arquitetura no desenvolvimento de software, vamos 
recordar brevemente o que é um processo de software.
O processo de software é um conjunto de atividades, ações e tarefas realizadas com 
o objetivo de se criar um produto de software. Uma atividade tem um objetivo mais 
amplo, sendo utilizada de forma independente do campo de aplicação, do tamanho e 
complexidade do projeto ou do nível de rigor com que a engenharia de software será 
aplicada; um exemplo de atividade é a de se comunicar com os envolvidos (stakeholders) 
do projeto. Uma ação, por sua vez, abrange um conjunto de tarefas que resultam em 
um artefato de software; um exemplo de ação é o próprio projeto arquitetural que pode 
gerar um artefato de software essencial, que é o modelo arquitetural. Por fim, uma ta-
refa tem um propósito mais limitado, mas muito bem definido e com resultado tangível, 
como um teste de unidade, por exemplo. 
Vale ressaltar que no contexto da engenharia de software, um processo não é uma 
prescrição rígida de desenvolvimento de software. Na realidade, o processo de desen-
volvimento pode ser adaptável, permitindo que a equipe de software escolha o conjunto 
de ações e tarefas necessárias. O importante é entregar o sistema de software dentro 
do prazo e com qualidade suficiente para atender às necessidades dos clientes e usuários 
(PRESSMAN; MAXIM, 2016).
Uma metodologia define a base para um processo de engenharia de software com-
pleto, contanto que haja determinadas atividades metodológicas genéricas aplicáveis a 
todos os projetos de software, desde o desenvolvimento de produtos de software de 
 pequeno porte e complexidade simples até a construção de sistemas de software gran-
des e complexos. Apesar dos detalhes do processo serem distintos para cada situação, as 
atividades metodológicas basicamente são as mesmas, compreendendo cinco atividades:
12
13
• Comunicação: o objetivo dessa atividade é compreender os objetivos desejados 
pelos stakeholders para o projeto e agrupar requisitos que ajudem a definir os re-
cursos e as funções do software;
• Planejamento: a intenção dessa atividade é simplificar o projeto de software, es-
tabelecendo um plano de projeto que guie a equipe no que tange ao trabalho a ser 
realizado, descrevendo as tarefas técnicas, os riscos possíveis, os recursos necessá-
rios, os artefatos gerados e o cronograma de trabalho;
• Modelagem: o propósito dessa atividade é elaborar modelos para se ter uma ideia 
global do software a ser desenvolvido, entendendo melhor os requisitos exigidos e o 
projeto de software, para assim atendê-los. Os modelos elaborados também ajudam 
na compreensão arquitetural (componentes e seus relacionamentos), além de outras 
características relevantes;
• Construção: o objetivo dessa atividade é construir o que foi projetado, combinando 
geração de código e testes que visem revelar erros de implementação;
• Entrega: o propósito dessa atividade é entregar o software ao cliente, seja como 
uma entidade completa ou como um incremento (uma parte do software já conclu-
ída) para operação e avaliação (PRESSMAN; MAXIM, 2016).
Importante!
Não existe processo de software certo ou errado; um processo de desenvolvimento pode 
ser adequado ou inadequado de acordo com o cenário de cada projeto.
A intenção deste material não é entrar em detalhes quanto a um processo de software, 
mas entender em qual momento deve haver a preocupação com o projeto da arquitetura 
no processo de desenvolvimento.
O projeto arquitetural pode ser abordado em diversos estágios do processo de desen-
volvimento, porém, sua importância aumenta consideravelmente durante a atividade de 
projeto (design) de software. Para Pressman e Maxim (2016), o projeto de softwarereali-
zado durante a atividade de modelagem contempla um conjunto de princípios, conceitos 
e práticas que permitem o desenvolvimento de um produto de software de alta qualidade.
Enquanto os princípios de projeto definem uma filosofia que conduz o trabalho a ser 
desempenhado, os conceitos de projeto devem ser compreendidos antes da aplicação das 
práticas de projeto, que por sua vez, orientam a elaboração de diversas representações do
software com o intuito de guiar a atividade de construção do sistema de software.
Importante!
Apesar do termo em inglês project ser bastante adotado para se referir a palavra projeto, o 
termo design é mais apropriado no contexto apresentado. Apenas para deixar mais claro: 
ao se fazer referência à gestão de um projeto de desenvolvimento de produto de software, 
ao projeto como um todo, a adoção do termo project é mais apropriada; contudo, ao se 
referir ao projeto da estrutura do software (projeto de arquitetura, projeto de interface, 
13
UNIDADE Contexto e Visões de Arquitetura
projeto de componentes, projeto de banco de dados), a palavra design é mais pertinente. 
Resumindo, a atividade de projeto (design) define como os requisitos exigidos para o pro-
jeto (project) de um sistema de software devem ser estruturados e implementados.
E qual a diferença entre as atividades de projeto (design) e implementação de software?
Segundo Sommerville (2019), as atividades de projeto e implementação de software 
convertem a especificação dos requisitos em um sistema de software executável. 
 Enquanto o projeto se preocupa com o design de estrutura do software que concretiza 
a especificação, a implementação transforma essa estrutura em um sistema executável.
 A Figura 4 mostra um modelo abstrato do processo de projeto (design) com suas en-
tradas, atividades e saídas. As entradas do projeto (determinados artefatos) alimentam as 
atividades de projeto. Cada atividade de projeto resulta em uma saída (novos artefatos). 
O projeto de arquitetura gera o artefato de arquitetura de sistema; o projeto de interface 
resulta no artefato de especificação de interface; a seleção e projeto de componentes 
gera o artefato de descrição dos componentes e o projeto de banco de dados resulta no 
artefato de especificação de banco de dados. As saídas são os resultados das atividades 
de projeto.
Arquitetura
do sistema
Projeto de
banco de dados
Especi�cação 
da interface
Descrição dos
componentes
Informações sobre
a plataforma
Requisitos
do software
Descrição 
dos dados
Projeto de
arquitetura
Projeto de
interface
Projeto de
banco de dados
Seleção e
projeto de
componentes
Atividades de projeto
Entradas para o projeto
Saídas do projeto
Figura 4 – Um modelo geral do processo de projeto
Fonte: Adaptado de SOMMERVILLE, 2019, p. 41
Ainda sobre a Figura 4, o que é feito em cada uma das atividades de projeto? Vale 
destacar que essas atividades são intercaladas e interdependentes.
• Projeto de arquitetura: a estrutura geral do software e os componentes (módulos 
ou subsistemas) principais são identificados, inclusive seus relacionamentos e a for-
ma como eles serão distribuídos;
14
15
• Projeto de interface: as interfaces entre os componentes do sistema são definidas, 
sendo que a especificação dessas interfaces deve ser explícita;
• Seleção e projeto de componentes: buscas por componentes reutilizáveis são 
realizadas e, não havendo componentes apropriados, novos componentes de sof-
tware são projetados;
• Projeto de banco de dados: as estruturas de dados do software são definidas, além da 
forma de representação dessas estruturas em um banco de dados (SOMMERVILLE, 2019). 
No caso do projeto de arquitetura, é importante lembrar que o propósito dessa ativi-
dade é a de possibilitar uma visão global do software, gerando um artefato que corres-
ponde ao modelo arquitetural do sistema de software, obtido basicamente de três fontes:
• Das informações a respeito do domínio de aplicação do software a ser desenvolvido;
• De determinados elementos do modelo de requisitos, como casos de uso ou classes 
de análise, seus relacionamentos e colaborações que visem solucionar o problema 
em questão;
• Da disponibilidade de padrões e estilos arquiteturais (PRESSMAN; MAXIM, 2016).
Modelo de Visões Arquiteturais 4+1
Além dos modelos arquiteturais de software serem adotados para apoiar as ativida-
des de requisitos e/ou de projeto (design) de software, eles também podem ser utilizados 
para documentar o projeto de desenvolvimento, tornando-se assim uma base para o 
projeto detalhado e a implementação do software. 
É bastante complicado representar em um único diagrama todas as informações 
relevantes da arquitetura de um software, já que um único modelo visual só consegue 
exibir uma visão ou perspectiva do sistema; um diagrama pode exibir como um software
é decomposto em módulos, enquanto outro representa como os processos interagem 
em tempo de execução; um terceiro diagrama pode mostrar como os componentes de 
software estão distribuídos em uma rede. Como tudo isso tem seu valor em estágios 
distintos de desenvolvimento, tanto no projeto quanto na documentação, geralmente é 
necessário apresentar várias visões de arquitetura de software. 
No que diz respeito às essas visões, uma recomendação bastante conhecida é a de 
que deve haver quatro visões fundamentais de arquitetura, todas ligadas por meio de 
casos de uso e de cenários comuns. Esse modelo de visões arquiteturais é denominado 
modelo 4+1, idealizado por Philippe Kruchten. As visões sugeridas são:
• Visão lógica: exibe as abstrações elementares do software como objetos e classes. 
Nessa visão, deve ser factível relacionar os requisitos com as suas entidades;
• Visão de processo: mostra como o software é composto por uma interação de 
processos, no caso, em tempo de execução. Essa visão é utilizada para avaliar os 
requisitos não funcionais, como desempenho e disponibilidade;
15
UNIDADE Contexto e Visões de Arquitetura
• Visão de desenvolvimento: exibe a decomposição do software para ser desenvol-
vido, especificamente a divisão do software em componentes a serem implementa-
dos, sendo assim uma visão útil para gerentes e desenvolvedores;
• Visão física: mostra a estrutura física, isto é, como os componentes serão distribu-
ídos fisicamente pelos processadores disponíveis na rede, sendo assim uma visão 
útil para os engenheiros de sistema que são os responsáveis pela implantação do 
software (SOMMERVILLE, 2019).
A Figura 5 mostra as visões arquiteturais do modelo 4+1 para um sistema de software. 
E quanto à visão “+1” desse modelo?
No que diz respeito à visão “+1” do referido modelo, esta corresponde à visão de 
caso de uso, isto é, um resumo dos casos de uso mais significativos sob o ponto de vista 
arquitetural; uma síntese das realizações de casos de uso. A visão de caso de uso retrata 
uma história comum que agrupa o entendimento das outras quatro visões e a forma 
como elas se inter-relacionam (LARMAN, 2007).
Informações sobre diversas contribuições de Philippe Kruchten, inclusive trabalhos relacio-
nados com arquitetura, disponível em: https://bit.ly/2H8rLGa
Arquitetura
de sistema
Visão
lógica
Visão
física
Visão de 
desenvolvimento
Visão de
processo
Figura 5 – Visões de Arquitetura
Fonte: Adaptado de SOMMERVILLE, 2019, p. 153
16
17
Todas essas visões arquiteturais são obrigatórias para projetar e documentar uma 
arquitetura de uma aplicação de software?
Não necessariamente. De acordo com Sommerville (2019), as visões arquiteturais 
geralmente são construídas ao longo do projeto (design) do software. Essas visões são 
utilizadas para explicar a arquitetura do software aos stakeholders e informar as deci-
sões arquiteturais tomadas. Durante o processo de design, outras visões podem ser do-
cumentadas para contemplar os diferentes aspectos do sistema de software, porém rara-
mente é preciso documentar de forma completa as descrições de todas as perspectivas. 
Vale ressaltar que padrões arquiteturaistambém podem ser associados às distintas 
visões de um sistema de software. Segundo Bezerra (2015), o desenvolvimento de um 
produto de software complexo exige de seus desenvolvedores o estudo desse sistema 
a partir de diversas visões, mas de acordo com as características e complexidade do 
software, nem todas as perspectivas arquiteturais precisam ser consideradas. Por exem-
plo, se o software tiver que ser implantado em uma estrutura física de processador 
único, não há necessidade da visão de implantação; outro exemplo é se o sistema for 
constituído de um único processo, nesse caso, a visão de processo é irrelevante. De forma 
geral, a depender do sistema de software, as visões podem ser classificadas pelo grau de 
importância (BEZERRA, 2015).
Processo Unificado
O Processo Unificado (PU), do inglês Unified Process (UP), e ́ um modelo de proces-
so de desenvolvimento de software idealizado por Ivar Jacobson, Grady Booch e James 
Rumbaugh e tem como princípio três características fundamentais: a) é dirigido a casos 
de uso; b) é centrado na arquitetura; c) é iterativo e incremental. 
O PU enfatiza a importância da comunicação com o cliente, e de ações que justifi-
cam a visão do cliente sobre o produto de software, especificamente a visão dos casos 
de uso. O PU também destaca a importância da arquitetura de software, ajudando o 
arquiteto a manter o foco em determinadas metas, como assegurar compreensibilidade, 
confiança em modificações futuras e reutilização. Além disso, o PU recomenda um fluxo 
de processo iterativo e incremental, proporcionando uma evolução essencial no desen-
volvimento de aplicações de software modernas (PRESSMAN; MAXIM, 2016).
No tópico 3 desta unidade foram descritas brevemente cinco atividades metodológi-
cas genéricas aplicáveis em qualquer modelo de processo de software. Visando mostrar 
que o Processo Unificado não é uma exceção, a figura 6 mostra as fases do PU sendo 
relacionadas com as atividades genéricas descritas no referido tópico. No que tange ao 
seu propósito, as fases do PU são similares às atividades metodológicas genéricas apre-
sentadas anteriormente na unidade.
17
UNIDADE Contexto e Visões de Arquitetura
Concepção
Elaboração
Construção
TransiçãoVersão
Produção
planejame
nto
modelage
m
construção
entrega
comunicaç
ão
incremento de software
Figura 6 – O Processo Unificado
Fonte: Adaptado de PRESSMAN; MAXIM, 2016, p. 57
Um processo de desenvolvimento de software iterativo e incremental, dirigido a casos 
de uso e centrado na arquitetura oferece um conjunto de fluxos de trabalho, atividades e 
artefatos bastante favoráveis ao estudo e aplicação de arquiteturas e padrões de software. 
Vamos observar as três características destacadas na descrição de cada fase do Pro-
cesso Unificado:
• A fase de concepção do PU contempla a atividade de comunicação com o cliente e 
a de planejamento. Mediante a colaboração entre os stakeholders, as necessidades 
de negócio são identificadas, uma arquitetura primária para a aplicação de software 
é proposta e as iterações e incrementos do software a ser desenvolvido são planeja-
das. No que tange à arquitetura, nessa fase ela é somente uma estrutura provisória 
dos principais componentes (subsistemas ou módulos) e suas funções e recursos. 
Mais  adiante, a arquitetura é refinada para um conjunto de modelos que visam 
representar diferentes visões do software. O planejamento, por sua vez, identifica 
recursos, avalia os principais riscos, estabelece um cronograma e define uma base 
para as fases seguintes, de acordo com o incremento do software a ser desenvolvido;
• A fase de elaboração abrange as atividades de planejamento e modelagem, refinan-
do e expandindo os casos de uso identificados inicialmente na fase de concepção, 
além de ampliar a representação da arquitetura, incluindo cinco visões diferentes 
do software: modelo de caso de uso, modelo de análise, modelo de projeto, modelo 
de implementação e modelo de implantação. Em algumas situações, já é possível 
haver uma base arquitetural executável na fase de elaboração, significando que já 
existe uma primeira versão do sistema de software executável; essa base gerada 
demonstra a viabilidade da arquitetura, porém ainda não oferece todos os recursos 
e funções necessárias para o software ser utilizado. Ainda nessa fase, o plano é 
revisado para garantir que o escopo, riscos e prazos continuem adequados;
18
19
• A fase de construção desenvolve ou adquire componentes de software com base 
no modelo arquitetural preliminar, operacionalizando os casos de uso para os usu-
ários. Para isso ser possível, os modelos de análise e de projeto, iniciados na fase 
de elaboração são finalizados para representar a versão final do incremento do 
software, e, portanto, os componentes exigidos para o incremento (versão) são 
implementados, realizando em paralelo os testes de unidade para cada componente 
de software. A composição dos componentes e os testes de integração também são 
realizados. Os casos de uso são usados para se realizar os testes de aceitação ainda 
nessa fase; 
• A fase de transição engloba as atividades de construção e entrega. Nessa fase, o 
software é entregue ao usuário para realizar testes beta e fornecer feedback quanto 
aos defeitos identificados e às modificações necessárias; materiais de apoio aos usu-
ários também são elaborados para efetivar o lançamento da versão. Ao final da fase 
de transição, o incremento do software torna-se uma versão funcional do produto 
de software, ou seja, pronto para ser utilizado;
• A fase de produção realiza o monitoramento contínuo da operação da aplicação 
de software pela comunidade usuária, disponibilizando suporte para a infraes-
trutura disponível e avaliando relatórios de defeitos e solicitações de mudanças 
(PRESSMAN; MAXIM, 2016).
O PU é um processo iterativo e incremental, e provavelmente, o próximo incremento 
do software tende a ser iniciado na próxima iteração, ou seja, ao mesmo tempo em 
que o incremento em questão esteja nas fases finais de sua iteração, significando que 
as cinco fases não ocorrem sequencialmente, mas de forma simultânea e escalonada. 
Um fluxo de trabalho (conjunto de tarefas) de engenharia de software é distribuído no 
decorrer de todas as fases do processo (PRESSMAN; MAXIM, 2016).
Por um lado, o Processo Unificado (PU) é também chamado de Rational Unified 
Process (RUP) por causa da Rational Software Corporation, mais tarde adquirida pela 
empresa IBM. A Rational Software foi uma das primeiras companhias que colaboraram 
com o desenvolvimento e refinamento do PU, além de ser ter sido uma empresa desen-
volvedora de ferramentas e tecnologias que suportam o referido processo (PRESSMAN; 
MAXIM, 2016). Por outro lado, o RUP é referido como UP, denominação bastante co-
mum nas empresas de software que desejam adotar a estrutura do processo RUP, mas 
sem ter a obrigação de usar os produtos licenciados da Rational Software, sendo assim, 
é possível considerar o RUP como um produto da Rational Software baseado no UP, 
como também pode-se entender os dois processos como semelhantes (FOWLER, 2005).
Informações adicionais sobre o IBM Rational Unified Process (RUP).
Disponível em: https://bit.ly/3lHjcB8
Geralmente, o Processo Unificado é compreendido como um processo prescritivo, 
mas também é possível adequá-lo como uma metodologia ágil, implicando assim na 
geração de poucos artefatos de software. Uma implementação ágil conhecida do PU é o 
AUP (AMBLER; JEFFRIES, 2002 apud WAZLAWICK, 2015, p. 6). Visando agilidade, 
19
UNIDADE Contexto e Visões de Arquitetura
toda documentação deve estar voltada à implementação do software. Cada atividade 
 realizada deve ter um objetivo explícito e um uso preciso, tendo como meta a produção 
de código que deve cumprir com os requisitos da melhor forma possível e no menor 
tempo razoavelmente possível. O sistema de software é projetado para atender a basica-
mente dois objetivos: entender as necessidades do cliente e construiruma solução viável 
que atenda a essas necessidades. Para ajudar a comunicação entre os stakeholders, 
artefatos como diagramas podem ser elaborados, ainda mais quando esses diagramas 
permitem a geração automática de código a partir deles (WAZLAWICK, 2015).
Informações sobre The Agile Unified Process (AUP), disponível em: https://bit.ly/2Hb5PKL
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Ambysoft
https://bit.ly/2Hb5PKL
 Leitura
O que é arquitetura de software?
https://bit.ly/3lH4yKr
Qual O Real Papel do Arquiteto de Software?
https://bit.ly/3f6MTsW
As qualidades de um arquiteto de software
https://bit.ly/35EvS6t
Apêndice a 2 de junho de 2020, palestra sobre arquitetura de software
https://bit.ly/2H8rLGa
IBM Rational Unified Process
https://bit.ly/3lHjcB8
21
UNIDADE Contexto e Visões de Arquitetura
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.
SOMMERVILLE, I. Engenharia de software. 10. Ed. São Paulo: Pearson, 2019. 
WAZLAWICK, R. S. Análise e design orientados a objetos para sistemas de informa-
ção: modelagem com UML, OCL e IFML. 3. Ed. Rio de Janeiro: Campus Elsevier, 2015.
22