ANÁLISE E PROJETO

DE SISTEMAS E
INFORMAÇÕES II
ANÁLISE E PROJETO
DE SISTEMAS E
INFORMAÇÕES II
 Copyright © UVA 2020
Nenhuma parte desta publicação pode ser reproduzida por qualquer
meio sem a prévia autorização desta instituição.

Texto de acordo com as normas do Novo Acordo Ortográfico

da Língua Portuguesa.

AUTORIA DO CONTEÚDO PROJETO GRÁFICO

Claudio Ribeiro da Silva UVA
Camilla Lobo Paulino
DIAGRAMAÇÃO
REVISÃO UVA
Janaina Vieira
Lydianna Lima

S586 Silva, Claudio Ribeiro da.

Análise e projetos de sistemas e informações II [recurso eletrônico] /
Claudio Ribeiro da Silva. – Rio de Janeiro: UVA, 2021.

1 recurso digital (3092 KB)

Formato: PDF
ISBN 978-65-5700-095-3

1. Análise de sistemas. 2. Projeto de sistemas. 3. Arquitetura de software. I.
Universidade Veiga de Almeida. II. Título.

CDD – 004.21

Bibliotecária Adriana R. C. de Sá CRB 7 – 4049.

Ficha Catalográfica elaborada pelo Sistema de Bibliotecas da UVA.
 SUMÁRIO

Apresentação 6
Autores 7

UNIDADE 1

A modelagem física de um sistema 9

• A modelagem física de um sistema

• Mapeamento do projeto lógico para o físico

• A modularização de um sistema

UNIDADE 2

Padrões de arquitetura de software 30

• Arquitetura baseada em componentes

• Padrão Model-View-Control (MVC)

• Padrão de projeto de software

 SUMÁRIO

UNIDADE 3

Diagramas estruturais da UML 59

• Diagrama de Pacotes

• Diagrama de Componentes

• Diagrama de Objetos

UNIDADE 4

Diagramas de implantação de um software 83

• Diagrama de Implementação

• Diagrama de Perfil

• Diagrama de Implantação
 APRESENTAÇÃO

Desenvolver softwares é a capacidade que o profissional de Tecnologia de Informação

(TI) possui de transformar pensamentos abstratos (apenas ideias), de quem precisa da
informação, em algo concreto. Ao longo do tempo esse tem sido um dos principais de-
safios para o desenvolvedor de software “entregar exatamente aquilo que foi pedido”.
Diversas metodologias surgiram para fazer com que essa transformação seja mais pa-
dronizada, definindo procedimentos aplicáveis para a maioria das soluções e que sejam
compreendidos pelos profissionais que os conhecem. Essas metodologias evoluíram e,
atualmente, os conceitos da Orientação a Objetos aplicados aos diagramas da lingua-
gem UML (Unified Modeling Language) vêm sendo os mais utilizados.

No passado era comum dividir o desenvolvimento de um software em duas etapas: o de-

senvolvimento conceitual, ou lógico, e o desenvolvimento físico. Embora o termo não seja
tão utilizado no meio acadêmico, nós o faremos como referência para reunir um conjunto
de ações que são realizadas no projeto de desenvolvimento de um sistema a partir da se-
guinte distinção: a modelagem conceitual é aquela em que não são observados aspectos
relacionados à tecnologia. Ou seja, não importa qual a linguagem de programação a ser
utilizada, arquitetura de software ou frameworks, o que importa são as funcionalidades que
ela terá que possuir, a relação entre os dados que a aplicação irá manipular etc. A forma
como a tecnologia pode evoluir, sejam “mil anos”, o seu modelo conceitual permanecerá o
mesmo, desde que não tenha havido mudanças em suas regras de negócio ou nos resul-
tados esperados.

O processo de construção dos diagramas utilizados para essa visão é apresentado em

Análise e Projeto de Sistemas de Informação I, tais como a modelagem dos casos de usos,
classes de negócios etc. Já no desenvolvimento do modelo físico ocorre exatamente o
oposto: aspectos tecnológicos estão presentes e irão impactar diretamente o processo de
construção do software até sua implantação. Daí a separação em duas grandes etapas —
na primeira não se olha para tecnologias e na segunda elas são consideradas.

Assim, nesta disciplina olharemos um pouco mais para fatores tecnológicos que irão im-
pactar a elaboração do modelo físico de um sistema, com base nos diagramas estrutu-
rais e comportamentais da UML, para o desenvolvimento de soluções a serem utilizadas
na implementação de um software.

6
 AUTORES

CLAUDIO RIBEIRO DA SILVA

Claudio Ribeiro da Silva é doutor em Engenharia de Sistemas e Computação pelo Insti-

tuto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de Engenharia da Universidade
Federal do Rio de Janeiro – COPPE/UFRJ, mestre em Ciência da Informação pela UFRJ,
Pós-Graduado em Análise e Desenvolvimento de Sistemas pela Pontifícia Universidade
Católica do Rio de Janeiro – PUC-RJ e graduado em Ciências Contábeis pela Faculdade
de Administração São Paulo Apóstolo – Faspa. Professor dos cursos de graduação nas
modalidades presencial e a distância na área de Gestão de Tecnologia da Informação,
Sistema da Informação e Análise e Desenvolvimento de Sistemas. Experiência em gestão
de cursos de graduação e pós-graduação em instituições universitárias e como gerente
de equipes de desenvolvimento de sistemas. Tecnologista da Informação em autarquia
federal de médio porte, tendo atuado na área de desenvolvimento, realizando atividades
de desenvolvimento de software e gerenciamento de projetos nessa área.

7
 AUTORES

CAMILLA LOBO PAULINO

Mestra em Educação pela Universidade Estácio de Sá – Unesa, especialista em Docência

do Ensino Superior; especialista em Análise, Projeto e Gerência de Sistemas pela Unesa,
graduada em Ciências da Computação pela Universidade Veiga de Almeida – UVA, certi-
ficada pela APMG US em COBIT 5 e ITIL v3 e certificada pela Escola de Design Thinking
em Business Design. Coordenadora de Polos da Universidade Federal do Estado do Rio
de Janeiro - Unirio (2008 -2009), coordenadora de Midiatização e professora (presencial
e EAD) da Universidade Castelo Branco – UCB (2007 -2009). Desde 2002 professora da
UVA, conteudista da Educação a Distância e consultora de Tecnologia e Inovação.

Experiência de 23 anos na área coorporativa, atuando em projetos de TI em empresas de

grande e médio porte. Suporte BackOffice, administração e gerenciamento de usuários,
perfis, ajustes, customização e parametrização dos módulos do sistema (ERP), desen-
volvimento e manutenção de relatórios; projetos de implantação e reestruturação; treina-
mentos e capacitação; mapeamento, levantamento e automatização de processos; expe-
riência em Regra (Plano) de Negócios, gerenciamento de projetos, liderança de equipes
de desenvolvimento Scrum. Gerência de projetos, ERPs, ITIL, Cobit5 e Design Thinking.

Experiência acadêmica de 18 anos.

8
 UNIDADE 1

A modelagem física de um sistema

 INTRODUÇÃO

Desenvolver um software não representa apenas “sentar à frente do computador e progra-

mar”. Iniciando pelo levantamento de seus requisitos até a implantação do produto, muitas
etapas são realizadas para que possa ser respondida a seguinte pergunta: o que o usuário
quer? Esta é a grande resposta que o profissional de TI precisa buscar, sendo ela obtida a
partir de diversas atividades nas quais, inicialmente, os requisitos funcionais são identifica-
dos para que seja iniciado o desenvolvimento do sistema por meio do uso de alguns dos
diagramas da UML nas etapas iniciais.

Com a conclusão dessas primeiras etapas é iniciado o processo de elaboração do projeto

físico, que consiste em identificar os componentes e características físicas a serem utiliza-
dos no desenvolvimento do software que atenderá às demandas do sistema. Nessa etapa
devemos transformar todas as necessidades identificadas em funcionalidades do softwa-
re a partir de um conjunto de ações que utilizarão mais alguns dos diagramas propostos
pela UML. Logo, o objetivo desta unidade é relacionar as ações que devem ser realizadas
para identificar as principais características físicas a serem utilizadas na construção e im-
plantação do software.

OBJETIVO

Nesta unidade você será capaz de:

• Identificar os elementos utilizados para a elaboração da modelagem física para

a construção de um sistema de informação.

10
Aspectos de um modelo físico

Estamos quase iniciando o momento de “programar” o Sistema de Informação. Para al-

guns profissionais de TI essa etapa é a mais importante do processo de desenvolvimen-
to de software. No entanto, ela é apenas mais uma das várias etapas desse processo.
Isso porque, antes de iniciar a programação dos métodos que irão compor o sistema, é
necessário organizar a infraestrutura que será utilizada.

Quais os padrões de desenvolvimento que serão empregados? Qual a arquitetura do

sistema? E até mesmo, em alguns casos, qual a linguagem de programação mais ade-
quada, considerando-se os requisitos não funcionais previamente definidos? Estas são
algumas das muitas perguntas que devem ser respondidas antes de se começar a
produzir o sistema.

Para refletir

Antes de iniciarmos a explicação do porquê tudo isso é necessário, vamos refletir:

Quais as consequências que podem surgir, caso não seja feito um planeja-
mento prévio?

Imagine que você começa algo e percebe que um dos itens de que necessita
não está disponível?

Façamos uma analogia: a cozinheira vai preparar o arroz, refoga o alho a ce-
bola e, na hora que seria a de colocar o arroz na panela, descobre que esse
ingrediente acabou. O que pode acontecer?

O problema tecnológico pode ser muito semelhante.

Algumas instalações possuem seu próprio padrão de desenvolvimento, arquitetura,

padrão de interface etc., e o desenvolvedor sabe o que vai usar. Nesse caso, a etapa de
“construção prévia” é curta ou até mesmo inexistente. Entretanto, pode haver situações
em que a empresa utiliza diferentes arquiteturas e padrões de desenvolvimento, sendo
necessária uma avaliação prévia sobre as opções existentes para realizar a escolha,
levando um pouco mais tempo para essa avaliação.

11
Pode também surgir a situação em que seja necessário algo novo, como o uso da nova
versão de algum componente da arquitetura. Nesse caso, esse componente deve ser
buscado, instalado, testado para depois ser disponibilizado para uso no desenvolvimen-
to. Assim, para que haja tal disponibilidade, poderá haver uma demora não prevista no
cronograma, que poderá impactar o prazo final da entrega. Todas essas avaliações de-
vem estar disponíveis quando o primeiro método é entregue ao desenvolvedor para
sua construção. Caso contrário pode ocorrer de ele interromper a construção pela indis-
ponibilidade de algum desses recursos ou utilizar um padrão ou versão e depois ter que
refazer tudo utilizando novos. Lembra do exemplo da cozinheira?

Segundo Cleison Carlos (2020), incertezas e riscos no desenvolvimento de softwa-

re estão associadas às mudanças tecnológicas. Para isso “um estudo antecipado
evitaria esse tipo de problema. Imagina construir uma aplicação e no mês seguinte
ela ser atualizada para uma nova versão não compatível com a anterior”.

Outro item importante para definição prévia em um projeto de construção do software

está relacionada à interface da aplicação, pois a utilização de alguns recursos pode im-
pactar o uso do site, como:

• Fontes pequenas.
• Excesso de “cliques”.
• Dificuldade de navegação.

Não podemos esquecer das di- Diferentes recursos que impactam o desenvolvimento.
ferentes plataformas e browsers
que uma aplicação web pode uti-
lizar, devendo ser previstos o uso
e testes em cada uma delas.

São muitos os aspectos que de-

vem ser analisados antes que
seja iniciada a etapa de desen-
volvimento do software. Como
foi dito em parágrafo anterior, os
requisitos necessários para esse
início podem variar de acordo
com as características e maturi-
dade da instalação.

12
 A elaboração do projeto para a construção do software consiste em identificar e tor-
nar disponíveis os recursos tecnológicos que serão utilizados para sua construção.

Os requisitos identificados na etapa de levantamento do sistema serão transformados

em componentes de software, mas, para isso, existem fortes influências tecnológicas
que irão impactar o produto a ser entregue.

Como, porém, decidir quais recursos tecnológicos serão utilizados? Ao verificar a figura
a seguir observamos que existem muitas opções que podem ser avaliadas para diversos
aspectos relacionados à construção do software.

Como decidir quais recursos tecnológicos serão utilizados.

Alguns dos aspectos que devem ser previamente avaliados:

Arquitetura do sistema – Define os componentes que farão parte do software, especifi-

cando suas interfaces, relacionamento com outros softwares e propriedades. A arquite-
tura utilizada varia de acordo com o padrão de interface, ambiente operacional ou nave-
gabilidade. Segundo a empresa DevMedia (2020), no artigo intitulado Atividades básicas
ao processo de desenvolvimento de software:

13
 [...] a arquitetura de um sistema tem diversos elementos como:
• Elementos utilitários.
• Elementos de interação.
• Elementos que fazem parte do domínio do problema.
• Elementos de conexão.
• Elementos de persistência etc.

Padrões de desenvolvimento – Representa a arquitetura da aplicação, ou seja, a forma

como ela será construída. O uso de um padrão depende da linguagem de programação
por utilizar recursos que devem estar disponíveis na linguagem.

Ferramentas a serem utilizadas – Devem ser definidas algumas ferramentas ou am-

bientes que serão utilizadas para a construção do software. Algumas dessas informa-
ções são identificadas como requisitos não funcionais, tais como:

• A linguagem de programação utilizada no desenvolvimento.

• Ambiente de desenvolvimento.
• Sistema operacional.
• Servidor de aplicação.
• Servidor de Banco de Dados.
• Framework de acesso ao banco de dados.
• Ferramenta de construção de relatório etc.

Algumas dessas ferramentas podem ser padrão, como o ambiente de dados quando a
empresa utiliza um único SGBD.

Importante

Algumas empresas possuem padrão de desenvolvimento ou componentes da

arquitetura previamente definidos. Nesse caso, essa etapa é simplificada, no
entanto é importante observar que frequentemente novas versões dos compo-
nentes são lançadas e novas tecnologias surgem. Nessas situações, é impor-
tante que essas tecnologias sejam avaliadas. Assim, será possível identificar
os eventuais impactos que as inovações podem provocar quando utilizadas de
forma concomitante com versões anteriores.

14
O uso de arquiteturas aplicadas à Engenharia de Software também pode ser definido
nesse momento como Arquitetura Orientado a Serviço (SOA) ou Arquitetura de MicroSer-
viços, ambas fazendo parte da arquitetura do sistema.

A definição das estratégias para o desenvolvimento, testes e implantação devem ser de-
finidas nesse momento. Essas estratégias permitem que o gerente do projeto de desen-
volvimento do software consiga previamente definir as ações que devem ser realizadas
em cada uma das etapas a seguir.

• A estratégia de desenvolvimento pode ser definida por meio da escolha do modelo

de desenvolvimento, sendo alguns deles os modelos incremental, ágil ou cascata.
• A estratégia dos testes deve ser criada especificando-se os modelos de testes
que serão realizados, o momento em que eles irão ocorrer e as pessoas envolvidas.
• Para a implantação do sistema, definir como será realizado; se houver migração
dos dados definir a estratégia para a migração.

Todas as ações descritas devem ser elaboradas na etapa de construção do projeto físico
do software. Os componentes devem ser disponibilizados para que seja iniciada a etapa
de implementação do software na qual os componentes do produto são produzidos, tes-
tados e posteriormente implantados.

15
Mapeamento do projeto lógico para o físico

Atualmente, a área de desenvolvimento possui profissionais que vêm se especializando

