Interactive Ant Colony Optimization (iACO) for Early Lifecycle Software Design Christopher L. Simons, Jim Smith and Paul White
Por Thiago do Nascimento Ferreira
Agenda ● Introdução ● O Problema ● Abordagem Proposta ● Perguntas de Pesquisas ● Experimentos ● Resultados ● Conclusão
Introdução
Introdução ● Design de Software é importante para o sucesso do projeto. ● Design de Software de Ciclo Antecipado, os designers lutam com numerosos julgamentos enquanto as soluções são construídas. ● Algorítmos Evolucionários são utilizados com a participação de humanos no processo de construção da solução
Introdução ● Sugestão de Leitura ● Para quem é o livro: ○
Para o desenvolvedor Java com mais de um ano de experiência ou que participou de mais de um projeto Java. Se você começou a participar de projetos Java e quer saber por que uma série de decisões foram tomadas (ou impostas!) de determinada forma, este livro é para você.
Early Lifecycle Software Design ● Fluxo do Design de Software de Ciclo Antecipado: 1.
Definir os requisitos do software relevantes para o domínio do problema sob investigação
2.
Designer identifica e avalia conceitos e informações relevantes para o domínio do problema de projeto ■
Esta é uma atividade centrada nas pessoas intensamente e, normalmente, envolve trade-offs multi objetivos utilizando critérios concorrentes.
Early Lifecycle Software Design ● Para o design de software, são utilizado Classes e Objetos do Paradigma Orientado a Objeto onde: 1.
Atributos - Dados que devem ser armazenados
2.
Métodos - Unidades de Execução pelo qual os objetos se comunicam com outros objetos, programas e/ou usuários
Early Lifecycle Software Design
O Problema
Problema
Como encontrar um design de software que seja bom (alta coesão e baixo acoplamento) e que leve em consideração as preferências e experiencias do usuário?
Interactive SBSE
Engenharia de Software
Interactive SBSE
SBSE
Interactive SBSE
Engenharia de Software
SBSE
Interactive SBSE
Engenharia de Software
SBSE
Interactive SBSE
Problema
Fadiga Humana
Fadiga Humana ● Minimizar a fadiga e maximizar a consistência da interação do usuário. 1.
Explorar o espaço de busca para chegar a soluções com aptidão superior, enquanto, ao mesmo tempo que permite a busca para ser dirigido conjuntamente pela avaliação subjetiva do usuário.
2.
Produzir soluções superior em um número mínimo de iterações de busca para proporcionar uma sensação de progresso positivo para o usuário.
3.
Buscar multi-objetivamente e ser dinamicamente sensível para a avaliação do usuário
Fadiga Humana ● Algoritmos Evolucionários são mais robusto para problemas de design de grande escala onde o número de classes no design de software é alto
Fadiga Humana ● Algoritmos Evolucionários são mais robusto para problemas de design de grande escala onde o número de classes no design de software é alto ● Se o orçamento computacional for limitado? (Como é provável em uma busca interativa)
Fadiga Humana ● Algoritmos Evolucionários são mais robusto para problemas de design de grande escala onde o número de classes no design de software é alto ● Se o orçamento computacional for limitado? (Como é provável em uma busca interativa)
Ant Colony Optimization
Fadiga Humana ● Algoritmos Evolucionários são mais robusto para problemas de design de grande escala onde o número de classes no design de software é alto ● Se o orçamento computacional for limitado? (Como é provável em uma busca interativa)
Ant Colony Optimization ● Encontra soluções candidatas com metade do número de iterações dos Algoritmos Evolucionários
Abordagem Proposta
Representação da Solução ● O problema do design de software é especificado por meio de Casos de Uso UML, isto é, cenários de uso do sistema pode ser descrito em termos das interações dos seres humanos (como atores) com o sistema automatizado ● Substantivos
são
identificados
identificados como ações.
como
dados;
verbos
são
Representação da Solução ● Se um dado é atendido pela ação, como é típico quando o dado e ação são co-localizados em uma única interação (passo da narrativa do texto) no cenário de caso de uso, a ação é dito que "usar" o dado. ● Assim, na linguagem da UML, um problema de design de software é definido por um conjunto de "métodos" (ações), um conjunto de "atributos" (dados), e seus "usos" correspondentes.
Representação da Solução
Representação da Solução ● Os atributos são derivados diretamente do conjunto de dados enquanto métodos são derivados do conjunto de ações. ● Classes são representadas como agrupamentos de métodos e atributos, embora, naturalmente, existam muitas maneiras em que os métodos e atributos podem ser agrupados em classes. ● Formalmente, o espaço de busca é definido por todas as possíveis alocações de métodos e atributos para um número específico de classes
Representação da Solução ● Exemplo: ○ M = {m1,m2,m3} (Conjunto de Métodos) ○ A = {a1,a2,a3,a4} (Conjunto de Atributos) ○ c = 2 (Número de classes) ● Um exemplo de partição: { {m2},{m1,m3} }. ● Defina a função f (surjection) de A para a partição como: ○ f(a1) = {m2} ○ f(a2) = {m1,m3} ○ f(a3) = {m1,m3} ○ f(a4) = {m2}
Representação da Solução ● Exemplo: ○ M = {m1,m2,m3} (Conjunto de Métodos) ○ A = {a1,a2,a3,a4} (Conjunto de Atributos) ○ c = 2 (Número de classes) ● Um exemplo de partição: { {m2},{m1,m3} }. ● Defina a função f (surjection) de A para a partição como: ○ f(a1) = {m2} ○ f(a2) = {m1,m3} ○ f(a3) = {m1,m3} ○ f(a4) = {m2}
● O resultado seria: ○ {m2,a1,a4} ○ {m1,m3,a2,a3}
Representação da Solução no ACO ● A representação de uma solução do design de software é inspirado no TSP e Vehicle Routing Problem ● A solução consiste em um caminho completo através de um grafo cujos vértices representam os elementos de uma solução de design de software (Atributos e Métodos) ● Cada visitando
formiga elementos
métodos) na sua iteração
cria
uma (Atributos
solução e
Medida de Fitness ● Designers normalmente se esforçam em fazer classes com alta coesão (para refletir um propósito claro) e baixo acoplamento entre os objetos (para garantir que o projeto é robusto, porém flexível para mudar)
Medida de Fitness ● Coupling Between Objects (CBO) Para cada solução gerada, o CBO é calculado como a proporção de todos os "usos" de
atributos
pelos
métodos
que
ocorrem
através
das
classes.
Assim,
convenientemente, um design completamente dissociado (todos os usos ocorrer classes dentro) marca um CBO de 1.0, enquanto uma pontuação de design completamente acopladas a CBO de zero.
● Numbers Among Classes (NAC) Média aritmética dos desvios padrões do número de atributos e de métodos entre as classes de design. A noção aqui é que quanto menor o valor para NAC, mais simétrico o aparecimento de atributos e métodos entre as classes no projeto como um todo.
Medida de Fitness ● Attribute to Method Ratio (ATMR) Desvio padrão da relação de atributos de métodos entre as classes em um projeto. O conceito aqui é que quanto mais baixo o valor de ATMR, mais simétrico o aparecimento de atributos e métodos em classes individuais de design.
Medida de Fitness ● Attribute to Method Ratio (ATMR) Desvio padrão da relação de atributos de métodos entre as classes em um projeto. O conceito aqui é que quanto mais baixo o valor de ATMR, mais simétrico o aparecimento de atributos e métodos em classes individuais de design.
● Boas soluções são geradas como:
Minimizar
CBO
Minimizar
NAC
Minimizar
ATMR
iACO ● MAX-MIN Ant System (MMAS) ○ Somente a melhor formiga da Iteração deposita feromônio ○ A faixa de possibilidades do feromônio é limitada em [Tmin, Tmax] ○ A trilha de feromônio é inicializada com Tmax ● Diferenças da versão original ○ Não existe busca local na iteração ○ A influência da atualização do feromônio é controlada por um parâmetro u.
Perguntas de Pesquisas
Como é feito a avalição da solução pelo usuário? ● O designer é convidado a avaliar uma solução em uma escala de 1 a 100, onde 1 é pobre e 100 é bom. ● Objetivo: ○ Reduzir o número de iterações ○ Aumentar a compreensão do juízo de valor ● O algoritmo apresenta uma solução e não toda a população. A solução será selecionada aleatóriamente da frente. ● iACO usa um modelo de fitness substituto (surrogate function) cujos parâmetros são adaptados em resposta às avaliações periódicas do usuário.
Como é feito a avalição da solução pelo usuário? ● A Avaliação Preditiva do Usuário é um Modelo de Regressão Linear Múltipla
a0 + a1*CBO + a2*NAC + a3*ATMR
Como as soluções são apresentadas ao usuário? ● Classes com alta, média e baixa coesão são coloridas com verde, âmbar e vermelho respectivamente. ● Quanto mais forte o acoplamento entre classes, mais forte será a seta ligando ambas as classes
Quando o designer interage com a busca? ● A questão crucial aqui é que a fadiga do usuário e perda de consistência coloca um limitado "orçamento" para o número de interações, que deve ser gasto com sabedoria. ● Intervalo de Interação proporcional ao fitness ○ Quando soluções pobres são geradas, o sistema produz um alto intervalo de interações (10 a 15 iterações) ○ Quando a qualidade das soluções aumenta, o intervalo diminui.
Que meios são providos para promover o aprendizado do designer? ● É possível que o designer se concentre em classes individuais de solução do projeto consideradas interessantes e úteis, e 'congelar' outras classes. ● O designer pode também descongelar a classe em qualquer interação. ● Este
mecanismo
de
"congelamento"
também
fornece
um
mecanismo eficaz para o designer de abordar projetos de maior escala.
Algoritmo
Experimentos
Estudo de Caso ● Cinema Booking System (CBS) Reserva antecipada para exibição de um filme
● Graduate Development Program (GDP) Extensão de um sistema de administração de estudantes
● Select Cruises (SC) Caso de estudo Industrial de uma empresa que vende férias em cruzeiros
Cinema Booking System (CBS)
Cinema Booking System (CBS) Use case: “Collect Tickets” Actor provides Payment Card Details System looks up Booking Details System prints Tickets for Booking Actions: LookUpPayment Uses: CardNumber, BookingNumber PrintTickets Uses: CardNumber, BookingNumber, TicketType Data: CardNumber CardType CardExpiry
MĂŠtricas do Design Manual
Participantes do Experimento ●
A
Abordagem
participantes
iACO e
uso
é do
explicado ambiente
aos é
apresentado através de um problema de projeto fictício. ●
Os três problemas são apresentados
●
Uma vez iniciado, o experimento termina quando o usuário decide terminar
●
Para prevenir a fadiga, redução de sessão e divisão em episódios
●
No final da sessão, cada participante é convidado
a
comentar
sobre
a
sua
experiência. Os comentários podem incluir todos os aspectos satisfatórios, todos os aspectos que geraram a fadiga do usuário e todas as sugestões para o aprimoramento da experiência
Resultados
Número de Interações por Usuário
Número de médio de interações por Estudo de Caso
Progress達o do Fitness
Melhores Valores de Fitness
Melhores Valores de Fitness
iACO produziu soluçþes com melhores NAC e ATMR, embora pior no CBO
God Class ●
Os participantes foram presenteados com visualizações de soluções de design que mostram a anti-padrão “God Class”. Isto é geralmente considerado pelos designers de software como uma solução de concepção mais deselegante para ser evitado, em que uma única classe atua como um agrupamento incoerente de um grande número de atributos e métodos, deixando outras classes com ineficaz
Evolução do Fitness com uma God Class
Conclus達o
Conclusão ● ACO é altamente eficaz para pesquisa interativa no design de software de ciclo de vida antecipado ● Uso de cores nas classes se mostrou inconclusivo. ● Tamanho da amostra é relativamente pequeno ● Grande variação do comportamento dos participantes durante o experimento é evidente. ● Os participantes deram avaliações positivas e dicas para avaliações futuras ● A media de Elegância ATMR é menos eficaz uma vez que deixa buscar a “God Class”
Obrigado Seminário de Otimização em Engenharia de Software Thiago do Nascimento Ferreira
Vem ai...
Symposium on Search-Based Software Engineering August 26 - 29, 2014