MODULARIDADE 


ESTRUTURAÇÃO DE SISTEMAS O.O

Roberto da Silva Bigonha

Mariza A.S.Bigonha
Laboratório de Linguagens de Programação
Departamento de Ciência da Computação
Universidade Federal de Minas Gerais
Maio de 2021
Todos os direitos reservados
Proibida a cópia sem autorização dos autores

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 1

ESTRUTURAÇÃO DE
MÓDULOS

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. - Estruturação de Módulos 2

 Conceito de Módulo

q  MÓDULO é um componente de software compilável

separadamente, por exemplo:

–  procedimento externo
–  unit do Turbo Pascal
–  arquivo fonte em C e C++
–  arquivo fonte em Java
–  pacote da ADA
–  module de Oberon-2
@Roberto S. Bigonha e Mariza Bigonha Estruturação de Sistemas O.O. - Estruturação de Módulos 3

Modularidade
■  MODULARIDADE é a chave para o desenvolvimento
de software com arquitetura flexível.

■  Modularidade permite atingir: extensibilidade e

reusabilidade

■  POO possibilita e prioriza a criação de módulos mais

flexíveis.

■  Módulos implementam abstrações.

■  O módulo é a única ferramenta disponível para

quebrar a complexidade e baixar o custo do software
(Parnas)
@Roberto S. Bigonha e Mariza Bigonha Estruturação de Módulo - Modularidade 4
 Princípios para Atingir Modularidade
q  Os seguintes princípios devem ser
observados para garantir modularidade:

–  Unidade Lingüística
–  Baixa Conectividade
–  Interface Pequena
–  Interface Explícita
–  Ocultação de Informação
–  Unidade Focal
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. 5

Princípio da Unidade Linguística

■  A todo tipo abstração realizável na linguagem deve corresponder um
tipo de módulo.
■  Deve existir um tipo de módulo para implementar as principais
abstrações correspondentes às principais construções da linguagem:
Expressões Funções
Comandos Procedimentos
Declarações de variáveis Abstração de Dados
Classes Tipo Abstrato de Dados
Classes genéricas Tipo Parametrizado
■  A linguagem deve prover o suporte lingüístico para a realização das
abstrações.

■  Sem o suporte lingüístico é muito difícil realizar manutenção em

software de grande porte.

■  A linguagem efetivamente modular deve prover recursos para construir

módulos para cada uma das abstrações.
@Roberto S. Bigonha, Mariza Bigonha Estruturaçãode Módulos 6
 Princípio da Baixa Conectividade
■  Todo módulo deve comunicar-se com um número
mínimo de outros módulos.

■  Baixo grau de conectividade decorre dos critérios de:

–  continuidade:
minimizar propagação de alterações

–  proteção:
erros propagam para poucos módulos

–  inteligibilidade:
baixa conectividade facilita entendimento
baixa conectividade aumenta grau de reusabilidade.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Módulos 7

Princípio da Baixa Conectividade...

Considere um sistema de 100 lâmpadas.

■  As lâmpadas podem ser conectadas de qualquer

forma.
■  Toda lâmpada está ligada e tem a probabilidade de
50% de desligar-se no próximo segundo.
■  Toda lâmpada desligada, que está conectada
diretamente a pelo menos uma lâmpada ligada, tem a
probabilidade de 50% de ligar-se no próximo segundo.
■  Toda lâmpada desligada assim permanece enquanto
estiver conectada diretamente a somente lâmpadas
desligadas.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 8
 Princípio da Baixa Conectividade...
Considere três casos:
■  100 lâmpadas desconectadas
■  100 lâmpadas completamente conectadas
■  100 lâmpadas conectadas em grupos de 10

Suponhamos que:
■  cada lâmpada representa um módulo.
■  Apagar ou acender uma lâmpada equivale a
modificar a interface de um módulo.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 9

Princípio da Baixa Conectividade...

1. 100 lâmpadas desconectadas e acesas:

em quantos segundos o sistema atinge estabilidade?

–  Como não tem nenhuma lâmpada conectada, a

metade apaga no próximo segundo

–  Como as 50 lâmpadas não estão conectadas, nunca

