Participantes

Camila Nunes, Fernanda d'Amorim, Márcio Ribeiro, Paulo Borba, Rodrigo Bonifácio, Uirá Kulesza (mais participantes...?)

Atividades

Resultados

* Escrita de paper? * Quais são os próximos passos? * Quais os resultados que pretendemos obter?

Novas Métricas para Linhas de Produtos de Software

Métrica Original Nova Métrica
Unused Inherited Concerns (UIC): conta o número de concerns não utilizados pela subclasse. Unused Inherited Concerns Variants (UICV): conta o número de variantes não utilizados pela subclasse.
Concern Lines Of Code (CLOC): conta o número de linhas de código de um concern. Concern Variant Lines Of Code (CVLOC): conta o número de linhas de código de uma variante.
Concern Diffusion over Lines Of Code (CDLOC): conta o número de pontos de transição para cada concern através de linhas de código. Concern Variant Diffusion over Lines Of Code (CVDLOC): conta o número de pontos de transição para cada variante através de linhas de código.

Exemplos:

//#ifdef device_screen_176x205
//#    
//# public static final int LOADING_MESSAGE_AREA = 154;
//#
//#elif device_screen_128x160
//#
//# public static final int LOADING_MESSAGE_AREA = 118;
//#
//#elif device_screen_132x176
//#
//# public static final int LOADING_MESSAGE_AREA = 118;

/**
* Classe que trata eventos genéricos
*/
public class EventDataManager {

   public Event createEvent() throws Exception {
      return new Event();
   }
}


/**
* Classe que trata eventos de viagem
*/
public class TravelEventDataManager extends EventDataManager {
   
   @Override
   public Event createEvent() throws Exception {
      return new TravelEvent();
   }
}

/**
* Classe que trata eventos acadêmicos
*/
public class AcademicEventDataManager extends EventDataManager {

   @Override
   public Event createEvent() throws Exception {
      return new AcademicEvent();
   }
}

Resultado da aplicação das métricas nesse exemplo:

Métrica Original Nova Métrica Justificativas
CDLOC = 2 CVDLOC(176x205) = 2; CVDLOC(128x160) = 2; CVDLOC(132x176) = 2; CVDLOC(TOTAL) = 6 Considerar somente CDLOC pode esconder alguma complexidade sobre as variantes. Por outro lado, considerar o CVDLOC total pode ser interessante pois teremos indicativos da quantidade de variantes, por exemplo.
CLOC = 6 CVLOC(176x205) = 2; CVLOC(128x160) = 2; CVLOC(132x176) = 2; CVLOC(TOTAL) = 6 CVLOC pode ser importante pra determinar a complexidade de cada variante... por exemplo, podemos ter CVLOC(X) = 50 e CVLOC(Y) = 4. CLOC = 54 poderia esconder detalhes de cada variante.
UIC(TravelEvent) = 0; UIC(AcademicEvent) = 0 UICV(TravelEvent) = 1; UICV(AcademicEvent) = 1 Para a métrica UIC o valor é 0 pois nós utilizamos o concern de eventos nas subclasses. Para o caso da métrica UICV o valor é 1, pois não utilizamos o concern já especificado na superclasse, nós sobrescrevemos o método e o redefinimos de acordo com a nova variante. O concern é o mesmo, mas a variação é outra.

Outras métricas a serem usadas:

  • LOC (overlapping, interlacing)
  • CA, CO
  • CBC (número de métodos, variáveis locais)
  • WOC
  • NOEDA, NOEDO, CVDC, NCVC (Tese Pedro Matos Jr.);

Representatividade do Estudo de Caso

Para elaboração de um estudo de caso representativo, que satisfaça todos os conceitos presentes em uma LPS, são necessárias as seguintes características:

    • Tipos de features (obrigatórias, alternativas, opcionais, OR)
    • Granularidade das features (coarse e fine - grained)
    • Tamanho das features (Definir o que é o tamanho para nós em termos de módulos, pacotes ou linhas de código)
    • Features transversais ou não transversais
    • Features funcionais e não funcionais
    • Features homogêneas e heterôgeneas
    • Feature interaction
    • Features com diferentes binding times

Levantamento de métricas de design

Pontos a serem discutidos

