MAC 413 - Tópicos Avançados de
POO
IME Design Fest
 |
Prof. Fábio Kon |
O problema
|
Este problema chama-se Fries
Right - A Distributed French Fry Processing Control System,
e foi apresentado no OOPSLA DesignFest
de 1998. O resumo do problema é o seguinte:
Alguns dos maiores componentes de uma fábrica de processamento
de alimentos são máquinas que separam produtos bons de ruins. Com a
chegada de redes mais rápidas, técnicas de orientação a objetos, e
principalmente, a noção de objetos distribuídos, estas fábricas
estão prontas para alcançar um novo nível, onde máquinas operam
interativamente umas com as outras para atingir uma meta global de
qualidade para toda a fábrica, permitindo às máquinas serem tratadas
e controladas como um sistema único, ao invés de um conjunto de
entidades individuais. Este problema de projeto lida com definir a
arquitetura dos objetos distribuídos que serão necessários para tal
sistema de controle distribuído, aplicado em particular ao processo
de seleção de batatas fritas. |
O Grupo F1
Reunião Inicial - Assuntos
discutidos
|
Diferenças entre as APIs das máquinas |
|
Fator de erro das próprias máquinas |
|
Possíveis arranjos de máquinas |
|
Notação a ser
adotada |
|
Reconfiguração em tempo de execução |
Tópicos
Polêmicos
Durante a discussão da arquitetura proposta, surgiram alguns pontos
polêmicos ou que não apresentavam uma solução claramente melhor que a
outra. Tais pontos são listados a seguir.
|
Classes ConfigEntrada e
ConfigSaida: em nosso desenho inicial, as classes ConfigEntrada
e ConfigSaida eram classes abstratas que deviam ser derivadas para
cada configuração a ser aplicada à linha de produção. Assim,
existiriam classes de configuração distintas para o McDonald's e
Bob's, por exemplo. Porém, após um estudo mais cuidadoso, observamos
que o mais adequado era que os diversos parâmetros de configuração
fossem atributos de ConfigEntrada e ConfigSaida. Assim, diversos
clientes implicam na utilização de diversas instâncias, cada qual
com parâmetros de configuração distintos.
|
|
Classe Histórico: outra grande
dúvida que surgiu durante a definição da arquitetura refere-se à
classe Histórico. No atual modelo, o Histórico atua como um
intermediário entre o Controlador e as PABs apenas no tocante à
coleta de informações. Nunca houve um consenso no grupo que levasse
à conclusão de que essa abordagem fosse a mais apropriada. A outra
possibilidade discutida era a eliminação da classe Histórico,
passando suas responsabilidades diretamente à classe Controlador.
Portanto, tal aspecto da arquitetura não deve ser considerado
definitivo.
|
|
Nós inicial e final: durante
boa parte das discussões sobre o modelo, este possuía classes que
representavam o início e os fins da linha de produção. Uma linha
deveria ter apenas um nó inicial e um ou mais nós finais.
Entretanto, essa representação foi abandonada em favor da utilizada
agora, que simplifica consideravelmente a arquitetura do sistema. O
nó inicial foi substituído por uma referência a um PAB. Como um PAB
tem apenas uma entrada, tal representação é suficiente. Já os nós
finais foram substituídos por um conjunto de referências a PABs, e a
classe de relacionamento SaidaFinal indica se cada saída é de
batatas aprovadas ou rejeitadas.
|
|
Classe Algoritmo: outro ponto
interessante foi a decisão de encapsular os possíveis diversos
algoritmos de reconfiguração das PABs na classe Algoritmo e suas
derivadas. Tal decisão facilita a troca de algoritmos e também
simplifica a interação com o Controlador, que pede uma
reconfiguração dos parâmetros dos diversos PABs e recebe uma lista
de novos parâmetros para cada um dos PABs. A partir desse ponto, o
Controlador pode facilmente reconfigurar a linha de produção. |
Diagramas
 |
 |
Diagrama de
Classes
|
Diagrama de
Objetos
|
 |
 |
| Diagrama de
Atividades |
Diagrama de
Sequência |
Arquivos para download (.pdf)
|