re-acenderão
– 
–  No próximo segundo 25 lâmpadas apagam-se
– 
–  Em 7 segundos todas as lâmpadas estarão
apagadas, 50, 25, 12, 6, 3, 2 e 1.
–  Equilíbrio em 7 segundos
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 10
 Princípio da Baixa Conectividade...

2. Particione o conjunto de 100

lâmpadas em 10 grupos de 10 em
grupos de 10, todas conectadas em
cada grupo.

Em quantos segundos o sistema atinge

estabilidade?

- Equilíbrio em 20 minutos
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. - Módulos 11

Princípio da Baixa Conectividade ...

3. 100 lâmpadas completamente conectadas: toda

lâmpada tem 99 conexões.
Em quanto tempo todas se apagam?
22
- Equilíbrio em 10 anos

q  CONCLUSÃO:
Conectividade é muito importante. Ao se
estabelecer uma conectividade entre
módulos está-se diretamente aumentando
o custo de manutenção
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 12
 Princípio da Interface Pequena
■  Se dois módulos não podem evitar de se comunicarem,
então a comunicação entre eles deve ser a mínima possível
■  O controle do volume e tipo de comunicação entre
módulos é fundamental para obter sistemas modulares.
■  Contra-Exemplos:
–  Common block do Fortran
Fortran: cada subrotina é um módulo compilado separadamente,
não tem aninhamento. É possível estabelecer áreas de dados
comuns usando commun.
–  External do C

Fato: a melhor forma de comunicação entre módulos deve

ser via parâmetros.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. Módulos 13

Princípio da Interface Explícita

■  Se dois módulos A e B se comunicam, então este fato deve
ser evidente pela simples inspeção do texto de A ou B.

■  Princípio relacionado com os seguintes critérios:

–  Composibilidade:
Composição só é possível se conexões forem claras.

–  Continuidade:
Componentes afetados por mudanças devem ser óbvios.

–  Inteligibilidade:
Como entender comportamento de um módulo se ele
é influenciado por outro módulo de alguma forma?
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. Módulos 14
 Definição de Interface Explícita
Para ilustrar o valor de interfaces explícitas, considere os módulos A e B
de uma biblioteca BiblioX definidos a seguir, onde o arquivo A.java tem o
código:
package BiblioX;
public class A {
private int pri = 1; protected int pro = 3;
public int op(int z){
X x = new X( ); Y y = new Y( );
pri = x.pac + y.op(z) + pri + pro; return pri;
}
}
class X{
private int pri = 1; int pac = 2; …
}
class Y{ Dentro da biblioteca, a
private int pri = 1; interface é o A, X e Y;
int op(int z) { return z+pri; }; fora da biblioteca, só o
} A
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. Módulos 15

... Definição da Interface Explícita

■  Interface do Módulo A contém:

–  operação int op(int z)

–  campo pro, exportado para subclasses e
outros módulos do pacote
–  classes X e Y, exportadas para outros
módulos do pacote
–  campo X.pac, exportado para outros
módulos do pacote.
–  Método Y.op(int z)
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 16
 ... Interface Explícita
CONSIDERE O MÓDULO B com o seguinte código:
package BiblioX;
public class B {
private int pri = 1;
protected int pro = 3;
private static class X {
private int pri = 1;
int pac = 2; ...
}
private static class Y {
private int pri = 1;
int op(int z) { return z+pri;}
}
public int op(int z) {
X x = new X( ); Y y = new Y( );
pri = x.pac + y.op(z) + pri + pro;
return pri;
}
}
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 17

...Definição da Interface Explícita

■  Interface do Módulo B contém:

–  operação int op(int z)

–  campo pro, exportado para subclasses e
outros módulos do pacote.

QUAL INTERFACE É A MELHOR?

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 18

 Definição das Interfaces de A e B
■  Interface do Módulo A contém:
–  operação int op(int z)
–  campo pro, exportado para subclasses e outros módulos do
pacote
–  classes X e Y, exportadas para outros módulos do pacote
–  campo X.pac, exportado para outros módulos do pacote.
–  Método Y.op(int z)

■  Interface do Módulo B contém:

–  operação int op(int z)
–  campo pro, exportado para subclasses e outros módulos do
pacote.
QUAL INTERFACE É A MELHOR?

