apostila gestão de projetos cruzeiro do sul 3

Prévia do material em texto

Gestão de Projetos 
de Tecnologia da 
Informação
Métricas de Orientação a Objetos 
Material Teórico
Responsável pelo Conteúdo:
Prof. Ms. Fábio Peppe Beraldo
Revisão Textual:
Prof. Ms. Claudio Brites. 
5
• Introdução
• Métricas de Orientação a Objetos
• Additional Measures (Medidas Adicionais)
O objetivo do estudo da disciplina Gestão de Projetos da TI é habilitar a planejar, organizar 
e gerenciar pools de recursos e desenvolver estimativas de recursos. Dependendo 
da sofisticação do software, você poderá gerenciar a estimativa e o planejamento, a 
programação, o controle de custos e a gestão do orçamento, a alocação de recursos, o 
software de colaboração, a comunicação, a tomada de decisão, a gestão da qualidade e 
dos sistemas de documentação ou de administração.
 · Falaremos bastante sobre tecnologia, tecnologia da informação, 
os sistemas da informação, e a gestão de todos os elementos, 
chamada de Governança de TI.
 · Nesse contexto, esta unidade apresenta a definição das 
métricas do projeto de software, definindo os tipos e focando 
principalmente nas métricas de orientação a objetos ou 
métricas orientadas a objetos.
Métricas de Orientação a Objetos 
6
Unidade: Métricas de Orientação a Objetos
Contextualização
As métricas de orientação a objetos (ou orientadas a objeto) são cada vez mais utilizadas na 
avaliação e prevenção da qualidade de softwares. Um grande número de resultados valida a 
teoria dessas métricas, esses indicadores demonstram que as métricas externas são importantes 
elementos de avaliação de confiabilidade, facilidade de manutenção e propensão a falhas, pois 
os atributos internos não podem ser medidos até muito tarde no processo de desenvolvimento 
de software.
7
Introdução
Programadores de software tem uma relação de amor e ódio com métricas. Por um lado 
desprezam e desconfiam de qualquer coisa que soe ou pareça uma medição, assim sendo são 
rápidos em apontar as “falhas” nos argumentos daqueles a favor da medição de produtos de 
software, processos de software, e (especialmente) as pessoas de software.
Mas o que são as Métricas de Software? O termo “métricas” é frequentemente utilizado para 
designar um conjunto de medidas específicas tomadas em um item ou processo particular. As 
métricas de engenharia de software são unidades de medida que são usados para caracterizar:
 » produtos de engenharia de software, por exemplo, desenhos e código-fonte,
 » processos de engenharia de software, por exemplo, as atividades de análise, projeto 
e codificação,
 » profissionais em engenharia de software, por exemplo, a eficiência de um testador, ou 
a produtividade de um designer.
 » Se usado corretamente as métricas de engenharia de software permitem:
 » quantitativamente definir o sucesso e o fracasso, e/ou o grau de sucesso ou fracasso, 
para um produto, um processo, ou uma pessoa,
 » identificar e quantificar a melhoria, a falta de melhoria ou degradação em produtos, 
processos e pessoas,
 » tomar decisões gerenciais e técnicas significativas e úteis,
 » identificar tendências,
 » fazer estimativas quantificadas e significativas.
As Métricas Orientadas a Objetos diferem das tradicionais devido a:
 » Localization: que é o processo de alocação de itens fisicamente próximos uns dos 
outros dentro da programação,
 » Encapsulation: que é a aglomeração (ou união) de um conjunto de itens,
 » Information hiding: que é a supressão de detalhes,
 » Inheritance: que é o mecanismo através do qual um objeto adquire as características 
de um, ou mais, outros objetos,
 » Abstraction: que é o mecanismo que foca nos detalhes importantes (ou essenciais) de 
um conceito ou item, ignorando os detalhes não essenciais,
8
Unidade: Métricas de Orientação a Objetos
Métricas de Orientação a Objetos
É cada vez mais abrangente o uso de métricas de orientação a objetos (ou orientadas a 
objeto) na avaliação e prevenção da qualidade de softwares. Um grande número de resultados 
valida a teoria dessas métricas, esses indicadores demonstram que as métricas externas são 
importantes elementos de avaliação de confiabilidade, facilidade de manutenção e propensão 
a falhas, pois os atributos internos não podem ser medidas até muito tarde no processo de 
desenvolvimento de software.
As figuras a seguir demonstram, não só as áreas medidas, mas também os métodos de 
medição (note que alguns modelos não utilizam as métricas que serão estudadas); a segunda 
figura mostra, em profundidade, as técnicas de medições das métricas (tanto as tradicionais 
quanto as orientadas a objetos) Vide páginas 11 e 12. 
Limitações das Métricas de Orientação a Objetos
O padrão internacional ISO/IEC, para qualidade de produtos de softwares, afirma que as 
métricas internas são de pouco valor a menos que haja evidência de que eles estão relacionados 
com a qualidade externa. É preciso notar que a validade destas métricas podem, às vezes, ser 
criticado. Muitas coisas, incluindo a fadiga e estresse físico/mental, pode afetar o desempenho 
de programadores com impacto resultante sobre as métricas externas. A única coisa que pode 
ser razoável afirmar é que a relação empírica entre as métricas de produtos de software não é 
muito forte, porque há outros efeitos que não são contabilizados.”
Métricas para Análise de Softwares Orientados a Objetos
Nesta seção, vamos descrever as métricas mais utilizadas para analise de softwares 
orientados a objetos:
Coupling (Acoplamento): Em 1974 definiu-se o acoplamento como “a medida da força 
de associação estabelecida através de uma ligação a partir de um módulo para o outro”; o 
acoplamento é uma medida da interdependência dos objetos. Por exemplo, objetos A e B 
são acoplados se um método do objeto A chama um método ou acessa uma variável no 
objeto B. As classes são acopladas quando os métodos declarados em uma classe usam 
métodos ou atributos das outras classes.
O fator de acoplamento (CF) é avaliado como uma fração onde o numerador representa 
o número de ligações sem herança; o denominador é o número máximo de acoplamentos 
de sistema. O número máximo de acoplamentos inclui tanto herança quanto acoplamento 
sem herança. Acoplamentos à base de herança surgem quando as classes derivadas 
(subclasses) herdam métodos e atributos de sua classe base (superclasse).
Evidencias suportam os benefícios do baixo acoplamento entre os objetos. Os principais 
argumentos são de que quanto mais forte o acoplamento entre artefatos de software:
9
• mais difícil é compreender artefatos individuais, e, portanto, manter ou melhora-los 
corretamente,
• maior a sensibilidade de mudança e de efeitos de propagação através de artefatos,
• mais testes são necessários para atingir níveis de confiabilidade satisfatórios.
Além disso, o acoplamento excessivo é prejudicial para o design modular e impede reutilização. 
Resumindo, o baixo ou fraco acoplamento é o mais desejável.
Cohesion (Coesão): Coesão refere-se a quão perto as operações em uma classe são 
relacionadas umas das outras. A coesão de uma classe é o grau em que os métodos locais 
estão relacionados com as variáveis de instância local na classe. Um conjunto de métricas 
examina a falta de coesão “Lack of Cohesion” (LOCOM), que é o número de vácuos nos 
métodos locais. Existem pelo menos duas maneiras diferentes para se medir a coesão:
 » calcular para cada campo de dados que percentagem dos métodos usar; calcule a 
média das percentagens e então subtrair de 100%. Percentagens mais baixas significam 
uma maior coesão.
 » métodos são mais similares que operem nos mesmos atributos. Contar o número de 