em cada uma das diferentes etapas do processo de construção de um software. Isso
significa que é recomendado que cada etapa do projeto de desenvolvimento de um sis-
tema seja construída por profissionais especialistas nas tarefas nelas desempenhadas.
Ou seja, um engenheiro de requisitos deve ser utilizado na etapa de levantamento de
requisitos por ser essa a sua especialidade, da mesma forma que o desenvolvedor na
linguagem Java deve ser utilizado na etapa de implementação.

Tendo como base as etapas comuns aos processos de desenvolvimento de software,

apresentado no artigo Atividades básicas ao processo de desenvolvido de software, da
empresa DevMedia (2020), podemos dividir esse processo em seis etapas :

Levantamento de requisitos – Quando são identificados, entre outras infor-

1 mações, os requisitos funcionais, não funcionais, regras de negócios etc.

Análise de Requisitos – Quando é construída a solução sistêmica para o

2 atendimento dos requisitos funcionais identificados na etapa anterior.

Projeto de construção do software – Quando são identificadas as soluções

3 tecnológicas para tornar disponíveis os requisitos levantados na primeira eta-
pa — sendo esse o objetivo desta disciplina.

Implementação – Consiste no desenvolvimento de soluções de software

com o uso do ambiente de programação e componentes identificados na
4 etapa anterior. Esse objetivo é atendido com o uso das disciplinas voltadas
para a linguagem de programação.

Testes – Implementação de diversas atividades que têm como objetivo ava-

5 liar a qualidade do software produzido. Para isso, diversas técnicas podem
ser utilizadas, não sendo esse o objetivo desta disciplina.

Implantação – Instalação do software no ambiente do usuário, disponibi-

lizando diferentes tipos de manuais voltados para ele. Após a implantação
6 toda a documentação produzida até então deve ser disponibilizada para con-
sulta futura.

16
Cabe esclarecer que não existe um padrão sobre essas etapas, sendo possível en-
contrar outras formas de representação na literatura, no entanto utilizando-as como
referência. Vamos dividir as “duas metades” do processo, antes de iniciada a etapa de
implementação.

1 – Na primeira metade o engenheiro de requisito é acionado utilizando as técnicas

indicadas para identificar os requisitos funcionais, não funcionais e regras de negócios,
atores envolvidos, entre outros. A partir do levantamento dos requisitos, inicia-se a etapa
de Análise dos Requisitos em que os profissionais especializados na construção do
modelo conceitual do sistema começam suas atividades, construindo alguns dos dia-
gramas da UML utilizados para sua modelagem. Nesse momento a estrutura lógica do
sistema está concluída, dando início a uma nova etapa em que todas as funcionalidades
identificadas na primeira etapa começam a transformar-se em algo “visível” para o usuá-
rio: o Sistema de Informação solicitado por ele.

2 – Ao concluir a “primeira metade”, esse grupo de especialistas “sai de cena” dando lugar
àqueles que passam a olhar o Sistema de Informação com uma visão tecnológica. Nes-
sa nova etapa o sistema começa a ter características de um projeto físico pela inserção
de aspectos tecnológicos. Algumas transformações e ações preparatórias começam a
ser realizadas para que possa ser iniciada a etapa de implementação do software, ou
seja, inicia-se o desenvolvimento dos métodos ou outros componentes utilizando-se
um ambiente de desenvolvimento e uma linguagem de programação.

Importante

Podemos afirmar que, se não houver nenhuma mudança nas funcionalidades

do sistema, a primeira metade do desenvolvimento poderá existir por muito
tempo. Entretanto, o dinamismo da segunda metade é muito maior, em razão
das novas versões ou tecnologias que surgem a cada dia, fazendo com que o
software necessite ser atualizado, sempre que necessário, para evitar que fique
defasado tecnologicamente.

Destacamos, então, que um projeto de desenvolvimento de sistemas envolve profis-

sionais de TI especializados em cada uma das etapas do desenvolvimento. O enge-
nheiro de requisitos na etapa de levantamento de requisitos, o administrador de banco
de dados na etapa de construção da base de dados, o desenvolvedor Java quando
houver o desenvolvimento na linguagem e assim por diante, cada um sendo utilizado
no momento correto.

17
 Exemplo

O projeto de desenvolvimento de um sistema pode ser comparado a um pro-

jeto para construir uma casa. Você chama o engenheiro para fazer o projeto,
chama os operários para realizarem a construção, o pintor para fazer a pintura
dos cômodos e assim por diante. Ou seja, conforme a obra é realizada, novos
especialidades de profissionais são utilizadas de acordo com a fase da obra.

Segundo o artigo Atividades básicas ao processo de desenvolvimento de software,

publicado pela DevMedia (2020):

[...] um processo de desenvolvimento de software pode ser visto como

um conjunto de atividades organizadas, usadas para definir, desenvolver,
testar e manter um software. A seguir, alguns objetivos do processo de
desenvolvimento:
• Definição das atividades a serem executadas.
• Quando determinada atividade deve ser executada.
• Pessoa ou grupo a executar tais atividades.
• Padronização no processo de desenvolvimento.

Considerando os objetivos propostos pelo usuário para o desenvolvimento de um sis-

tema, observa-se que:

• A definição das atividades a serem executas representa o conjunto de ações

que devem ser realizadas para a construção do sistema, desde a etapa do levanta-
mento até a implantação.
• Determinar as atividades que devem ser executadas está relacionada às etapas
de desenvolvimento e o que deve ser produzido em cada uma delas.
• As pessoas ou grupo a executar tais atividades define a equipe de desenvolvi-
mento com suas diferentes especialidades, que deve atuar nas etapas apropriadas.
• A padronização no processo de desenvolvimento representa o uso dos diagra-
mas da UML apropriados para cada uma dessas etapas.

O processo de mapeamento do projeto lógico em físico representa algumas ações que

serão realizadas para iniciar-se o desenvolvimento do software. Após a definição dos
componentes estruturais que serão utilizados, algumas ações devem ser realizadas para
viabilizar e agilizar o início desse processo.

18
 Importante

Apesar de a UML propor padrão para seus diagramas, o uso de cada um deles,
assim como os procedimentos realizados para produzir a documentação de
um sistema, varia de acordo com a empresa e tamanho de sua equipe de pro-
fissionais de TI. Algumas empresas valorizam a documentação, por entender
que facilita o entendimento do projeto quando houver necessidade de mudan-
ças futuras. Outras entendem que é “perda de tempo” e que o mais importante
é produzir. Não busque uma verdade absoluta sobre isso, pois não existe. Avalie
os prós e contras e chegue à sua conclusão.

Definições prévias para iniciar a etapa de implementação

de software

Vamos relacionar alguns dos itens que devem ser previamente definidos antes de iniciar
a etapa de desenvolvimento do software. A definição prévia evita interrupções ou retra-
balho durante essa etapa.

• Criar a estrutura da base de dados do sistema – Realizar o mapeamento dos atribu-

tos e relacionamentos descritos no Diagrama de Classe, permitindo a construção da es-
trutura da base de dados a ser utilizada pela aplicação. Se a empresa possuir um banco
de dados que implementa o modelo relacional, serão necessárias algumas adaptações
representadas pela transformação do modelo orientado a objeto para o relacional.

• Definir um padrão de interface – Caso a empresa não possua um padrão institucio-

nal para as interfaces dos softwares que utiliza — conhecido como a identidade da em-
presa —, o desenvolvedor deve criar protótipos para que sejam avaliados pelo usuário.
Devem ser identificados previamente os recursos que serão considerados para a cons-
trução, para que sejam avaliados no protótipo, tais como usabilidade, navegabilidade
etc. Também serão definidos os padrões de qualidade a serem avaliados nas interfaces
e verificados se contemplam as informações necessárias solicitadas pelo usuário.

A definição de padrões para os tipos dos componentes que farão parte das inter-
faces, como tamanho, tipo de fonte, posicionamento das ações mais comuns, são
alguns dos exemplos do que deve ser previamente definido para evitar mudanças,
principalmente quando o desenvolvimento for realizado por uma equipe. Imagine
uma aplicação em que cada interface tem um padrão diferente!

19
 • Propor o modelo de navegação do sistema – Deve ser proposta a estrutura de
navegação e acesso aos diferentes módulos que compõem o sistema. Esse mode-
lo é comum quando estruturas de menu e submenu de acesso são utilizadas para
definir o acesso às diferentes funcionalidades. A forma como a estrutura das funcio-
nalidades será organizada faz parte desta definição.

• Definir a sequência de desenvolvimento – Devem ser relacionadas todas as fun-

cionalidades que serão implementadas. Elas devem ser organizadas em módulos
que caracterizam as possíveis entregas que podem ser feitas. Em cada módulo de-
ve-se realizar a sequência como os componentes serão desenvolvidos. O objetivo
dessa etapa é relacionar os procedimentos que serão desenvolvidos e a ordem em
que serão realizados.

• Especificar a política de testes do software – Organizar como será realizada a

etapa de testes dos componentes ou métodos do software, conforme forem desen-
volvidos. Elaborar o plano de testes, definir a equipe, o tipo de teste, os recursos
que serão utilizados etc. são alguns dos itens que devem planejados.

• Montagem do ambiente para a construção do software – Quando o software

estiver concluído e validado (etapa de implantação), ele será instalado em um am-
biente conhecido como “ambiente de produção”, em que estão presentes todos os
sistemas utilizados no dia a dia da empresa. Na etapa de implementação ele está
sendo construído, utilizando-se um ambiente conhecido como “ambiente de desen-
volvimento”. Antes de ser disponibilizado ao usuário, o sistema será migrado para
um ambiente conhecido como “ambiente de homologação”, para que as funciona-
lidades possam ser validadas e seja verificada a compatibilidade com as demais
aplicações. Os ambientes de desenvolvimento e homologação devem estar dispo-
níveis para que possa ser iniciado o desenvolvimento do software.

Após a validação do software, ou de uma parte dele, será feita sua implantação. Nessa eta-
pa outras ações podem ser previamente realizadas, como o registro das ações de migra-
ção de uma versão para outra, os procedimentos para mudança da estrutura de uma base
de dados etc. A definição dessas ações varia de acordo com a característica do desenvol-
vimento que está sendo feito e deve ser elaborada nas etapas de projeto e implementação.

Todas as ações realizadas ao longo de todo o projeto de desenvolvimento de um softwa-

re devem ser documentadas, exigindo que sejam produzidos documentos que irão gerar
a documentação do sistema, que precisa ser validado e aceito pelo usuário que solicitou
seu desenvolvimento.

20
A modularização de um sistema

O conceito de modularidade pode ser aplicado em várias situações, seja na área empre-
sarial ou industrial. Se você analisar um móvel feito em madeira, por exemplo, observará
que ele é desmontável na maioria das vezes e sua montagem é feita por meio de para-
fusos de tamanho previamente definido. Esses mesmos parafusos podem ser utilizados
em diferentes móveis que possuem o mesmo tamanho para encaixe. Ao utilizar o mes-
mo componente em diferentes produtos você otimiza sua produção, reduzindo o custo.

Seguindo essa mesma linha de raciocínio, imagine uma companhia aérea que possui
200 aeronaves de 50 tipos diferentes. Ela terá que ter componentes para a manutenção
para todos esses tipos. No entanto, se as 200 aeronaves forem de cinco tipos diferentes,
a compra de material de manutenção será em maior quantidade, o que reduzirá o custo
de aquisição, podendo um componente ser utilizado em diferentes aeronaves. Este con-
ceito é aplicável em diversas áreas industriais, podendo ser observado na maioria dos
produtos que utilizamos no nosso dia a dia.

O que isso até a ver com desenvolvimento de software?

A resposta é simples: tudo!

Importante

No momento em que desenvolvemos o código de um software, temos que ter

sempre em mente a preocupação com a prática de reúso desses códigos. Em
desenvolvimento de software essa prática é conhecida como “componenti-
zação”, em que um pequeno módulo (componente) é construído e acoplado
a outro, que é incorporado a outro e assim por diante, até que o software seja
construído como um todo.

21
 Componentes do motor de um veículo.

Vamos analisar a figura composta de diversos componentes que fazem parte, por exem-
plo, do motor de um veículo. Esses componentes, de forma isolada, não possuem nenhu-
ma utilidade, ou seja, não agregam valor ao motor ou ao veículo, pois somente produzem
esse valor se combinados a outros componente. Um componente de um software, quando
analisado de forma isolada, representa exatamente essa situação. Ele tem um objetivo es-
pecífico, mas de forma isolada não produz valor para o usuário.

Por exemplo, um módulo que realiza o cálculo da área de uma região só tem valor se
estiver associado a outro módulo que, por sua vez, possua as medidas e a característica
da região cuja área será calculada, fazendo uso do resultado obtido. Essa situação pode
ser observada na figura do motor completo, em que mesmos componentes representa-
dos na figura anterior aparecem integrados para alcançar um objetivo maior, que seria o
funcionamento do motor.

Motor completo.

22
O que nós fazemos apenas com o motor de um veículo? Se você deseja um veículo, são
necessários outros componentes, tais como: carroceria, pneus, sistema elétrico etc. Na
maioria dos casos, o que produz valor ao usuário não é um componente, mas sim o produ-
to acabado, ou seja, o veículo completo.

Ampliando o foco

Segundo Moura et al. (2017), “Modularidade é um conceito-chave em projetos

de software complexos. Com a modularização, o software ou sistema é dividi-
do em partes distintas, contribuindo com o aumento da produtividade desde o
desenvolvimento inicial até a fase de teste”.

Observe que a construção de um software representa esta situação: voltando ao exem-

plo anterior, o módulo que calcula a área de uma região, se acoplado a outro módulo que
forneça os dados para esses cálculos, produz um resultado. Porém, se incorporarmos
todos os módulos a um software que produz o desenho de um projeto de engenharia
eles estarão integrados a um componente maior. Por exemplo, esse software desenha
os diversos cômodos de uma construção e, “com um clique”, calcula a área de cada um
deles, ou seja, ele atendeu ao seu objetivo (calcular a área) dentro de um objetivo maior
(desenhar os cômodos da construção).

Ainda neste exemplo, verificamos que existem vários outros componentes, como o que
faz a metragem do espaço para o cálculo, outro que identifica a figura do cômodo e
assim por diante. Em resumo, o software de engenharia possui todos os componentes
necessários sem a percepção do usuário.

Caso queira desenvolver outro software com objetivo diferente, mas que necessite reali-
zar desenhos, calcular área etc., basta utilizar esses componentes sem precisar reescre-
vê-los. Observou como agilizou o tempo de desenvolvimento? Não foi necessário desen-
volver todos os componentes, bastou usá-los.

Importante

Componentes de software representam unidades independentes, que podem

ser interligadas a outros componentes formando sistemas mais complexos e
cada uma delas deve encapsular um objetivo específico e único.

23
Ao construir um componente de software, ele deve possuir as seguintes características:

• Deve encapsular a sua implementação.

• Deve possuir interface e objetivo bem definidos.
• Deve ser utilizado independente de outros módulos.
• Deve fornecer recursos suficientes para que possa ser reutilizável.
• Deve deixar explícitos os conceitos das dependências e conexões entre os
componentes.
• Deve possuir documentação clara e precisa sobre o seu uso.

Como modularizar um sistema?

A modularização pode ser iniciada com a identificação dos métodos relacionados no

Diagrama de Classe e construir, a partir dele, o que seria o principal componente do
software: as suas classes de negócio. Lembrando que uma das principais característi-
cas da orientação a objeto é o reúso do código ao criar um componente que encapsula
todos os métodos e atributos da classe de negócio. Assim, você poderá incorporá-los a
novos programas sempre que essa classe for utilizada. A partir dessa construção, cada
um dos métodos deve ser observado de forma isolada, identificando procedimentos
que podem ser reutilizáveis.

Exemplo

Lembre-se de que pode haver método que seja específico a uma classe. Como
exemplo, temos aquele que consulta uma informação na base de dados a partir
de uma identificação, como a consulta dos dados de um aluno a partir da sua
matrícula em que, nesse caso, esse componente/método deve fazer parte do
componente maior associado à classe de negócio.

No entanto, outras situações podem surgir aplicáveis a diferentes classes de

negócios. Por exemplo, o método de verificação de um dígito verificado, como
a validação de um CPF, que pode ser utilizado em qualquer classe que possua
esse atributo. Nesse caso, esse componente/método não deve estar associado
a nenhuma dessas classes de negócio, mas sim vinculado a uma classe gené-
rica de uso comum ou deve ser utilizado de forma isolada.

24
A partir da definição dos componentes, deve ser elaborada a sequência para o seu de-
senvolvimento, conforme as etapas descritas a seguir :

Buscar e selecionar os componentes disponíveis que possuem

Seleção
potencial para utilização na construção do sistema.

Verificar se o componente adequa-se ao modelo de arquitetura

Qualificação
utilizada pelo software.

Verificar a necessidade de adaptação do componente ao soft-

Adaptação ware, podendo ser necessária a criação de uma nova versão,
caso ele esteja sendo utilizado.

Realizar a integração do componente ao sistema a partir de

Composição
suas interfaces.

A partir da próxima unidade você conhecerá alguns dos padrões de desenvolvimento

utilizados e os principais diagramas propostos pela UML, que permitem os registros
dessas informações.

25
 MIDIATECA

Para ampliar o seu conhecimento veja o material complementar, disponível na

midiateca na Unidade 1.

NA PRÁTICA

O desenvolvimento de um software é composto por diversas etapas. As primei-

ras têm a preocupação de identificar seus objetivos, sem ter como referência
fatores tecnológicos como linguagem de programação, SGBD etc. Ao concluir
essa etapa, será necessário iniciar a implementação do software em que de-
vem ser identificadas as respostas para algumas das perguntas abaixo:

• Qual será o ambiente operacional? Windows, Android, Linux, vários?

• Qual o ambiente de programação que será utilizado? Dot.Net, Eclipse,
Netbeans?
• Qual a plataforma? Web, Desktop?
• Qual o padrão de arquitetura de desenvolvimento? MVC, Cliente-Servidor,
Sistema distribuído?
• Qual SGBD será utilizado? Oracle, Postgree, SQL-Server?
• Qual o volume de transações? De dados? De usuários?
• Qual a rapidez no tempo de resposta?
• Quais as linguagens utilizadas na interface? CSS, HTML, JS?
• Quais os padrões de interface? Componentes da interfaces e seus
formatos?

Estas e muitas outras perguntas precisam ser respondidas para que seja co-
nhecido o ambiente operacional, recursos tecnológicos, versões etc. que serão
utilizados para o desenvolvimento do software. As ações apresentadas nesta
unidade são realizadas pelos profissionais que respondem a estas perguntas e
produzem a documentação necessária para registrar os recursos e componen-
tes tecnológicos utilizados para a construção do software.

26
Resumo da Unidade 1

Nesta unidade você estudou as ações que devem ser realizadas para iniciar-se a etapa
de implementação de um software. Para que o início ocorra de forma segura devem ser
definidos os componentes tecnológicos que serão utilizados na construção do software,
deixando-os disponíveis e previamente testados sem que haja o risco de interromper
ou cancelar o desenvolvimento por inadequações técnicas. Eliminando os riscos, será
possível transformar os requisitos identificados em funcionalidades do software. Em re-
sumo, a construção do Sistema de Informação.

Podemos dividir as etapas de desenvolvimento de um sistema em duas grandes meta-

des. Na primeira os profissionais envolvidos estão focados em identificar os requisitos
funcionais junto aos usuários, preparando os diagramas que irão compor a análise do
sistema, não havendo nenhuma influência de tipos ou componentes tecnológicos. “A tec-
nologia não interessa”, é o que poderiam afirmar os profissionais que atuaram até esse
momento no desenvolvimento do sistema. Já na segunda metade os requisitos tecno-
lógicos tornam-se necessários, pois eles irão orientar a maneira como o software será
construído. As ações devem ser documentadas para que possam produzir as documen-
tações do sistema que serão úteis em atualizações futuras, uma vez que as evoluções
tecnológicas ocorrem de maneira frequente. Por este motivo, para facilitar mudanças
futuras a partir de diagramas e padrões de desenvolvimento, o registro dos elementos
tecnológicos utilizados, suas versões e características devem estar sempre disponíveis.

27
Referências

ATIVIDADES básicas ao processo de desenvolvimento de software. DevMedia. Dispo-

nível em: https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvi-
mento-de-software/5413. Acesso em: 10 jul. 2020.

CLEISON, C. Incertezas e riscos no desenvolvimento de software. Disponível em: ht-

tps://medium.com/trainingcenter/incertezas-e-riscos-no-desenvolvimento-de-software-
-6eabbeedb055. Acesso em: 5 jul. 2020.

INTRODUÇÃO ao padrão MVC. DevMedia. Disponível em: https://www.devmedia.com.

br/introducao-ao-padrao-mvc/29308. Acesso em: 5 jul. 2020.

ESCUELA TECNOLÓGICA INSTITUTO TÉCNICO CENTRAL. Guía metodológica desar-

rollo de sistema de información. Disponível em: http://www.itc.edu.co/archives/calidad/
GIC-GU-01.pdf. Acesso em: 10 jul. 2020.

PERITO, J. A importância da documentação de software. Disponível em: https://blog.

geekhunter.com.br/qual-e-a-importancia-da-documentacao-de-software/. Acesso em:
5 jul. 2020.

MODULARIDADE. In: WIKIPEDIA: the free encyclopedia. [San Francisco, CA: Wikimedia
Foundation, 2010]. Disponível em: http://en.wikipedia.org/wiki/Modularidade. Acesso em:
10 jul. 2020.

MOURA, L. F.; MARTINS, R. G.; SILVA, L. L. Modularidade de Sistemas de Software. VII

Seminário de Iniciação Científica e Inovação Tecnológica do IFTM. Uberaba, 8 de junho de
2017. Disponível em: https://iftm.edu.br/ERP/MPES/EVENTOS/arquivos/030517150836_
resumo_sin_lucas_moura.pdf. Acesso em: 5 jul. 2020.

PRÁTICA: desenvolvimento baseado em componentes. Demoiselle Framework. Dispo-

nível em: http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisel-
lePlugin/guidances/practices/componentes_6A150B73.html?nodeId=e61bad17. Acesso
em: 10 jul. 2020.

28
 UNIDADE 2

Padrões de arquitetura
de software
 INTRODUÇÃO

O desenvolvimento de um software consiste na aplicação de recursos tecnológicos para

sua construção. A escolha desses recursos deve ser feita antes de iniciada sua imple-
mentação para que possam ser previamente avaliados e testados, estando validados
e disponíveis no momento da utilização. Alguns dos recursos utilizados no desenvolvi-
mento da programação do software estão relacionados aos padrões de arquitetura que
serão usados em sua construção. Em alguns casos, são dependentes dos ambientes
operacionais ou das linguagens de programação a serem utilizados.

A escolha dos componentes que serão utilizados no software, o padrão de projeto e o

padrão de desenvolvimento são alguns dos padrões arquiteturais que devem ser previa-
mente avaliados para serem utilizados na fase de implementação do software. Assim,
o objetivo desta unidade é apresentar três padrões arquiteturais: a arquitetura baseada
em componentes, o padrão MVC e o padrão de projeto Gof, que representam diferentes
formas de arquiteturas utilizadas para a construção de um software.

OBJETIVO

Nesta unidade você será capaz de:

• Aplicar os padrões de arquitetura de software para a construção de um Sistema

de Informação.

30
Arquitetura baseada em componentes

O que é arquitetura baseada em componentes?

De forma simples, podemos dizer que a arquitetura baseada em componentes represen-

ta um dos modelos utilizados na arquitetura de software, que realiza o modelo de desen-
volvimento arquitetural de um software a partir do uso de componentes.

O que é arquitetura de software?

Segundo a Secretaria Nacional de Cultura, “a arquitetura de software representa a(s) estru-

tura(s) do sistema, que consiste nos componentes de software, nas propriedades externa-
mente visíveis desses componentes e nos relacionamentos entre eles”. Essa arquitetura
tem como principal característica a modelagem e o projeto do software, considerando os
aspectos tecnológicos e estruturais. Dessa forma, é possível definir diferentes formas de
projetos, os módulos de um software e suas comunicações que estejam relacionadas ao
desenvolvimento, como sistemas distribuídos, web, cliente servidor etc.

A arquitetura baseada em componentes possui a visão do desenvolvedor no que se refere

à componentização do software, ou seja, sobre como podemos definir os componentes
necessários para sua construção. Isso é realizado a partir da definição das propriedades
externas desses componentes e seus relacionamentos com outros softwares no modelo
de implementação. Em uma forma mais ampla, a arquitetura baseada em componentes
define situações em que pequenos componentes integram-se a outros, formando um
maior que, ao ser integrado, produz componentes cada vez mais robustos e com objeti-
vos mais abrangentes. Dessa forma, permite construir sistemas de informação utilizando
módulos com quantidades menores de linhas de programação.

Ampliando o foco

A arquitetura de software foi apresentada por Macilory em 1968, em um trabalho

que tinha uma proposta de desenvolvimento de componentes reutilizáveis para a
construção de um software, no qual o desenvolvedor escolheria qual componen-
te seria utilizado de acordo com suas necessidades. Em 1976, DeRenner propôs
que fosse construído um conjunto de módulos independentes para serem depois
interligados. Com o surgimento da programação orientada a objetos a ideia de
componentização e reutilização em software tornou-se mais popular.

31
Existem diversos termos similares que levam a soluções ou propostas próximas. Como
exemplo, os termos: Engenharia de Software baseada em componentes, Desenvolvimen-
to baseado em componentes ou Arquitetura baseada em componentes, da mesma forma
que Arquitetura de software ou Arquitetura de sistemas ou Arquitetura de componentes,
são alguns dos que tratam de forma muito próxima cada um dos objetivos. Em alguns
casos, existem diferenças entre eles que variam na forma como são implementados ou
em seu alcance como projeto. Entretanto, existem situações que possuem o mesmo
objetivo, sendo apenas tratadas com nomenclatura diferente.

Um exemplo que aproxima-se ao que foi apresentado está relacionado à definição de

Arquitetura de componentes, atribuída à Secretaria Nacional de Cultura, que refere-se
a esta arquitetura como sendo: “A Prática de Desenvolver e Utilizar Arquiteturas de
Componentes ajuda a gerenciar a complexidade e encoraja a reutilização, porque as
Arquiteturas de Componentes baseiam-se em componentes independentes, substituí-
veis e modulares.”

A integração de diferentes componentes que compõem a arquitetura de um sistema, tais como:

ambiente, segurança, dispositivos, interface, arquitetura etc.

32
Diferenças entre componentes e objetos

A similaridade entre componentes e objetos pode levar o desenvolvedor a pensar que

ambos possuem os mesmos objetivos, porém isso não é verdade. Vamos ver algu-
mas diferenças:

Itens comparativos Componentes Métodos

Pode ser implementado por A implementação é feita por

Metodologia de linguagem de programação linguagens de programação
desenvolvimento que utilize qualquer tipo de que utilizam a metodologia de
metodologia. orientação a objeto.

Pode possuir granularidade

que envolva vários objetos Deve ter um objetivo específico
Granularidade
e métodos, até mesmo de restrito à classe a que pertence.
diferentes classes.

Não está associado a uma

Flexibilidade classe de negócio, poden- Um método está restrito à clas-
de uso do ser compartilhado por se de negócio a que pertence.
várias delas.

O componente que calcu-

la o dígito verificador do
CPF pode ser utilizado em
qualquer classe de negócio
Exemplo
que manipula este atributo,
podendo ser desenvolvido
em qualquer linguagem e
anexado ao programa.
O método que realiza a cria-
ção de uma instância de uma
classe de negócio está restrito
apenas a esta classe e deve ser
implementado em uma lingua-
gem orientada a objeto.

Considerando que existem diferenças entre métodos e componentes, para que um des-
ses componentes sejam criados alguns critérios devem ser considerados, conforme des-
critos abaixo:

• Reúso: possibilidade de usar o componente em diferentes aplicações.

• Encapsulamento: para usar o componente devem ser conhecidas apenas as
suas interfaces.

33
 • Independência: um componente não pode ser dependente de outro que não es-
teja encapsulado.
• Documentação: deve ser bem documentado, deixando de forma clara seus obje-
tivos e interfaces.

Atendendo aos critérios acima, o desenvolvedor tem como resultado:

• Redução do custo e tempo: o reúso de componentes evita que haja novas imple-
mentações, reduzindo o tempo total do desenvolvimento.
• Facilidade de desenvolvimento: quanto menor o componente, menor o tempo
para desenvolvimento e teste, agilizando a entrega do produto.

Arquiteturas que implementam a integração de componen-

tes, disponíveis nos atuais ambientes operacionais

• CMM (CORBA Component Model): desenvolvido pela OMG (Object Management

Group), Consiste em um framework utilizado para que componentes desenvolvi-
dos em diferentes plataformas ou ambientes operacionais possam interagir. Como
exemplo, o desenvolvimento de uma aplicação desenvolvida para o sistema opera-
cional Windows e linguagem JSP que utilize componentes desenvolvidos em outras
linguagens de programação e sistema operacional Unix.

Componentes que formam a estrutura da família CORBA.

INTERFACE IDL IMPLEMENTATION

REPOSITORY COMPILER REPOSITORY

in args

CLIENT OBJ
operation() OBJECT
(SERVANT)
REF
out args + return value

IDL DSI
SKELETON
IDL ORB DSI
DII
STUBS INTERFACE

GIOP/IIOP ORB CORE

STANDARD INTERFACE STANDARD LANGUAGE MAPPING

ORB-SPECIFIC INTERFACE STANDARD PROTOCOL

Fonte: www.gta.ufrj.br.

34
• COM/COM+ (Component Object Model): desenvolvido pela Microsoft, o COM
consiste em um padrão de interface binária, que permite o acoplamento entre apli-
cações independentemente da linguagem desenvolvida. O COM+ é uma evolução
desse padrão utilizado em sistemas distribuídos, ou seja, as aplicações podem estar
em diferentes equipamentos. Segundo a Microsoft, “é um sistema independente de
plataforma, distribuído e orientado a objetos para a criação de componentes biná-
rios de software que podem interagir”.

• DCOM (Distributed Component Obejct): desenvolvido pela Microsoft, o DCOM

representa uma estrutura de programação que permite que um computador exe-
cute programas em outro pela rede, como se estivesse sendo executado local-
mente. DCOM é um componente de software de propriedade da Microsoft que
permite que objetos COM comuniquem-se pela rede. Essa arquitetura representa
uma evolução da COM/COM+, sendo que a diferença entre elas é que a DCOM
atua em sistemas distribuídos.

Arquitetura DCOM.

Web clients TCP clients

Local Local
data data
IIS/SAP

DCOM

ASP COM

IUnknown

MTS
Query

Application
logic

MS SQL Server MSMQ

Fonte: datahousecorp.com.

35
• JavaBeans e Entreprise JavaBeans – EJB: desenvolvido pela Sun, tem como ob-
jetivo permitir que unidades independentes e reutilizáveis possam ser manipuladas
pelos desenvolvedores a partir do ambiente de desenvolvimento da linguagem Java.
Dessa forma, ao utilizar um dos ambientes de desenvolvimento da linguagem (Ne-
tbeans ou Eclipse, por exemplo) é possível compartilhar suas próprias bibliotecas
(classes de negócios compartilhadas) ou bibliotecas do sistema (sql, swing, io etc).

