5 Operative kapasiteter og fellesfunksjoner
5.7 Fellesfunksjoner
5.7.4 Styrkebeskyttelse
A noção de complexidade na engenharia do software (CES) aparece na literatura com vários significados, alguns dos quais sobrepostos ao conceito de funcionalidade abordado na secção 3.5.2.. Em seguida apresenta-se uma lista das definições mais utilizadas:
a complexidade computacional é um atributo do problema, que o produto modela e soluciona [Fenton,N.97; Wegner,P.95],
a complexidade algorítmica mede a eficiência do algoritmo implementado para resolver o problema. Alguns autores, neste caso, chamam-lhe eficiência [Fenton,N.97; Harel, D.92], a complexidade estrutural mede o número e a estrutura das primitivas do algoritmo da
solução [Fenton,N.97;Whihy,R.90],
a complexidade cognitiva mede o esforço requerido para entender o problema ou a solução [Coulter,N.83].
Dos enunciados anteriores ressalta que existem noções ligadas, quer à complexidade do problema quer à complexidade da solução.
A complexidade do problema é diferente da complexidade da solução. São conhecidas soluções complicadas de problemas simples e o mesmo problema pode conduzir a soluções de diferentes complexidades.
Exemplo 3.5.3.1.: O problema de ordenação de um ficheiro é exemplo deste último caso. Os diferentes algoritmos existentes para esse fim têm, segundo qualquer um dos tipos de complexidade antes mencionados, valores bastante diferentes. Por exemplo, a eficiência do algoritmo de ordenação por inserção é menor que a eficiência do algoritmo de ordenação por acervo (heap), respectivamente N2 e N log N em que N é a dimensão dos dados. Já na complexidade estrutural, existe uma relação inversa entre os algoritmos de ordenação por inserção e por acervo: o primeiro é executado com um ciclo dentro de outro ciclo, o segundo já exige a operação de restabelecimento da condição de acervo e eliminação de elementos de maior prioridade.
Segundo alguns autores [Fenton,N.97; Wegner,P.95] a complexidade do problema é o conjunto dos recursos necessários para implementar a solução óptima do problema. Naturalmente coloca se o problema de como definir óptimo. Não conhecemos qualquer regra para o efeito. No entanto, temos observado que, na prática, se optimiza localmente a solução em relação ao atributo medido.
Exemplo 3.5.3.2.: Por exemplo, se estivermos a medir a complexidade algorítmica que usa o atributo eficiência, o recurso optimizado será o tempo de execução, se o conceito usado for o da complexidade estrutural, a optimização será em relação ao tempo de implementação. Passando às análise das definições encontradas para a complexidade da solução, não há unanimidade. Referenciamos duas definições conhecidas:
A complexidade da solução “é a quantidade dos recursos necessários para implementar essa particular solução”.
A complexidade da solução “é o grau de complicação do sistema (modelo da solução), determinado por factores tais como o número e a complicação das interfaces, o número e a complicação das decisões condicionais, o grau de recorte (indent) dos tipos de estrutura de dados e outras características do sistema”.
A primeira referência [Fenton,N.97; Conte,S.86,Zuse,98; Halstead,M.77; Hill,P.99; Weyuker, E.88], é uma definição operacional e que tem servido de base à maioria das construções das métricas de complexidade que enunciamos na secção 3.5.3.1.
Citamos a segunda [IEEE83], embora ambígua, visto ser uma norma do IEEE e fornecer a perspectiva da multiplicidade de utilizações que este conceito encerra. Dá-nos também a oportunidade para esclarecer que as noções de “complicação” e de “complexidade” não devem ser utilizadas enquanto tendo o mesmo significado. A primeira consiste numa característica de sistemas cujo entendimento pode ser melhorado através da decomposição (análise parcelar) dos seus elementos constituintes; enquanto que a segunda caracteriza os sistemas cuja natureza (complexa) provém fundamentalmente da interacção entre aqueles elementos.
Analisaremos resumidamente as métricas da complexidade (CES), evidenciando os aspectos da sua ligação ao mundo real, a fim de concluirmos (como já fizemos com a funcionalidade), que necessitamos de outro tipo de métricas para controlar o processo.
O algoritmo que lhe serve de modelo à solução é frequentemente utilizado para efectuar a métrica da complexidade. Existem várias estratégias para a obtenção desta métrica:
Calculado a partir da chamada Eficiência do Algoritmo.
É uma métrica que usa o número de operações primitivas relevantes para o desenvolvimento desse algoritmo, necessárias para produzir uma determinada saída e a notação “Big 0” [Fenton,N.97] para garantir a condição de representação da métrica [Zuse,H.91]. Considera-se que, quanto menos operações primitivas são necessárias para obter um resultado, menos complexo é o algoritmo.
Calculado a partir da estrutura do algoritmo. Existem três tipos de métricas de estrutura [Witty,R.90;Conte,S.86]:
as que medem a complexidade da estrutura de controlo do algoritmo; as que medem a complexidade do tratamento de dados pelo algoritmo; as que medem a complexidade dos dados independentes do programa.
Para medir a complexidade da estrutura de controlo de um algoritmo, o mesmo é transformado num fluxograma [Fenton,N.97;Conte,S.86], a que está provado corresponder uma decomposição única em hierarquia de primitivas. Sobre essas árvores constroem-se métricas de complexidade que são chamadas métricas hierárquicas.
Exemplo 3.5.3.1.1.: São exemplos da medida a complexidade da estrutura de controlo de um algoritmo: o número de nós, o número de arcos, a métrica k da maior primitiva, a métrica d da estruturação. Outro exemplo muito conhecido é a métrica da complexidade ciclomática de McCabe, que representa o número de caminhos independentes que existem para percorrer o fluxograma. Várias outras métricas do tipo idêntico às primeiras foram propostas para este tipo de medição: a métrica de complexidade essencial [McCabe,J.89], a métrica de Vinap [Bach,R.90] e a métrica Knot [Woodward,M.93].
É ainda usada outra aproximação para medir complexidade da estrutura. Alguns autores consideram que a estrutura de um módulo está relacionada com a dificuldade de o testar. Esse tipo de métricas [Bach,R.90a] medem o número de casos de teste e a eficiência do teste e consideram que estão a medir a complexidade.
Para medir complexidade de tratamento de dados pelos programas analisam-se as relações entre os módulos. Transforma-se uma arquitectura de um programa num module call-graph, que desenha a hierarquia dos módulos e indica a troca de informações entre eles [Fenton,N.97;Conte,S.86].
Para analisar a dependência de dados dentro dos módulos usam-se outros tipos de diagramas [Fenton,N.97;Conte,S.86;Bieman,N.90].
Exemplo 3.5.3.1.2.: São exemplos de métricas dependência de dados dentro dos módulos a modularidade global (“global modularity”), que calcula a medida do comprimento dos
módulos e que corresponde à ideia de que, quanto menor for o tamanho dos módulos, menor é a complexidade do produto e a impureza hierárquica (“tree impurity”), que traduz o
afastamento de um dado módulo “call-graph” de uma árvore.
Esta métrica está suportada pela ideia de que, quanto mais um módulo “call-graph” se afasta de um árvore, mais complexo ele é.
São também usadas como métricas de complexidade métricas de acoplamento e de coesão entre módulos [Yourdan,E.79;Fenton,N.97;Conte,S.86], considerando que, arquitecturas com módulos muito acoplados e com fraca coesão interna são considerados complexos.
Constroem-se as denominadas métricas de informação medindo o nível total do fluxo de informação através do sistema e entre cada módulo com o restante sistema.
Exemplo 3.5.3.1.3.: São exemplos destas métricas: a complexidade do fluxo de informação
(“information flow complexity”), que usa o comprimento módulo, o seu “fan-in” e o seu
”fan-out” de Henry e Kafura [Fenton,N.97]; a “shepperd complexity” [Swepperd, M.93], que mede o fluxo de informação de um módulo.
A ideia pré-existente será que, quanto mais fluxo de informação passa ou é gerado por um módulo, mais complexo ele se torna e mais tempo leva a ser desenvolvido.
Para medir a complexidade da estrutura de dados foram usadas métricas análogas às da estrutura dos algoritmos. Neste caso, cada tipo de dados é considerado uma primitiva e é medida estrutura de dados na hierarquia formada por essas primitivas [Elliot,J.88;Berg,K.95]. Zuse lista 187 métricas de complexidade [Zuse,H.91], dizendo que existem mais de mil. A
listagem que fizemos incluiu a caracterização dos tipos de métricas que apresenta.