Validação Cruzada de Métricas para Componentes}

1

Validação Cruzada de Métricas para Componentes Miguel Goulão, Fernando Brito e Abreu

Resumo Objectivo: Apresentar uma técnica facilitadora da replicação de experiências de validação cruzada de métricas para o desenvolvimento baseado em componentes. Método: A aplicação da técnica é ilustrada com uma experiência de validação cruzada de um conjunto de métricas publicadas na literatura que se destinam a aferir a facilidade de reutilização em desenho baseado em componentes. As métricas a validar foram originalmente propostas usando uma notação parcialmente informal, que combinava fórmulas matemáticas com descrições informais dos elementos nelas usadas. Propõe-se uma formalização dessas métricas que combina o meta-modelo do UML 2.0 com OCL. Resultados: Esta técnica permite obter uma definição formal, portável e executável das métricas, que pode ser usada em experiências de validação cruzada das mesmas, como a apresentada neste artigo. Conclusões: A facilitação da replicação de experiências de validação de métricas é essencial para a elevação destas experiências de um estatuto “artesanal” para um “científico”. Termos de indexação—component-based development, OCL, UML, software engineering, software metrics.

A

I. INTRODUÇÃO

modelação da qualidade de software envolve não só a definição de taxonomias adequadas de atributos de qualidade, mas também o estabelecimento de métodos para a avaliação dos mesmos. A avaliação pode assumir um carácter qualitativo ou quantitativo. Neste artigo estamos sobretudo interessados na avaliação quantitativa de atributos de qualidade. A avaliação requer o uso de métricas de software que podem ser combinadas na construção de modelos de qualidade, usando técnica estatísticas, tais como os modelos de regressão multi-variada. A exemplo do que acontece com outros modelos estatísticos, antes de serem adoptados, os modelos de qualidade devem ser validados de modo a se garantir: • consistência interna – Com base numa amostra da população, constrói-se um modelo. O modelo é especificado através de um conjunto de expressões, cuja validade deve M. Goulão é Assistente do Departamento de Informática da Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa, 2829-516 Caparica, Portugal (e-mail: [email protected]). F. Brito e Abreu é Professor do Departamento de Informática da Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa, 2829-516 Caparica, Portugal (e-mail: [email protected]).

ser verificada, garantindo-se assim a sua correcção matemática. O modelo permite calcular um conjunto de saídas que representam o comportamento do sistema que se está a modelar. Num modelo com consistência interna, as saídas são válidas quando as entradas também o são. • consistência externa – Um modelo apresenta consistência externa quando a informação com ele recolhida não é contrariada por outra informação observada em sujeitos não pertencentes à amostra usada na criação do modelo. Isto tem implicações na aplicabilidade do modelo, na medida em que permite avaliar até que ponto os pressupostos assumidos num modelo se aplicam para além da amostra usada na sua construção. A credibilidade de modelos de qualidade para o Desenvolvimento Baseado em Componentes (DBC) e métricas a eles associadas depende não só do rigor com que são definidos, mas também do grau de validação apresentado, quer pelos seus proponentes, quer, sobretudo, por avaliadores independentes. A prática corrente da engenharia de software experimental aplicada ao DBC está longe de atingir esse grau de maturidade. Apesar de existirem algumas propostas de modelos de qualidade [1,2], essas propostas carecem de validação apropriada. Apesar de a necessidade de mais estudos de validação ser reconhecida pelos próprios proponentes dos modelos supracitados, existem diversos obstáculos a dificultar a condução desse tipo de estudos, dos quais destacamos (i) a falta de dados disponíveis para a realização de estudos, (ii) dificuldades na interpretação das especificações de modelos e métricas e (iii) a ausência de ferramentas adequadas para a recolha de dados. Neste artigo apresentamos uma experiência de validação cruzada de um conjunto de métricas para CBD. Os proponentes deste conjunto de métricas usaram uma notação semiformal para a sua definição, bem como um conjunto de ferramentas desenvolvidas à medida para suportar a sua recolha e validação. Propomos uma formalização da especificação dessas métricas e apresentamos um ambiente que permite a sua recolha que resulta da combinação de ferramentas de domínio público. Para garantir a portabilidade da nossa abordagem, utilizamos linguagens padrão para a especificação de métricas, de heurísticas sobre essas métricas, e dos próprios componentes a analisar. A nossa técnica de formalização usa um meta-modelo do domínio que pretendemos analisar – neste caso a modelação

2

para o DBC usando a Unified Modeling Language (UML 2.0 [3, 4]) – sobre o qual se definem métricas, usando a Object Constraint Language (OCL 2.0 [5]). Os vantagens desta abordagem são várias: • É objectiva, dado que o meta-modelo que lhe está subjacente elimina eventuais imprecisões na percepção dos conceitos e no seu interrelacionamento (subjectividade). • É formal, uma vez que a OCL disponibiliza todos os mecanismos necessários à definição não ambígua das métricas. • Usa linguagens padronizadas, dado que tanto o metamodelo como a especificação de métricas e heurísticas são expressos usando a UML – uma norma publicada pelo Object Management Group (OMG) – da qual a OCL faz parte. • É relativamente fácil de compreender pelos elementos das equipas de desenvolvimento de software, dado que tanto os diagramas de classe em UML usados na representação do meta-modelo, como a OCL, foram concebidos para garantir a simplicidade, sem sacrificar a expressividade. • É genérica, proporcionando condições para a replicação de experiências de validação, quer com este, quer com outros conjuntos de métricas. • Pode ser automatizada, uma vez que com a adopção do UML 2.0 se antevê que os fornecedores de ferramentas CASE suportem o seu meta-modelo, bem como OCL. Este artigo está organizado do seguinte modo. Na secção II apresentamos alguns exemplos de validação cruzada de métricas de software, realçando o seu carácter de excepção, nas práticas correntes. Enquadramos a nossa abordagem de formalização de métricas, e os contributos que com ela pretendemos dar. Na secção III explicamos a técnica para a definição formal de métricas usando a UML 2.0, juntamente com OCL. Na secção IV propomos uma definição formal para o conjunto de métricas proposto por Washizaki et al. [6], que será complementada na secção V pela definição formal de um conjunto de heurísticas destinadas a facilitar a interpretação dos valores das métricas. Na secção VI descrevemos uma experiência de validação deste conjunto de métricas, discutindo os resultados obtidos e identificando aspectos que poderiam ser melhorados neste conjunto de métricas. Na secção VII apresentam-se as conclusões, sendo a secção VIII dedicada a trabalhos futuros. Em apêndice, descrevemos brevemente o ambiente de recolha de métricas utilizado. II. TRABALHO RELACIONADO A ideia da validação cruzada de modelos de qualidade, recorrendo a experiências independentes, não é nova. Noutras ciências este tipo de validação é prática comum. Na indústria farmacêutica, os novos medicamentos estão sujeitos a um conjunto de testes realizados por entidades independentes antes de serem aprovados para comercialização pública. No âmbito da engenharia de software experimental existem diversos exemplos de escrutínio independente a conjuntos de

