Análise e Projeto de Software

Diagramas de
Componentes
Profa. Alessandra Alaniz Macedo
Slides adaptados do Prof. Dr. M. Goulão Ana
Moreira, João Araújo e Vasco Amaral
 ● Diagrama de Componentes
● Estereótipos de
Componentes
Tópicos ● Estratégias na Construção
de Componentes
○ Como se Implementa
um Componente
○ Princípios no desenho
de componentes
1. Diagrama de
Componentes
Diagrama de Componentes
Definição segundo a OMG
Structured Classifiers -> Components
“A Component represents a modular part of a system that encapsulates its
contents and whose manifestation is replaceable within its environment.
A Component is a self-contained unit that encapsulates the state and behavior of a
number of Classifiers. A Component specifies a formal contract of the services that
it provides to its clients and those that it requires from other Components or
services in the system in terms of its provided and required Interfaces.
A Component is modeled throughout the development life cycle and successively
refined into deployment and run-time.”
Segundo a OMG (Object Management Group)
Componentes
● Os componentes são elementos do modelo que representam
partes independentes e “substituíveis” de um sistema
○ Os componentes são mais abstratos que as classes e podem ser
considerados como fornecedores de serviços independentes
● Os componentes implementam e fornecem uma ou mais
interfaces e requerem do ambiente uma ou mais interfaces
○ Em conjunto, as interfaces oferecidas e requeridas determinam o
comportamento dos componentes
● A utilização de componentes contribui para construir sistemas
mais reutilizáveis, escaláveis e flexíveis
Componentes
● Os componentes oferecem serviços de modo
independente de onde o componente é executado, ou da
linguagem de programação em que foi construído
○ Um componente é uma entidade independente executável
que pode ser constituída por um ou mais objetos executáveis

● Os componentes podem variar em tamanho, desde

simples funções a sistemas completos
Componentes
● A estrutura interna dos componentes tem de ser
escondida e independente
○ Não se pode criar dependências entre o conteúdo de um
componente e os objetos externos (i.e. os objetos internos
não conhecem os objetos externos)
● Os componentes têm de oferecer interfaces para que
objetos externos possam interagir com eles
● Os componentes têm de requerer interfaces para poder
acessar a objetos externos sem conhecer
Componentes
● Têm um nome (ou mesmo um endereço – path name)
● Têm interfaces
○ A sua interface é publicada e todas as interações realizadas
com o componente são feitas através dessa interface
publicada
● Podem ter estereótipos
○ <<executable>>, <<library>>, <<table>>, <<file>>,
<<document>>
Componentes
● São substituíveis em tempo de desenho, ou de
execução, por outros componentes que ofereçam
funcionalidade equivalente, garantida pela
compatibilidade das suas interfaces
Interfaces (em geral)
● Uma interface é uma coleção de operações que especifica um serviço
oferecido por uma classe ou componente
● As classes realizam (ou seja, implementam) interfaces e podem conter
operações adicionais
● Cada interface representa um papel desempenhado por uma classe
○ Note que uma classe pode desempenhar mais papéis

● As interfaces disponibilizam vistas diferentes de uma classe, para ser

usadas por diferentes clientes
● As interfaces são usadas como “cola” no desenvolvimento baseado em
componentes
Interfaces de Componentes
● Interface = classificador com operações, mas sem atributos
○ Define um conjunto coeso de comportamentos
● Interfaces oferecidas
○ Definem os serviços que são fornecidos pelo componente a outros
componentes
● Interfaces requeridas
○ Especificam que serviços têm de estar disponíveis para que o
componente possa executar conforme especificado
● O nome da interface é colocado junto com o símbolo de interface
Interfaces de Componentes
● Notações equivalentes:

Provided Required
interface interface
Representação explícita de
interfaces oferecidas e requeridas

● OrderEntry é uma interface oferecida por Order

● Person é uma interface requerida por Order
Componentes e Interfaces
● Uma interface oferecida e uma requerida podem ser ligadas se
as operações da interface requerida forem um sub-conjunto
das operações da interface oferecida e as assinaturas das
operações associadas forem compatíveis
● Uma interface realizada por um componente é denominada
interface exportada, ou seja, uma interface que o componente
oferece a outros componentes como serviço
● Uma interface usada por um componente é denominada
interface importada
Componentes e Interfaces
● Um componente pode importar e exportar várias
interfaces
● Uma interface oferecida por um componente é
realizada por classes implementadas nesse
componente
Diagrama de Componentes
● Modelos da arquitetura de software que exibem uma
vista dos componentes de software, suas interfaces e
dependências
● A sua principal utilização é a modelagem das relações
estruturais entre componentes de um sistema
● Os elementos destes diagramas são os componentes,
suas interfaces e relações entre eles (dependência,
generalização, associação e realização)
Ligando interfaces requeridas e
oferecidas: Conector
Conector (notação mais compacta)
Conector ligando múltiplos
fornecedores e clientes que
partilham a mesma interface
oferecida/requerida
Infraestrutura de Componentes
(assembly)
Portos
● Um porto (feature de um classificador): especifica
um ponto de interação distinto entre o classificador
e o seu ambiente
● Apresentado como um pequeno quadrado no lado
do classificador
● Pode ter um nome
● Suporta comunicação unidirecional e bi-direcional
 Portos - Exemplo
