Modelagem UML Petrolimpa

Transcrição

1 Modelagem UML Petrolimpa Disciplina: MAC5714-5/4 - Programação Orientada a Objetos Dupla: Danilo Caetano Matias dos Santos nusp: Rogério Cardoso - nusp: Professor: Fábio Kon

2 1 Introdução Os alunos da disciplina de Programação Orientada a Objetos (POO) MAC5714-5/4, ministrada no IME-USP pelo professor Fábio Kon, foram desafiados a modelar um sistema com o codinome Petrolimpa e o objetivo de aplicar os conhecimentos adquiridos em sala sobre modelagem UML na prática. O minimundo apresentado aos alunos foi: Os alunos do IME foram contratados por uma grande empresa petrolífera para projetar um sistema de combate à corrupção interna. O sistema deve executar de forma distribuída nos 5 escritórios da empresa espalhados pelo país, coletando dados dos postos de gasolina, 20 plataformas de petróleo, 30 centros de distribuição de combustível e 10 refinarias. Não há um único ponto de centralização do sistema, os 5 escritórios são independentes. O sistema utilizará um motor de inferência (utilizando técnicas de mineração de dados e IA para localizar suspeitas de fraudes que serão postadas publicamente, diariamente no web site da empresa). Cada compra da empresa (que acontecem a uma taxa de milhares por dia, espalhadas pelo país) pode ser com licitação ou dispensa de licitação. Além disso, cada compra pode ser de serviços, de equipamentos permanentes ou de insumos. Finalmente, cada compra pode ser via importação ou no mercado interno. Para cada tipo diferente de compra, os algoritmos de detecção de fraudes são diferentes, i.e., personalizados para cada caso. Além disso, há algoritmos próprios para detectar fraudes analisando-se a totalização dos gastos de cada unidade (posto, plataforma, centro de distribuição ou refinaria. 1.1 Descrição técnica do minimundo O objetivo desta seção é quebrar o minimundo em partes oferecendo uma descrição técnica para a construção dos diagramas. 1. O sistema deve executar de forma distribuída nos 5 escritórios da empresa espalhados pelo país; 2. Vai coletar dados de: postos de gasolina; plataformas de petróleo; centros de distribuição

3 Refinarias 3. O sistema utilizará um motor de inferência 3.1. Deve utilizar técnicas de mineração de dados e IA para localizar suspeitas de fraudes que serão postadas publicamente, diariamente no web site da empresa) 3.2. Para cada tipo diferente de compra, os algoritmos de detecção de fraudes são diferentes, i.e., personalizados para cada caso Além disso, existem algoritmos próprios para detectar fraudes analisando-se a totalização dos gastos de cada unidade (posto, plataforma, centro de distribuição ou refinaria. 4. As compras da empresa acontecem a uma taxa de milhares por dia, espalhadas pelo país e podem ser: 4.1. Com licitação ou 4.2. Dispensa de licitação 4.3. Cada compra pode ser: De serviços; De equipamentos permanentes Insumos As compras podem ser via importação ou no mercado interno; 4.5. Cada compra deve ser analisada por exatamente 3 escritórios diferentes. Consequentemente, para expressar os requisitos enumerados anteriormente, optamos pela utilização de três diagramas UML: A. Diagrama de Classe: Descrever os vários tipos de objetos no sistema e o relacionamento entre eles [1]; B. Diagrama de Implantação: Serve para descrever como os componentes de hardware e software vão estar disponibilizados no sistema [2]; C. Diagrama de Estado: Mostra os possíveis estados de um objeto e as transações responsáveis pelas suas mudanças de estado [3]. A seguir estão os diagramas e as descrições necessárias para o entendimento de cada um.

4 2 Diagrama de Classe O pacote de detecção de fraude (br.com.petrolimpa.deteccão_fraude) contém a classe MotorInferencia que coleta dados sobre a compra, assim como localiza suspeitas de fraude nas unidades que fazem compra, publica as suspeitas de fraudes no site da unidade corporativa, e detecta fraude através da análise da totalização dos custos de todas as unidades. No pacote de compras, as funções de cada classe serão enunciadas a seguir: 1. Compra: possui dois atributos que são os responsáveis por determinar a modalidade de compra. O primeiro atributo localidadecompra do tipo LocalidadeCompraEnum que determina se a compra terá localidade no mercado interno ou via importação. Já a segundo, a modalidadecompra do tipo ModalidadeCompraEnum

5 determinará se a compra é com ou sem licitação. Obs: será partir dos tipos de modalidade e localidade de compra que o motor de inferência vai utilizar algoritmos de IA para determinar se houve, ou não, fraude na compra. 2. Refinaria/Plataforma/CentroDistribuição/Posto: realizam compras distintas de acordo com as especifidades da unidade e representa fisicamente todos os atributos e características de uma refinaria física. Como este diagrama oferece uma perspectiva conceitual [1] do minimundo, os detalhes que representam a unidade física está fora do escopo deste diagrama. 3. Escritório: Representa a unidade física dos cinco escritórios que são independentes nas suas análises de detecção de fraude; 4. EscritorioAnalisador: Representa um dos três escritórios escolhidos pelo motor de inferência para analisar as detecções de fraude. Ele pode analisar uma compra individual e as compras de uma unidade. Obs: Nos próximos modelos serão detalhados os tipos de análise que um EscritorioAnalisador pode fazer. Este diagrama de classe oferece uma perspectiva conceitual [1] que representa os conceitos do minimundo apresentado e não contém todas as especificações que deverão ser tratadas em reuniões futuras com o cliente afim de validar as funcionalidades com o cliente.

6 3 Diagrama de Implantação No diagrama de classes optamos pela criação de um servidor de aplicação que será o back-end(:servidoraplicacaocompras) do nosso sistema de compras e servirá como uma API REST para que outras instâncias possam, além de analisar os dados por ela gerados, também possam enviar dados para o armazenamento dos dados de compra e ela possa oferecer dados criptografados via HTTPS para o Motor de Inferência. Essa arquitetura permite também que cada unidade de compra possa adotar a solução cliente que desejar. E como as taxas de transação são de milhares por dia, a utilização da arquitetura REST torna-se viável. O motor de inferência utiliza o protocolo HTTPS para fazer a inferência nos escritórios e na API de compras de forma diferenciada a trafegar dados criptografados. Note que cada escritório possui uma instância distribuída do sistema interno de corrupção, o que dá autonomia completa para que cada escritório tenha sua própria base de dados para analisar os dados das compras da unidades.

7 4 Diagrama de Estado Este diagrama representa os estados de uma compra por uma unidade (Escritório/Plataforma/Refinaria/Centro de Distribuição/Posto/Escritório) quando está sendo realizada. Temos inicialmente o estado em elaboração durante a digitação do mesmo até que ele seja salvo, mudando para gravado. Após o pedido ser gravado, o usuário irá solicitar a aprovação. Este parecer será emitido por um funcionário do escritório de análise. O qual poderá aprovar (aprovado) ou negar (reprovado) a compra de acordo com a sua análise. Caso a compra seja aprovada, receberá o estado aprovado e ela vai entrar em auditoria. A auditoria emitirá parecer de aprovado ou reprovado.

8 5 Ferramentas utilizadas e Conclusões Astah Community: A conclusão deste exercício mostrou que para as fases iniciais de um projeto são necessários a utilização de modelos UML para clarear o que se pretende desenvolver na solução final do software. Além disso, notamos que não precisamos utilizar de todo o aparato que a UML possui para demonstrar o que queremos quando estamos apenas na fase de conceituação do projeto. E caso seja necessário a completude dos modelos, podemos detalhá-los e modificá-los, caso necessário, em versões posteriores. 6 Bibliografia [1] Diagrama de Classes. [Online]. Available: asses/classes1.htm. [Accessado: 24-Mar-2016]. [2] Notas de Aula - MAC 441/5714. [Online]. Available: [Accessado: 24-Mar-2016]. [3] Diagrama de estados. [Online]. Available: tado/diag_estados.htm. [Accessado: 24-Mar-2016].