A interface do Módulo B, por ser bem menor que a de A, é de melhor

qualidade, pois contém apenas a operação int op(int z) e o campo pro,
exportado para subclasses e outros módulos do pacote
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 19

Uso de A de B na mesma Biblioteca

package BiblioX; •  Módulo C:
public class C { ............
public int f( ) {
A a = new A( ); B b = new B( ); X x = new X( ); Y y = new Y( );
return x.pac + y.op(2) + a.op(3) + b.op(4);
}
}
•  Módulo C depende de:
•  A que é um módulo ou arquivo.
•  B que é módulo ou arquivo.
•  X e de Y, que não são módulos.
• Simples inspeção do módulo C não permite
•  determinar em que arquivos X e Y estão definidos.
• Diretório BiblioX não possui arquivos X.java e Y.java, eles estão em
A.java. Portanto pode ser preciso inspecionar outros arquivos da
biblioteca BiblioX.
•  Módulo B tem uma estrutura melhor que a de A.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 20
 Uso de A e B em Módulo Independente

Módulo Main da Biblioteca BiblioY:

package BiblioY;
import BiblioX.*;
public class Main {
public static void main(String[] args) {
A a = new A(); B b = new B(); int x = a.op(10) + b.op(20);
System.out.println("x = " + x);
}
}
•  Módulo Main depende apenas dos módulos A e B, não lhe
é permitido usar o X e Y.
•  As definições estão nos arquivos A.java e B.java do
subdiretório BiblioX.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 21

Princípio da Ocultação de Informação

■  Toda informação a respeito de um módulo deve ser
privativa do módulo, exceto se for explicitamente declarada
pública.

■  Todo módulo deve ser conhecido pela sua interface.

■  Ocultação de informação facilita a manutenção da

integridade do sistema a longo prazo.

■  Ocultação privilegia, principalmente, o critério de:

–  continuidade
■  Também está relacionado a:
–  composibilidade
–  inteligibilidade
22
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O.
 Princípio da Unidade Focal
Todo módulo deve servir a um único propósito, estar focado
em um aspecto específico do sistema, de tal forma a se ter
apenas um motivo para ser alterado.

■  Módulos que implementam aspectos distintos de um

sistema, como os módulos do tipo mistifório, tem mais
motivos de serem modificados em consequência de
inevitáveis alterações na especificação de todo o sistema.

Fato - consequência direta no grau de conectividade do sistema

■  Toda vez que um módulo precisa ser alterado, todos os que

dele dependem devem ser inspecionados para ver o efeito das
alterações realizadas.

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 23

Recomendações da Boa Prática

■  Cada módulo TAD deve implementar um único

tipo abstrato de dados.

■  Em geral, campos de qualquer classe devem, por

default, ser privados.

■  Somente a classe pública de um módulo deve

ser referenciada fora dele.

■  Deve-se evitar ao máximo acesso a classes que

não sejam públicas, mesmo dentro do próprio
pacote.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 24
 … Recomendações de Boa Prática
■  Para assegurar legibilidade e minimizar
conectividade, as classes não-públicas de um módulo
devem ser implementadas como classes aninhadas
da classe pública do módulo, observadas as
seguintes restrições:

–  usar apenas um nível de aninhamento.

–  classe devem ser estáticas para impedir
referências a campos da classe envolvente.
–  programar as classes aninhadas como se fossem
de primeiro nível.
–  declarar privadas as classes aninhadas.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 25

… Recomendações de Boa Prática

O seguimento dessas regras torna o modulo mais coeso, como ilustra o

seguinte pequeno exemplo, que mostra um módulo A encapsulando
completamente uma classe auxiliar C, enquanto exporta uma classe B a
ele fortemente vinculada.

public class A {
public static class B{ private int x; private int y; … }
private static class C { public int z; … }
}
Posso escrever: A.B fora de A?
A.C do lado de for A?
A.C.z dentro de A?
A.B.y fora de A?
A.B.x fora de A?
26
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O.
 … Recomendações de Boa Prática
public class A {
public static class B{ private int x; private int y; … }
private static class C { public int z; … }
}
Posso escrever: A.B fora de A? SIM
A.C do lado de for A? NÃO
A.C.z dentro de A? SIM
A.B.y fora de A? NÃO
A.B.x fora de A? NÃO

CONCLUSÃO: posso ter uma classe dentro de outra classe. Se a classe interna
é pública, ela é válida fora de A. Se ela for privada, ela só vale dentro de A,
contudo ela pode ter membros públicos, mas a publicidade deles é só do lado de
fora da classe e não do lado de fora da classe que a está envolvendo.
@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 27

ESTRUTURAÇÃO DE
SISTEMAS ORIENTADOS A
OBJETOS

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 28

 Estrutura Geral de um Sistema OO
S.O.O

CAMADA ... CAMADA ... CAMADA

ACERVO ... ACERVO ... ACERVO
ACERVO ... ACERVO ... ACERVO
….. ….. …..
BIBLIOTECA ... BIBLIOTECA ... BIBLIOTECA

MÓDULO ... MÓDULO ... MÓDULO

CLASSE ... CLASSE ... CLASSE

@Roberto S. Bigonha e Mariza A.S.Bigonha Estruturação de Sistemas O.O. 29

ORGANIZAÇÃO DO
ACERVO DE BIBLIOTECAS

@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 30
 Conceito de Biblioteca
■  Uma biblioteca é um conjunto de módulos

■  Um acervo é um conjunto de bibliotecas

■  Acervos podem ser organizados

hierarquicamente

■  A
hierarquia de acervo pode pertencer a
uma camada de software
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. - Organização do acervo de bibliotecas 31

■  Bibliotecas e acervos são diretórios.

... Conceito de Biblioteca

q  Define-sea inserção de um módulo em uma
dada biblioteca B de uma determinada
hierarquia de acervos A1.A2.A3. ... .An por
meio da diretiva

package C1.A1.A2.A3. ... .An.B

q  Diretivapackage deve ser incluída na primeira

linha do módulo.

q  Estemódulo pertence ao diretório B que

pertence ao diretório An, etc, até C1.
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. - Organização do acervo de bibliotecas 32
 Exemplo - Módulo A
package Camada1.Acervo1.Biblio1;
public class A{
private static class X {
private int pri = 1; int pac = 2; ...
}
private static class Y {
private int pri = 1; int op(int z){return z+pri;}
}
private int pri = 1; protected int pro = 3;
public int op(int z){
X x = new X( ); Y y = new Y( );
pri = x.pac + y.op(z) + pri + pro; return pri;
}
}
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. - Organização do acervo de bibliotecas 33

... Exemplo - Módulo B

package Camada1.Acervo1.Biblio1;
public class B {
private static class X {
private int pri = 1; int pac = 2; ...
}
private static class Y{
private int pri = 1; int op(int z){ return z+pri;};
}
private int pri = 1;
protected int pro = 3;
public int op(int z) {
X x = new X( ); Y y = new Y( );
pri = x.pac + y.op(z) + pri + pro;
return pri;
}
}
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 34
 ... Exemplo - Módulo Principal
package Camada1.Mains;
import Camada1.Acervo1.Biblio1.*;
public class MainB {
public static void main( String[ ] args)
A a = new A( );
B b = new B( );
int x = a.op(10) + b.op(20);
System.out.println("x = " + x);
}
}
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 35

Exemplos de Módulos de Uma Biblioteca

• Módulo T, que implementa o TAD T:
package BibliotecaA;
public class T {
private int pri = 1; protected int pro = 3; int pac = 4;
public void op1(...) {... X ...}
}
class X{ private int pri = 1; public int pub = 2;
protected int pro = 3; int pac = 4; .........…
}

•  Módulo U, que implementa o TAD U:

package BibliotecaA;
public class U { private X x = new X( );
private int pri = 2; protected int pro = 4;
void op1 ( ) { ....}
void op2 ( ) { .. }
}
@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 36
 Modularizar é a atividade central no
desenvolvimento de sistemas de grande
porte ou ponto grande, e módulos devem
ser autônomos e independentes, de forma
a minimizar sua conectividade e reduzir os
custos de manutenção

@Roberto S. Bigonha, Mariza Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 37

FIM

@Roberto S. Bigonha, Mariza A.S.Bigonha Estruturação de Sistemas O.O. Organização do acervo de bibliotecas 38