MEI / LEIC Engenharia de Requisitos de Sistemas de Software Estudo de Casos - Caso da Colocação de Professores João Pascoal Faria Novembro de 2004.

Slides:



Advertisements
Apresentações semelhantes
CIn-UFPE1 Diagramas de Atividades UML. CIn-UFPE2 Diagramas de Atividades n Os Diagramas de Atividades mostram o fluxo entre atividades (ações não-atômicas);
Advertisements

Considerações Finais sobre Medidas de Tendência Central Na maioria das situações, não necessitamos de calcular as três medidas, normalmente precisamos.
EA976 – Engenharia de Software AULA 19 Pré-Projeto e Modelagem de Negócios.
EA976 – Engenharia de Software AULA 11 Planejamento e Estimativas.
Cinemática Escalar. 1. O movimento de um carro, que se move com velocidade constante, é descrito pela seguinte tabela t (h) S (km)
CONTAGEM Princípios Básicos Permutações Arranjos Combinações.
Projeto em Consórcio Otimização da Mobilidade Transnacional VET em Rede III.
Análise e qualificação de funções  Posto de Trabalho - Conjunto de tarefas com exigências (aptidões, responsabilidades, esforços e condições de trabalho),
O MÉTODO PERT-CPM. Em 1958 foi desenvolvido o método do PERT – Program Evaluation and Review Technique. Esse método permitiu instituir uma linguagem de.
Definição de função afim Chama-se de Função Afim ou Função do 1º grau toda a função da forma: PROFESSOR VALDEMIR
Fundamentos de Aritmética
MMC e MDC.
PROFESSOR: ALEXSANDRO DE sOUSA
Casamento de Padrão Aproximado e Compressão de Huffaman
Modelação de Sistemas de Informação com UML
UNIVERSIDADE FEDERAL DE UBERLÂNDIA FACULDADE DE MATEMÁTICA PROJETO PIBEG Unidade IV Interpolação Polinomial.
Análise de Estruturas.
Grupos de Slides No 7. Prof. SIMÃO
Estatística 2. Estatística indutiva
Algoritmos Genéticos Alex F. V. Machado 1.
Projecto de bases de dados relacionais:
Métodos Formais em Engenharia de Software Utilização da Ferramenta VDMTools Lite João Pascoal Faria
Sociologia Política Prof. Dr. André Zanetic
Criação: Caroline Brasileiro Atualização: Laura Matos
Sistemas de Controle III N8SC3
SISTEMAS OPERACIONAIS
ANÁLISE DAS DEMONSTRAÇÕES FINANCEIRAS
Introdução ao RUP – Rational Unified Process
P3 - Fluxo máximo numa rede de transporte
Introdução O que é um sistema de controlo?
Métodos Formais em Engenharia de Software Utilização da Ferramenta VDMTools Lite João Pascoal Faria
Modelagem para Otimização:Aula 2
Introdução à Engenharia Civil
Sistemas de Controle III N8SC3
3.1 Classes e Objetos Em um programa orientado a objetos normalmente existem vários objetos de um mesmo tipo. Por exemplo, um programa de controle de.
Jogos Repetidos.
Sistemas de Controle III N8SC3
Diagrama de Atividade Prof. Thales Castro.
FEUP/LEEC Algoritmos e Estruturas de Dados 2001/2002
EGP, CPC, 2004/05 Problema e Algoritmos de Colocação de Professores
ÁLGEBRA LINEAR INDEPENDÊNCIA E DEPENDÊNCIA LINEAR (LI e LD)
Lógica de Primeira Ordem
Kroton Educacional Universidade uniderp (Unidade Matriz)
Combinando inequações lineares
TQS - Teste e Qualidade de Software (Software Testing and Quality) Discussão de Exercícios de Análise de Cobertura de Código.
Algoritmos de Redes Rota mais curta Árvore de ramificação mínima
Introdução à análise combinatória

Cálculo do clique maximal de um grafo
Máscara de Sub-redes aula 11
Operações Básicas da Matemática
O jogo de Sperner Roberto Imbuzeiro Oliveira (IMPA)
Zeros de funções.
Professor : Neilton Satel
Função Profª. Carla S. Moreno Battaglioli
Cálculo de Sub redes.
Estatística Básica AULA Nº. 1 Medidas de Centralização Profº Fábio Tozo.
1 Modelagem Matemática de Sistemas Dinâmicos 3.9. Gráfico de Fluxo de Sinais Linearização de Modelos Prof. André Marcato Livro Texto: Engenharia.
              Investigação Operacional Métodos de Programação Linear: Big M, 2 Fases, S Dual (Mestrado) Engenharia Industrial
COMPUTAÇÃO BIOINSPIRADA
Introdução ao Projeto na Engenharia
Algoritmos Genéticos Alex F. V. Machado.
Modelagem Matemática de Sistemas Dinâmicos. 3. 9
INTRODUÇÃO À ENGENHARIA AVALIAÇÃO DE SOLUÇÕES
Diagramas de Seqüência
Aula 7 – Algoritmos Genéticos
GRAUS DOS ADJETIVOS PROFESSORA: RITA TRINDADE.
1º DIA – aula 01: conhecendo as partes de um tcc
Programação Dinâmica (PD)
Álgebra Linear Sistemas de Equações Lineares
Transcrição da apresentação:

MEI / LEIC Engenharia de Requisitos de Sistemas de Software Estudo de Casos - Caso da Colocação de Professores João Pascoal Faria Novembro de 2004

Modelação de requisitos – modelo de domínio (UML) atributo identificador, isto é, não há dois professores com o mesmo ranking pressupõe-se que a posição inicial é sempre acrescentada no fim da lista de preferências Professor Posição ~30.000 ~100.000 professor inicial posição inicial ranking: Integer {I} 0..1 0..1 {subset} candidatos preferências * 1..* {subset} {ordered} /professor final /posição final 0..1 0..1 /Colocação Final * 1 associação derivada, a determinar pelo sistema! Escola

Formulação como problema de matching num grafo bipartido pesado (ou problema de afectação) Professores grau de preferência (custo) Posições ou Vagas 1 P1 V1 2 2 P2 V2 1 . . ranking 1 Pn Vm Um matching num grafo é um conjunto de arestas disjuntas, isto é, sem vértices comuns Mas não é um problema standard de matching ou afectação, por causa das restrições a seguir!

Modelação de requisitos – restrições Para além das restrições já traduzidas no diagrama de classes, uma colocação tem de garantir a satisfação das seguintes restrições, que garantem a justiça da colocação na perspectiva de cada candidato: R1) Um professor que tinha colocação no início tem de ter colocação no fim. Formalmente, em OCL: context Professor inv ColocaçãoObrigatória: posição_inicial->notEmpty() implies posição_final->notEmpty()

Modelação de requisitos – restrições R2) Para cada professor e para cada posição por ele preferida em relação àquela em que foi colocado (inclui todas as posições no caso de não ter sido colocado), essa posição tem de estar ocupada por um professor com melhor ranking ou pelo professor que aí estava anteriormente colocado (*) (*) sem esta última cláusula o problema é impossível – ver exemplo do slide 11 Formalmente, em OCL: context Professor inv OcuparVagasEObedecerRanking: preferências->forAll( pos | (posição_final->isEmpty() or preferências->indexOf(pos) < preferências->indexOf(posição_final)) implies (pos.professor_final->notEmpty() and (pos.professor_final.ranking < p1.ranking or pos.professor_final = pos.professor_inicial)))

Análise de requisitos Será que as restrições indicadas são suficientes para determinar uma e uma só solução/colocação (ainda que de forma implícita)? Não é razoável deixar ao cuidado do implementador a escolha de uma entre várias soluções possíveis, nem faz sentido especificar algo que não pode ser realizado Pode ser necessária a contribuição de um designer de algoritmos ou matemático durante a análise de requisitos! É fácil convencermo-nos que existe pelo menos uma solução Algoritmo pessimista simples baseado na recuperação de vagas encontra sempre uma solução com estas características – ver slide 7 Mas o exemplo do slide 9 mostra que pode existir mais do que uma solução! O algoritmo pessimista baseado na recuperação de vagas não dá a "melhor" solução nesse exemplo!

Algoritmo de colocação pessimista 1) Consideram-se inicialmente ocupadas as posições iniciais dos professores que pretendem mudar de posição 2) Colocam-se os professores pela ordem do ranking: 2.1) Coloca-se o professor na sua melhor preferência que está ainda livre 2.2) Se o professor estava inicialmente colocado e é colocado agora numa nova posição, gera uma vaga que tem de ser recuperada: 2.3.1) Procura-se o professor já colocado de melhor ranking que pode beneficiar dessa vaga 2.3.2) Se não se encontrar nenhum professor nessas condições, a recuperação da vaga fica concluída 2.3.3) Se se encontrar um professor nessas condições, muda-se a colocação desse professor (melhorando-a), o que origina uma nova vaga que tem de ser recuperada da mesma forma

Análise do algoritmo de colocação pessimista Uma vez que a recuperação de uma vaga corresponde à melhoria de posição de um professor, o nº máximo de movimentos de recuperação de vagas ao longo de toda a execução do algoritmo é o nº total de preferências indicadas pelos professores. Isto também garante que o algoritmo termina sempre É fácil (?) de ver que ambas as restrições (R1 e R2) são satisfeitas

Análise de requisitos - multiplicidade de soluções professor posição (ou vaga) preferência Situação inicial: V1 V2 Soluções possíveis válidas (obedecendo às restrições): P1 P2 V1 V2 solução melhor pior algoritmo pessimista só consegue encontrar algoritmo optimista consegue encontrar

Refinamento de requisitos Que o critério para escolher a "melhor" solução? Como se comparam duas soluções válidas (que obedecem às restrições já indicadas)? PROPOSTA: Dá-se prioridade à satisfação do professor com melhor ranking, isto é, procura-se o professor de melhor ranking em que as soluções divergem, e escolhe-se a solução que coloca melhor esse professor Este critério impõe uma ordenação total das soluções válidas. O sistema deve encontrar a solução "óptima", isto é, a solução válida que é melhor do que todas as outras Obviamente, existe só uma solução óptima pelo critério anterior. Como se formaliza esta regra? Invariante em OCL não trivial ....

Análise de requisitos – estranhezas da lei Ao melhorar a posição de alguns professores mantendo a posição dos restantes, pode-se violar a restrição de justiça relativa entre dois candidatos à mesma vaga! Por isso é que o critério de comparação indicado no slide anterior refere soluções válidas, e não soluções em geral não é colocação válida (segundo regras anteriores) P1 P1 professor com melhor ranking, mas sem posição inicial P2 P3 P3 P2 colocação inicial é colocação final válida (segundo regras anteriores) melhorar situação de P2 e P3, mantendo situação de P1

Análise de requisitos A solução pode ser determinada em tempo útil? Não faz sentido especificar algo que não pode ser realizado CONJECTURA: o algoritmo optimista desenvolvido pela ATX Software – ver slide 13 – determina a solução óptima no sentido do critério apresentado FALTA PROVAR! Pode ser necessária a contribuição de um designer de algoritmos ou matemático durante a análise de requisitos! Esse algoritmo corre em tempo polinomial (demorou cerca de 30 minutos com os dados de 2004)

Algoritmo de colocação optimista (*) 1) Consideram-se inicialmente livres as posições iniciais dos professores que pretendem mudar de posição 2) Colocam-se os professores pela ordem do ranking, na melhor preferência ainda livre de cada professor (alguns professores podem ficar por colocar) 3) Se os professores que estavam inicialmente colocados ficaram todos colocados, o processo termina. 4) Senão, 4.1) Os professores que estavam inicialmente colocados e ficaram por colocar são colocados definitivamente nas suas posições iniciais, que deixam de estar livres 4.2) Repete-se a colocação com menos estes lugares livres (*) Desenvolvido pela

Análise do algoritmo de colocação optimista O nº máximo de iterações externas é limitado pelo número de professores que estavam inicialmente colocados. Isto também garante que o algoritmo termina sempre Intuitivamente faz sentido, mas não é trivial mostrar que encontra a melhor solução!! Ver demonstração da correcção do algoritmo nas referências.

Modelação de requisitos - formalização Especificação formal do objectivo de optimização em OCL a fazer

Especificação por pós-condições Em vez de invariantes sobre o estado, podem-se definir pós-condições sobre a operação que efectua a colocação O algoritmo pode ser expresso no corpo da operação por uma linguagem de acções de alto nível

Lições Uma coisa é especificar o problema a resolver (nível dos requisitos) e outra coisa é especificar o algoritmo para resolver o problema (nível da solução) Neste caso, é difícil separar as duas coisas Não vale a pena comparar a eficiência de algoritmos que resolvem problemas diferentes (ou, o mesmo é dizer, dão resultados diferentes)

Referências Algoritmo de colocação de professores www.uml.org

Agradecimentos Agrade-se ao Dr. Luis Andrade e à ATX Software (www.atxsoftware.com) toda a informação disponibilizada sobre o problema e o algoritmo desenvolvido