Arquitetura JBS em uma aplicação.

Controller Model
Request
Sessions Beans
(EJB)

Client (servlet)

Entity Classes
(browser) (JPA)
View Database

Response
(JSP pages)

Fonte: netbeans.org.

36
Padrão Model-View-Control (MVC)

Segundo a empresa DEVMEDIA, o padrão MVC (Model-View-Control) é um dos padrões

arquiteturais mais antigos. Ele apresenta uma arquitetura em três camadas, que atuam
de forma independente na construção de um software. São elas:

• Model (Modelo): essa camada representa as classes de negócio tratadas pela

aplicação, sendo disponibilizados os métodos desenvolvidos e definidos no Diagra-
ma de Classe.
• View (Visão): representa as interfaces definidas para a aplicação.
• Control (Controle): camada que realiza a interligação entre as outras duas camadas.

Embora não exista um padrão para esta construção, no que se refere às características
dos métodos que devem ser colocados em cada uma delas, há o consenso de que de-
vem ser construídas de forma independente, para que o reúso ou manutenção possa ser
feito sem que haja impactos nas demais.

A arquitetura padrão do modelo MVC.

37
 Ampliando o foco

O padrão MVC foi desenvolvido em 1979 por Trygve Reenskaug para que fosse
uma arquitetura de software utilizada em aplicações desktop. Atualmente, esse
padrão tem sido mais utilizado em aplicações web, embora seja possível utili-
zá-lo em todos os tipos de implementação.

Vamos entender o que significam as três camadas que representam o padrão MVC, de-
talhando cada uma delas, seguindo a sequência que representa a execução de um pro-
grama. Ou seja, o usuário fornece um dado, este sofre algum tipo de processamento pela
aplicação e o resultado é devolvido.

Camada de visão

As interações entre o usuário e a aplicação são feitas por meio do que chamamos de
interface, normalmente representada por telas, por onde os dados são fornecidos pelo
usuário e por onde as informações são apresentadas a ele. Quando um dado é forneci-
do e uma operação é acionada (calcular, salvar etc.) a partir de um link, botão ou outro
componente, é iniciada uma sequência de procedimentos para atender a essa operação.

Observe que, até o momento, houve apenas o fornecimento dos dados. Por esse motivo,
todas as operações que estejam relacionadas a esse dado devem ser definidas na pró-
pria interface. Por exemplo, para verificar se um campo foi preenchido ou não deve ser
criada uma rotina para realizar esse teste. Outro exemplo: se um valor preenchido para
uma variável numérica deve ter seu conteúdo maior do que o valor zero, também deve
ser criado um procedimento para fazer essa validação na própria interface.

As principais motivações para que essas ações sejam realizadas desse modo são:

• Evita que haja continuidade na operação com uma informação incorreta.

• Haverá perda de tempo e recursos, caso a validação seja feita “mais para a frente”.
• Em termos estruturais, a interface está disponível no equipamento do cliente.
Assim, o método utilizado já está disponível, não sendo necessário “buscá-lo” em
outras camadas.

38
 Importante

Para comprovar a teoria de que o que for referente a dados deve ser tratado na
interface, as linguagens disponibilizam componentes que já realizam validação
de formato. Por exemplo, se precisamos informar uma data deve ser utilizado
o componente próprio para variáveis do tipo “data”, pois automaticamente será
feita a validação de formato e conteúdo, não sendo necessário criar métodos
que verifiquem se foi informada no formato dia, mês e ano e se ela é válida.

Camada de controle

Essa camada tem função “gerencial” na aplicação. Os procedimentos definidos têm o

objetivo de identificar a ação acionada na interface e de identificar o método da classe
de negócio que deve ser executado.

Em uma situação em que o usuário digita os dados e escolhe a opção “salvar” na tela de
entrada de dados da classe “Cliente”, a camada de controle identifica essa ação e aciona
o método correspondente dessa classe. Apenas isso que ela deve fazer? Sim!

Nessa camada não devem ser definidos métodos que estejam relacionados a validação
de dados ou a ações de negócios que facilitem o seu reúso quando necessário, manten-
do a independência em relação às camadas de visão e de negócio em relação a ela.

Camada de negócio

Nessa camada são definidos os métodos associados às classes de negócio. Os méto-

dos mais comuns implementados nessa camada são:

• As regras de negócio vinculados à classe.

• As operações que manipulam os atributos da classe de negócio.
• Os métodos de validação e armazenamento dos dados.

Quando o Diagrama de Classe do sistema é construído são descritas as classes de ne-

gócios por ele manipuladas com seus atributos, métodos e relacionamentos. Esses
métodos são implementados e “empacotados” como componentes para que possam
ser utilizados por outras aplicações, sem que haja a necessidade de reescrevê-los, garan-
tindo assim sua independência em relação às demais camadas.

39
Por exemplo, no Diagrama de Classe de um sistema, foi definida a classe “Cliente” com
seus atributos e métodos. Essa classe foi implementada e disponibilizada em uma bi-
blioteca de classes para que as outras aplicações que também a utilizem apenas a “im-
portem”. Esse tipo de operação é semelhante às importações realizadas nas linguagens
de programação, como importar a biblioteca com os métodos de manipulação de string,
sempre que necessitamos utilizar um deles.

A implementação na prática

Vamos fazer um passo a passo do que acontece quando fornecemos um conjunto de da-
dos em uma aplicação e mandamos gravá-los na tabela correspondente da base de dados.

1 - Camada de visão

O usuário fornece os dados na interface e escolhe a opção “Salvar”.

2 - Camada de controle

O método vinculado a esta interface identifica que esta opção foi acionada e aciona o
método correspondente a esta operação da camada de negócio.

3 - Camada de negócio

Recebe o controle da aplicação, realiza a operação e retorna este controle para que a
camada de visão informe ao usuário que a ação foi concluída.

E de onde retiramos a independência entre as camadas?

Vamos imaginar a seguinte situação:

Para uma aplicação web a empresa deseja alterar o padrão de interface utilizado. As
funcionalidades são as mesmas, apenas aspectos relacionados à navegabilidade ou
layout serão alterados. Nesta situação surge a primeira questão: será que os métodos
da classe de negócios utilizados sofrerão algum tipo de alteração em razão do novo
padrão de interface?

40
Se a resposta for não, significa que nenhuma alteração deve ser feita nesses métodos,
ou seja, a camada de negócio não deve sofrer alteração, representando apenas uma
mudança de interface. Neste caso, basta ser definido o novo padrão, refeitas as interfa-
ces envolvidas adotando-se o novo padrão, e por último, substituir uma pela outra. Ou
seja, serão feitas mudanças apenas na camada de interface, sem preocupar-se com as
demais. Simples, não? A camada de visão configura-se independentemente das demais.

Importante

Caso a resposta à pergunta acima seja sim, significa que não se trata apenas
de uma mudança de interface. Se outros métodos estão sendo adicionados,
alterados ou removidos, significa que houve mudanças nas funcionalidades
previstas nos casos de uso, ou seja, o software está sofrendo manutenção por
alguma razão, não sendo apenas por mudança na interface.

Se a mudança for em alguma regra de negócio, o pensamento é o mesmo. Se não hou-

ver necessidade de mudança na interface, deve-se apenas alterar o método impactado
e substituí-lo na biblioteca da classe de negócio à qual pertence. Ou seja, deve-se alterar
o método, testá-lo e substituir a versão anterior pela nova, sem que seja necessário fazer
qualquer tipo de mudança nas demais camadas. Outra independência!

A exceção pode ocorrer se uma nova operação for necessária em uma interface. Por exem-
plo, se uma nova operação de “consulta” for inserida na interface por meio de um novo
componente representado por um botão, devem ser realizadas as seguintes operações:

• Na interface, para realizar a nova operação, incluindo o novo componente.

• No controle, para identificar esse novo componente e vincular ao método que irá
executá-lo.
• Na camada de negócio, introduzindo esse novo método ou alterando algum já
existente.

41
 As camadas do Modelo MVC.

request
Controller
HTTP

demand dados
envia dados

Model response
Html, XML,

View

Fonte: www.portalgsti.com.br. Adaptada.

Avaliando a figura anterior, observamos as trocas de mensagens existentes entre as ca-

madas. A camada de controle recebe a requisição a partir do HTTP e, a partir dela, realiza
a interação entre as camadas de visão e modelo para o seu atendimento.

Importante

Observe que NÃO existem interações entre a visão e o modelo, ou seja, por
questão de segurança a visão não pode acionar métodos da camada de negó-
cio, conforme representado na figura anterior.

Para que possa continuar havendo independência entre as camadas e tendo como base
as características tecnológicas utilizadas, é comum identificar aplicações que dividem a
camada de negócio em outras duas:

• A camada de implementação das regras de negócios em que são definidos os

métodos que tratam essas regras.
• A camada de acesso ao banco de dados em que são definidos os comandos de
acesso aos dados armazenados (comandos SQL). Essa camada, conhecida como
DAO (Data Access Object), contém apenas os métodos associados, a conexão ao
Banco de Dados e os comandos SQL. Logo, são criados métodos apenas com os
comandos SQLs sem qualquer tipo de implementação. A principal vantagem do uso

42
 dessa quarta camada é percebida nas situações de mudança de SGBD, pois, nesse
caso, é necessário apenas avaliar e alterar esses métodos, adaptando-os às regras
do novo SGBD, não havendo nenhuma alteração nos demais métodos.

Dessa forma, o padrão MVC passaria a ser:

1. Visão.
2. Controle.
3. Negócio.
4. Acesso a dados.

Massari (2020), no portal GSTI, relacionou ações que devem ser implementadas em cada
uma das camadas, das quais algumas delas são:

• Camada de Visão
→ Exibe a representação dos dados.
→ Camada de interface com usuário, realizando entrada e exibição dos dados.
→ Responsável por usar as informações modeladas para produzir interfaces de
apresentação conforme a necessidade.

• Camada de Modelo
→ Camada que contém a estrutura de dado atrás de uma parte específica da
aplicação.
→ Responsável pela leitura, manipulação e implementação das regras de negócios.
→ Notifica a visão e o controle associados quando há mudança em seu estado.

• Camada de Controle
→ Exerce o controle sobre o modelo e a visão que serão utilizados.
→ Manipula e roteia as requisições dos usuários.
→ Realiza o gerenciamento das demais camadas.
→ Avalia as ações realizadas pelo usuário e as transfere em comandos para as
classes de modelo e/ou visão.
→ Realiza a validação das ações dos usuários conforme as regras de autentica-
ção e autorização definidas pela aplicação.

• Camada de Dados
→ Implementa os métodos associados aos procedimentos de conexão e acesso
aos dados, tais como as consultas e operações de atualização.

43
Padrão de projeto de software

Segundo Christopher Alexander, citado em DEVMEDIA (2020):

Cada padrão descreve um problema que ocorre repetidamente em nos-

so ambiente, e então descreve o núcleo da solução para esse problema,
de forma que você possa usar essa solução um milhão de vezes, sem
nunca o fazer da mesma forma duas vezes.

Analisando a definição acima entendemos que na área de desenvolvimento de software

deparamo-nos com problemas comuns em diversas oportunidades. Considerando que
para o mesmo problema é possível que seja aplicada a mesma solução, a proposta dos
padrões de projetos é apresentar soluções previamente avaliadas e aceitas para proble-
mas recorrentes. Cada padrão é implementado de acordo com a situação identificada na
etapa de implementação do software. Assim, seu uso está diretamente relacionado ao
uso de linguagens de programação que implementem a orientação a objeto.

A técnica de design pattern (padrão de projeto) surgiu em 1970, por meio da apresenta-
ção de algumas soluções de desenvolvimento para problema comuns, ou seja, soluções
padronizadas para problemas previamente conhecidos, sendo atualmente considerada
como boa prática para a programação orientada a objeto.

Ampliando o foco

Com a publicação do livro dos autores Gamma, Helm, Johnson e Vlissides,

conhecidos como a “Gangue dos Quatro” (Gang of Four) ou GoF, em 1995 foi
proposto um catálogo de soluções para implementação em projeto de desen-
volvimento de software, passando a ser uma das principais referência para pa-
drão de projeto. Em 1997, com a publicação do livro de Craig Larman, intitulado
Utilizando UML e Padrões – Uma introdução à análise e ao projeto orientado
a objetos e ao desenvolvimento iterativo, foi apresentado o padrão GRASP
(General Responsibility Assignment Software Patterns), que utiliza o conceito
de atribuição de responsabilidades a classes e objetos para o desenvolvimento
de um software.

44
O uso de padrões de projeto vem apresentando diversos benefícios, tais como:

• Criação de um vocabulário comum para conversar sobre projetos de software.

• Limitação de espaço para as soluções.
• Identificação, a partir de nomes, de soluções previamente conhecidas.
• Necessidade de definir padrões de projetos reutilizáveis.
• Uso das melhores práticas na solução de um dado problema.
• São utilizados em conjunto com outras soluções para resolver problemas de
grande porte.

Os padrões devem possuir um formato previamente definido, facilitando a produção de

sua documentação e aprendizado. Devem conter:

• Nome: para que haja uma referência de fácil identificação.

• Problema: para o entendimento do contexto ao qual ele se aplica.
• Solução: para o entendimento da solução proposta ao problema.
• Consequência/Forças: deve apresentar as vantagens e desvantagens do uso do pa-
drão a partir da descrição de suas forças e restrições aplicadas e como elas interagem.

Com base na documentação produzida, a seleção de um padrão de projeto deve atender

aos seguintes critérios:

• Deve solucionar problemas de projeto e deve ser implementado para atender de

forma objetiva a tal problema.
• Verificar o comportamento do padrão e de sua implementação quando relacio-
nados a outros.
• Deve atender às necessidades do software sem que seja necessário adaptá-lo ao
padrão utilizado.
• Avaliar o melhor padrão a ser utilizado, considerando suas características e os
fatores positivos e negativos dessa escolha.

Importante

O uso de cada um dos padrões deve estar associado ao problema identificado

na etapa de implementação do software e ao objetivo de cada um deles. O
uso do padrão correto é importante para o desenvolvimento exato do software.
Para isso é importante conhecer o objetivo de cada um deles e a maneira como
devem ser implementados na linguagem de programação orientada à objeto.

45
O padrão orientado a objeto GRASP

O padrão GRASP relaciona a responsabilidade que os objetos possuem entre si, ou seja,
para definir a responsabilidade de um objeto deve-se considerar o que ele irá fazer ou
saber, assim descritas, conforme DEVMEDIA (2020):

As responsabilidades relativas ao que um objeto faz incluem:

• A execução de ações que condizem com o papel desempenhado por tal objeto.
• A criação de outros objetos dos quais a instância (objeto) inicial depende.
• A coordenação de atividades envolvendo vários outros objetos.

Quanto ao que um objeto sabe, é possível citar:

• O conhecimento sobre os outros objetos relacionados.

• O conhecimento dos dados privados, que o objeto em questão encapsula.
• O conhecimento a respeito de coisas que serão calculadas ou derivadas a partir
de um elemento principal.

Assim, um objeto deve identificar as responsabilidades e atribuições atribuídas a ele e

aqueles que enxerga, como uma instância de uma nota fiscal, que deve visualizar todas
as informações relacionadas aos itens que compõem essa nota em uma implementação
de Composição do Diagrama de Classe.

Importante

Para fazer uso de um padrão, você deve conhecer o seu objetivo, avaliar a sua
aplicação na situação que se apresenta e verificar se ele realmente atende ao
que deseja. Para alguns deles, não existe uma relação direta e objetiva que pos-
sa associar o problema ao padrão. Com a prática, essa identificação vai se
tornando mais clara pois, em alguns casos, é possível mapear algo concreto
próximo dessa relação. Em outros casos, no entanto, essa associação é con-
ceitual e abstrata, não havendo um exemplo objetivo fora do contexto da imple-
mentação de uma aplicação.

