A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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.

Apresentações semelhantes


Apresentação em tema: "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."— Transcrição da apresentação:

1 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

2 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 ~ 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

3 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!

4 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()

5 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)))

6 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!

7 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

8 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

9 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

10 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 ....

11 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

12 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)

13 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

14 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.

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

16 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

17 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)

18 Referências Algoritmo de colocação de professores

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


Carregar ppt "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."

Apresentações semelhantes


Anúncios Google