Proposta conceptual com recurso à linguagem UML

Por forma a poder comunicar com as equipas de desenvolvimento, foi necessário apresentar a proposta resultante de todo este estudo num formato gráfico e do conhecimento dos programadores. Como tal, foi escolhida a Unified

Modeling Language (UML), por representar uma linguagem padrão, unificada e

independente de qualquer ferramenta CASE e tecnologia de programação. Booch, Rumbaugh e Jacobson (2005) explicam que a modelação de sistemas complexos se deve ao facto de não ser possível a compreensão desse tipo de sistemas no seu todo, e encontram-se explicadas e exemplificadas as regras de aplicação desta linguagem na sua obra.

Segundo Dennis, Wixom e Tegarden (2012), a UML constitui uma forma de vocabulário em forma de diagramas orientado a objetos, que permite a modelização de qualquer tipo de sistema a partir da sua análise e no sentido da sua implementação. Explicitam também que, sistemas orientados a objetos focam-se na estrutura e comportamento dos sistemas de informação, particularmente no que diz respeito a processos, dados e mensagens, de forma concisa e detalhada em pequenos módulos. Estes módulos constituem objetos, que podem ainda ser descritos por atributos que descrevem toda a informação relativa a cada objeto.

A UML foi, assim, utilizada com o propósito de apresentar ao software

developer o modo de funcionamento pretendido para o sistema informático, as

principais interações e a informação relevante a ser contemplada, ou seja, os requisitos funcionais do sistema. A visão contemporânea do desenvolvimento de

software tem em conta, ou é centrada, em objetos (Booch et al., 2005), assim

sendo o foco desta modelização será na definição destes objetos e sua modelização.

Desenvolveram-se 3 modelos, o diagrama de Use-Cases (Figura 55), o diagrama de Classes (Figura 56) e o diagrama de sequências (Figura 57 e 58).

Figura 55 - UML: Diagrama de Use-Cases do sistema MES

O Diagrama de Use-Cases é a ferramenta principal e que guia toda a modelação (Dennis, Wixom, & Roth, 2012). Representa as principais utilizações em termos de input e output que se pretende que sejam respondidas pelo sistema MES a implementar.

Os principais Atores em termos de input de informação serão os PLCs das máquinas, os operadores (ou MODs) que neste diagrama são considerados apenas os operadores de linha, a BLE (Bluetooth Low Energy) que é uma tecnologia que permite obter localização geográfica de um material através da acoplação de um dispositivo, a RFID e os responsáveis pelos controlos de

qualidade. Em termos de output, os principais atores serão os TGPs e os CUETs que irão receber e analisar a informação relacionando-a com os seus objetivos. Os “sistemas de informação” representados como atores, correspondem aos sistemas identificados no ponto 3.5 e já presentes nas infraestruturas da fábrica, que desempenham já funções relacionadas com a rastreabilidade, qualidade ou

stocks.

O Diagrama de Classes (Figura 56) apresenta claramente as principais informações a guardar no sistema para os objetivos do projeto. Explicita também alguns modos de funcionamento reais que devem estar presentes no MES e constituem factos importantes no próprio desenvolvimento do sistema. Cada classe representa um objeto (real ou virtual), cada objeto é caracterizado por atributos que podem ter valores diferentes e existem ainda relações entre objetos que podem ter diferentes multiplicidades. Por exemplo, diz-se que um lote ou embalagem contém apenas um tipo de componentes, mas que o mesmo tipo de componentes pode constituir lotes diferentes. Ainda a título de exemplo, deixam- se claras as principais informações acerca de um componente, o tipo (PL 1ª, 2ª, etc…), a referência da peça que é única para cada componente e difere mesmo dentro de componentes do mesmo tipo como especificado no ponto 3.2. As Classes podem representar também a informação contida no hardware, por exemplo a RFID, e as interações que tem com outros objetos ou com o sistema. Podem ainda dar informação dos dados de saída que se pretendem obter, como por exemplo, os KPIs.

Posto isto, pode dizer-se que cada objeto pertencente a uma classe é descrito através do valor dos respetivos atributos e da sua identidade, podendo relacionar- se com outros objetos de classes diferentes ou da mesma classe. Esta definição encontra-se também presente em Dennis, Wixom e Tegarden (2012), e constitui um ponto-chave na definição deste sistema.

Figura 56 - UML: Diagrama de Classes do MES

Mais uma vez, é importante referir que constam nos diagramas apresentados apenas as informações mais relevantes, não sendo levadas ao detalhe uma vez que os parceiros que irão desenvolver o projeto juntamente com a equipa Renault terão também eles que compreender o processo. Após a realização desse reconhecimento, estarão aptos a interpretar os presentes diagramas de acordo com as definições e especificidades definidas para o projeto e principais objetivos.

Os diagramas de sequências, representados nas Figuras 57 e 58, descrevem interações ao nível dos objetos, comportamentos de classes perante determinados eventos e/ou operações mostrando também as sequências de mensagens ao longo do tempo (Dennis, Wixom, & Roth, 2012), e por isso, foram utilizados para representar as trocas de informação entre Homem, Sistema e outros elementos físicos como máquinas, veículos, embalagens e outros. Nestes Diagramas, os MODs são considerados operadores que interagem com o sistema

e não exclusivamente os operadores de linha. Ou seja, estão incluídos os técnicos de qualidade, os CUETs e os TGPs como operadores ou MODs do sistema. Mais uma vez, são representados os principais intervenientes e não a totalidade.

Figura 58 - Interação para controlo de qualidade

Os diagramas UML aqui apresentados foram realizados após compreensão do problema. Este estudo é de importância elevada uma vez que uma má definição e explicitação das necessidades, objetivos e modos de funcionamento pode levar à aquisição de ferramentas que não respondem a essas necessidades. O diagrama de Use-Cases define claramente as principais funcionalidades às quais os TGPs, CUETs e Técnicos de Qualidade devem ter acesso, assim como as funções críticas e cruciais ao bom funcionamento do sistema no que toca a input de dados e output de informação.

O diagrama de Classes apresenta claramente a relação entre diferentes entidades do sistema, os principais objetos de informação a guardar pelo sistema a desenvolver e relações entre estes.

Finalmente, os diagramas de sequência, serviram para mostrar as interações entre diferentes objetos, neste caso atores e sistemas informáticos, através da troca de mensagens. A comunicação entre estas entidades acaba por ser um modo de funcionamento da tecnologia que fica definido em UML. Importa também realçar que este tipo de diagrama oferece a possibilidade de esquematizar um processo resultante da interação entre sistemas físicos, virtuais e entidades “humanas” constituindo por isso uma linguagem aplicável a CPSs.

É de realçar que os diagramas apresentados serviram para definir claramente as principais necessidades e objetivos a terceiros (Programadores da solução). O sistema terá muitas outras funcionalidades que levariam estes diagramas a tornarem-se extremamente vastos e complexos. O foco é então cumprir com as principais definições e requisitos, garantindo que nesses aspetos não existem equívocos.