Quais são as técnicas de design a serem comparadas no projeto PROCAD? A dúvida é, essas técnicas se fundamentam em quais notações? Lembro que o pessoal de Natal tem uma extensão UML para weaving the modelos. Um grupo de São Paulo usa DSLs; enquanto Camila apresentou algo na linha de UML mesmo. O objetivo é comparar essas técnicas? Possíveis atributos de qualidade (alguns podem ser úteis para código)

    • Facilidade de evolução (open-closed, tempo para efetuar mudanças, etc.)
    • Facilidade de uso da técnica (tempo necessário para compreender, erros encontrados após especificação, etc.)
    • Modularidade das especificações de features?(DSMs, suite de métricas CK, ...)
      • Atributos: facilidade de compreensão, facilidade de manutanção, desenvolvimento em paralelo
    • Facilidade de configuração de produtos (expressiva? é possível especificar, instanciar a família dos produtos?)
    • ...
Atributos de Qualidade definidos em Quality Modeling for Software Product Lines (QAOOSE 2003)
    • Flexibilidade
    • Reusabilidade
    • Transparência

Além desses, podemos ter:

    • Facilidade de Evolução
    • Modularidade
    • Estabilidade

Papers (de alguma forma) relacionados com avaliação de linhas de produto / desgin / models

  • SPLC 2001
    • Quality Attribute Design Primitives and the Attribute Driven Design Method - Len Bass, Mark Klein, and Felix Bachmann
    • Measuring Product Line Architectures Ebru Dincel, Nenad Medvidovic, and Andr´e van der Hoek

  • SPLC 2003
    • A Quantitative Model of the Value of Architecture in Product Line Adoption - Key Note - Klaus Schmid
    • Towards a UML Profile for Software Product Lines - Tewfik Ziadi, Lo¨ıc H´elou¨et, and Jean-Marc J´ez´equel
    • Na verdade, alguns papers da sessão técnica e relatórios de experiência podem contribuir

  • SPLC 2004
    • Software Product Family Evaluation- Frank van der Linden, Jan Bosch, Erik Kamsties, Kari K¨ans¨al¨a, Henk Obbink
    • Practical Evaluation of Software Product Family Architectures - Eila Niemel¨a, Mari Matinlassi, Anne Taulavuori
    • Product Line Potential Analysis- Claudia Fritsch, Ralf Hahn

  • SPLC 2005
    • Modeling Architectural Value: Cash Flow, Time and Uncertainty - J.H. Wesselius
    • Comparison of System Family Modeling Approaches - Øystein Haugen, Birger Møller-Pedersen and Jon Oldevik
    • Design Verification for Product Line Development - Tomoji Kishi, Natsuko Noda and Takuya Katayama
    • Product-Line Architecture: New Issues for Evaluation - Leire Etxeberria and Goiuria Sagardui

  • SPLC 2007
    • Impact of Architecture and Quality Investment in Software Product Line Development - Makoto Nonaka, Tokyo University Liming Zhu, National ICT Australia
    • Comparing Costs and Benefits of Different Test Strategies for a Software Product Line: A Study from Testo AG - Dharmalingam Ganesan and others
    • A Case Study Implementing Features Using AspectJ - Christian Kastner, Sven Apel and others

  • ISESE 2005
    • Detecting structural changes in object oriented software systems- Rajesh Vasa; Schneider, J.-G.; Woodward, C.; Cain, A.

  • ISESE 2004
    • An empirical study of software change: origin, acceptance rate, and functionality vs. quality attributes- Mohagheghi, P.; Conradi, R.
    • The influence of the level of abstraction on the evolvability of conceptual models of information systems Verelst, J.
    • Finding "early" indicators of UML class diagrams understandability and modifiability Genero, M.; Piatini, M.; Manso, E.

  • ISESE 2002
    • Empirical validation of class diagram metrics - Genero, M.; Piattini, M.; Calero, C.

  • ESEM 2007
    • A Comparative Study of Aspect-Oriented Requirements Engineering Approaches - Sampaio, A.; Greenwood, P.; Garcia, A.F.; Rashid, A.
    • Applying Systematic Reviews to Diverse Study Types: An Experience Report - Dyba, T.; Dingsoyr, T.; Hanssen, G.K.
    • Fine-Grained Software Metrics in Practice English, M.; Buckley, J.; Cahill, T.
    • Mining Software Evolution to Predict Refactoring Ratzinger, J.; Sigmund, T.; Vorburger, P.; Gall, H.
    • Characterizing Software Architecture Changes: An Initial Study - Williams, B.J.; Carver, J.C.
    • How Software Designs Decay: A Pilot Study of Pattern Evolution - Izurieta, C.; Bieman, J.M.
    • A Survey of the Practice of Design -- Code Correspondence amongst Professional Software Engineers Nugroho, A.; Chaudron, M.R.V.
    • Evidence relating to Object-Oriented software design: A survey - Bailey, J.; Budgen, D.; Turner, M.; Kitchenham, B.; Brereton, P.; Linkman, S.

  • Transaction on Software Engineering
    • A Validation of Object-Oriented Design Metrics as Quality Indicators, V. Basili, L. Briand, W. Melo, 1996

  • Models 2008
    • NAOMI - An Experimental Test Bed for Multi Modeling - Trip Denton, Edward Jones, Srini Srinivasan, Kenneth Owens, Richard Buskens
    • Integrating Performance Analysis in the Model Driven Development of Software Product Lines - Rasha Tawhid, Dorina C. Petriu
    • A Model-driven Measurement Approach - Martin Monperrus, Jean-Marc Jézéquel, Joel Champeau, Brigitte Hoeltzener

  • Models 2005
    • Lessons Learned from Metrics-Based Automated Analysis of Industrial UML Models (An Experience Report) - Betty H.C. Cheng, Ryan Stephenson, Brian Berenbach

  • Models 2004
    • Applying OO Metrics to Assess UML Meta-Models - Haohai Ma, Weizhong Shao, Lu Zhang, Zhiyi Ma, Yanbing Jiang

Métricas implementadas em ferramentas (isso será útil para alguma coisa?)

  • Magic Draw (suporta as métricas CK e DSMs)
  • ArgoUML (checa basicamente possíveis erros de modelagem. na UCB, implementamos uma extensão CK para o ArgoUML)
  • ...

Métricas de Design OO

Atualmente, mecanismos como bad smells (Fowler et al, 1999) e estratégias de detecção (Marinescu, 2002) têm sido propostas para avaliar a qualidade de design OO. Lanza & Marinescu (2006) definiram algumas estratégias para detecção no código dos problemas de design:

    • God Class (classes que tentam centralizar a funcionalidade do sistema);
    • Data Class (classes que fornecem mais dados que serviços);
    • Long Parameter List, Shotgun Surgery (classes cuja modificação;implica muitas pequenas modificações em muitas outras classes);
    • Misplaced Class (classes definidas no pacote errado);
    • God Package (pacote grande, com muitas classes que não inter-relacionam-se entre si e que é utilizado por muitas outras classes).

Características de um bom design:

    • Baixo Acoplamento
    • Alta Coesão
    • Complexidade adequada
    • Abstração de Dados

Levantamento de métricas de design

Trabalho Conferência/Journal/Ferramenta Métricas
Bansiya 1997 Modelo de Qualidade QMOOD DSC, NOH, ANA, DAM, DCC, CAM, MOA, MFA, NOP, CIS, NOM
Tese - Baiano ECSA 2008 Concern Diffusion over Architectural Components (CDAC), Concern Diffusion over Architectural Interfaces (CDAI), Concern Diffusion over Architectural Operations (CDAO), Component-level Interlacing Between Concerns (CIBC), Interface-level Interlacing Between Concerns (IIBC), Operation-level Overlapping Between Concerns (OOBC), Lack of Concern-based Cohesion (LCC), Concern-Sensitive Coupling (CSC), Architectural Fan-in (AFI), Architectural Fan-out (AFO), Number of Concern Interfaces (NCI), Number of Interfaces (NI), Number of Operations (NO)
(Genero e Piattini, 2001; Genero et al 2002) Métricas para diagramas de classes Quantidade de relações por Associação (NAssoc), Quantidade de relações por Agregação (NAgg), Quantidade de Dependências (NDep), Quantidade de Generalizações (NGen), Quantidade de relações por Agregação entre Hierarquias (NAggH), Maior profundidade na árvore de herança (MaxDIT), Quantidade de Classes (NC), Quantidade de Atributos (NA), Quantidade de Métodos (NM), NAssocVC, NAggVC, NGenVC