46
O GRASP apresenta nove padrões, a saber:

Padrões GRASP

Creator Define qual classe será responsável pela criação da ins-

(Criador) tância de seus objetos.

Information Expert Determina a atribuição da responsabilidade à classe

(Especialista na Informação) que tenha a informação necessária.

Atribui responsabilidades de modo que o acoplamento

Low Coupling
entre os objetos seja baixo. Quanto menos dependên-
(Baixo Acoplamento)
cias houver entre as classes, melhor.

High Cohesion Define que as classes devem tratar exclusivamente de

(Alta Coesão) suas responsabilidades.

Controller Atribui as responsabilidades de manipular eventos do

(Controlador) sistema.

Polymorphism Atribui responsabilidades a abstrações, possibilitando

(Polimorfismo) que possam variar de acordo com a necessidade.

Classe artificial, que não representa um domínio do pro-

Pure Fabrication
blema. Atua como uma classe prestadora de serviços
(Fabricação/Invenção Pura)
para obter baixo acoplamento e alta coesão.

Ajuda a manter baixo acoplamento entre dois elemen-

Indirection
tos, atribuindo a um objeto intermediário a responsabili-
(Indireção)
dade de ser o mediador entre eles.

Protected Variations
Protege os elementos do sistema das variações de outros.
(Variações Protegidas)

Ampliando o foco

Para conhecer mais profundamente os conceitos sobre padrões de projeto

GRASP, consulte o livro Utilizando UML e Padrões: uma introdução à análise
e ao projeto orientados a objetos e ao desenvolvimento iterativo, de Craig
Larman. Disponível na Minha Biblioteca.

47
O padrão de projeto GoF

O padrão Gof é dividido em três categorias, que, por sua vez, incluem 23 padrões de
projetos propostos como as melhores práticas de soluções para as situações a que se
propõem resolver. Segundo Gamma et al. (2007) as três categorias são:

• Padrões de criação: “os padrões de criação abstraem o processo de instancia-

ção. Eles ajudam a tornar um sistema, independentemente de como seus objetos
são criados, compostos e representados. Um padrão de criação de classe usa a
herança para variar a classe que é instanciada, enquanto um padrão de criação de
objeto delegará a instanciação para outro objeto.”
• Padrões estruturais: “os padrões estruturais se preocupam com a forma como
classes e objetos são compostos para formar estruturas maiores. Os padrões es-
truturais de classes utilizam a herança para compor interfaces ou implementações.”
• Padrões comportamentais: “os padrões comportamentais se preocupam com
algoritmos e a atribuição de responsabilidades entre objetos. Os padrões compor-
tamentais não descrevem apenas padrões de objetos ou classes, mas também os
padrões de comunicação entre eles. Esses padrões caracterizam fluxos de controle
difíceis de seguir em tempo de execução. Eles afastam o foco do fluxo de controle
para permitir que você se concentre somente na maneira como os objetos são in-
terconectados.”

Divisão dos padrões de acordo com o escopo.

Propósito
1. Criação 2. Estrutura 3. Comportamento
Escopo Classe Interpreter
Factory Method Class Adapter
Template Method

Objeto Chain of
Responsability
Object Adapter
Command
Bridge
Abstract Factory Iterator
Composite
Builder Mediator
Decorator
Prototype Memento
Facade
Singleton Observer
Flyweight
State
Proxy
Strategy
Visitor

Fonte: sites.google.com.

48
Os padrões de criação
Os autores do padrão Gof classificam e definem os padrões a seguir como sendo de criação.
Segundo Gamma et al. (2007):

• Factory Method: “definir uma interface para criar um objeto, mas deixar as sub-
classes decidirem qual classe instanciar. O Factory Method permite adiar a instan-
ciação para subclasses.” Dessa forma, os objetos são instanciados e suas subclas-
ses decidem que outros objetos devem ser criados no momento que necessitarem.
• Abstract Factory: “fornecer uma interface para criação de famílias de objetos re-
lacionados ou dependentes sem especificar suas classes concretas.” Logo, permite
a criação de objetos sem especificar as classes concretas.
• Builder: “separar a construção de um objeto complexo da sua representação de
modo que o mesmo processo de construção possa criar diferentes representações.”
Dessa forma, o padrão realiza o encapsulamento da construção do produto, além de
permitir sua construção em etapas.
• Prototype: “especificar os tipos de objetos a serem criados usando uma instân-
cia-protótipo e criar objetos a partir dele.” Com o uso desse padrão é possível criar
novas instancias copiando de outras já existentes.
• Singleton: “garantir que uma classe tenha somente uma instância fornecendo
um ponto global de acesso a ela.” Ou seja, garante que apenas um objeto de uma
determinada classe seja criada na aplicação.

Os padrões estruturais
Os autores do padrão Gof classificam e definem os padrões a seguir como sendo es-
truturais. Segundo Gamma et al. (2007):

• Adapter (Class/Object): “converter a interface de uma classe em outra interface,

esperada pelos clientes. permitindo que classes com interfaces incompatíveis tra-
balhem em conjunto.” Utilizado quando necessitamos “adaptar” duas interfaces di-
ferentes criando um método intermediário, que realiza a compatibilização entre elas.
• Bridge: “desacoplar uma abstração da sua implementação, de modo que as duas
possam variar independentemente.” Assim, forma uma ponte construída para que a
implementação torne-se independente de suas abstrações.
• Composite: compor objetos em estruturas de árvore para representar hierarquias
partes-todo. Esse padrão permite aos clientes tratar de maneira uniforme objetos
individuais e composições de objetos”, devendo ser utilizado em implementações
dessas estruturas, tratando seus objetos de maneira uniforme.

49
 • Decorator: “dinamicamente, agregar responsabilidades adicionais a um objeto.
Eles fornecem alternativa flexível ao uso de subclasses para extensão de funciona-
lidades.” Desse modo, ele permite que o objeto “decorador” crie ou incorpore suas
funcionalidades em tempo de execução.
• Facade: “fornecer uma interface unificada para um conjunto de interfaces em um
subsistema. Define uma interface de nível mais alto que torna o subsistema mais
fácil de ser usado.” Com o uso desse padrão é possível simplificar um sistema com-
plexo a partir do uso de uma classe com uma interface mais simples.
• Flyweight: “usar compartilhamento para suportar eficientemente grandes quan-
tidades de objetos de granularidade fina.” Esse padrão visa reduzir a quantidade de
recursos utilizados pela aplicação minimizando o consumo de memória.
• Proxy: “fornece um substituto (surrogate) ou marcador da localização de outro
objeto para controlar o acesso a esse objeto.” Assim, forma a classe “proxy” e per-
mite a conexão a qualquer objeto, passando o controle a esse objeto.

Os padrões comportamentais
Os autores do padrão Gof classificam e definem os padrões adiante como sendo com-
portamentais. Segundo Gamma et al. (2007):

• Interpreter: “dada uma linguagem, definir uma representação para a sua gra-
mática juntamente com um interpretador que usa a representação para interpretar
sentenças dessa linguagem”, sendo o seu uso comum quando necessita fazer a
conversão de um modelo para outro, como transformar uma data de um formato
para outro.
• Template Method: “definir o esqueleto de um algoritmo em uma operação, pos-
tergando alguns passos para as subclasses. Template Method permite que subclas-
ses redefinam certos passos de um algoritmo sem mudar a sua estrutura.” Desse
modo, o padrão é utilizado quando uma subclasse decide em tempo de execução
como realizar a lógica da aplicação.
• Chain of Responsability: “evitar o acoplamento do remetente de uma solicitação
ao seu receptor ao dar a mais de um objeto a oportunidade de tratar a solicitação.
Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que
um objeto a trate.” Esse padrão permite que o método avalie a solicitação, executan-
do-a ou repassando-a para outro.
• Command: “encapsular uma solicitação como um objeto, desta forma permitindo
parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log)
de solicitações e suportar operações que podem ser desfeitas.” Esse padrão define
como criar objetos de comandos que realizam solicitações para alguns objetos.

50
 • Iterator: “fornecer um meio de acessar, sequencialmente, os elementos de um
objeto agregado sem expor a sua representação subjacente.” Assim, o padrão tem
como objetivo encapsular uma interação a partir da interface definida na aplicação.
• Mediator: “definir um objeto que encapsula a forma como um conjunto de obje-
tos interage. O Mediator promove o acoplamento fraco ao evitar que os objetos se
refiram uns aos outros explicitamente e permite variar suas interações independen-
temente.” Esse padrão permite a intermediação entre dois objetos que não se comu-
nicam de forma direta, ou seja, caso o objeto A não possa comunicar-se diretamente
com o objeto B ele se comunica com o Mediator e este faz a comunicação com o B.
• Memento: “sem violar o encapsulamento, capturar e externalizar um estado in-
terno de um objeto, de maneira que o objeto possa ser restaurado para esse estado
mais tarde.” Logo, sempre que for necessário restaurar o objeto à situação original,
como se fosse a opção “Desfazer” ou “Cancelar”, é indicado o uso desse padrão.
• Observer: “definir uma dependência um-para-muitos entre objetos de maneira
que quando um objeto muda de estado todos os seus dependentes são notificados
e atualizados automaticamente”, devendo ser utilizado sempre que houver neces-
sidade de fazer algum tipo de notificação para alguém ou algum objeto, quando
ocorrer mudança do estado de uma instância da classe.
• State: “permite a um objeto alterar seu comportamento quando o seu estado in-
terno muda.” Dessa forma, quando um objeto possui diferentes comportamentos
de acordo com o seu estado, esse padrão promove a execução do comportamento
vinculado ao estado atual. Por exemplo, as ações que devem ser implementadas
para uma instância da classe “AssentoAviao” variam se esse assento está disponí-
vel, reservado ou ocupado.
• Strategy: “definir uma família de algoritmos, encapsular cada uma delas e tor-
ná-las intercambiáveis. Strategy permite que o algoritmo varie independentemente
dos clientes que o utilizam.” Deve ser utilizado quando a aplicação possui um con-
junto de classes com lógicas semelhantes, porém objetivos distintos. Nesse caso, o
padrão permite a criação de uma superclasse que contemple as diferentes lógicas
aplicadas às subclasses criadas.
• Visitor: “representar uma operação a ser executada nos elementos de uma estru-
tura de objetos. Visitor permite definir uma nova operação sem mudar as classes
dos elementos sobre os quais opera.” Desse modo forma um novo método agrega-
do a um objeto em tempo de execução.

A figura a seguir, sobre “Classificação dos padrões de acordo com o foco” apresenta
outro modelo de classificação dos padrões, tendo como ênfase o seu foco de atuação
associado ao problema a ser solucionado. Segundo Metsker (2004), “o objetivo de um
padrão de projeto em geral é facilmente expresso com a necessidade de ir além das

51
características comuns embutidas em Java”. A classificação apresentada por Metsker é
definida da seguinte forma:

• Interfaces: quando o padrão declara os métodos implementados por uma classe.

• Responsabilidade: quando o padrão atribui a responsabilidade a outras entida-
des ou sistemas.
• Construção: quando o padrão cria mecanismos para instanciar a classe.
• Operação: quando o padrão implementa um método com características diferen-
tes à execução comum de um método, como o encapsulamento de procedimentos
de diferentes classes.
• Extensão: representa o acréscimo de uma classe, interface, método ou subclasse
conforme as características do padrão.

Classificação dos padrões de acordo com o foco.

Intenção Padrões

1. Interfaces Adapter, Facade, Composite, Bridge.

2. Responsabilidade Singleton, Observer, Mediator, Proxy, Chain of Responsability, Flyweight.

3. Construção Builder, Factory Method, Abstract Factory, Prototype, Memento.

4. Operações Tempate Method, State, Strategy, Command, Interpreter.

5. Extensões Decorator, Iterator, Visitor.

Fonte: sites.google.com.

52
 Ampliando o foco

Para conhecer mais profundamente os conceitos sobre padrões de projeto Gof,

consulte o livro Padrões de Projeto: soluções reutilizáveis de software orien-
tado a objetos, de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissi-
des. Disponível na Minha Biblioteca.

MIDIATECA

Para ampliar o seu conhecimento veja o material complementar da Unidade 2,

disponível na midiateca.

NA PRÁTICA

Ao realizar a implementação de um software, o desenvolvedor deve utilizar os

padrões arquiteturais previamente definidos por atender aos requisitos não fun-
cionais do sistema. Por exemplo, com base na linguagem de programação a
ser utilizada o desenvolvedor deverá ter acesso ao padrão arquitetural associa-
do a ela e deve utilizar os componentes que implementem algumas das suas
funcionalidades, como o uso da biblioteca “String” quando for necessário ma-
nipular esse tipo de variável no programa a partir de um dos métodos contidos
na biblioteca. Essa mesma regra serve para as todas as operações implemen-
tadas, tais como: entrada e saída, tratamento de erros etc.

Ao desenvolver um software, utilizar o padrão MVC por ser de grande relevância no

aspecto arquitetural por restringir a chamada na camada de visão de métodos da
classe de negócio, além de criar independência entre as camadas possibilitando o

53
reúso dos códigos desenvolvidos na camada de negócio. Outro fator importante
no uso desse padrão está relacionado à segurança, uma vez que os componentes
utilizados na visão são transferidos para o equipamento do usuário. Assim, ele não
pode ter acesso a nenhuma informação relacionada ao negócio, razão pela qual o
uso do controlador como elemento intermediário entre elas torna-se importante.
Todos os conceitos aplicados no padrão devem ser implementados e documenta-
dos nos diagramas da UML que atendem a representação desses objetivos.

Ao realizar a implementação do software, diversos padrões de projetos podem

ser utilizados. Para isso, é importante que se saibam os objetivos de cada um
deles e avalie-se sua aplicação na situação apresentada. Não se esqueça da cria-
ção das classes, interfaces, variáveis e demais recursos que estiverem associa-
dos à solução. Com isso, você conseguirá agilidade no desenvolvimento, pois
alguns deles simplificam ações que possuem maior complexidade quando são
implementadas por meio das soluções tradicionais, ou seja, sem uso do padrão.

54
Resumo da Unidade 2

Nesta unidade você estudou algumas das definições de padrões de arquitetura de

software, que o desenvolvedor deve previamente avaliar e definir para dar início à etapa
de implementação. Dentro desse contexto, o uso de modelos que implementam a
interligação de componentes baseados em componentes do software, torna-se um dos
primeiros fatores a serem definidos.

CORBA, COM, DCOM são alguns dos frameworks que podem ser selecionados tendo
como base o ambiente operacional ou a linguagem de programação que será utilizada
no projeto de desenvolvimento do software.

Além do padrão arquitetural, torna-se necessário definir se o MVC será o padrão a ser
utilizado na implementação, pois dessa escolha depende a avaliação e a definição dos
componentes ou métodos das classes de negócios utilizadas, que poderão ter reúso no
software a ser desenvolvido. Da mesma forma, o conhecimento dos padrões de projeto
GRASP e Gof também irá agilizar o seu desenvolvimento, sempre que a implementação
necessitar de alguns desses recursos. Ao definir o uso destes, o desenvolvedor estará
apto a iniciar a elaboração de alguns dos diagramas propostos pela UML, que serão apre-
sentados nas próximas unidades.

55
Referências

BACCARO, M. Arquitetura baseada em componentes. Disponível em: https://marcobac-

caro.wordpress.com/2010/10/05/arquitetura-baseada-em-componentes/. Acesso em:
10 jul. 2020.

BRASIL. Secretaria Especial de Cultura – Ministério do Turismo. Arquitetura de compo-