métricas. Em [7] Harrison et al. validaram o conjunto de métricas MOOD (Metrics for Object Oriented Design) de Abreu [8]. Em [9] Basili et al. verificaram a adequação do conjunto de métricas de Chidamber e Kemerer [10] para prever a propensão de classes a faltas. O mesmo conjunto de métricas foi ainda validado como avaliador da facilidade de manutenção por Li e Henry [11]. Os dois conjuntos anteriores de métricas para o desenho orientado a objectos (DOO) e outras que as antecederam, mais vocacionadas para o paradigma procedimental, tais como como a complexidade ciclomática de McCabe [12] e as métricas de Halstead [13], também elas sujeitas a validações independentes, têm sido usadas quer na indústria quer na academia e estão incorporadas em diversas ferramentas de desenvolvimento de software. A maioria das métricas propostas na literatura foi sujeita a uma validação manifestamente insuficiente, sendo que em diversos casos não foram sujeitas a qualquer espécie de validação. Os exemplos anteriores são a excepção, e não a regra. A validação insuficiente é particularmente notória no domínio das métricas para o DBC (e.g. [14-16]). Neste contexto, o conjunto de métricas proposto por Washizaki et al. [6] é uma excepção digna de registo, pelo esforço de validação levado a cabo pelos seus autores. A validação apresentada baseia-se na análise estatística de dados observados numa amostra de 125 componentes comerciais, contrapondo a avaliação de peritos sobre a facilidade de reutilização desses componentes aos valores obtidos com as métricas. Este tipo de validação contrasta com a apresentação de casos isolados, ou de amostras de reduzidas dimensões, sobre as quais se produzem considerações baseadas sobretudo na intuição dos proponentes das métricas, ou se recolhem apenas algumas estatísticas descritivas, como se relata num estudo comparativo entre propostas de métricas para o DBC apresentado em [17]. Desconhecemos qualquer tentativa de validação cruzada sobre conjuntos de métricas para o DBC. Neste particular, o conjunto de métricas de Washizaki et al. não constitui excepção, dado que apenas foi validado pelos seus proponentes. Esperamos mitigar este problema com este artigo, de duas formas: por um lado, apresentando uma experiência de validação cruzada para este conjunto de métricas. Por outro, abrindo caminho a outros esforços de validação, a realizar com este ou outros conjuntos de métricas, através da partilha da nossa abordagem metodológica. A formalização de métricas apresentada neste artigo é uma evolução do trabalho realizado no seio do nosso grupo de investigação (QUASAR), com a formalização de métricas para o DOO. A utilização do OCL para a formalização de métricas foi inicialmente proposta em [18], usando o metamodelo da linguagem GOODLY (a Generic Object-Oriented Language? Yes!) [19], uma linguagem de DOO. A crescente adopção da UML, quer na academia, quer na indústria, combinada com a nossa intenção de tornar as métricas acessíveis aos elementos das equipas de desenvolvimento de software, levou-nos ao desenvolvimento da FLAME (Formal Library for Aiding in Metrics Extraction), uma biblioteca de funções definidas em OCL, sobre o meta-modelo da UML 1.x, em

3

cima da qual se formalizaram diversos conjuntos de métricas para o DOO [20-22]. O trabalho descrito no presente artigo difere dos acima citados nos seguintes aspectos: • Em vez da versão 1.x do meta-modelo da UML, estamos agora a usar a versão 2.0 da UML como base para a nossa formalização de métricas. Esta escolha deve-se à expressividade acrescida disponibilizada a partir desta versão da UML, para a especificação de arquitecturas baseadas em componentes, tal como discutido em [23]. • O tipo de métricas a analisar é agora dedicado ao DBC, em vez de ao DOO. • O suporte computacional para a recolha das métricas tornou-se mais independente de formatos proprietários das ferramentas de modelação em UML. III. FORMALIZAÇÃO E RECOLHA DE MÉTRICAS A nossa técnica consiste na especificação de cláusulas em OCL que nos permitem navegar através do meta-modelo e recolher a informação pretendida. Essencialmente, as métricas são especificadas como cláusulas OCL (que poderão recorrer a clausulas auxiliares). O cálculo das métricas é feito pela avaliação das respectivas cláusulas. Considere o extracto do meta-modelo do UML 2.0 apresentado na Fig. 1. Omitem-se alguns dos elementos do metamodelo que serão adiante usados na formalização de métricas, bem como diversos atributos das meta-classes, para permitir a legibilidade da figura. Podemos observar neste extracto, por exemplo, como os componentes estão associados com as respectivas operações (ownedOperation) e propriedades (ownedAttribute), ou como as operações contêm diversos parâmetros (ownedParameter). NamedElement

TypedElement

(from Basic)

Parameter (from Basic)

(from Basic)

name : String *

*

type Classifier

0..1

(from Basic)

0..1 Class

ownedParameter

class

(from Basic)

ownedOperation *

0..1

Operation (from Basic)

selectoras (), e 5 modificadoras (), sendo as restantes operações de negócio do componente (todas as operações não estereotipadas declaradas na interface do componente). O termo “operações de negócio” surge aqui em conformidade com o definido por Washizaki et al., para representar todas as operações que implementam funcionalidades no componente, com excepção das construtoras, selectoras e modificadoras. SQL_Select NO_WORK:int DO_SELECT:int work: int spaces:Logical View::java::lang::String url:Logical View::java::lang::String user:Logical View::java::lang::String password:Logical View::java::lang::String SQL:Logical View::java::lang::String maxRows:int SQL_Select() doLayout():void doWork():void getMaxRows():int getPassword():Logical View::java::lang::String getSQL():Logical View::java::lang::String getURL():Logical View::java::lang::String getUser():Logical View::java::lang::String getWork():Logical View::java::lang::String initialize():void layout():void readObject(arg0: ObjectInputStream):void select():void setMaxRows(arg0:int):void setPassword(arg0: Logical View::java::lang::String):void setSQL(arg0: Logical View::java::lang::String):void setURL(arg0: Logical View::java::lang::String):void setUser(arg0: Logical View::java::lang::String):void update():void update(arg0: ActionEvent):void writeObject(arg0: ObjectInputStream):void

