Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Engenharia de Software - Métricas - Conceitos, Notas de estudo de Engenharia de Produção

Apostila - Engenharia de Software - Métricas - Conceitos

Tipologia: Notas de estudo

2010

Compartilhado em 23/05/2010

thiago-costa-77
thiago-costa-77 🇧🇷

3 documentos

1 / 25

Documentos relacionados


Pré-visualização parcial do texto

Baixe Engenharia de Software - Métricas - Conceitos e outras Notas de estudo em PDF para Engenharia de Produção, somente na Docsity! Engenharia de Software Orientada a Objetos TOTO == eetnaaçãs—| Avaliação da Qualidade: medindo o produto Guilherme H. Travassos Programa de Engenharia de Sistemas e Computação ahicos.ute br Be x [Prleegeroo] Shari Lawrence Plleeger; Software Engineering: Theory and Practice, Second Edition, Prentice Hall, 2000 [Travassos et allot] Travassos, GH., Shull, F. and Carver, J.; Working with UML: A Software Design Process Based on Chidamber, S.R. and Kemerer, C. F.; A Metrics Suite for Object Oriented Design, IEEE Transactions on Basili, Victor R.; Eriand, Lionel and Melo, Walcelio; A validation of Object-Oriented design metrics, W. Lie and S. Henry (1993). Object-oriented metrics that predict maintainability, Journal of Systems and Travassos, G. H. and Andrade, R. S., Combining Metrics, Principles and Guidelines for Object Oriented Copyright by G.H. Travassos coppEuERa- 2001 Engenharia de Software OO TT ia] Bibliografia Chapter 6 Inspections for the Unified Modeling Language, in Advances in Co mputers, vol. 54, Academic Press, 2001 Software Engineering, vol.20, no6, June 1994 Technical Report, Univ. of Maryland, Dep. Of Computer Science, CS-TR-3443, May, 1995 Software. 23(2):111-122. Design, Workshop on Quantitative Approaches on Object Oriented Software Engineering, ECOOP99, Lisbon, Portugal, 1999 (http://www .esw.inesc.pt/ftp/pub/esw mood/ecoop93) Medição do Produto | * Modelos de Software e Medidas: Escopo * Precisamos definir modelos para * Ajudar a entender o que estamos fazendo * Fornecer uma base para definir objetivos * Fornecer uma base para medição * Precisamos modelos de: - pessoas, i.e., cliente, gerente, desenvolvedor * processos, i.e., um ciclo de vida, método, técnica * produtos, o sistema,um componente, um plano de teste * Precisamos estudar as interações entre estes modelos - Qualo efeito da modificação de um processo no produto? * Precisamos associar métricas a estes modelos * Como medir processo? Copyright by G.H. Travassos coppEuERa- 2001 Medição do Produto * Modelos de Software e Medidas * Oque podemos medir? * Dados sobre recursos: - Esforço por atividade, fase, tipo de pessoal, tempo de computação, tempo de desenvolvimento - Dados sobre alterações/ defeitos: - Alterações e defeitos de acordo com diferentes esquemas de classificação * Dados sobre processo: - Definição do processo, Conformidade com o processo, compreensão do domínio - Dados sobre produto: - Características do produto - Lógicas, i.e., domínio de aplicação, função - Físicas, i.e., tamanho, estrutura - Operacional, i.e., confiabilidade - Informação de uso e contexto, i.e., método de projeto utilizado Copyright by G.H. Travassos coppEuERa- 2001 Medição do Produto TT ni] * Modelos de Software e Medidas * Contribuindo para: - Planejar o desenvolvimento do software e o processo de manutenção de forma que - Recursos adequados estejam disponíveis quando necessários - Análise de custo/benefício e identificação de riscos possam ser executadas - Monitorar o processo para prevenir ou reduzir dificuldades quando ainda possível - Controlar o processo através de ações corretivas ou preventivas baseadas na análise quantitativa * Avaliar a eficiência das fases e atividades de desenvolvimento ou processo de manutenção baseado em informação objetiva - Refinar os processos de desenvolvimento e manutenção Copyright by G.H. Travassos coppEuERa- 2001 Medição do Produto TT | * Modelos de Software e Medidas [Basis] ões de Métricas de Software - Existem várias maneiras de se discutir métricas: - Nível de precisão, e.g., objetiva, subjetiva - Escalas de medição , e.g., nominal, ordinal, intervalo, razão - Objeto de medição, e.9., processo ou produto - Métrica Objetiva: - Uma medida absoluta extraída do produto ou do processo - Usualmente representada num intervalo ou escala razão - Exemplos: tempo de desenvolvimento, número de linhas de código, número de erros ou modificações - Métrica Subjetiva: - Uma estimativa de extensão ou grau de aplicação de alguma técnica - Uma classificação ou qualificação do problema ou experiência - Normalmente feita numa escala nominal ou ordinal - Exemplos: qualidade do uso de um método ou técnica, experiência dos programadores na aplicação ou processo Copyright by G.H. Travassos coppEuERa- 2001 Medição do Produto . . * Modelos de Software e Medidas * Visões de Métricas de Software * Escalas de Medição Escala Operações Básicas Exemplos Típicos Nominal Determinação de igualdade Áreas de aplicação Tipos de defeitos Ordinal Determinação de maior ou menor Nível de treinamento ou compreensão Intervalo Determinação de igualdade de Datas de calendário intervalos ou diferenças Linhas de código Razão Determinação de igualdade de Número de defeitos razões Complexidade do código Copyright by 6.4. Travassos coprEurRs- 201 Medição do Produto TT TT Si) - Métricas para qualquer produto “engenheirado” são governadas pelas características do produto * Assim como para software convencional, métricas OO objetivam: - Melhor compreender a qualidade do produto - Identificar a eficiência do processo - Melhorar a qualidade do trabalho sendo realizado O que faz um produto de software OO ser diferente de um software convencional? Como medimos a qualidade de um sistema 00? Que características do modelo de projeto podem ser identificadas para determinar se um sistema será fácil de implementar, ameno de ser testado, simples de modificar, e mais importante, será aceito pelos usuários? Copyright by G.H. Travassos coppEuERa- 2001 Medicção do Produto TT a] - “Engenheirando” produtos de software convencionais - Solução está centrada na função ou nos dados - Utiliza algoritmos, procedimentos (com diferentes notações ao longo do ciclo de vida) e organização de dados para descrever o problema e organizar a informação - Basicamente, módulos organizam a arquitetura do software * Tecnologia de estruturação da informação (modelo relacional, por exemplo) determina como a informação será armazenada e avaliada. Copyright by G.H. Travassos coppEuERa- 2001 Medição do Produto - “Engenheirando” produtos de software convencionais - Decomposição funcional (desenvolvimento estruturado) e algumas métricas possíveis r 1 Program a na Il do while X O po cab: po calle; Po cana Subroutine c 1º endwhile: calle; O ' if y then call £ O ' end; Especificação Projeto Implementação Testes Pontos por função Coesão Complexidade Ciclomática Cobertura Páginas de documentação acoplamento Teoria de Halstead Confiabilidade Linhas de código estimadas Complexidade Linhas de código Tempo (calendário) Número de Módulos Ligações de Dados Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO TT a] * Modelos e Métricas *. Tamanho (descrição de requisitos, projeto de alto e baixo nível) Lorenz e Kidd [Lorenz94] Fase] Descrição Projeto | Projeto | Codificação | Testes Métrica | Requisitos Alto Baixo Nível | Nível NSS N cs N Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO * Modelos e Métricas The Gas Station problem A 2 Requirements: claims po —, 1 — A customer has the option to be billed automatically at — ssem C> Pinte system the time of purchase (gas, car maintenance or parking spots) or to be sent a monthly paper bill. Customers can pay via cash, credit card or personal check. Gas Station services have a fixed price (gas: US$ 1.09 gallon, car Corsi imertoy maintenance: US$ 150.00 and parking spot: US$ 5.00 per ZA day). The taxis 5% added to the final price of the purchase. Sometimes, the Gas Station owner can define / CO System discounts to those prices. Customer 2 — The system has to track bills on a month -to-month Gas santos maintenance services basis and the services performed by the gas station on a day-b-day basis. The results of this tracking canbe Patsordamo reportedto the owner upon request. ss Parking services 3 — The gas station owner can use the system to control inventory. The system wil either warn of low inventory or NSS -6 automatically order new parts and gas. Copyright by G.H. Travassos coppEuERa- 2001 10 Medição de Software OO | * Modelos e Métricas E —s 7 ba 1 TE Es] pe Fes] sc Min — [Max Lote dq E NKC 17 17 E A cs 1 7 gestgço | a) Noo º 1 mma NOA o o / si 0 1 SE == uy ta E T E E ce Copyrightby GM Travassos copp vera. sos Medição de Software OO * Modelos e Métricas * Produto (projeto de alto e baixo nível) Chidamber e Kemerer Metrics Suite [Chidamber94] * Métodos Pesados por Classe (WMC) - Profundidade de Herança (DIT) * Número de Filhos (NOC) * Acoplamento entre Objetos (CBO) - Resposta de uma classe (RFC) - Perda de Coesão em Métodos (LCOM) o Fase | Projeto | Projeto | Codificação | Testes Métrica | Alto Baixo Nível | Nível WMC DIT NOC CBO REC LCOM Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO | * Modelos e Métricas * Produto - Métodos Pesados por Classe (WMC) Considere uma classe C,, com métodos M,,.... M, que são definidos pela classe. Faça Cy... Cy Ser a complexidade dos métodos. Então: n WMC =)'ci = Se todas as complexidades dos métodos são consideradas ser 1, então WMC = n, o número de métodos. Pontos de Vista: 1) Número de métodos e a complexidade de métodos relacionam-se com quanto tempo e esforço são necessários para desenvolver e manter a classe 2) Quanto maior o número de métodos numa classe, maior o potencial de impacto nos filhos, desde que os filhos herdam os métodos da classe 3) Classes com grande número de métodos tendem a ser mais específicas da aplicação, limitando sua possibilidade de reutilização Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO TT Si] * Modelos e Métricas * Produto - Profundidade de Herança (DIT) Profundidade de herança da classe é a métrica DIT para a classe. Em casos envolvendo múltipla herança, a DIT será a extensão máxima do nó até a raiz da árvore. Pontos de vista: 1) Quanto mais profunda uma classe está na hierarquia, maior o número de métodos que provavelmente herdará, fazendo ser mais difícil predizer seu comportamento. 2) Árvores profundas constituem maior complexidade de projeto, desde que mais métodos e classes estão envolvidos. 3) Quanto mais profunda está uma classe particular na hierarquia, maior o potencial de reutilização dos métodos herdados. Copyright by G.H. Travassos coppEuERa- 2001 12 Medição de Software OO TT | * Modelos e Métricas - Produto Lie e Henry [Lie93] - Métricas validadas através do estudo do número de modificações executadas em dois sistemas comerciais implementaddos com um dialeto Ada OO - Adiciona duas métricas ao conjunto proposto por Chidamber e Kemerer: - Acoplamento de Passagem de Mensagem (MPC): é calculado como o número de declarações de envio definido na classe - Acoplamento de Abstração de Dados (DAC): calculado como o número de tipos abstratos de dados usados na classe medida e definidos em outra classe do sistema - Modelo foi adequado para predizer o tamanho das modificações nas classes durante a fase de manutenção Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO TT Sia] * Modelos e Métricas Basili, Briand e Melo [Basilig5] - Baseado em Chidamber e Kemerer, empiricamente validaram a adequabilidade destas métricas para predição da probabilidade de identificar classes sujeitas a falha em softwares baseados em C++ Ajustaram levemente algumas das métricas para capturar algumas &s características de C+ + (as métricas não são independentes da linguagem) WMC: todos os métodos tem complexidade 1 e operadores “triend” não são contados CBO: uma classe está acoplada a outra se utiliza suas funções membro e/ou variáveis de instância DIT: mede o número de ancestrais de uma classe RFC: número de funções diretamente NOC: número de descendentes chamadas por funções membro ou operadores diretos para cada classe da classe LCOM: número de pares de funções membro sem variáveis de instância compartilhadas, menos o número de pares de funções membro com variáveis de instância compartilhadas. Assume valor O se a subtração é negativa. Copyright by G.H. Travassos coppEuERa- 2001 15 Medição de Software OO TT | * Modelos e Métricas Pontos de vista Basili, Briand e Melo : NOC: classes com grande número de WMC: uma classe com significativamente filhos são difíceis de modificar e mais funções membro que seus pares é usualmente requerem mais teste porque mais complexa, em consequência sendo a classe potencialmente afeta todos os mais propensa a falhas seus filhos DIT: sistemas OO bem projetados são CBO: classes fortemente acopladas aqueles estruturados como florestas de são mais propensas a falha que classes classes, ao invés daqueles fracamente acopladas estruturados como uma grande estrutura de herança RFC: quanto maior a resposta de uma classe, maior a complexidade da classe, e mais propensa a falha e dificil de modificar LCOM: uma classe com baixa coesão entre seus métodos sugere um projeto não apropriado (i.e., o encapsulamento de objetos de programa e funções membro não relacionadas que não deveriam estar juntos), provável de ser propenso a falha. Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO * Modelos e Métricas =1 me = E RR Análise das Distribuições: a - E Métricas OO baseadas em 180 classes: Ê DIT indica que hierarquias de herança são de alguma forma planas e NOC que classes tem, 1 as em geral, poucos filhos. Classes parecem ter po = alta coesão (LCOM perto de 0) e é WC Drr REC NOC LCoM cro Maximum sa 0a ado 050 too 42600 39.08 Minimum Loo 0.00 0.06 0.00 0.00 0.00 Mediaa sa D.00 12.50 0.00 0.00 5.00 Mem 1340 L32 33.91 az EE 6.80 Std Dev 14.90 1.99 sa ar 1.54 63.77 2.56 Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO TT | * Modelos e Métricas resultados relativos a probabilidade de identificação de falhas numa classe durante a fase de teste: WMC: quanto maior WMC, maior a probabilidade de identificação de falha NOC: quanto maior o NOC, menor a probabilidade de identificação de falhas LCOM: não significante Copyright by G.H. Travassos DIT: quanto maior DIT, maior a probabilidade de identificação de falhas RFC: quanto maior RFC, maior a probabilidade de identificação de falhas CBO: mais significante para classes de IU que para classes de BD (não foi encontrada explicação satisfatória para as diferenças nos padrões entre estes tipos de classe) coppEuERa- 2001 Medição de Software OO TT Sia] ai rode m = Cusbrar * Modelos e Métricas TES e nn a rg adires : Segs (alto nível) AM SS Sung bithay” atotine trrning leer accouri numbor :long creato customersy = Fa 7 crente a customer TESE Dalarima ce iDaletima Baymaa date DateTime | 1º lar: oat= 005 price() * price asd taxas csstomar) fist purchases() o: Bill [Purchase [Warning [Periodic [Message | Customer Letters | Messages wMc | 4 2 0 0 º 2 Noc [0 0 0 0 2 0 DIT o o 1 1 o o REC | — - - - - - cBO | 2 4 2 1 1 2 LCoM | - = E = E E Copyright by G.H. Travassos coppEuERa- 2001 17 Medição de Software OO * Modelos x Métricas: Onde medir/visualizar métricas OO Model[Use [Class — [Interaction [Class Metric Cases | Diagrams| Diagrams | Descriptions N NKC N NSUB NOO NOA Copyright by G.H. Travassos State — [Package | Deployment Diagrams| Diagrams | Diagrams coppEuERa- 2001 Medição de Software OO TT Sia] Modelos x Métricas: Onde medir/visualizar métricas OO ModelfUse [Class [Interaction [ Class CBO RFC LCOM ModelfUse [Class - [Interaction [Class State Copyright by G.H. Travassos Package | Deployment Package | Deployment coppEuERa- 2001 20 Medição de Software OO | Modelos de Software e Medidas: Automação * Que aspectos da medição podem ser automatizados? - Existe uma variedade de ferramentas disponíveis comercialmente que geram várias métricas de código para uma variedade de linguagems - Exemplos: Code Metric Tools such as Analysis of Complexity Tool (ACT) and BattleMap (McCabe& Associates) and Logiscope (Verilog) - Existem vários ambientes de medição que vão além das métricas de código e suportam várias funções de gerenciamento. Estes utilizam dados históricos do ambiente ou de outros ambientes. - Exemplos: SPQR AND Checkpoint (Software Productivity Research, Inc.) and PADS (Quantitative Software Management, Inc.) Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO TT SE] Modelos de Software e Medidas: Aplicação - Qual o estado da prática? - Muitas companhias possuem programas de medição em escala completa, não apenas no nível de projeto mas a nível de divisão e corporação. Tipicamente, as mais avançadas utilizam algum tipo de infraestrutura ou modelo. Exemplos: - HP utilizando uma versão preliminar do GOM - Motorola empregando GOM e Quality Improvement Paradigm - NEC empregando SQMAT, uma melhoria sobre SOM, e Plan -Do-Check-Act - AT&T utilizando QFD, adaptado para software Copyright by G.H. Travassos coppEuERa- 2001 2 Medição de Software OO | * Como desenvolvedores utilizam métricas OO: - Avaliando qualidade do software * Compreendendo o processo de projeto * Identificando problemas no produto - Melhorando soluções * Adquirindo conhecimento de projeto - Por exemplo - Utilizando métricas para avaliar complexidade estrutural OO * Abordagem aplicada a dois domínios de aplicação diferentes - Software Telecomunicações (C++) * Ambientes de Desenvolvimento de Software (Eiffel) Copyright by G.H. Travassos coppEuERa- 2001 Medição de Software OO - Utilizando métricas para avaliar a complexidade estrutural OO [Travassos99] - Desenvolvedores podem combinar: * Heurísticas aplicadas para reduzir a complexidade do software durante atividades de projeto (Diretrizes para reduzir a complexidade de projeto OO ) * Conhecimento sobre experiências de desenvolvimento (Princípios de Projeto 00) * Métricas para caracterizar como as solucões foram projetadas. G1 | Classes Restructuring Guideline Mr [DT [set of 10 procedures) Adapter Class Guideline M2 |NOC Bridge Class Guideline M4 | Coupiing Ms MG Facade Class Guideline Multiple Inheritance Elimination ep|8R Class Size Guideline Number of Multiple Inheritance G6 | Large Hierarchies Redefinition M11 | Number of Abstract Classes Guideline . Métricas Heurísticas Copy by G.H Travassos coprerRa. 20 22
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved