Trabalho de Modelagem UML

(1)

Trabalho de Modelagem UML

Curso de Programação Orientada a Objetos

Prof. Fábio Kon

(2)

Introdução

Foi solicitado pelo prof. Fábio Kon da disciplina de POO (MAC0441) a modelagem de 3 diagramas UML de um sistema hipotético para detecção de fraudes de uma petrolífera. Para elaboração dos diagramas foi fornecida um texto com especificações de entidades e funcionalidades necessárias no sistema. Este texto é apresentado abaixo.

“Sistema PetroLimpa

Você foi contratado 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 1.000 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.

Cada compra deve ser analisada por exatamente 3 escritórios diferentes.”

Observa-se que ainda existem muitas especificações em aberto, como por exemplo, a especificação de tecnologias para implantação do sistema, informações de controle de acesso, detalhes mais específicos das entidades, os possíveis algorítimos que podem ser utilizados pelo motor de inferência etc. Sendo assim, a modelagem não restringiu o sistema além do que foi especificado no texto.

1 Diagramas UML do sistema PetroLimpa

Foram usados os diagramas de classe, de sequência e de implantação. O diagrama de classe,

além de ser uma requisição do trabalho, foi usado por ser flexível e capaz de expressar as entidades

e suas funções mesmo quando não possuem definições precisas, fornecendo uma visão geral do

sistema. O diagrama de sequência foi utilizado para ilustrar o processo de análise das ordens de

compra de um escritório e a criação dos motores de inferência de acordo com o tipo da ordem de

(3)

compra. O diagrama de implantação foi uma requisição do trabalho e é usado para mostrar o hardware, middleware, sistemas operacionais e servidores que serão usados na implantação do sistema.

2 Diagrama de Classe do sistema PetroLimpa

As classes foram retiradas com base na descrição do sistema PetroLimpa pelo texto fornecido. A Figura 1 apresenta o diagrama de classe.

Figura 1. Diagrama de classe do sistema PetroLimpa

Inicialmente foi observado que cada unidade da empresa apresenta propriedades semelhantes, como a possibilidade de realizar compras e uma localidade. A classe de UnidadeCorporativa agrupa oque cada unidade pode fazer e pode ser especializada para cada tipo específico de unidade corporativa. A classe escritório mantém os dados de todas as outras unidades e isso foi representado com as setas de uso e com as cardinalidades de instâncias assim como definidas no texto.

A classe OrdemDeCompra foi associada a classe UnidadeCorporativa, pois todas podem realizar compras. Os diferentes tipos de compra e itens (e.g., importação, nacional, insumo, equipamentos etc) são necessários para a especificação do algorítimo de inferência de fraudes. Para

Item nome: String tipo :ItemTipo origemDaCompra

<<Enumeration>>

ItemTipo Serviço Equipamento

Insumo

OrdemDeCompra - identificação - compraTipo

UnidadeCorporativa - endereço

- nome

Refinaria PostoGasolina CentroDistribuição Plataforma

Escritorio

-coletarDados(unidadeCorporativa) -inicializarMotorInf(ordensComprList)

5 1000 10

5

20

5 30

MotorInfBuilder - ordensComprList - motorDeInferenciaList + buildMotorInf (ordensComprList) + analisarOdC

3

5 1..*

MotorInfEspecifico - ordensComprList

+analisarOdC(ordensComprList) MotorInf

- ordensComprList

+analisarOdC(ordensComprList)

<<Enumeration>>

OrigemCompraTipo Importação

Nacional

<<Enumeration>>

CompraTipo Licitação SemLicitação

(4)

a classificação destes tipos foram criadas entidades anotadas com o esteriótipo Enumeration que definem nomes de tipos. Considerando que o processo de licitação pode ser burocrático, foi considerado que uma mesma ordem de compra não deveria possuir itens oriundos de aquisições sem licitação. Assim, uma ordem de compra agrupa todos os itens adquiridos apenas por um processo de aquisição, que pode ser com ou sem licitação.

Como o sistema em cada escritório deve ser capaz de analisar nos dados das ordens de compra realizada pelas outras unidades corporativas, a classe Escritorio foi implementada com os métodos coletarDados que coleta os dados de uma outra unidade e com o método inicilizarMotorInf que delega o processo de criação do motor de inferência de fraudes para a classe MotorInfBuilder que constrói o motor de inferência. Observa-se que o uso de padrão de projeto Builder pode ser aplicado para a construção das instâncias que representam cada algorítimo de inferência específico para um dado tipo de compra e item.

3 Diagrama de Sequência do Motor de inferência

O diagrama de sequência apresenta o processo de coleta e análise de dados em uma unidade corporativa (Figura 2).

Figura 2. Diagrama de sequência do motor de inferência de fraudes

Inicialmente o escritório precisa coletar os dados as serem analisados em uma unidade corporativa (1.1). Em seguida o escritório delega (1.3) o processo de criação dos motores de inferência para uma instância da classe MotorInfBuilder que irá criar o motor de inferência (1.4)

1.3 inicializarInf (ordensCompra)

motInfB:MotorInfBuilder

sd analisarOrdemdeCompra

escrt01: EscritorioSys :UnidadeCorporativa

1.1 coletarDados(unidCorp) 1.2 dadosUniCorp

1.6 resultadoAnalise

1.4 buildMotorInf (ordensCompra)

loop [para cada tipo de item e ordem de compra]

1.5 analisarOdC

loop [para cada motor de inferencia construido]

MotorInfSpecifico

1.7 resultadoAnalisedeTodasOdC

(5)

específico para cada tipo de compra presente na lista de ordens de compra. Finalmente em 1.5 cada motor de inferência especializado para um dado tipo de compra analisa os dados da compra e retorna um resultado(1.6).

4 Diagrama de Implantação do sistema PetroLimpa

Como não foi especificado restrições quanto a configuração dos servidores e serviços no sistema, a presente modelagem apenas destacou os tipos dos nós e as suas relações necessárias para realização do sistema (Figura 3).

Figura 3. Diagrama de sequência do motor de inferência de fraudes

Como foi especificado que a arquitetura devia ser descentralizada, foi desconsiderada uma solução na nuvem. Assim cada unidade possui uma instância do sistema em uma infraestrutura de hardware local. Admitiu-se apenas o uso da Internet e do protocolo TCP, já que a comunicação deve garantir confiabilidade nos dados. No entanto, destaca-se que seria interessante o uso de contratos de interface bem definidos com uso de WSDL/SOAP para comunicação entre os servidores.

5 Conclusão

Foram apresentados três diagramas UML, no qual dois são estáticos e um é dinâmico. O diagrama de classe apresentou em alto nível as entidades, as suas relações, propriedades e possíveis funções do sistema. O diagrama de sequência mostrou uma execução do processo de coleta, criação dos motores de inferência e de análise dos dados. Por último, o diagrama de implantação apresentou uma arquitetura decentralizada do sistema, onde cada unidade corporativa teria uma infraestrutura e uma instância do sistema.

<<device>> :Server

<<artifact>>

EscritorioSys

<<device>> :DBServer

<<database system>>

OfficeDB

<<device>> :Server

<<artifact>>

PostoSys

<<device>> :Server

<<artifact>>

CentrDistrSys

<<device>> :Server

<<artifact>>

PlataformaSys

<<device>> :Server

<<artifact>>

RefinariaSys

<<database system>>

PostroDB

<<database system>>

RefinariaDB

<<database system>>

CentroDistrDB

<<database system>>

PlataformaDB

5 5 5 5

1000

10

30

20

<<protocol>> TCP/IP

<<protocol>>

TCP/IP

<<protocol>> TCP/IP