nentes. Brasília, DF: Secretaria Especial de Cultura. Disponível em: http://mds.cultura.gov.
br/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC-
2F6B5.html . Acesso em: 13 jul. 2020.

BRASIL. Secretaria Especial de Cultura – Ministério do Turismo. Arquitetura de siste-

ma. Brasília, DF: Secretaria Especial de Cultura. Disponível em: http://mds.cultura.gov.
br/core.base_rup/guidances/concepts/system_architecture_5F3B1E17.html. Acesso
em: 13 jul. 2020.

CELESTINO, André Luís. O conceito e as dúvidas sobre o MVC. Disponível em: https://
www.profissionaisti.com.br/o-conceito-e-as-duvidas-sobre-o-mvc/. Acesso em ju-
lho/2020.

COMPONENTES da arquitetura CORBA. Disponível em: https://www.gta.ufrj.br/

grad/00_2/corba/componentes_arquitetura.html. Acesso em: 10 jul. 2020. LINK, E.; ALE

XANDRE, E. B. P.; WOLF, J. L.; STRZYKALSKI, M. S. Uma introdução ao Corba. Disponível

em: https://www.inf.pucrs.br/~gustavo/disciplinas/sd/material/Artigo_Corba.pdf. Acesso
em: 5 jul. 2020.

DEVMEDIA. Breve estudo sobre engenharia de componentes. Disponível em: https://

www.devmedia.com.br/breve-estudo-sobre-engenharia-de-componentes/19139. Aces-
so em: 10 jul. 2020.

DEVMEDIA. Desenvolvimento com qualidade com GRASP. Disponível em: https://www.de-

vmedia.com.br/desenvolvimento-com-qualidade-com-grasp/28704. Acesso em: 5 jul. 2020.

DEVMEDIA, Estudo e aplicação do padrão de projeto Strategy. Disponível em: https://

www.devmedia.com.br/estudo-e-aplicacao-do-padrao-de-projeto-strategy/25856. Aces-
so em: 5 jul. 2020.

56
DEVMEDIA. Introdução ao Padrão MVC. Disponível em:https://www.devmedia.com.br/
introducao-ao-padrao-mvc/29308. Acesso em: 19 jul. 2020.

DEVMEDIA. Padronizando seus projetos no mundo corporativo – Parte I. Disponível

em: https://www.devmedia.com.br/padronizando-seus-projetos-no-mundo-corporativo-
-introducao-parte-i/7158. Acesso em: 10 jul. 2020.

DEVMEDIA. Conheça os padrões de projeto. Disponível em: https://www.devmedia.

com.br/conheca-os-padroes-de-projeto/957. Acesso em: 20 jul. 2020.

KON. F. Padrões de projeto de software orientado a objetos. Disponível em: https://

www.ime.usp.br/~kon/presentations/GoF.ppt. Acesso em: 15 jul. 2020.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções reutili-
záveis de software orientado a objetos. Porto Alegre: Bookman, 2007. ISBN 978-85-7780-
046-9. Minha Biblioteca.

LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orienta-

dos a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN
978-85-7780-047-6. Minha Biblioteca.

LINHA DE CÓDIGO. O Component Object Model. Disponível em: http://www.linhadecodi-

go.com.br/artigo/2864/o-component-object-model.aspx. Acesso em: 10 jul. 2020.

LINHA DE CÓDIGO. O Modelo de Arquitetura Corba. Disponível em: http://www.linhade-

codigo.com.br/artigo/299/o-modelo-de-arquitetura-corba.aspx. Acesso em: 10 jul. 2020.

MASSARI. Jorge. Padrão MVC. Arquitetura Model-View-Controller. Disponível em:

https://www.portalgsti.com.br/2017/08/padrao-mvc-arquitetura-model-view-controller.
html. Acesso em: 8 jul. 2020.

METSKER, S. J. Padrões de projeto em Java. Porto Alegre: Bookman, 2004.

MICROSOFT. Component Object Model (COM). Disponível em: https://docs.microsoft.

com/en-us/windows/win32/com/component-object-model--com--portal. Acesso em:
14 ago. 2020.

57
PRACTICE: desenvolvimento baseado em componentes. Disponível em: https://www.
agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/practices/componen-
tes_6A150B73.html. Acesso em: 7 jul. 2020.

VILAS BOAS, L. Padrões GRASP – Padrões de Atribuir responsabilidades. Disponível

em: https://medium.com/@leandrovboas/padr%C3%B5es-grasp-padr%C3%B5es-de-a-
tribuir-responsabilidades-1ae4351eb204. Acesso em: 20 jul. 2020.

58
 UNIDADE 3

Diagramas estruturais da UML

 INTRODUÇÃO

A UML (Unified Modeling Language) é uma linguagem de modelagem utilizada para es-
pecificar, visualizar, construir e documentar artefatos de software. É uma notação gráfica
padrão para uso em projetos de sistemas desenvolvidos no paradigma da Orientação a
Objetos. É composta por 13 diagramas, que se dividem em dois grandes grupos: diagra-
mas comportamentais e diagramas estruturais.

Os diagramas comportamentais apresentam como o sistema responde às requisições,

eventos ou como o mesmo evolui durante o tempo. Já os diagramas estruturais apresen-
tam as características estruturais do sistema.

Esta unidade aborda três diagramas estruturais: Diagrama de Pacotes, Diagrama de

Componentes e Diagrama de Objetos. A UML, de acordo com a OMG ( Grupo de
Gerenciamento de Objetos, uma organização Internacional, fundada em 1889), forne-
ce a arquitetos de sistemas, engenheiros de software e desenvolvedores de software
ferramentas de análise, design e implementação para sistemas baseados em software
orientado a objetos.

OBJETIVO

Nesta unidade você será capaz de:

• Construir a modelagem física de um sistema utilizando os diagramas

estruturais da UML.

60
Diagrama de Pacotes

O Diagrama de Pacotes faz parte do grupo de diagramas estruturais da UML e tem por
objetivo representar os pacotes ou pedaços do sistema divididos em agrupamentos lógi-
cos, mostrando as dependências entre eles e as partes que os compõem.

Os diagramas de pacotes são frequentemente utilizados em conjunto com outros diagra-

mas (classes, componentes, implantação etc.) para demonstrar como esses elementos
são agrupados.

O Diagrama de Pacotes é um diagrama formado por pacotes (package) e relacionamen-

to entre eles.

Importante

Um pacote em UML é um mecanismo de agrupamento genérico (lógico ou

físico), que pode ser formado por classes, interfaces, componentes, diagramas
ou até outros pacotes.
- Um pacote lógico é um agrupamento lógico de classes e relações entre
essas classes.
- Um pacote físico representa uma estrutura física, como: arquivo fonte,
imagem etc.
Um pacote pode relacionar-se com outros. Os relacionamentos permitidos
entre pacotes são de dependência, refinamento e generalização (herança).
Os relacionamentos mais comuns são: dependência de acesso (simples) e
dependência de importação.

Componentes do Diagrama de Pacote:

Nome Símbolo Definição

Package

É um mecanismo de agrupamento
PACOTE
Attributes genérico (lógico ou físico).

61
 A linha de dependência UML pode ser
utilizada para mostrar as dependên-
DEPENDÊNCIA cias entre pacotes ou entre elemen-
tos dos pacotes, ou seja, como um
pacote depende ou influencia outro.

Fonte: Elaborada pela autora (2020).

Em um pacote podemos agrupar classes, componentes, nós de uma infraestrutura de

hardware, entre outros. Além disso, um pacote pode conter outros.

O critério para definir os pacotes é subjetivo, ou seja, depende da visão e das necessidades
do analista ou projetista e, ainda, da particularidade do cenário que se propõe representar.

Por exemplo, um dos critérios seria utilizar o Diagrama de Pacotes para representar a
arquitetura do sistema (conforme exemplo a seguir). Outro critério seria representar os
pacotes que iriam compor uma aplicação (sistema, sistema web ou aplicativo). Como
terceiro critério, representar os pacotes de classes que serão utilizados na aplicação (sis-
tema, sistema web ou aplicativo).

Conforme já mencionado, um Diagrama de Pacote pode ser utilizado para realizar diver-
sas representações necessárias e úteis na fase de análise e projeto de sistemas.

Exemplo: apresentar a arquitetura do sistema.

Sistema Administrativo
<<system>>

Apresentacao
<<layer>>

Negocio
<<layer>>

Dados
<<layer>>

Fonte: Elaborado pela autora (2020).

62
O Diagrama de Pacotes do exemplo anterior organiza o sistema em um conjunto de
camadas lógicas (layers). Cada camada (pacote) tem uma função bem definida no siste-
ma. O diagrama também mostra a dependência (relacionamento entre os pacotes) das
camadas: uma camada somente solicita serviços da camada inferior e fornece serviços
para a camada superior.

Vamos entender as “dependências” no Diagrama de Pacotes.

As dependências, geralmente, são divididas em dois grupos: de acesso e de importação.

1. Dependência de acesso: o pacote A depende, de alguma forma, do pacote B.

É chamada também, de dependência simples.

No exemplo a seguir, a comunicação depende de segurança.

comunicacao seguranca

Fonte: Elaborada pela autora (2020).

2. Dependência de importação («import»): o pacote A importa os elementos

públicos do pacote B.

No exemplo a seguir o pacote “venda” importa do pacote “dao”.

venda <<import>> dao

Fonte: Elaborada pela autora (2020).

63
 Ampliando o foco

Existem outras categorias de dependência, como: uso, abstração e disponibili-

zação. Essas são menos utilizadas.

Dependência de Uso

Ocorre quando um determinado pacote nomeado requer outro para sua

definição e implementação completa.
Exemplo: cliente e fornecedor.

Dependência de Abstração

Relaciona dois pacotes que representam o mesmo conceito em diferen-

tes níveis de abstração no sistema (geralmente uma relação entre cliente
e fornecedor).
Exemplo: cliente e fornecedor.

Dependência de Disponibilização

Apresenta a implementação de um artefato em um alvo de implementação.

Alguns estereótipos utilizados nos Diagramas de Pacotes:

Pacote que representa o sistema completo que está sendo

«system»
modelado.

Pacote que representa uma parte independente do sistema que

«subsystem» está sendo modelado. Corresponde normalmente a um corte
“vertical”.

«layer» Pacote que representa uma camada lógica de um sistema.

Pacote que representa um conjunto de classes abstratas e con-

«framework» cretas concebido para ser estendido, implementando uma fun-
cionalidade específica.

Pacote sem nenhum elemento (vazio), que representa uma vi-

«facade» (fachada) são sobre outro pacote (não acrescenta funcionalidades, ape-
nas as apresenta de forma diferente).

64
Exemplos

Exemplo 1: Diagrama de Pacotes.

No exemplo a seguir são apresentados os pacotes, seus elementos e o relacionamento

entre eles. A linha de dependência UML, neste contexto, é utilizada para apresentar as
dependências entre os pacotes do diagrama.

Control Model
<<interface>>
Bola Bola
InterfaceDoViewer

ControleDeObjetos

ControleDeColisao

Viewer2D Viewer3D Utilitarios

Viewer2D Viewer3D Desenhar3D Util3D

Fonte: Campos e Costa (2017).

O Diagrama de Pacote acima apresenta o relacionamento que é necessário existir entre

os pacotes, viabilizando um mecanismo para propagação das mudanças de forma a
manter a consistência entre Model e View:

65
 Os Controllers recebem a entrada do usuário
(geralmente eventos).

Eventos são traduzidos em requisições de serviço,

que são enviadas para o Model ou para a View.

Após receber a requisição e alterar seu estado interno

o Model notifica todas as Views a ele conectadas.

As Views notificadas recuperam os dados do Model

e atualizam as informações para o usuário.

Exemplo 2: Diagrama de Pacotes - Sistema e Subsistemas.

SistemaAdministrativo
<<system>>

Contabilidade Financeiro RH Vendas

<<subsystem>> <<subsystem>> <<subsystem>> <<subsystem>>

Neste segundo exemplo o Diagrama de Pacotes apresenta um sistema administrativo e

seus módulos, ou seja, o sistema Administrativo possui os módulos Contabilidade (sub-
sistema), Financeiro (subsistema), RH (subsistema) e Vendas (subsistema). Para apre-
sentar esta lógica, foi utilizado o Diagrama de Pacotes em que cada pacote corresponde
a um subsistema.

66
Diagrama de Componentes

O Diagrama de Componentes especifica um conjunto de componentes que podem ser

usados para definir sistemas de software. Os diversos componentes podem ter relacio-
namentos entre si e esses relacionamentos podem ser de qualquer tipo: dependência,
generalização, associação ou realização.

Importante

O componente é uma unidade modular com interfaces bem definidas e subs-

tituíveis dentro do seu ambiente. Em outras palavras, um componente é uma
parte reusável e substituível do software.

Com relação ao relacionamento, os componentes de um diagrama não funcio-

nam sozinhos, pois existem diferentes níveis de colaboração entre eles. Grafi-
camente, o relacionamento é representado por linhas de tipos diferentes para
cada tipo de relacionamento.

Cabe destacar que existe uma diferença na definição de componente da

UML 1.x para a UML 2.x.

Na UML 1.x, um componente representa uma estrutura física (arquivo). Como exemplos,
podemos citar:
• Arquivo executável.
• Biblioteca de classes ou funções.
• Arquivo de dados.
• Banco de dados.
• Tabela do banco de dados.
• Arquivo de configuração.
• Imagem; documento.
• Arquivo-fonte etc.

Atualmente, na UML 2.x, o Diagrama de Componentes tem por objetivo apresentar os com-
ponentes, especificando quais são suas interfaces, permitindo que outros componentes
possam acessar seus serviços sem que para isso precisem conhecer seu conteúdo.

67
 Importante

Um componente é um elemento abstrato e não necessariamente uma única clas-

se. Deve ser entendido como um artefato (caixa preta) reusável e substituível.

Para que sejam componentes reusáveis e substituíveis eles devem estar fracamente aco-
plados, ou seja, a dependência entre eles deve ser fraca. Quando a dependência é fraca,
conseguimos substituir um componente (artefato) sem afetar os demais. Nesse sentido,
os componentes devem interagir uns com os outros sempre por meio de interfaces.

Componentes do Diagrama de Componentes:

Nome Símbolo Definição

É representado como um retângulo,

<<componentent>>
AcessoSistema
COMPONENTE
<<componentent>>
Banco de dados SQLite
é utilizado o estereótipo
<<component>> seguido do nome
do referido componente.
Atenção: também pode ser incluído,
no canto direito, um ícone (um retân-
gulo com duas tabs sobrepostas)
similar à representação antiga.

É o serviço ou informação provida ou

INTERFACE
oferecida por um componente. Pode
PROVIDA
ser representado por uma “bola”.

É o serviço ou informação que o

INTERFACE componente necessita para realizar
REQUERIDA o seu trabalho. Pode ser representa-
do por um “soquete”.

A linha de dependência UML pode

ser utilizada para mostrar as de-
pendências entre os componentes,
DEPENDÊNCIA ou seja, a ligação entre a interface
provida e a requerida também é
definida com o relacionamento de
dependência.

Fonte: Elaborado pela autora (2020).

68
 Importante

Algumas ferramentas UML permitem a ligação direta da bola com o soquete,

sem a necessidade da dependência.

Alguns estereótipos utilizados nos Diagramas de Componentes:

«file» Arquivo: é um arquivo de dados do sistema.

«libray» Biblioteca: é uma biblioteca de código.

«document» Documento: é um documento de sistema.

«executable» Executável: é um arquivo executável

«table» Tabela: é uma tabela de um banco de dados

Fonte: Elaborado pela autora (2020).

Para refletir

Para que servem os diagramas?

Eles são construídos para planejar, discutir os possíveis componentes, validar e
depois documentar a aplicação (programa) construída.

