Arquiteturas e

Padrões de Software
Contexto e Visões de Arquitetura

Responsável pelo Conteúdo:

Prof. Me. Wilson Vendramel

Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
 Contexto e Visões de Arquitetura

• 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.

OBJETIVO DE APRENDIZADO
• Entender a importância da arquitetura no desenvolvimento de sistemas de software.
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,
­M AXIM, 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
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 ‘requer’ Interface ‘fornece’

Define os serviços Define os serviços
necessários que Componente que são fornecidos
devem ser fornecidos pelo componente para
por outros componentes outros componentes

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
9
UNIDADE Contexto e Visões de Arquitetura

getImagem
adicionarItem

recuperar Adaptador GerenciadorDeImagens

BibliotecaDeFotos
entradaDoCatalogo
getEntradaDoCatalogo

InterfaceComUsuario

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 atender aos 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 t­ omar 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 d ­ evem buscar
responder questões fundamentais relacionadas às decisões arquiteturais, conforme mos-
tra a Figura 3 (SOMMERVILLE, 2019).

10
 1. Existe uma arquitetura de
2. Como o sistema será 3. Quais padrões ou estilos
aplicação genérica que possa agir
distribuido entre os núcleos de arquitetura poderiam
como um template para o sistema
ou processadores do hardware? ser utilizados?
que está sendo projetado?

?
4. Qual será a abordagem 5. Qual estratégia será utilizada
fundamental utilizada para para controlar a operação dos
estruturar o sistema? componentes no sistema?

6. Como os componentes 7. Qual é a melhor organização

estruturais no sistema serão 8. Como a arquitetura
da arquitetura para entregar
decompostos em do sistema deve ser
os requisitos não funcionais
subcomponentes? documentada?
do sistema?

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
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
 • 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 software reali-
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
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.

Entradas para o projeto

Informações sobre Requisitos Descrição

a plataforma do software dos dados

Atividades de projeto

Projeto de Projeto de
arquitetura interface

Projeto de Seleção e
banco de dados projeto de
componentes

Saídas do projeto

Arquitetura Projeto de Especificação Descrição dos

do sistema banco de dados da interface componentes

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
 • 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
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

Visão Visão
lógica física

Arquitetura
de sistema

Visão de Visão de
desenvolvimento processo

Figura 5 – Visões de Arquitetura

Fonte: Adaptado de SOMMERVILLE, 2019, p. 153

16
 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 arquiteturais també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), é 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
17
UNIDADE Contexto e Visões de Arquitetura

Elaboração

Concepção
ento
planejam modelag
em

ão
construç
ão
comunicaç

entrega Construção

Versão Transição
incremento de software

Produção
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
 • 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
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 construir uma 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
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
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