● O componente Student tem dois portos Bi-directional
unidirecionais e um bi-direcional port

Input port

Output port
Portos - Mostrando Conectores

● Os portos e conectores especificam de que modo as interfaces de componentes se

mapeiam na funcionalidade interna dos componentes
● Estes conectores são considerados limitados, quando comparados com os usados
em outras linguagens de descrição de arquitetura de software
Portos (regras de utilização)
● Devem ser semanticamente coesos
○ O conjunto de interfaces oferecidas e requeridas através do porto deve ser coeso

● Permitem organizar as interfaces oferecidas e requeridas pelo respectivo

classificador (neste caso, o componente)
● Podem ter visibilidade
○ Quando representados sobre a fronteira do classificador, são públicos
○ Quando representados dentro da fronteira do classificador, são protegidos
○ Naturalmente não há portos privados
Componentes de Componentes
Componentes vs Classes

● Classes representam abstrações lógicas

● Componentes implementam um conjunto de elementos lógicos (e.g. Classes)
○ Classes podem ser mapeadas em componentes
● Classes podem ter atributos e operações públicas
● Componentes têm operações públicas apenas acessíveis através das suas
interfaces
Conectores de Delegação

● Conectores de delegação ligam as interfaces externas às

partes dos componentes que as implementam ou requerem
Conectores de Delegação
2. Estereótipos de
Componentes
Estereótipos de Componentes

● <<application>> ● <<datastore>>
● Interface com o
● Localização
utilizador
persistente para
○ Telas e controladores em
GUIs
armazenar dados
○ Páginas web

○ ...
Estereótipos de Componentes

● <<document>> ● <<entry>>
● Representa um ● Componente que
documento no representa um conceito
sistema do domínio
○ Documento eletrônico, ○ Frequentemente, estes componentes
Documento impresso não têm funcionalidade própria

○ São utilizados como repositório de

dados, para armazenamento e leitura
dos mesmos
Estereótipos de Componentes

● <<executable>> ● <<file>>
● Componente pode ser
● Arquivo de dados
executado num nó
● Ou seja, é sempre um
componente de software

○ A ser discutido nos diagramas de

instalação
Estereótipos de Componentes

● <<infrastructure>> ● <<library>>
● Componente técnico ● Biblioteca de funções ou
interno do sistema objetos
○ Ex: Logger
Estereótipos de Componentes

● <<realization>> implementa um ● <<process>>: oposto de

outro componente <<entity>>
○ Não tem a sua especificação ○ <<entity>> conceito do negócio
sem funcionalidade própria
própria
○ <<process>>
■ Usa a do componente que
implementa ■ Baseado em transações

○ Tem associado um componente ■ Pode satisfazer pedidos de

natureza funcional
estereotipado com
<<specification>>, de onde retira ■ Costuma ter um estado e
a especificação a implementar preservar os dados atuais
desse estado
Estereótipos de Componentes

● <<service>> ● <<source code>>

● Componente sem ● Arquivo com código
estado fonte
○ Arquivo em java, c++
● Satisfaz requisito
funcional
● Normalmente sem
persistência
associada
Estereótipos de Componentes
● <<subsystem>>
● Parte de um sistema
maior
○ Autocontido
○ Representa um componente
relativamente complexo
■ Pode conter vários
componentes internos
● <<specification>>
● Tem interfaces, mas não
implementação
○ Não contém classificadores para implementar
as interfaces que oferece
● Emparelhado com
componentes estereotipados
com <<realization>>
Estereótipos de Componentes

● <<table>> tabela, ● <<web service>>