Levantamento de métricas de código fonte

Trabalho Conferência/Journal/Ferramenta Métricas
On the Assessment of Aspectual Design: A Concern-Driven Heuristics Suite Submetido ao ICSM 2007 CBC, DIT, IUR, LCOO, VS, NOO, NOA, LOC, CDC, NCC, CA, CO, UIC, CLOC, CDLOC
Tese - Pedro SAC 2008 VS, LOC, NOA, NOO, WOC, CBC, LCOO, CDC, DoS, NCC, BS, NOEDA, NOEDO, CVDC, NCVC
Tese - Márcio SAC 2008, CSMR 2009 CDC, CLOC, CDLOC, NCC, LOC, VS, CBC, DIT
Métricas do Lattix Lattix Average Impact, System Stability, Atom Count, Instability, Abstractness, Distance, Outgoing/Incoming dependencies, Abstract atom count, Violation count
Identifying, Assigning, and Quantifying Crosscutting Concerns ACoM/ICSE 2007 DOS, DOF, CDO
Métricas do Plugin Metrics Metrics Number of Classes, Number of Children, Total number of direct subclasses of a class, Number of Interfaces, Depth of Inheritance Tree (DIT), Number of Overridden Methods (NORM), Number of Methods (NOM), Number of Fields, Lines of Code: TLOC/ MLOC, Specialization Index, McCabe Cyclomatic Complexity, Weighted Methods per Class (WMC), Lack of Cohesion of Methods (LCOM*), Afferent Coupling (Ca), Efferent Coupling (Ce), Instability (I), Abstractness (A), Normalized Distance from Main Sequence (Dn)
Métricas do Plugin State Of Flow Eclipse Metrics State Of Flow Eclipse Metrics Cyclomatic Complexity, Lines of Code in Method, Number of Locals in Scope, Number of Levels, Number of Parameters, Number of Statements, Efferent Couplings, Lack of Cohesion in Methods (Chidamber & Kemerer), Lack of Cohesion in Methods (Henderson-Sellers), Lack of Cohesion in Methods (Pairwise Field Irrelation), Lack of Cohesion in Methods (Total Correlation), Number of Fields, Weighted Methods Per Class
Métricas do AOP Metrics AOP Metrics Lines of Class Code (LOCC), CK metrics suite for AOP: Weighted Operations in Module (WOM), Depth of Inheritance Tree (DIT), Number Of Children (NOC), Crosscutting Degree of an Aspect (CDA), Coupling on Intercepted Modules (CIM), Coupling on Advice Execution (CAE),, Coupling on Method Call (CMC), Coupling on Field Access (CFA), Coupling between Modules (CBM), Respone For a Module (RFM), Lack of Cohesion in Operations (LCO). Package dependecies: Number of Types (NOT), Abstractness (A), Afferent Couplings (Ca), Efferent Couplings (Ce), Modified Efferent Couplings (Ce), Instability (I)

Análise no contexto de Linhas de Produtos de Software:

  • As métricas NOEDA, NOEDO, CVDC e NCVC tentam "corrigir" alguns problemas das métricas de concerns...
  • A métrica UIC parece não fazer sentido para LPS.
  • Todas as métricas do Lattix são pra código? Ou tem alguma relacionada a design?
  • Temos que definir o que queremos avaliar a nivel de codigo (atributos de qualidade) para selecionar o conjunto de metricas relevantes para o contexto de LPS. Elaborar um GQM para isto?
  • Analisar se existem ferramentas que automatizam a coleta do conjunto de métricas selecionado...

TODO list

  • Envolver Cláudio Sant'Anna nessa frente de trabalho
  • Identificar trabalhos relacionados em OOPSLA, ICSE, ACOM, ECOOP, IEEE transactions on software, ...
  • ...

-- MarcioRibeiro - 11 Sep 2009 -- MarcioRibeiro - 11 Aug 2009 -- CamilaNunes - 11 Aug 2009 -- MarcioRibeiro - 10 Aug 2009 -- MarcioRibeiro - 14 Apr 2009 -- RodrigoBonifacio - 06 Apr 2009

Topic revision: r17 - 2009-09-21 - LeopoldoTeixeira
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort