Sap – stablility and abstract principle
-
Upload
engenharia-de-software-agil -
Category
Technology
-
view
1.039 -
download
1
description
Transcript of Sap – stablility and abstract principle
Princípio de Estabilidade e Abstração
SAP Definição: Um pacote deve ser tão abstrato quanto
estável.
Um pacote estável deve ser também abstrato de
modo que sua estabilidade não impeça que ele seja
estendido.
Um pacote instável deve ser concreto desde que o
código concreto dentro dele seja facilmente alterado.
Exemplo Exemplo de mudança no cliente.
Usuários e gerentes são incapazes de prever a qualidade de seus
produto. Uma simples mudança em uma parte do pedido pode
provocar falhas em outras partes que parecem ser completamente
independentes. Corrigindo esses problemas podem surgir ainda
mais problemas, e o processo de manutenção começa a se
assemelhar a um cachorro correndo atrás do rabo.
É difícil reutilizar um projeto que é altamente interdependente. Por
isso os desenvolvedores se assustam com a quantidade de trabalho
para separar uma parte indesejável do projeto, da parte desejável se
um projeto possui essa característica.
Exemplo Exemplo de mudança no cliente.
Muitas vezes o custo é menor do que fazer a separação, sendo
assim, é comum vermos projetos desse tipo serem remodelados do
zero.
Para ilustrar vamos utilizar um programa simples que é carregado
com a tarefa de copiar caracteres digitados em um teclado para uma
impressora, e que a plataforma de implementação não dá suporte a
independência dos dispositivos.
Exemplo
Exemplo Exemplo de mudança no cliente.
Há três módulos. O módulo "Copy" chama os outros dois. Imagine um loop dentro do módulo "Copy". O corpo do loop que chama o módulo "Read Keybord” (leitura do teclado) para buscar um caracter do teclado, que envia um caracter para omódulo "Write Printer” (Escrever impressora) que imprime o caráter.
Os dois módulos de baixo nível são bem reutilizáveis. Eles podem ser usados em muitos outros programas para ter acesso ao teclado e a impressora. Este é o mesmo tipo de reutilização que ganhamos com bibliotecas de rotinas.
Veja um exemplo de código parecido com o módulo “Copy”.
Exemplo Exemplo do código Copy
void Copy()
{
int c;
while ((c = ReadKeyboard()) != EOF)
WritePrinter(c);
}
Exemplo Exemplo de mudança no cliente.
Note que o módulo "Copy" é dependente do módulo "Write Printer", e portanto, não pode ser reutilizado em um novo contexto, apesar da funcionalidade desse módulo ser muito interessante, ele não é reutilizável em qualquer contexto que não envolva um teclado ou uma impressora.
Por exemplo, considere esse contexo: um programa que copia os caracteres digitados em um teclado para um arquivo em disco.
Certamente poderíamos modificar o módulo "Copiar" para dar-lhe a nova funcionalidade desejada.
Exemplo Exemplo de mudança no cliente.
Poderíamos acrescentar um “if” para que possamos escolher entre o
módulo "Write Printer" e o "Write Disk”, dependendo somete de
algum tipo de comando.
No entanto, isso acrescenta novas interdependências, para o
sistema, e conforme o passar do tempo, cada vez mais dispositivos
podem participar do programa, então o módulo "Copy" estará repleto
de declarações “if” e “else” e será dependente de vários módulos de
nível inferior. Ele se tornará rígido e frágil.
Ivertendo Dependências Invertendo dependências com OOD
Uma forma de caracterizar o problema acima é de notar que o
módulo que contém
um alto nível de acoplamento, ou seja, o módulo "Copy", é
dependente de seus detalhes.
Se pudéssemos controlar os outros módulos a partir de qualquer
dispositivo de entrada para qualquer dispositivo de
saída, poderíamos reutilizar livrimente o “Copy”. O OOD nos dá
mecanismos para a realização dessa inversão de dependência.
Ivertendo Dependências
Exemploclass Reader{ public:virtual int Read() = 0;};class Writer{public:virtual void Write(char) = 0;};void Copy(Reader& r, Writer& w){int c;while((c=r.Read()) != EOF)w.Write(c);}
Exemplo No entanto, essa classe "Copy" de não depende em tudo da
"Keyboard Reader", nem da "Printer Writer". Assim, as
dependências foram invertidas. Agora, a classe "Copy" depende
somente das abstracts, e o “Read” e o “Writer”.
Agora podemos reutilizar a classe "Copy", independentemente do
"Keyboard Reader" e do "Printe Writer". Podemos inventar novos
tipos de "Reader" e "Writer" que podem dar suporte à classe "Copy".
Além disso, não importa quantos tipos de "Reader e "Writer" são
criados, "Copy" não dependerá de nenhum deles.
Não haverá interdependências para deixar o programa frágil ou
rígido. Esta é a essência do DIP.
Estável VS Volátil Certamente poderíamos imaginar algumas mudanças se
estendecemos um pouco o nosso pensamento. Mas no curso dos
acontecimentos normal, essas classes têm baixa volatilidade.
Desde "Copy" dependa de módulos que são do tipo não-volátil, é
muito pouco provável que a “Copy” sofra alterações. "Copy" também
é um exemplo do princípio "Open/Closed". "Copy" está aberta a ser
expanção, uma vez que podem criar novas versões de "Reader"
e "Writer". No entanto, "Copy" está fechada para a modificação, já
que não tem que modificá-lo para alcançar essas extensões.
Assim, podemos dizer que uma dependência boa é uma
dependência de algo com baixa volatilidade. Quanto menos volátil o
objetivo da dependência, melhor a dependência. Da mesma forma
uma "Má Dependência" é uma dependência de algo que é volátil.
Quanto mais volátil o objetivo da dependência, pior é a
dependência.
Estabilidade Independência A definição clássica da estabilidade palavra é: "Não é facilmente
abalado."
Esta é a definição que iremos utilizar neste artigo. Ou seja, a
estabilidade não é uma medida da probabilidade que um módulo vai
mudar, e sim é uma medida da dificuldade de um módulo em mudar.
Como se alcançar a estabilidade? Por que, por exemplo
"Reader" e "Writer", são tão estáveis?
Considere novamente as forças que poderiam fazê-los mudar. Eles
não dependem de nada
em tudo, então a mudança de uma dependencia não podem
estender-se até eles e levá-los a mudar.
Essa característica é chamda de "Independência".
Estabilidade Independência Classes Independente são classes que não dependem de qualquer
outra coisa.
Outra razão que "Reader" e "Writer" são estáveis é que eles são
dependencias de outras classes. Entre "Copy", "KeyboardReader" e
"KeyboardWriter“.
O fato é que, podem existir alterações de "Reader" e
"Writer", mas, quanto mais dependencias essas classes
tiverem, mais difícil será alteralas.
Se alterarmos "Reader" ou "writer" que teria que mudar todas as
outras classes que dependem delas. Assim, essa mudança daria
muito trabalho e isso nos impede de mudar essas classes, e
aumentando a sua estabilidade.
Classes Estáveis
As classes mais estáveis, são classes que são
independentes e responsáveis. Essas classes não
têm nenhuma razão para mudar, e muitas razões
para não mudar
Dependências Estáveis
As dependências entre pacotes em um projeto devem ser no sentido da estabilidade dos PACOTES. Os PACOTES devem depender apenas de pacotes que são MAIS ESTÁVEL que ele.
Projetos não podem ser completamente estáticos. Alguma volatilidade é necessário ser mantida no projeto.
Métricas de Estabilidade Como podemos medir a estabilidade de um
pacote?
Uma maneira é contar o número de
dependências que entram e saem desse pacote.
Estas contagens nos permitirá calcular a posição
estabilidade do pacote.
Métricas de Estabilidade Ca: Acoplamentos Aferentes: O número de classes de fora deste
pacote, que dependemem classes dentro deste pacote.
Ce: Acoplamentos eferente: O número de classes dentro desse pacote que depende declasses de fora deste pacote.
I: Instabilidade: (Ce/(Ca + Ce)): Esta métrica tem no intervalo [0,1].
I = 0 (indica ser um pacote maximamente estável).
I = 1 (indica um pacote máximamente instável).
As métricas de Ca e Ce são calculados pela contagem do número de classes fora do pacote em questão que têm dependências com as classes dentro do pacote em questão.
Métricas de Estabilidade O PSD diz que a métrica de um pacote que deve ser maior do que
as métricas I do
pacotes que ele depende. ou seja, eu métricas devem diminuir na
direção de dependência.
Nem todos os pacotes devem ser estáveis. Se todos os pacotes em
um sistema foram maximamente estável, o sistema seria imutável.
Esta não é uma situação desejável. Na verdade, queremos projetar
a nossa estrutura de pacotes, de modo que alguns pacotes são
instáveis, e alguns são estáveis. A figura a seguir mostra o ideal
configuração de um sistema com três pacotes.
Métricas de Estabilidade
SAP Este princípio estabelece uma relação entre a
estabilidade e a abstração.
Ele diz que um pacote estável deve também ser
abstrato de modo que sua estabilidade não impeça
que ele seja modificado. Por outro lado, ele diz que
um pacote instável deve ser de concreto, uma vez
que a sua instabilidade permita que o código de
concreto dentro dele seja facilmente alterado.
SAP- Como mensurar? (NC): O número de classes do pacote
(Na): O número de classes abstratas no
pacote
(Abstração): A = Na / Nc
Um A tem o intervalo [0,1]
A = 0 (implica que o pacote não tem classes abstratas)
A = 1 (implica que o pacote possui somente classes
abstratas)
SAP - Gráfico A.I.
I = 1, A = I
maximamente
instável e
Abstrato
I = 0, A = 0
maximamente
estável e
concreto
SAP - Gráfico A.I.
I = 1, A = I
maximamente
instável e
Abstrato
I = 0, A = 0
maximamente
estável e
concreto
SAP - Gráfico A.I.
Pacotes que são maximamente ESTÁVEIS devem ser maximamente ABSTRATOS.
PACOTES instáveis DEVEM SER CONCRETOS.
A abstração de um pacote deve ser PROPORCIONAL a sua estabilidade.
Um pacote que fica na seqüência principal não é abstrato o bastante para a sua estabilidade,nem é instável para a sua abstração.
SAP - Distância da seqüência principal O pacote deve estar ligado ou próximo da seqüência
principal
(Distância D): D = | A + I - 1 | / √ 2
Intervalos D‟ a partir de [0, 0,707 ~]
(Distância normalizada D „): D‟ = | I + A - 1 |
Intervalos D 'a partir de [0, 1]
D = 0 indica que o pacote está diretamente ligadoa seqüência principal
D = 1 indica que o pacote está tão longelonge possível a partir da seqüência principal
SAP – Média e variância de todas as métricas D.
SAP- Plotando a métrica D’ de cada pacote ao longo do tempo
SAP- Plotando a métrica D’ de cada pacote ao longo do tempo
SAP- Plotando a métrica D’ de cada pacote ao longo do tempo
SAP
Dependências-Acíclicas
Dependências-Estáveis
Abstrações-Estáveis
Estabilidade
Autores
Cláudio Roberto Xavier
Samuel Lopes