dentro de uma base de representa um web service
dados, onde se
guardam dados
3. Estratégias na Construção
de Componentes
Construção de Diagramas de
Componentes
Estratégia descendente (top-down)
● Adequada para dar um primeiro panorama do projeto
● Ajuda na distribuição do trabalho pela equipe, numa fase
inicial
● “Perigosa” por promover/facilitar exageros na arquitetura
e no desenho
○ Pode-se desenvolver componentes que (ainda?) não sejam
necessários
Construção de Diagramas de
Componentes
Estratégia ascendente (bottom-up)
● Interessante quando partimos de uma coleção de classes
e a tentamos evoluir para uma coleção de componentes
reutilizáveis
● Interessante para possibilitar o acesso a funcionalidade
reutilizável existente numa aplicação
● Interessante na distribuição do trabalho para sub-equipes
3.1 Como se abstrai um
componente
Guias na construção de
componentes (1/2)
● 1) Mantenha os componentes coesos
● 2) Atribua classes de interface/fronteira a componentes
da aplicação
● 3) Atribua classes “técnicas” aos componentes de
infraestrutura
● 4) Defina os contratos entre as classes
● 5) Atribua hierarquias ao mesmo componente
● 6) Identifique componentes do domínio do negócio
Guias na construção de
componentes (2/2)
● 7) Identifique o tipo de colaboração entre as classes do negócio
○ 7a) As classes do servidor devem estar no seu próprio componente
○ 7b) Se um componente apenas tiver um cliente, funda-o no cliente
○ 7c) Classes cliente puras não devem ser usadas em componentes do domínio

● 8) Classes com elevado nível de acoplamento devem pertencer ao

mesmo componente
● 9) As trocas de mensagens entre componentes devem ser minimizadas
● 10) Defina os contratos entre componentes
1) Mantenha os Componentes Coesos

● Um componente deve implementar apenas um conjunto

de funcionalidades fortemente relacionadas
● Exemplos:
○ A interface lógica de uma aplicação mono-utilizador
○ Um conjunto de classes que representam um conceito de
domínio em grande escala
○ Classes técnicas que em conjunto representam um conceito
comum de infraestrutura
2) Atribua classes de interface como o
utilizador a componentes da aplicação
● As classes de interface com o utilizador e de fronteira devem
ser colocadas em componentes com o estereótipo
<<application>>
○ Estas classes implementam telas, páginas, ou relatórios, ou a “cota
lógica” que permite escolher que tela, página ou relatório deve ser
mostrada
● Numa aplicação com tecnologia Java, isto corresponde
normalmente a Java Server Pages, servlets, e classes que
representam telas implementadas sobre bibliotecas de classes
de interface, tal como Swing
3) Atribua classes técnicas a
infraestruturas de componentes
● As classes técnicas devem ser atribuídas a
componentes com o estereótipo <<infrastructure>>
○ As classes técnicas implementam serviços de sistema como
segurança, persistência e middleware
Exemplo
4) Definir Contratos de Classe
● Um contrato de classe é um método que responde
diretamente a uma mensagem enviada por outros objetos
○ Os contratos das classes Seminar incluem operações como
enrollStudent() e dropStudent()
● Na identificação de componentes, qualquer operação que
não seja um contrato de classes pode ser ignorada
○ Essas operações não contribuem para a comunicação entre
objetos distribuídos por diferentes componentes
5) Colocar hierarquias de classe
dentro de um mesmo componente
● Na esmagadora maioria dos casos, faz sentido que
todas as classes de uma mesma hierarquia. Seja ela
de herança ou composição, façam parte de um
mesmo componente
6) Identificar componentes do
domínio (do negócio)
● Componentes do domínio (do negócio) são normalmente
compostos por um conjunto de classes que colaboram
entre si para suportar um conjunto coeso de contratos
(coesão alta)
● Para minimizar o tráfego na rede, a fim de reduzir o
tempo de resposta da aplicação, tenta-se desenhar os
componentes de modo que o fluxo de informação ocorra
sobretudo dentro de um componente e não entre
componentes distintos (acoplamento baixo)
Componente do Domínio
7) Identificar o tipo de colaboração
entre as classes do domínio
● Para determinar a que componente do domínio uma classe de
negócio deve pertencer, deve-se identificar o tipo de
distribuição de informação que essa classe faz
○ Classe servidor: recebe, mas não envia mensagens
○ Classe cliente: envia, mas não recebe mensagem
○ Classes cliente/servidor: envia e recebe mensagens
● Depois de identificar o tipo de distribuição de informação de
cada classe, pode-se começar a identificar potenciais
componentes do domínio
7a) As classes de servidor devem estar num
componente representando o servidor

● As classes de servidor devem ficar alojadas num

componente do domínio próprio, formando por
vezes elas próprias componentes do domínio
○ Estes componentes funcionam como “última passagem” do
fluxo de mensagens, na execução de casos de uso de uma
aplicação
7b) Fundir um componente com o
seu único cliente
● Se tiver um componente de domínio que é um
servidor de apenas um outro componente de
domínio, pode fazer sentido (muitas vezes, faz
mesmo) combinar ambos os componentes num só
7c) As classes que são clientes puros não devem
fazer parte dos componentes do domínio