Exemplos

Exemplo 1: Diagrama de Componentes.

69
 O componente Compressor
usa o serviço provido pelo
componente Loader

Loader <<interface>> Compressor

FileLoader

+ load (path: String): File

<<interface>>
FileCompressor

+ compress (path: String): CompressedFile

Fonte: Elaborada pela autora (2020).

No exemplo 1 a ligação entre a interface provida e a requerida também é definida com o

relacionamento de dependência (seta pontilhada).

Para explicitar exatamente quais serviços estão disponíveis em uma interface podemos
adotar a notação utilizada no exemplo 1:

<<interface>>
FileLoader

+ load (path: String): File

O componente Loader
disponibiliza o método
load a partir da
interface FileLoader

Fonte: Elaborada pela autora (2020).

Nesse caso, é possível visualizar os métodos disponíveis, seus parâmetros e tipo de re-
torno. Ainda, nessa notação podemos utilizar os estereótipos << provided interface>> e <<
required interface>> para identificar as interfaces providas e requeridas.

70
 Importante

Para quem for utilizar essa notação, em que as interfaces são descritas no
diagrama, é importante conhecer a sintaxe das interfaces.

Exemplo 2: Diagrama de Componentes.

IValidaUsauario IValidaSenha

<<component>>
AcessoSistema

IConexao

Fonte: Melo (2011, p. 215).

No exemplo 2, o Diagrama de Componentes mostra o componente de acesso ao sistema

associado a três interfaces, duas interfaces provida (“IvalidaUsuario” e “IValidaSenha”) e
uma interface requerida (“IConexao”).

Outra forma de representar o Diagrama de Componentes do exemplo 2:

<<component>>
AcessoSistema

<<provided interface>> + IValidaUsuario

<<provided interface>> + IValidaSenha
<<required interface>> + IConexao

Fonte: Melo (2011, p. 215).

71
Diagrama de Objetos

O Diagrama de Objetos é um refinamento realizado no Diagrama de Classes. Os elemen-

tos do Diagrama de Objetos são especificações de instâncias, ou seja, fornecem uma
visão dos valores armazenados pelos objetos de um Diagrama de Classe (modelo de
domínio) em um determinado momento da execução de um processo — fato que explica
a associação dos dois diagramas.

O Diagrama de Objeto, também chamado de Diagrama de Instância, apresenta um

arranjo de objetos e seus relacionamentos no tempo.

De acordo com o exposto, podemos entender o Diagrama de Objetos como uma instân-
cia do Diagrama de Classe no qual temos para cada classe um objeto (instância) em um
determinado ponto do tempo. Logo, é necessário chamar a atenção para o seguinte fato:

Só devemos criar objetos que tenham relevância dentro da modelagem.

Dessa forma, na hora de criarmos o Diagrama de Objetos, só vamos criar objetos para o con-
junto de classes complexas, ou seja, para modelagem de estruturas complexas de dados.

Importante

Para criar um Diagrama de Objeto basta pegar o Diagrama de Classes (domí-

nio), identificar as classes complexas que necessitam ser modeladas e substi-
tuí-las por objetos e seus relacionamentos. Deve-se, ainda, utilizar anotações e
cores diferenciadas para chamar a atenção no diagrama.

72
Exemplo 1

Diagrama de Classe.

1..” 1
Funcionario Projeto
trabalha
descricao: string
nome: string
1 0..1 inicio: date
cargo: string gerencia
fim: date
salario: real
custo: real

FuncionarioContratado FuncionarioTerceirizado

carteiraProfissional: string inicioContrato: date

dataAdmissao: date terminoContrato: date
prestadoraServicos: string
taxaAdministracao: real

Fonte: Melo (2011, p. 138).

No Diagrama de Classe anterior a “Classe Funcionário” é uma classe abstrata, ou seja,

não poderá haver instâncias diretas dessa classe. Neste caso, precisamos compreender
o relacionamento das subclasses da “Classe Funcionário”> Para tal utilizamos o Diagra-
ma de Objetos a seguir, a fim de mapear apenas as subclasses com a “Classe Projeto”.

73
 Diagrama de Objeto.

P1: Projeto

descricao = “Desenvolvimento do Sistema SCMK1”

inicio = “01/06/2000”
fim = “31/12/2000”
custo = 6000,00

F1: FuncionarioContratado F2: FuncionarioContratado

nome = “Joao Silva” nome = “Maria Santos”

cargo = “Analista de Sistemas” cargo = “Analista de Sistemas”
salario = 3500,00 salario = 3800,00
carteiraProfissional = “012345-0” carteiraProfissional = “0987-5”
dataAdmissao = 01/06/1997 dataAdmissao = 01/02/1995

F3: FuncionarioTerceirizado

nome = “Antonio Souza”

cargo = “Analista de Sistemas”
salario = 2500,00
inicioContrato = 01/05/1999
terminoContrato = 30/04/2001
prestadoraServicos = “CA Terc”
taxaAdmissao = 6

Fonte: Melo (2011, p. 139).

Importante

Devemos utilizar o Diagrama de Objeto sempre que for necessário compreender

o relacionamento de uma classe com outra. Ou seja, quando houver complexi-
dade no relacionamento de determinada classe.

74
Exemplo 2:

O Diagrama de Objetos a seguir mapeia o relacionamento da Classe Pedido, Classe Item

Pedido e a classe Produto.

Vamos analisar uma parte do Diagrama de Classe a seguir.

Diagrama de Classe.

Cliente
nome
endereço

Pedido ItemPedido Produto

1 * * 1
data quantidade nome
hora obterTotal() descrição
obterTotal() preçoUnitário
desconto
obterValor()

Fonte: Bezerra (2015).

No exemplo 2 precisamos compreender o relacionamento da classe Pedido, Item Pedido

e Produto. Para tal, utilizamos o Diagrama de Objeto para criar instâncias e entendermos
de forma clara o relacionamento das três classes.

Nesse caso, criamos as instâncias pedido e item pedido e seus produtos, conforme o
Diagrama de Objeto a seguir:

75
 Diagrama de Objeto.

produto20: Produto

nome = “Caderno M”
descrição = “Caderno em espiral tamanho médio”
preçoUnitário = 4,50
desconto = 15

item1: ItemPedido

quantidade = 6

produto12: Produto
pedido1: Pedido
item2: ItemPedido nome = “Caneta ESF”
data = 13/09/2002 descrição = “Caneta esferográfica 5mm”
quantidade = 20
hora = 10:00am preçoUnitário = 1,20
desconto = 2

item3: ItemPedido

quantidade = 1

produto07: Produto

nome = “Esquadro”
descrição = “Esquadro de acrílico 20cm”
preçoUnitário = 2,35
desconto = 10

Fonte: Bezerra (2015).

76
 Componentes do Diagrama de Objeto.

Nome Símbolo Definição

A representação gráfica de um
objeto é similar à de uma classe.

É representado por um retângulo

carro1: Carro com dois compartimentos. O pri-
meiro mostra o nome do objeto
+Ano: int = 2010 e o segundo apresenta os atribu-
+Marca: string = “VW” tos, um em cada linha, com seus
Objetos
+Modelo: string = “Fox Trend” respectivos valores.
+Quilometragem: double = 2353190
+ValorDiaria: double = 94.00 É possível, ainda, omitir o nome
+Cor: string = “Preto” do objeto representando um ob-
jeto anônimo ou omitir o nome
da classe. Em ambos os ca-
sos se mantêm os dois pontos
e o sublinhado

É a instância de uma associa-

ção. O nome da associação pode
Links
ser mostrado na terminação
dos links.

Fonte: Elaborada pela autora (2020).

77
 Ampliando o foco

Os diferentes diagramas que compõem a UML são classificados em três ca-

tegorias: Diagramas Estruturais, Diagramas Comportamentais e Diagramas
de Interação.

Diagramas Estruturais

Priorizam a descrição estática de estruturas de um sistema, como clas-

ses, atributos e operações dessas classes, além de prováveis relaciona-
mentos entre tais construções.

Diagramas Comportamentais

Detalham o comportamento de partes de um sistema ou processos de

negócio relacionados à aplicação que se deseja modelar.

Diagramas de Interação

É um subgrupo dos diagramas comportamentais, sendo normalmente

utilizado na representação de interações entre objetos de uma aplicação.

78
 MIDIATECA

Para ampliar o seu conhecimento veja o material complementar da Unidade 3,

disponível na midiateca.

NA PRÁTICA

Vamos imaginar a seguinte situação:

A loja K&K vende eletrodomésticos e, atualmente, está precisando de um siste-

ma para ajudar a gerenciar suas vendas e principalmente a calcular as comis-
sões a serem pagas aos seus vendedores.

Nessa empresa o valor das comissões varia de acordo com os produtos e ain-
da existe a necessidade de saber algumas informações, como:

Qual vendedor obteve o maior número de vendas?

Quais são os produtos mais vendidos?
Qual é o produto menos vendido?

Suponha que você seja o analista responsável pelo desenvolvimento do siste-

ma anterior e precisa explicar para a sua equipe como é o relacionamento do
vendedor com os produtos vendidos. Qual diagrama você usaria para explicar o
relacionamento da Classe produto com a classe Vendedor?

Nesse caso, você deveria utilizar um Diagrama de Objetos. Quando utilizamos

o Diagrama de Objetos passamos a analisar dados reais, que auxiliam na com-
preensão, esclarecendo dúvidas relacionadas ao domínio do negócio.

79
 Diagrama de Objeto.

V1: Vendedor V2: Vendedor V3: Vendedor

nome = “Carlos” nome = “Carla” nome = “Amelia”

P1: Produto P2: Produto P3: Produto

descricao = “ TV 14” ” descricao = “Geladeira” descricao = “Freezer”

Fonte: Melo (2011, p. 140).

Analisando o Diagrama de Objetos anterior entendemos como é o relaciona-

mento da Classe vendedor com a classe produto. Assim, temos:

• Vendedores que não vendem nada.

• Vendedores que vendem vários produtos.
• Um produto não vendido.
• Um produto vendido por vários vendedores.

De acordo com o exposto, verificamos que o Diagrama de Objetos apresentou

as diferentes relações que podem existir entre as classes “Vendedor” e “Produ-
to”, pois foi possível trabalhar com suposições reais, representadas no diagra-
ma. Já o Diagrama de Classe mostra apenas as classes Vendedor” e “Produto
e o relacionamento entre essas classes.

80
Resumo da Unidade 3

Nesta unidade conhecemos três diagramas estruturais da UML: Diagrama de Pacote,

Diagrama de Componentes e Diagrama de Objeto. Vimos também quando devemos uti-
lizar esses diagramas e a importância de cada um deles.

Assim, pudemos compreender que um Diagrama de Pacote descreve as dependências

entre diferentes pacotes que compõem uma aplicação. Já um Diagrama de Componen-
tes apresenta diferentes componentes de um sistema, além de possíveis dependências
entre tais componentes e elementos desses componentes, enquanto um Diagrama de
Objeto apresenta uma determinada estrutura de objeto em tempo de execução.

81
Referências

BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de Ja-
neiro: Campus-Elsevier, 2015. ISBN – 978-85-352-2626-3. ISBN (versão digital) 978-85-
352-2627-0. Minha Biblioteca.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: soluções reutilizá-
veis de software Orientado a Objetos. 2. ed. Porto Alegre: Bookman, 2000. Minha Biblioteca.

LARMAN, C. Utilizando UML e Padrões: uma Introdução à Análise e Projeto Orientado a

Objetos e ao Desenvolvimento Iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN 978-
85-7780-047-6. Biblioteca Virtual.

MEDEIROS, E.S. Desenvolvendo software com UML 2.0 definitivo. São Paulo: Pearson,
2004. ISBN 978-85-346-1529-7. Biblioteca Virtual.

MELO, A. C. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação.

3. ed. Rio de Janeiro: Brasport, 2011.

82
 UNIDADE 4

Diagramas de implantação
de um software
 INTRODUÇÃO

Nesta unidade vamos abordar os três diagramas da UML utilizados para apresentar os
detalhes da implantação de um software. Esses diagramas são: Diagrama de Implemen-
tação, Diagrama de Perfil e Diagrama de Implantação.

Todos compõem o grupo dos diagramas estruturais da UML, e têm por objetivo apresen-
tar a visão física da aplicação que está sendo projetada do ponto de vista do engenheiro,
em que o foco é a topologia dos componentes de software, hardware e a comunicação
entre esses componentes.

OBJETIVO

Nesta unidade você será capaz de:

• Construir os diagramas da UML utilizados na fase de implantação de um sistema.

84
Diagrama de Implementação

Os diagramas de implementação compõem o grupo dos diagramas estruturais da UML.

A função do Diagrama de Implementação é mostrar a visão física da aplicação sob o pon-
to de vista do engenheiro, em que o foco é a topologia dos componentes de software,
a comunicação entre esses componentes e a distribuição física do processamento.

Os diagramas de implementação, que geralmente são desenvolvidos e analisados du-

rante a fase de codificação (implementação), apresentam a organização física dos nós,
artefatos, componentes e outros elementos, que compõem um sistema distribuído. Os
artefatos geralmente são armazenados em um nó. Já os nós representam dispositivos
de hardware, como servidores, sensores e impressoras, bem como outros dispositivos.
Por exemplo: os dispositivos que suportam o ambiente de tempo de execução de um sis-
tema, os caminhos de comunicação e relacionamentos de implementação que mostram
suas conexões.

O Diagrama de Implementação — também chamado de Diagrama de Implantação no

Nível de Especificação — apresenta a combinação entre os dispositivos de hardware e
os componentes de software, sem especificar as instâncias dos nós. Esse diagrama co-
meça a ser criado na fase de elaboração e é finalizado na fase de construção, tendo por
objetivo especificar, documentar e apresentar a visão física do software.

Um Diagrama de Implementação deve ser criado quando é necessário ana-

lisar ou criar sistemas incorporados, ou seja, que utilizam um hardware que
é controlado por estímulo externo. Por exemplo: sistemas cliente/servidor
e sistemas distribuídos. Ambos os sistemas possuem vários servidores e
podem hospedar várias versões de artefatos de software.

A função dos diagramas de implementação é focar na configuração dos nós de proces-

samento de tempo de execução e de seus componentes e artefatos no nível da especifi-
cação, sem fazer referências a instâncias específicas de artefatos ou nós. Nesse sentido,
é possível utilizar esse tipo de diagrama para avaliar as implicações da distribuição e de
alocações de recursos.

85
 Nome Símbolo Definição

Nós: podem ser de dois tipos.

Dispositivos de hardware:
representam recursos com-
putacionais físicos (servi-
dores, dispositivos móveis,
notebooks, sensores, impres-
soras, roteadores, câmeras,
leitores biométricos etc.).
Servidor da
Nós
Aplicação
Ambientes de execução
de softwares: representam
recursos computacionais
lógicos que oferecem um
ambiente de execução para
componentes específicos
(sistemas operacionais, ser-
vidores web, servidores de
aplicação, SGBDs etc.).

Caminhos de comunicação:
associações entre nós que
permitem a comunicação,
Associação
ou seja, a troca de dados,
sinais e mensagens entre
esses nós.

A linha de dependência UML

pode ser utilizada para mos-
trar as dependências entre
DEPENDÊNCIA pacotes ou entre elementos
destes, ou seja, como um
pacote depende ou influên-
cia outro.

86
 <<device>> Nó que contém outro nó em
:UserClient
seu interior, que por sua vez
Nó (contêiner) <<device>>
:Browser
possui componentes e/ou
<<artifact>>
artefatos.
HTML5

Representado como um re-

tângulo, é utilizado o este-
<<component>>
COMPONENTE AcessoSistema reótipo <<component>> se-
guido do nome do referido
componente.

É utilizado com um nome