Fig. 2 – O componente SQL_Select

Este componente pode ser representado instanciando o meta-modelo da UML 2.0 com meta-objectos e meta-ligações apropriadas. Na Fig. 3 podemos observar um pequeno extracto do diagrama de objectos representando essa instanciação. Para facilitar a legibilidade da figura, omitem-se diversas instâncias neste diagrama.

operation +ownedAttribute *

Property (from Kernel)

o1:Operation

p1:Property name="NO_WORK"

class ownedOperation

Class (from Constructs)

0..1

*

Operation

+ownedAttribute

(from Constructs)

Class (from Kernel)

+class

+ownedOperation 0..1 * +class 0..1

ownedAttribute

Property *

o2:Operation

name="SQL_Select" stereotype="constructor"

name="doLayout"

ownedOperation

ownedOperation

(from InternalStructures)

p2:Property

Operation

name="DO_SELECT "

(from Kernel)

ownedOperation

ownedAttribute

o3:Operation name="doWork"

0..1

Class

Class

Component

(from Communications)

(from StructuredClasses)

(from BasicComponents)

c1:Component p3:Property name="work"

Fig. 1 – Extracto do meta-modelo da UML 2.0 (adaptado de [3, 4])

o4:Operation ownedOperation

ownedAttribute

name="maxRows"

name="getPassword" stereotype="getter"

...

... p9:Property

Para ilustrar o processo de recolha de métricas, considerese o seguinte exemplo: o componente SQL_Select, representado na Fig. 2, contém 9 atributos e 21 operações. As operaçõe incluem 1 uma operação construtora (), 6

name="SQL_Select"

ownedAttribute

ownedOperation

o21:Operation name="writeObjects"

Fig. 3 – Extracto do diagrama de objectos que instanciam o componente SQL_Select

Recorrendo a expressões OCL, podemos atravessar o dia-

4

grama de meta-objectos para recolher informações sobre o componente c1. Por exemplo, podemos determinar o conjunto de propriedades deste componente, o conjunto das operações fornecidas na interface do mesmo e as respectivas dimensões dos conjuntos. Seguidamente, exemplificamos tais expressões, fornecendo ainda os resultados da avaliação de cada uma delas, em itálico. c1.ownedAttribute c1.ownedOperation c1.ownedAttribute->size() c1.ownedOperation->size()

= = = =

{p1, p2, p3,…, p9} {o1, o2, o3, o4,…,o21} 9 21

É também possível definir cláusulas dentro de um determinado contexto. As expressões OCL que se seguem definem um conjunto de cláusulas que usaremos adiante neste artigo, na formalização do conjunto de métricas de Washizaki et al. O primeiro conjunto de cláusulas é definido para elementos do meta-modelo do tipo Component. O segundo é definido para elementos do tipo Operation.

-- Return type name of an Operation ReturnTypeName (): String = if (self.formalParameter -> exists(direction = #return)) then if (self.ReturnParams()->asSequence()-> first.type.isDefined) then self.ReturnParams()->asSequence()-> first.type.name else 'void' endif else 'void' endif

As seguintes expressões em OCL recorrem às cláusulas até aqui definidas e permitem obter, para o componente SQL_Select, o número de propriedades acessíveis para leitura, o número de propriedades acessíveis para escrita e o número total de propriedades no componente, respectivamente: SQL_Select.Pr() = 6 SQL_Select.Pw() = 5 SQL_Select.A() = 9

Component -- Number of Readable Properties Pr(): Integer = self.ownedOperation->select(o: Operation| o.stereotype = 'getter')->size() -- Number of Writable Properties Pw(): Integer = self.ownedOperation->select(o: Operation| o.stereotype = 'setter')->size() -- Number of Properties in the component A(): Integer = self.ownedAttribute->size() -- Total number of constructors in the component Co(): Integer = self.ownedOperation->select(o: Operation| o.stereotype = 'constructor')->size() -- Set of business methods provided by the component BusinessMethods(): Set (Operation)= self.ownedOperation->select(o: Operation| (not (o.stereotype = 'constructor')) and (not (o.stereotype = 'getter')) and (not (o.stereotype = 'setter'))) -- Number of business methods with no return value Bv(): Integer = self.BusinessMethods()->select(b: Operation| b.ReturnTypeName()= 'void')->size() -- Number of business methods with no parameters Bp(): Integer = self.BusinessMethods()->select(b: Operation| b.OwnedParameter()->size() = 0)->size() -- Number of business methods B() : Integer = self.BusinessMethods->size() Operation -- Set of formal parameters(except return parameter) Params(): Set(Parameter) = self.formalParameter->select(fp: Parameter | fp.direction #return) -- Set of return parameters of an Operation ReturnParams(): Set(Parameter) = self.formalParameter->select(fp: Parameter | fp.direction = #return)

IV. FORMALIZAÇÃO DAS MÉTRICAS DE WASHIZAKI ET AL. A. Descrição do conjunto de métricas Washizaki et al. propuseram um conjunto de 5 métricas para a avaliação da facilidade de reutilização de JavaBeans [6]. Para cada uma destas métricas, os autores apresentaram: • o objectivo da métrica; • a definição da métrica, combinando expressões matemáticas com descrições informais dos elementos utilizados nessas expressões; • um intervalo de confiança; assume-se que componentes que apresentem um valor da métrica fora do intervalo são assinalados como potencialmente problemáticos, mal desenhados, ou defeituosos; • heurísticas para facilitar a interpretação dos valores das métricas, com base nos intervalos de confiança. Importa realçar que este tipo de avaliação pretende detectar componentes que apresentem, com uma elevada probabilidade, um determinado problema. Isso significa que também existe uma baixa probabilidade de o componente apresentar o problema quando o valor da métrica está dentro do intervalo, ou de não o apresentar quando o valor está fora do intervalo. Ou seja, este tipo de avaliação fornece-nos um indicador ao qual associamos um determinado grau de confiança. A tabela I apresenta as definições das métricas de Washizaki et al. Para cada métrica apresenta-se o seu nome, quer numa versão traduzida quer na original, o seu acrónimo e a expressão que a define.

5

TABELA I – MÉTRICAS DE WASHIZAKI ET AL.

Existência de meta-informação (Existence of Meta-Information – EMI) Comentário: A existência de uma classe BeanInfo dá acesso a meta-informação sobre o componente.

{

1,existe a classe BeanInfo

EMI (c ) = 0,caso contrário

Taxa de facilidade de observação de um componente (Rate of Component Observability – RCO) Comentário: A facilidade de observação de um componente depende da percentagem de propriedades acessíveis do exterior do componente, sendo necessário disponibilizar a informação relevante, quebrando o menos possível o encapsulamento.  Pr (c) , A(c) >0  A(c) RCO(c) =   0,caso contrário 

B(c): operações de negócio em c. Auto-completitude dos valores de retorno (Self-Completeness of Component’s return values – SCCr) Comentário: Representa uma medida indirecta da dependência do componente face a componentes externos, estando também relacionado com a portabilidade do componente   Bv (c ) , B(c) >0  B (c ) SCC r (c) =     1, caso contrário

em que: Bv(c): operações de negócio sem valor de retorno em c. Este conjunto de métricas surge enquadrado num modelo de qualidade hierárquico, em que uma característica de qualidade é subdividida em diversos factores, para os quais se estabelecem critérios que deverão ser avaliados através de métricas. Este modelo de qualidade é apresentado na Fig. 4.

em que: Pr(c): número de propriedades acessíveis para leitura em c. A(c): número de propriedades em c. Taxa de facilidade de parametrização de um componente (Rate of Component Customizability – RCC) Comentário: A percentagem de propriedades acessíveis para escrita relaciona-se com a facilidade de parametrização do componente, sendo desejável um equilíbrio entre a flexibilidade oferecida e o esforço envolvido na parametrização do componente.   Pw (c) , A(c ) >0  A(c ) RCC (c) =     1, caso contrário

em que: Pw(c): número de propriedades acessíveis para escrita em c. Auto-completitude dos parâmetros do componente (Self-Completeness of Components parameters – SCCp) Comentário: Representa uma medida indirecta da dependência do componente face a componentes externos sendo que a uma menor dependência corresponderá uma maior portabilidade.   B p (c) , B (c ) >0  B (c ) SCC p (c) =     1, caso contrário

em que: Bp(c): operações de negócio com parâmetros em c.

Fig. 4 – Modelo de Qualidade de Washizaki et al (adaptado de [6])

Washizaki et al. validaram a sua com uma amostra de 125 JavaBeans comerciais disponíveis em jars.com [24]. Neste site comercial, os componentes são avaliados por um painel de peritos que os classificam com base em critérios como a apresentação, funcionalidade e originalidade. A cada componente, é atribuída uma classificação entre 0 e 1000 pontos. Washizaki et al. assumiram que os componentes com mais de 875 pontos seriam “altamente reutilizáveis”, servindo portanto como base para o estabelecimento dos critérios quantitativos a avaliar com as métricas. Os limites inferior e superior para cada uma das métricas, foram calculados com intervalos de confiança de 95%. B. Formalização das métricas Para a formalização deste conjunto de métricas usando expressões OCL, usamos o meta-modelo da UML 2.0. Das 5 métricas definidas no conjunto original, apenas nos foi possível formalizar 4. A métrica EMI é demasiado dependente da tecnologia JavaBeans. A noção de classe BeanInfo não é convenientemente representada no meta-modelo da UML 2.0, uma vez que a detecção dessa classe resulta de uma convenção de nomes. As especificações de métricas seguites utilizam as funções OCL definidas na secção III deste artigo. Como seria de esperar, são definidas no contexto da metaclasse Component.

6 Component -- Rate of Component Observability RCO(): Real = if self.A() = 0 then 0.0 else self.Pr()/self.A() endif -- Rate of Component Customizability RCC(): Real = if self.A() = 0 then 0.0 else self.Pw()/self.A() endif

lidade respectiva, neste caso a adaptabilidade. Definimos as três primeiras cláusulas no contexto de Class, em vez de o fazermos no âmbito de Component. No meta-modelo da UML 2.0, Component é subclasse de Class e por isso as cláusulas definidas para Class podem ser usadas no âmbito de Component. Isto permite-nos reutilizar estas cláusulas na definição de heurísticas com outras métricas baseadas no meta-modelo da UML não relativas a diagramas de componentes (por exemplo, métricas de DOO sobre diagramas de classes).

-- Self-Completeness of Component's return value SCCr(): Real = if self.B() = 0 then 1.0 else self.Bv()/self.B() endif

Class AboveRange (limit: Real, value: Real): Boolean = value > limit

-- Self-Completeness of Components Parameter SCCp(): Real = if self.B() = 0 then 1.0 else self.Bp()/self.B() endif

OutOfRange (lowerLimit: Real, upperLimit: Real, value: Real): Boolean = (self.BelowRange (lowerLimit, value)) or (self.AboveRange (upperLimit, value)) pre: lowerLimit < upperLimit

C. Expressividade da técnica de formalização A nossa técnica de formalização depende da expressividade do meta-modelo utilizado e da capacidade para popular esse meta-modelo convenientemente, a partir de uma especificação existente (neste caso, arquivos jar). Isso implica a geração de um grafo constituído por meta-objectos e meta-ligações entre estes. A partir deste grafo é possível, com expressões OCL apropriadas, extrair a informação relevante para determinar o valor das métricas. Embora exista a opção de estender o meta-modelo para colmatar alguma falta de expressividade que ele apresente, usando os mecanismos de extensão da UML, essa opção sacrifica a conformidade com o meta-modelo padrão, o que teria implicações negativas óbvias na portabilidade da nossa formalização. A formalização de métricas relativas a propriedades extrafuncionais é, igualmente, um desafio para o futuro. O metamodelo da UML 2.0 não apresenta elementos adequados à representação destas propriedades, pelo que a utilização da nossa abordagem implicaria a utilização de um perfil de UML adequado. V. FORMALIZAÇÃO DE UM CONJUNTO DE HEURÍSTICAS DE FACILIDADE DE REUTILIZAÇÃO

Para além do seu conjunto de métricas, Washizaki et al. também propuseram um conjunto de heurísticas, para interpretação das primeiras. Três das heurísticas baseadas nessas métricas, adiante referidas como WarningRCO, WarningRCC e WarningSCCp (relativas às métricas RCO, RCC e SCCp, respectivamente), traduzem um filtro passa banda, na medida em que um aviso de problema ocorrerá se o valor das métricas for abaixo de um limiar inferior ou acima de um superior. A heurística WarningSCCr estabelece apenas um limiar inferior para o valor da métrica SCCr. Se o valor da métrica estiver abaixo do limiar, isso deve ser interpretado como uma indicação de um problema potencial relativo à característica de qua-

BelowRange (limit: Real, value: Real): Boolean = value < limit

As heurísticas podem ser formalizadas com OCL, como se segue: Component WarningRCO(lowerThreshold: Real, upperThreshold: Real): Boolean = self.OutOfRange (lowerThreshold, upperThreshold, self.RCO()) WarningRCC(lowerThreshold: Real, upperThreshold: Real): Boolean = self.OutOfRange (lowerThreshold, upperThreshold, self.RCC()) WarningSCCr(lowerThreshold: Real): Boolean = self.BelowRange(threshold, self.SCCr()) WarningSCCp(lowerThreshold: Real, upperThreshold: Real): Boolean = self.OutOfRange (lowerThreshold, upperThreshold, self.SCCp())

A tabela II resume a informação relativa aos limites inferior e superior das heurísticas fornecidos por Washizaki et al. Para cada métrica apresentamos o seu acrónimo, o valor médio encontrado para as métricas na amostra descrita na secção IV, subsecção A, os limites inferior e superior para os filtros de qualidade e o número de componentes na amostra que se encontram dentro dos limites estabelecidos. Por uma questão de completitude, incluímos também os limites para EMI. Todas as métricas neste conjunto foram definidas como rácios e o seu valor máximo é 1. Por isso, o predicado de WarningSCCr não requer um limiar superior. TABELA II LIMIARES PARA HEURÍSTICAS PROPOSTOS POR WASHIZAKI ET AL. Métrica Média Limite Inf. Limite Sup. # componentes RCO 0,40 0,17 0,42 36 RCC 0,35 0,17 0,34 35 SCCr 0,85 0,61 1,00 108 SCCp 0,74 0,42 0,77 28 EMI 0,84 0,50 1,00 105

Finalmente, a heurística DesignWarning é definida como uma disjunção das primeiras. Os argumentos do predicado DesignWarning (limites aceitáveis das métricas) permitirão

7

calibrar cada heurística à medida que mais dados forem recolhidos. Component DesignWarning( RCO_LL: Real, RCO_UL: Real, RCC_LL: Real, RCC_UL: Real, SCCp_LL: Real, SCCr_LL: Real, SCCp_UL: Real): Boolean = (self.WarningRCO(RCO_LL, RCO_UL)) or (self.WarningRCC(RCC_LL, RCC_UL)) or (self.WarningSCCr(SCCr_LL)) or (self.WarningSCCp(SCCp_LL, SCCp_UL))

É possível verificar se um dado componente (por exemplo, origina um aviso de alguma dessas heurísticas através da avaliação da seguinte expressão em OCL: c1)

c1.DesignWarning(0.17,0.42,0.17,0.34,0.61,0.42,0.77)

VI. EXPERIÊNCIA DE VALIDAÇÃO CRUZADA A. Recolha de métricas Para ensaiarmos a nossa técnica de formalização conduzimos a seguinte experiência: recolhemos as métricas de Washizaki et al. sobre uma biblioteca de componentes de domínio público (a biblioteca FukaBeans [25]). Esta biblioteca foi desenvolvida de acordo com o modelo de componentes JavaBeans [26] pela equipa de investigação de Washizaki. Cada componente é distribuído num arquivo jar separado. A tabela III apresenta os valores das métricas para cada um dos componentes da biblioteca. Para efectuarmos esta análise, usamos modelos dos componentes obtidos por engenharia inversa, a partir dos arquivos jar. Os valores em negrito representam as métricas que, de acordo com as heurísticas de Washizaki et al., originariam avisos. TABELA III MÉTRICAS DE WASHIZAKI ET AL. PARA A BIBLIOTECA FUKABEANS JavaBean

RCO

RCC

SCCr

SCCp

CellBean

0,037

0,111

0,909

0,818

FileUtil

1,000

0,667

1,000

1,000

FilterBean

0,267

0,133

0,933

0,200

FukaCalendarBean

0,444

0,444

0,857

0,571

FukaGraphBean

1,000

1,000

1,000

0,733

FukaStopWatchBean

0,667

0,667

1,000

0,200

FukaTextBean

0,000

0,000

1,000

1,000

GameBean

0,250

0,250

1,000

0,556

GraphBean

0,182

0,273

1,000

0,714

StatementBean

0,667

0,667

0,500

0,500

DocumentBean2

0,000

0,000

1,000

1,000

WordBean2

0,000

0,000

1,000

1,000

Média

0,376

0,351

0,933

0,691

Desvio Padrão

0,376

0,333

0,145

0,294

Apesar de os valores médios das métricas se encontrarem bem dentro dos intervalos de qualidade determinados por

Washizaki et al., apenas dois dos componentes (GameBean e GraphBean) respeitam todas as heurísticas de qualidade, enquanto 7 dos 12 componentes avaliados falham 3 critérios. Deve-se realçar que os valores usados nestas heurísticas foram calibrados com componentes comerciais, enquanto os componentes sob avaliação nesta experiência de validação cruzada foram desenvolvidos com objectivos académicos, contando na sua maioria com um número bastante reduzido de operações (menos de 10). Uma possível explicação para a aparente falta de facilidade de reutilização destes componentes, face às heurísticas, é que para um tão reduzido número de operações e propriedades, o modelo se torna vulnerável: dado que todas as métricas são definidas como rácios, o pequeno número de elementos envolvidos na sua computação leva a uma grande variância nos valores das métricas. Se assumirmos que boa parte dos componentes na amostra agora analisada apresenta uma boa facilidade de reutilização, podemos estar na presença de um caso de falta de consistência externa, ou seja, perante um modelo que não se comporta tão bem quando aplicado a componentes que não os usados na sua construção. B. Definição do conjunto de métricas A definição original deste conjunto de métricas é ambígua, no que respeita ao conceito de herança. Não é claro se as operações e propriedades herdadas por um componente devem ou não ser contabilizadas no cálculo das métricas. Esta ambiguidade relativa à herança ilustra bem o tipo de dificuldades de interpretação que uma definição informal pode levantar, reforçando a argumentação a favor da formalização das definições. Na nossa formalização, apenas usamos operações e propriedades directamente definidas para o componente em questão. Outro aspecto discutível está relacionado com a complexidade associada aos tipos dos parâmetros na avaliação de interfaces das operações. As métricas apenas contam o número de parâmetros, não sendo portanto sensíveis à repetição de tipos de parâmetros, ou à complexidade desses tipos. Por exemplo, um método com N parâmetros de tipos distintos é, intuitivamente, mais difícil de compreender do que um método em que todos os parâmetros são do mesmo tipo. Além disso, parâmetros de tipos atómicos, como Integer, Real, ou Boolean são intuitivamente menos complexos do que tipos compostos. C. Aplicabilidade do conjunto de métricas Este conjunto de métricas foi desenvolvido para a avaliação da facilidade de reutilização de componentes de pequena dimensão (JavaBeans), através da análise da complexidade da sua interface. Isto limita o tipo de elementos analisados. Os componentes arquitecturais da UML 2.0 têm uma expressividade mais rica do que a usada neste conjunto de métricas. É possível definir métricas sobre modelos de componentes mais ricos avaliando, além das interfaces fornecidas, as interfaces requeridas por um componente, bem como os eventos produzidos e consumidos pelo componente. Em todo o caso, este tipo de métricas para componentes baseadas apenas nas suas interfaces fornecidas parece-nos, efectivamente, bastante mais adequado para componentes de pequena dimensão (fine-

8

grained components) do que para componentes de grande dimensão (coarse-grained components). Este conjunto de métricas não trata os aspectos não funcionais dos componentes, que nos parecem mais úteis no apoio à selecção de componentes de grande dimensão. VII. CONCLUSÕES A validação cruzada de métricas e modelos de qualidade é um passo essencial para a promoção da sua adopção num contexto mais generalizado. O estado da arte no que respeita a modelos de qualidade e métricas para o DBC caracteriza-se por propostas insuficientemente validadas, não apenas pelos seus autores, mas, sobretudo, por entidades independentes. Apesar de se poder argumentar que as propostas de métricas para o DBC são recentes e carecem de uma maior maturidade, a nossa experiência na área das métricas de software, ao longo dos últimos dez anos, leva-nos a acreditar que dois dos factores que mais têm dificultado a replicação de experiências de recolha de métricas com vista à sua validação cruzada são a ambiguidade na sua definição e a utilização de formalismos de especificação inadequados. A proposta apresentada neste artigo resolve estes dois problemas. Apresenta uma técnica formal, portável e executável de especificar métricas para o DBC, utilizando notações normalizadas, como diagramas de classe UML 2.0 e OCL. A preocupação em utilizar tecnologias baseadas em normas é prevalente na nossa abordagem. O objectivo é mitigar a tradicional distância entre as comunidades académica e empresarial, disponibilizando uma solução que permita, com relativa simplicidade, integrar a recolha de métricas e a ajuda baseada em heurísticas para o DBC nos ambientes de desenvolvimento normalmente usados. Além disso, a utilização de mecanismos precisos baseados em notações normalizadas e de utilização bastante generalizada contribuem para suportar a validação e, consequentemente, a utilização de métricas. Ao facilitar as actividades de validação, tornando-as testáveis e reproduzíveis, estamos a incutir nelas uma característica fundamental para as podermos enquadrar no método científico: se o trabalho experimental for repetido em diversos ambientes, por equipas independentes, criam-se as condições para cancelar os efeitos de erros, sistemáticos ou não, que possam ser cometidos por uma determinada equipa. Este tipo de erros pode surgir, por exemplo, da falta de representatividade de dados a que uma determinada equipa tem acesso, ou de algum tipo de julgamento tendencioso, ainda que inconsciente, que possa influir na interpretação dos resultados experimentais obtidos.

Wallnau e Stafford [27] é mais interessante avaliar a qualidade resultante da interacção entre componentes do que a qualidade dos componentes isolados. A abordagem aqui apresentada é também genérica, dado que, de um ponto de vista conceptual, ela é independente do meta-modelo que lhe está subjacente. Em particular, estamos interessados na avaliação de linhas de produto de software (software product lines), usando conjuntos de métricas como o proposto por Hoek et al. [15]. Paralelamente, temos uma linha de investigação a decorrer em que estamos a formalizar métricas para esquemas de bases de dados objecto-relacionais [28]. IX. APÊNDICE O processo de recolha dos valores das métricas é suportado por um conjunto de ferramentas, condição essencial para a escalabilidade de experiência relatada neste artigo. Uma vez que as métricas e heurísticas são formalizadas em expressões OCL, baseadas no meta-modelo da UML 2.0, o conjunto de ferramentas tem de suportar as seguintes funcionalidades: • capacidade para gerar uma representação abstracta de meta-objectos e meta-ligações para instanciar o metamodelo da UML 2.0, a partir de uma determinada arquitectura de componentes que se pretende analisar; • capacidade para instanciar o meta-modelo da UML 2.0, isto é popular o meta-modelo com as instâncias correspondentes (meta-objectos e meta-ligações); • capacidade para avaliar as expressões OCL sobre a instanciação do meta-modelo. A Fig. 5 apresenta uma vista geral sobre o nosso ambiente experimental. A especificação do meta-modelo da UML 2.0 foi obtida em [29] no formato XMI. As especificações dos componentes a analisar foram também obtidas em XMI produzido por uma ferramenta comercial de desenho em UML. Essa ferramenta foi usada na engenharia inversa dos arquivos jar, sendo os modelos assim obtidos convertidos para XMI. Com base nas meta-classes da UML 2.0 e nos modelos de componentes especificados em XMI, procedemos à instanciação do meta-modelo da UML 2.0. Utilizamos o avaliador de expressões OCL sobre essa instanciação, para calcular os valores das métricas e heurísticas especificadas em OCL. Os valores das métricas obtidos para esta especificação e os valores obtidos para a avaliação das heurísticas são os resultados de todo este processo. Adaptador XMI

VIII. TRABALHO FUTURO Apesar de as métricas formalizadas neste artigo se destinarem à avaliação de componentes de pequena dimensão, a abordagem apresentada é flexível, podendo ser aplicada a diferentes níveis de granularidade e com preocupações diversas. Em particular, estamos interessados em explorar também métricas para infra-estruturas de componentes, em vez de nos centrarmos apenas em componentes isolados. De acordo com

Meta-modelo UML 2.0 (XMI)

Especificação de infraestrutura de componentes em UML 2.0 (XMI)

Tradutor de Modelo

Meta-modelo do UML 2.0 (meta-classes)

Gerador de Instâncias do meta-modelo

Instanciação de infraestrutura de componentes em UML 2.0 (meta-objectos)

Fig. 5 – Arquitectura para a recolha de métricas

Especificação de métricas em OCL

Valores das métricas recolhidas

Avaliador de expressões em OCL Valores das heurísticas calculadas Especificação de heurísticas em OCL

9

À data em que esta experiência foi realizada, não existiam, tanto quanto sabemos, ferramentas CASE com dicionários construídos de acordo com a especificação da UML 2.0 suportando a avaliação de expressões OCL. Por este motivo, recorremos à ferramenta USE [30] como avaliador de expressões OCL e construímos um adaptador de especificações (XMI front-end) para o formato usado por aquela ferramenta. A. A ferramenta USE A ferramenta USE foi desenvolvida por Richters, na Universidade de Bremen, para permitir a expressão de restrições em diagramas de classe UML 1.x, usando OCL. 1) Vantagens da ferramenta USE A ferramenta USE inclui um carregador de modelos. Dado um diagrama de classes, a ferramenta permite popular esse diagrama com objectos apropriados, sendo depois possível avaliar expressões OCL sobre o modelo populado. Além de se poder verificar com o avaliador de expressões OCL se o estado do modelo carregado obedece às restrições impostas em OCL, é também possível recolher a informação relevante e detalhada sobre o estado do modelo. Estas características são essenciais para a nossa técnica de formalização de métricas: podemos carregar um meta-modelo apropriado (neste caso particular, o da UML 2.0) e popular esse meta-modelo com os elementos correspondentes à infra-estrutura de componentes que pretendemos avaliar; além disso, a especificação das métricas funciona como uma consulta ao estado do modelo, sendo portanto executáveis. 2) Problemas com a ferramenta USE Apesar das suas inegáveis virtudes, a ferramenta USE tem alguns problemas. O primeiro deles é apenas suportar um subconjunto da UML 1.x, deixando de fora alguns elementos de modelação que nos seriam particularmente úteis, tais como os pacotes (packages). Apesar de o problema poder ser torneado pela utilização de identificadores qualificados, não deixa de ser uma fonte de complexidade acrescida na nossa definição de métricas. Para facilitar a sua leitura, e por não se tratar de algo intrínseco à nossa abordagem, mas antes decorrente de uma limitação da ferramenta USE, apresentamos no artigo os identificadores na sua versão não qualificada. Uma segunda limitação do USE é a utilização de um formato de dados para modelos UML e respectivos objectos não padronizados, que nos obriga a ter um adaptador que seja alimentado pelo formato gerado pela ferramenta CASE, de onde obtemos a especificação dos componentes para o formato do USE. Outra limitação da ferramenta USE é a impossibilidade de proceder ao carregamento incremental de modelos, que permitiria uma separação da definição de métricas e heurísticas do modelo a ser avaliado. B. Adaptador de XMI Nas nossas primeiras tentativas de formalização de métricas, criámos um adaptador entre uma ferramenta comercial de UML e o USE [20], [22]. A desvantagem desta abordagem era ficarmos presos a um formato proprietário, na origem dos

modelos a analisar. Com a crescente adopção de XMI como o formato para garantir a interoperabilidade entre produtores de ferramentas de desenvolvimento, optámos por criar um adaptador de XMI para o formato usado na ferramenta USE. Este adaptador recebe como entradas a especificação do metamodelo da UML 2.0 e da infra-estrutura de componentes a analisar, produzindo dois tipos de saída: • uma especificação no formato USE equivalente ao diagrama de classes do meta-modelo da UML 2.0, originalmente especificado em XMI; esta especificação permitenos carregar o meta-modelo na ferramenta USE (metaclasses do meta-modelo da UML 2.0, na Fig. 5); • um ficheiro de comandos USE, com as instruções necessárias à geração do conjunto de meta-objectos representando a infra-estrutura de componentes (instanciação da infraestrutura de componentes na UML 2.0, na Fig. 5). A combinação destas duas saídas permite-nos gerar o metamodelo e carregar esse meta-modelo com os meta-objectos correspondentes à infra-estrutura de componentes a analisar com as expressões OCL. O extracto que se segue, em USE script, gera os meta-objectos e meta-ligações correspondentes ao diagrama de objectos apresentado na Fig. 3. --Cria o componente, propriedades e operações !create c1: Component !create p1: Property !create p2: Property !create p3: Property ... !create p9: Property !create o1: Operation !create o2: Operation !create o3: Operation !create o4: Operation ... !create o21: Operation --Preenche os atributos dos meta-objectos !set c1.name = 'SQL_Select' !set p1.name = 'NO_WORK' !set p2.name = 'DO_SELECT' !set p3.name = 'work' ... !set p9.name = 'maxRows' !set o1.name = 'SQL_Select' !set o1.stereotype = 'constructor' !set o2.name = 'doLayout' !set o3.name = 'doWork' !set o4.name = 'getMaxRows' !set o4.stereotype = 'getter' ... !set o21.name = 'writeObject' --Estabelece as ligações entre o componente --e as suas propriedades e operações !insert (p1,c1) into Property__Component !insert (p2,c1) into Property__Component !insert (p3,c1) into Property__Component ... !insert (p9,c1) into Property__Component !insert (o1,c1) into Operation__Component !insert (o2,c1) into Operation__Component !insert (o3,c1) into Operation__Component !insert (o4,c1) into Operation__Component ... !insert (o21,c1) into Operation__Component

BIBLIOGRAFIA [1]

M. Bertoa e A. Vallecillo, "Quality Attributes for COTS Components", in Proceedings of 6th International Workshop on Quantitative Ap-

10

[2] [3] [4] [5] [6]

[7] [8] [9] [10] [11] [12] [13] [14] [15]

[16] [17] [18] [19]

[20]

[21]

[22] [23]

[24] [25]

proaches in Object-Oriented Software Engineering (QAOOSE'2002), Málaga, Espanha, Junho 2002. N. S. Gill e P. S. Grover, "Component-Based Measurement: Few Useful Guidelines", ACM SIGSOFT Software Engineering Notes, vol. 28, Novembro 2003. UML 2.0 Infrastructure Final Adopted Specification, Object Management Group, Inc. ptc/03-09-15, Setembro 2003. UML 2.0 Superstructure Final Adopted Specification, Object Management Group Inc. ptc/03-08-02, Agosto 2003. UML 2.0 OCL Final Adopted specification, Object Management Group Inc. ptc/03-10-14, Outubro 2003. H. Washizaki, H. Yamamoto e Y. Fukazawa, "A Metrics Suite for Measuring Reusability of Software Components", in Proceedings of the Ninth International Software Metrics Symposium (Metrics'03), Sydney, Austrália, Setembro 2003. R. Harrison, S. J. Counsell e R. V. Nithi, "An Evaluation of the MOOD Set of Object-Oriented Software Metrics", IEEE Transactions on Software Engineering, vol. 24, pp. 491-496, Junho1998. F. B. Abreu e R. Carapuça, "Candidate Metrics for Object-Oriented Software within a Taxonomy Framework", Journal of Systems and Software, vol. 26, pp. 87-96, Julho 1994. V. Basili, L. Briand e W. L. Melo, "A Validation of Object-Oriented Design Metrics as Quality Indicators", IEEE Transactions on Software Engineering, vol. 22, pp. 751-761, Outubro 1996. S. R. Chidamber e C. F. Kemerer, "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, vol. 20, pp. 476493, Junho 1994. W. Li e S. Henry, "Object-Oriented Metrics that Predict Maintainability", Journal of Systems and Software, vol. 23, pp. 111-122, Novembro 1993. T. McCabe, "A Complexity Measure", IEEE Transactions on Software Engineering, vol. 2, pp. 308-320, Dezembro 1976. M. Halstead, Elements of Software Science. New York, EUA: Elsevier Computer Science Library / North-Holland, 1977. R. Dumke e A. Schmietendorf, "Possibilities of the Description and Evaluation of Software Components", Metrics News, vol. 5, 2000. A. v. d. Hoek, E. Dincel e N. Medvidovic, "Using Service Utilization Metrics to Assess and Improve Product Line Architectures", in Proceedings of the Ninth International Software Metrics Symposium (Metrics'03), Sydney, Austrália, Setembro 2003. M. A. S. Boxall e S. Araban, "Interface Metrics for Reusability Analysis of Components", in Proceedings of Australian Software Engineering Conference (ASWEC'2004), Melbourne, Austrália, Abril 2004. M. Goulão e F. B. Abreu, "Software Components Evaluation: an Overview", Actas da 5ª Conferência da APSI, Lisboa, Novembro 2004. F. B. Abreu, "Using OCL to formalize object oriented metrics definitions", INESC, Software Engineering Group ES007/2001, Relatório Técnico, Maio (versão 0.9) 2001. F. B. Abreu, L. M. Ochoa e M. Goulão, "The GOODLY Design Language for MOOD2 Metrics Collection", in Proceedings of ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'1999), Lisboa, Portugal, Junho 1999. A. L. Baroni, S. Braz e F. B. Abreu, "Using OCL to Formalize ObjectOriented Design Metrics Definitions", in Proceedings of 6th International Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'2002), Málaga, Espanha, Junho 2002. A. L. Baroni, "Formal Definition of Object-Oriented Design Metrics", Dissertação de MSc, Vrije Universiteit Brussel - Bélgica, em colaboração com a École des Mines de Nantes - França e Universidade Nova de Lisboa - Portugal, 2002. A. L. Baroni e F. B. Abreu, "Formalizing Object-Oriented Design Metrics upon the UML Meta-Model", in Proceedings of Brazilian Symposium on Software Engineering, Gramado - RS, Brazil, Outubro 2002. M. Goulão e F. B. Abreu, "Bridging the gap between Acme and UML for CBD", in Proceedings of Specification and Verification of Component-Based Systems (SAVCBS'2003), ESEC/FSE'2003, Helsinki, Finland, Setembro 2003. JARS, [Online]. Disponível: "http://www.jars.com/". Y. Fukazawa, H. Washizaki, H. Yamamoto, T. Adachi, Y. Sakai, K. Satoh, e D. Hoshi, "FukaBeans: JavaBeans Components Library, [Online].Disponível: http://www.fuka.info.waseda.ac.jp/Project/CBSE/fukabeans/".

[26] G. Hamilton, "JavaBeans (version 1.01-A)", Sun Microsystems, API Specification, Agosto 1997. [27] K. Wallnau e J. A. Stafford, "Dispelling the Myth of Component Evaluation", in Building Reliable Component-Based Software Systems, I. Crnkovic and Larsson, Eds. Boston, London: Artech House, pp. 157177, 2002. [28] A. L. Baroni, C. Calero, F. Ruiz, and F. B. Abreu, "Formalizing ObjectRelational Structural Metrics", Actas da 5ª Conferência da APSI, Lisboa, Novembro 2004. [29] Neptune Consortium UML 2.0 resources page. [Online]. Disponível: http://neptune.irit.fr/. [30] M. Richters, "A UML-based Specification Environment". [Online]. Disponível:http://www.db.informatik.uni-bremen.de/projects/USE University of Bremen, 2001.

BIOGRAFIAS Miguel Goulão nasceu em Lisboa, Portugal, em 20 de Junho de 1972. É licenciado em Engenharia Informática e de Computadores e Mestre em Engenharia Electrotécnica e de Computadores, pelo Instituto Superior Técnico, da Universidade Técnica de Lisboa. Prepara actualmente o seu Doutoramento em Abordagens Quantitativas à Engenharia de Software Baseado em Componentes. Actualmente é Assistente do Departamento de Informática da Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa e membro do grupo de Investigação QUASAR, de que é co-fundador. Foi membro do grupo de Engenharia de Software do INESC e Assistente Convidado no Instituto Superior de Economia e Gestão da Universidade Técnica de Lisboa. Ao longo dos últimos 10 anos, tem vindo a desenvolver investigação na área engenharia de software experimental, tendo publicado cerca de 20 artigos em revistas, conferências e workshops na área das métricas de software. Recebeu o János Szentes Award para o melhor artigo sobre métricas de software apresentado na 6th European Conference on Software Quality, em 1999. Fernando Brito e Abreu nasceu em Lisboa, Portugal, em 14 de Maio de 1959. É Licenciado em Engenharia Electrotécnica, Mestre em Engenharia Electrotécnica e de Computadores e Doutorado em Engenharia Informática, desde 2000, pelo Instituto Superior Técnico, Universidade Técnica de Lisboa. É Professor Auxiliar no Departamento de Informática da Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa, Professor Convidado no EMOOSE (European Master in Object and Component Oriented Software Engineering Technologies), na École des Mines de Nantes, fundador e líder do grupo de investigação QUASAR, Presidente da Comissão Sectorial para a Qualidade nas Tecnologias de Informação e Comunicações, membro do Editorial Board da revista Software Quality Professional da American Society for Quality e representante de Portugal no Software Group da European Organization for Quality. Foi investigador do grupo de Engenharia de Software do INESC, Assistente do Instituto Superior de Economia e Gestão da Universidade Técnica de Lisboa, Director do departamento de desenvolvimento de uma software house e consultor em diversas organizações. Entre os seus principais interesses científicos actuais, contam-se a engenharia de software experimental, a qualidade de software, a análise e desenho de software, a gestão de projectos de engenharia de software e a reengenharia de sistemas legados. Publicou mais de 50 artigos em revistas, conferências e workshops e é membro regular de comités de avaliação e organização de diversos eventos científicos.