● Classes clientes apenas geram mensagens

○ O propósito de um componente do domínio é poder
responder a mensagens !!

● As classes clientes puros não adicionam nada à

funcionalidade oferecida por um componente de
domínio e muito provavelmente devem ser
colocadas em componentes de aplicação
8) Classes muito acopladas devem
pertencer ao mesmo componente
● Se duas ou mais classes colaboram com grande frequência,
devem ser colocadas no mesmo componente para diminuir o
tráfego de rede entre componentes diferentes
○ Isto é especialmente importante quando a comunicação entre as
classes em causa envolva o envio de objetos grandes, sejam eles
passados como parâmetro no envio de mensagens, ou recebidos
como valores de retorno
● O princípio estruturante é que as classes fortemente acopladas
devem estar juntas dentro do mesmo componente
9) Minimizar a dimensão do fluxo
de mensagens entre componentes
● As classes cliente/servidor devem ser colocadas em
componentes do domínio, mas há que escolher em
que componentes elas se integram
● Devemos escolher componentes de domínio de
forma a minimizar a comunicação entre
componentes distintos
○ Como já visto, pode-se fundir um componente com o seu
único cliente
10) Definir contratos do componentes

● Cada componente oferece serviços aos seus clientes

● Cada um desses serviços representa um contrato
Exercício

Com base no diagrama de classes a seguir, proponha um

diagrama de componentes.
3.2 Princípios no desenho de
componentes
Princípios no desenho de
componentes
● Dependências acíclicas
○ Não devemos ter dependências cíclicas nos grafos de
componentes
○ A -> B -> C -> A
Princípios no desenho de
componentes
● Limitação na propagação de mudanças
○ Uma mudança que afete uma classe deve apenas afetar
outras classes dentro do mesmo componente
■ E mesmo essas, o menos possível, claro

○ Não deve afetar classes fora desse componente

○ Esta propriedade liga-se com a coesão dos componentes
Princípios no desenho de
componentes
● Reutilização em conjunto
○ As classes de um componente são reutilizadas em conjunto
■ Para reutilizar uma, tem-se que reutilizar todas

○ Novamente, esta propriedade tem a ver com a coesão dos

componentes
Princípios no desenho de
componentes
● Não inverter as dependências na abstração
○ A abstração não deve depender dos detalhes
○ São os detalhes que dependem da abstração
Princípios no desenho de
componentes
● Aberto-fechado
○ Os elementos de software devem ser abertos a extensões,
mas fechados a modificações
Princípios no desenho de
componentes
● A granularidade de reutilização é a granularidade das
entregas
○ Não devemos reutilizar apenas parte de um elemento de
software entregue
Princípios no desenho de
componentes
● Abstrações estáveis
○ Um componente deve ser tão abstrato como estável
○ Por outras palavras, deve ser suficientemente abstrato de
modo que as alterações que lhe sejam feitas não afetem a
sua estabilidade
Princípios no desenho de
componentes
● Dependências estáveis
○ Se um componente X depende de outro Y, então Y deve
ser mais estável (menos propenso a alterações) que X
3.3 Codificação de diagrama
de componentes
Codificação de componentes

● Várias linguagens de programação fornecem construções

para subsistemas de modelagem
● pacotes em Java,
● módulos em Modula-2
● C ou C++, os subsistemas não são modelados
explicitamente, então os desenvolvedores usam
convenções para agrupar classes
● por exemplo, um subsistema pode ser representado como um
diretório contendo todos os arquivos que implementam o
subsistema
Codificação de componentes

● Independentemente dos subsistemas serem

explicitamente representados na linguagem de
programação, os desenvolvedores precisam
documentar cuidadosamente a decomposição do
subsistema, pois os subsistemas geralmente são
realizados por equipes diferentes
REFERÊNCIAS E
MATERIAL EXTRA
Tutoriais e Documentos
● UML 2.0 Superstructure
○ http://www.omg.org/cgi-bin/doc?formal/05-07-04
● UML 2 and the Unified Process, Arlow & Neustadt,
2005
○ http://www.agilemodeling.com/artifacts/componentDiagr
am.htm
● Documento de especificação UML
○ https://www.omg.org/spec/UML/2.5.1/PDF
Ferramentas
● Lucidchart: Editor online de diagramas (com modelos
UML, inclusive Diagrama de Componentes)
○ https://www.lucidchart.com
Análise e Projeto de Software
Diagramas de
Componentes
Profa. Alessandra Alaniz Macedo
Slides adaptados do Prof. Dr. M. Goulão Ana
Moreira, João Araújo e Vasco Amaral