entre dois sinais de menor
<<database>> em sequência e dois sinais
ESTEREÓTIPOS vendas de maior, também em se-
quência (<< >>). Geralmente
é predefinido pela UML.

É o serviço ou informação
provida ou oferecida por um
INTERFACE
componente. Pode ser re-
presentado por uma “bola”.

É basicamente um arqui-
vo de configuração, como
um documento XML ou um
ESPECIFICAÇÃO DE <<deployment spec>>
DeploymentSpecification1
arquivo de texto, que espe-
IMPLEMENTAÇÃO
cifica as propriedades que
definem como um artefato
é implementado em um nó.

O exemplo a seguir traz o Diagrama de Implementação para apresentar a visão física

de uma aplicação de controle bancário sendo acessada a partir de um caixa eletrôni-
co. Para tal, foi observado e analisado tudo que era necessário em relação a hardwares

87
(dispositivos) e componentes de comunicação para o funcionamento da aplicação. Por
exemplo, o primeiro nó, “Caixa Eletrônico”, precisa ter o monitor, dispensador de dinheiro,
impressora de recibos, leitor de cartões, teclado numérico e dispositivo de log para fun-
cionar. É necessária, ainda, uma interface de rede com uma conexão para conectar-se a
um servidor da rede de “Caixas Eletrônicos”.

Após a identificação dos nós é preciso analisar e verificar o que é necessário em termos
de artefatos dentro de cada nó. Por exemplo, o Nó Caixa Eletrônico, precisa ter um con-
trolador de dispositivos e ainda uma interface para o usuário interagir com o caixa, além
da interface de rede responsável pela comunicação.

De acordo com o exposto, o diagrama a seguir apresenta uma visão geral da implementa-
ção de nós (dispositivo e seus subcomponentes), sem fazer referência a instâncias espe-
cíficas de artefatos ou nós, que deverá ser analisada e detalhada em momento posterior.

Dispositivo Dispensador Monitor

de log de dinheiro

Impressora
de recibos Teclado
numérico
Nó no caixa
eletrônico
Leitor de
cartões
preventivo Interface
de rede
Caixa eletrônico principal
Interface do cliente conexão da
Interface da rede de caixas eletrônicos rede T-1
Processador:
Pentium 200 Mhz Controlador de dispositivos
Memória
64 MB

Servidor da
Interface
rede de caixas de rede
eletrônicos
preventivo

Fonte: http://denan.com.br/documentos/DiagramaImplantacao.pdf.

No exemplo, o Diagrama de Implementação de Nível de Especificação (também chamado

de Nível de Tipo) apresenta uma visão geral da implementação de nós (dispositivo e seus
subcomponentes), sem fazer referência a instâncias específicas de artefatos ou nós.

88
Diagrama de Perfil

Os diagramas de perfil compõem o grupo dos diagramas estruturais da UML. É o diagra-

ma mais recente da UML, foi criado na UML 2.2.

O objetivo do Diagrama de Perfil é produzir perfis que adequem a UML a

plataformas e tecnologias atuais para os quais a UML não foi projetada.

O Diagrama de Perfil possui um conjunto de perfis que contém estereótipos, definições

(valores atribuídos), restrições e novos tipos de dados, ou seja, por meio da criação de
perfis é possível criar novos estereótipos ou metaclasses personalizados com valores
e restrições.

Conforme vimos nas unidades anteriores, a UML disponibiliza estereótipos padrões,

como: <<interface>>, <<file>, <<extends>>, <<include>>, <<database>> e etc.

Ampliando o foco

• Metaclasse: é uma classe em que suas instâncias também são classes e não
objetos. Assim como as classes definem o comportamento de certos objetos,
as metaclasses definem o comportamento de certas classes e suas instâncias.
• Estereótipo: permite adequar os modelos com construções específicas para
um domínio, plataformas tecnológicas ou método de desenvolvimento parti-
cular. Os estereótipos devem ser criados com um nome entre dois sinais de
menor em sequência e dois sinais de maior, também em sequência (<< >>).
Existem dois tipos de estereótipos: predefinidos pela linguagem ou definidos
pela equipe de desenvolvimento.

89
• Componentes do Diagrama de Pacotes:

Nome Símbolo Definição

Permitem adaptar ou perso-

<<metaclass>> nalizar modelos com cons-
Actor
truções específicas para
um domínio, plataforma ou
Estereótipo (criado / <<stereotype>> método de desenvolvimen-
InternetActor
perfil) to particular; é utilizado com
um nome entre dois sinais
<<Perfil>> de menor em sequência e
EJB
dois sinais de maior, tam-
bém em sequência (<< >>).

Caminhos de comunicação:
associações entre nós que
permitem a comunicação,
Associação
ou seja, a troca de dados,
sinais e mensagens entre
esses nós.

O Diagrama de Perfil utiliza a mesma notação do Diagrama de Pacotes com a adição da

palavra <<perfil>> apresentada anteriormente ao nome do pacote, conforme o Exemplo 1.

Exemplos:

Exemplo 1
Apresenta um estereótipo criado para especificar o contêiner de um servidor de aplicação.
Neste caso é o Enterprise JavaBeans (EJB), um componente da plataforma Java EE, ou
seja, houve a necessidade de especificar o tipo do componente (pacote) a ser utilizado.

<<Perfil>>
EJB

Fonte: O autor (2020).

90
Exemplo 2

<<Metaclass>> <<stereotype>>
Connector ServiceChannel

Fonte: O autor (2020).

O Diagrama de Perfil do exemplo 2 apresenta uma metaclasse “Connector” e um estereó-

tipo para representar o serviço (canal de serviço) a ser utilizado.

91
Diagrama de Implantação

O Diagrama de Implantação da UML tem por objetivo revelar quais partes do software
são executadas em quais partes do hardware. Esse diagrama foca na estrutura sobre a
qual o software será implantado e executado em termos de hardware ou combinando
hardware e software. O Diagrama de Implantação define, ainda, como os dispositivos
de hardware estarão conectados e por meio de quais protocolos elas se comunicarão.
Também é chamado de Diagrama de Instalação.

O Diagrama de Implantação é de grande utilidade quando o sistema é projetado para ser

executado em múltiplos nós, facilitando, dessa forma, a compreensão de todo o funcio-
namento da aplicação (sistema) sobre a sua visão física.

Componentes do Diagrama de Implantação:

Nome Símbolo Definição

<<device>> Representam elementos fí-

Servidor de
Aplicação I sicos concretos (arquivos
Artefatos
executáveis, bibliotecas, ar-
<<artifact>>
Módulo Gerenciador de Login quivos de configuração etc.).

Caminhos de comunicação:
associações entre nós que
permitem a comunicação,
Associação
ou seja, a troca de dados,
sinais e mensagens entre
esses nós.

92
 Nós podem ser de dois tipos:

Dispositivos de hardware:
representam recursos com-
putacionais físicos (servi-
dores, dispositivos móveis,
notebooks, sensores, impres-
soras, roteadores, câmeras,
leitores biométricos etc.).
Servidor da
Nós
Aplicação
Ambientes de execução
de softwares: representam
recursos computacionais
lógicos que oferecem um
ambiente de execução para
componentes específicos
(sistemas operacionais, ser-
vidores web, servidores de
aplicação, SGBDs etc.).

Caminhos de comunicação:
associações entre nós que
permitem a comunicação,
Associação
ou seja, a troca de dados,
sinais e mensagens entre
esses nós.

A linha de dependência UML

pode ser utilizada para mos-
trar as dependências entre
DEPENDÊNCIA pacotes ou entre elementos
destes, ou seja, como um
pacote depende ou influên-
cia outro.

93
 <<server>>
Servidor de Aplicações
Nó que contém outro nó em
<<executionEnvironment>> seu interior, que por sua vez
Nó (contêiner) Servidor JSP
possui componentes e/ou
AppVenda artefatos.

Representado como um re-

tângulo, é utilizado o este-
<<component>>
COMPONENTE AcessoSistema reótipo <<component>> se-
guido do nome do referido
componente.

É utilizado com um nome

entre dois sinais de menor
<<database>> em sequência e dois sinais
ESTEREÓTIPOS vendas de maior, também em se-
quência (<< >>). Geralmente
é predefinido pela UML.

É o serviço ou informação
provida ou oferecida por um
INTERFACE
componente. Pode ser re-
presentado por uma “bola”.

É basicamente um arqui-
vo de configuração, como
um documento XML ou um
ESPECIFICAÇÃO DE <<deployment spec>>
DeploymentSpecification1
arquivo de texto, que espe-
IMPLEMENTAÇÃO
cifica as propriedades que
definem como um artefato
é implementado em um nó.

É um elemento de modelo
que representa uma instan-
ciação de um nó existente,
INSTÂNCIA DE NÓ Node4Instance : Node4
ou seja, representa um nó
definido e específico no am-
biente do sistema.

94
 Assim como os demais diagramas da UML, o Diagrama de Implantação pode representar
a arquitetura do sistema sob diversas perspectivas. As três perspectivas mais comuns são:

• Diagrama de Arquitetura de Rede: apresenta os dispositivos de hardware e os

links de comunicação entre eles. Também chamado de Diagrama de Perfil, confor-
me já detalhado no Tópico 2 desta unidade.
• Diagrama de Implantação no Nível de Especificação: apresenta a combinação
entre os dispositivos de hardware e os componentes de software, sem especificar
as instâncias dos nós. Também chamado de Diagrama de Implementação, confor-
me já detalhado no Tópico 1 desta unidade.
• Diagrama de Implantação no Nível de Instância: apresenta a combinação entre
os dispositivos de hardware e os componentes de software, especificando as ins-
tâncias nos nós.

Exemplo 1

O Diagrama de Implantação a seguir apresenta uma visão geral da implementação de

nós (dispositivo e seus subcomponentes), detalhando as referências das instâncias espe-
cíficas dos artefatos e nós do sistema (aplicação) que está sendo construído. O modelo
foca na visão física da aplicação apresentada, detalhando todos os componentes neces-
sários para o seu funcionamento.

<<estação de trabalho do cliente>>

: PCGenérico

<<artefato>>
SO

MinhaIGURucaDoCliente.exe
AP

<<servidor>>
/H

:Dell Power Edge 3600

TT

{SO = Red Hat Enterprise Linux 4}

P

<<estação de trabalho do cliente>> <<aglomerado de <<container de servelet>>

: PCGenérico servidores Web>> Ajpv13 : Tomcat 6
HTTP : Apache 2.1 { JVM = sun Hotspot 2,0 }
<<navegador>>
{contagem <<artefato>>
:NavegadorWeb
DoAglomerado = 4} webstore.war

Um caminho de
comunicação pode
indicar o protocolo
Nó do dispositivo
<<servidor>>
: Dell Power Edge 3400
SQL Notação alternati-
va para um artefato
<<SO>>
: Red Hat Enterprise Linux 4}

Nó de ambiente <<banco de dados>>

: PostgreSQL 10 webstore.war
de execução

Fonte: Larman (2007).

95
 MIDIATECA

Para ampliar o seu conhecimento veja o material complementar da Unidade 4,

disponível na midiateca.

NA PRÁTICA

Analise o estudo de caso a seguir:

Uma empresa de venda de bebidas (cervejas artesanais) tem um catálogo com

cerca de 20 produtos e pouco mais de 100 vendedores. Cada vendedor visita,
por dia, aproximadamente 50 clientes distribuídos por toda a cidade do Rio de
Janeiro, Baixada Fluminense e Niterói. O roteiro de visita de cada vendedor é
fixo por dia da semana. A empresa gostaria de desenvolver um sistema que
permitisse aos vendedores coletar eletronicamente os pedidos dos clientes
para que, ao final do dia, esses pedidos fossem faturados e entregues no dia
seguinte. Toda a transmissão de dados deve ser feita de forma segura, ou seja,
criptografada. Os vendedores trabalham distribuídos por toda a cidade, ou seja,
não existe um local único de onde os vendedores partam ou cheguem ao final
do dia. Nas localidades de muitos clientes, principalmente os mais afastados,
não há sinal de telefonia celular disponível ou o sinal é muito fraco.

Vamos supor que você é o responsável por desenvolver esse sistema para co-
letar e processar pedidos. Mais ainda, suponhamos que você precise explicar
como a solução vai funcionar na prática para todos os envolvidos no projeto
de desenvolvimento desse novo sistema. Para tal, você deve criar a solução
arquitetural, ou seja, um Diagrama de Implantação para explicar todo o funcio-
namento estrutural sobre o qual o software será implantado e executado em
termos de hardware e software utilizados.

96
SOLUÇÃO:
Diagrama de Implantação:

Fonte: O autor (2020).

Este diagrama apresenta como vai funcionar o sistema a ser desenvolvido.

1. Smartphone (nó), a aplicação será desenvolvida para rodar em plataforma

Android. Dentro do nó Smartphone existe o nó do sistema operacional Android,
que por sua vez possui os seguintes componentes: aplicativo de vendas, base
de dados e um serviço para enviar os pedidos para o servidor de aplicação.

2. O nó <<app server>> é um servidor que disponibiliza um ambiente para insta-

lação e execução de aplicações, que por sua vez possui um nó Sistema opera-
cional Linux, que possui um servidor apache Tomcat (é um servidor web Java,
mais especificamente um container de servlets) e um serviço para enviar os
pedidos para a base de dados.

3. O nó << database server>> é um servidor de banco de dados que usa um

aplicativo de banco de dados e que fornece serviços de banco de dados. O
<< database server>> possui o nó Sistema operacional Linux, que possui um
banco de dados MySQL (artefato) e uma base de dados (artefato) faturamento.

4. O diagrama apresenta, ainda, o tipo de comunicação utilizada entre os nós. Exem-

plo: entre o smartphone e o servidor de aplicação utiliza-se WI, entre os demais nós
uma comunicação Ethernet. (É uma arquitetura de interconexão para redes locais
— Rede de Área Local — baseada no envio de pacotes. Define cabeamento e sinais
elétricos para a camada física, em formato de pacotes e protocolos.)

97
Resumo da Unidade 4

Nesta unidade aprendemos sobre os diagramas de implantação, que são classificados

como Diagramas de Implementação, Diagramas de Perfil (que é um tipo de um diagra-
ma de implantação) e Diagramas de Implantação. Esses diagramas são utilizados para
descrever a topologia dos componentes de hardware e software que fazem parte do
sistema. Assim como os demais diagramas da UML, o Diagrama de Implantação pode
representar a arquitetura do sistema sob diversas perspectivas.

As três perspectivas comuns são:

• Diagrama de Implementação: também chamado de Diagrama de Implantação no

nível de especificação, apresenta a combinação entre os dispositivos de hardware e
os componentes de software, sem especificar as instâncias dos nós.
• Diagrama de Perfil: apresenta os dispositivos de hardware e os links de comuni-
cação entre eles.
• Diagrama de Implantação no Nível de Instância: apresenta a combinação entre os
dispositivos de hardware e os componentes de software, especificando as instân-
cias nos nós.

98
Referências

BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de Janei-
ro: Campus-Elsevier, 2015. ISBN: 978-85-352-2626-3/ISBN (versão digital): 978-85-352-
2627-0. Minha Biblioteca.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: soluções reutilizá-
veis de Software Orientado a Objetos. 2. ed. Porto Alegre: Bookman, 2000. Minha Biblioteca.

LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e projeto Orientado a

Objetos e ao Desenvolvimento Iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN: 978-
85-7780-047-6. Biblioteca Virtual.

MEDEIROS, E. S. Desenvolvendo software com UML 2.0 definitivo. São Paulo: Pearson
Makron Books, 2004. ISBN: 978-85-346-1529-7. Biblioteca Virtual.

MELO, A. C. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação.

3. ed. Rio de Janeiro: Brasport, 2011.

99