conjuntos vazios produzidos a partir da interseção dos conjuntos de atributos utilizados 
pelos métodos.
Alta coesão indica boa subdivisão da classe. A falta de coesão ou a baixa coesão aumentam 
a complexidade, aumentando assim a probabilidade de erros durante o processo de 
desenvolvimento. Classes com baixa coesão provavelmente poderiam ser subdividida em duas 
ou mais subclasses com maior coesão.Esta métrica avalia a implementação de design, bem 
como a reutilização.
Encapsulation (Encapsulamento): Ocultar informações é uma maneira de projetar 
rotinas de tal forma que apenas um subconjunto de seja conhecido dos usuários do módulo. 
Informações ocultas dão origem ao encapsulamento em linguagens orientadas a objeto. 
Encapsulamento significa que tudo o que é visto de um objeto é a sua interface, ou seja, 
as operações que podem ser executadas sobre o objeto. O ocultamento de informações é 
uma técnica que tem provado seu valor na prática, onde, os programas de grande porte 
que utilizam informações ocultas são mais fáceis de ser encontrados e modificados quatro 
vezes mais que aqueles que usam o encapsulamento.
A seguir seguem duas medidas de encapsulamento:
Attribute Hiding Factor (AHF): O Fator de Ocultação de Atributos mede as invisibilidades 
dos atributos. A invisibilidade de um atributo é o percentual das classes totais a partir do 
qual o atributo não é visível. Um atributo é chamado visível se ele pode ser acessado por 
outra classe ou objeto. Atributos devem ser “ocultos” dentro de uma classe. Eles podem 
ser impedidos de serem acessados por outros objetos por ser declarado privado. O AHF é 
uma fração onde, o numerador é a soma das invisibilidades de todos os atributos definidos 
em todas as classes e o denominador é o número total de atributos definidos no projeto. É 
desejável um alto valor de AHF.
Method Hiding Factor (MHF): O Fator de Ocultação de Método mede a invisibilidade 
de métodos em classes. A invisibilidade de um método é a percentagem do total de classes 
10
Unidade: Métricas de Orientação a Objetos
de que o método não é visível. O MHF é uma fração em que o numerador é a soma das 
invisibilidades de todos os métodos definidos em todas as classes e o denominador é o 
número total de métodos definidos no projeto. Os métodos devem ser ocultados dentro de 
uma classe e não estão disponíveis para o uso de outros objetos.
Inheritance (Herança): A herança diminui a complexidade, reduzindo o número de 
operações e operadores, mas essa abstração de objetos pode fazer a manutenção e design 
se tornar mais difícil. As duas métricas usadas para medir a quantidade de herança são a 
profundidade e a amplitude da hierarquia de herança.
Depth of Inheritance Tree (DIT): A profundidade de uma classe dentro da hierarquia 
de herança é definida como o comprimento máximo do nó de classe para a raiz da árvore 
da hierarquia e é medido pelo número de classes predecessoras. Nos casos que envolvem 
herança múltipla, o DIT é o comprimento máximo do nó para a raiz da árvore.
Number of Children (NOC): Esta métrica é o número de descendentes diretos (subclasses) 
para cada classe. Classes com grande número de descendentes são consideradas difíceis 
de se modificar e, geralmente, necessitam de mais testes devido aos efeitos sobre as 
modificações em todas os descendentes. Eles também são considerados mais complexo 
e propenso a falhas porque uma classe com vários descendentes podem ter de prestar 
serviços em um número maior de contextos e, portanto, deve ser mais flexível.
Complexity (Complexidade): Também conhecido como Weighted Methods/Class 
(WMC) ou Métodos Ponderados/Classe mede a complexidade de uma classe individual. 
Uma classe com mais funções do que os seus pares é considerado mais complexo e, 
portanto, mais propenso a erros. Quanto maior o número de métodos em uma classe, 
maior o impacto sobre os descendentes, pois estes irão herdar todos os métodos definidos 
em uma classe. Classes com um grande número de métodos são mais específicos o que 
limita a possibilidade de reutilização. Esse raciocínio indica que um número menor de 
métodos é bom para a usabilidade e reutilização. Recentemente, a tendência é utilizar 
métodos menores para reduzir a complexidade, aumentar a capacidade de leitura e 
melhorar a compreensão.
 
Additional Measures (Medidas Adicionais)
 » Number of Classes (Número de Classes): Se é feita uma comparação entre projetos 
com funcionalidade idêntica, os projetos com mais classes são melhor captados.
 » Lines of Code (Linhas de Código): Se é feita uma comparação entre os projetos com 
funcionalidade idêntica, os projetos com menos linhas de código tem design superior 
e requerem menos manutenção. Além disso, métodos maiores sempre representarão 
um risco maior em atributos como compreensibilidade, reutilização, e sustentabilidade.
11
Áreas medidas na Engenharia de Software 
12
Unidade: Métricas de Orientação a Objetos
Técnicas de medições das métricas
13
Material Complementar
GRAEML, A. R. Sistemas de informação: o alinhamento da estratégia de TI com a estratégia 
corporativa. 2. ed. São Paulo: Atlas, 2003. (e-book)
OLIVEIRA, F. B. (org.). Tecnologia da informação e da comunicação: desafios e propostas 
estratégicas para o desenvolvimento dos negócios. São Paulo: Pearson/FGV, 2010. v.1 (e-book)
PAGE-JONES, M. Fundamentos do desenho orientado a objeto com UML. São Paulo: 
Pearson, 2000. (e-book)
PRESSMAN, R. S. Engenharia de software. 7. ed. Porto Alegre: Grupo A, 2011. (e-book)
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Addison-Wesley, 2011. (e-book)
14
Unidade: Métricas de Orientação a Objetos
Referências
CARVALHO, M. M.; RABECHINI JR., R. Construindo competências para gerenciar 
projetos. 3. ed. São Paulo: Atlas, 2011.
COHN, M. Desenvolvimento de software com Scrum. Porto Alegre: Grupo A, 2011. (e-book)
GIDO, J.; Clements, J. P. Gestão de projetos. 3. ed. São Paulo: Cengage, 2007.
15
Anotações
www.cruzeirodosulvirtual.com.br
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil 
Tel: (55 11) 3385-3000
http://www.cruzeirodosulvirtual.com.br