“A importância da informação para as organizações é hoje universalmente aceite, constituindo um dos recursos cuja gestão e aproveitamento mais influencia o seu sucesso” (Amaral, 1994). O novo SI proposto neste capítulo para a área de SGQ permite a edição de não conformidades, ações corretivas e preventivas, servindo de base a novos objetivos da gestão. Com a aplicação do Ciclo de Deming, o fim de um ciclo dá início a outro, sendo menores as probabilidades de as não conformidades voltarem a acontecer, verificando-se, assim, a melhoria contínua.
Para a especificação do sistema foi usada a Unifield Modeling Language (UML). A sua abrangência, aliada à facilidade de utilização e integração, fez com que rapidamente se transformasse num referencial na área de desenvolvimento de SI. Inicialmente, recorreu-se aos Diagramas de Packages com o objetivo de dividir a complexidade do sistema em partes menores, para uma melhor organização. Segundo o Object Management Group (OMG, 2012), um Diagrama de Packages é usado para agrupar elementos que são semanticamente relacionados, podendo ser alterados conjuntamente, proporcionando assim, uma melhor estrutura na construção do modelo do sistema. Na Figura 25 apresenta-se o Diagrama de Packages do novo sistema.
Figura 25 - Diagrama de Packages relativo à organização do SGQ SASUTAD
A UML define os Diagramas de Casos de Uso para representar graficamente os casos de uso do sistema e as suas relações. Na especificação dos casos de uso evita-se o uso de termos técnicos, preferindo-se a linguagem corrente. O Diagrama de Casos de Uso representa a funcionalidade do sistema na perspetiva do utilizador, descrevendo os eventos realizados pelos atores no uso do sistema. As aplicações mais comuns são (Silva e Videira, 2005):
Modelar o contexto de um sistema: a ênfase encontra-se na identificação das fronteiras do sistema, dos seus atores e no significado das suas funções;
Modelar os requisitos de um sistema: identificação do que o sistema deve fazer, independentemente de como o sistema o deve realizar.
A modelação, como referido anteriormente, é uma componente central das atividades que conduzem à concretização de SI bem fundados. Segundo (Ribeiro, 2008) “a modelação constitui uma técnica de engenharia com provas dadas, visto que a criação de modelos permite antever o produto final e raciocinar sobre ele”.
Numa primeira fase, na construção do modelo funcional, foram identificados os atores do sistema, nomeadamente, os clientes internos e externos, o gestor da qualidade, o administrador e os técnicos de manutenção. Ao analisar um caso de uso, o utilizador pode verificar as funcionalidades que o sistema irá disponibilizar. Para verificar o tipo de interação existente entre os diferentes componentes do sistema é necessário definir os seus relacionamentos, podendo ser de vários tipos: association, extend, include ou generalization. Os relacionamentos do tipo association, verificam-se entre os atores e os casos de uso. Os casos de uso, devem ser sempre iniciados por um ator, com exceção em casos de uso com relacionamentos include, extend e generalization. Os relacionamentos do tipo include permitem indicar que um caso de uso utiliza as funcionalidades disponibilizadas por outro caso de uso. Os relacionamentos do tipo extend, utilizam-se entre dois casos de uso, quando se pretendem aumentar funcionalidades de algum caso de uso. Os relacionamentos tipo generalization são usados quando vários atores ou vários casos de uso têm algo em comum. Na Figura 26 pode-se observar o Diagrama Caso de Uso Gestor da Qualidade, encontrando-se representados graficamente os casos de uso e os seus relacionamentos. O Gestor da Qualidade desempenha um papel central no SI, pois o seu raio de ação é transversal a toda a organização do SGQ SASUTAD. Na Figura 27 apresenta-se o Diagrama de Casos de Uso Clientes. Depois de autorizada a entrada no sistema, o cliente interno poderá enviar não conformidades, ações preventivas e ações de manutenção preventivas assim como solicitar a aprovação de modelos de impressos. O cliente externo poderá submeter reclamações, consultar a agenda da qualidade e a legislação relacionada. Na Figura 28 apresenta-se o Diagrama Casos de Uso Administrador, onde são representados os casos de uso relacionados essencialmente com a supervisão de todo o SGQ SASUTAD. Neste projeto usou-se a ferramenta StartUML, em detrimento de ferramentas comerciais.
Na Figura 29 pode-se visualizar o Diagrama Casos de Uso Técnico de Manutenção. Os casos de uso resumem-se essencialmente às ações de planeamento, análise e execução de manutenções.
3.1 - Componente estrutural do sistema
Na área dos SI, é comum recorrer-se a linguagens de modelação para auxiliar no desenho de bases dados relacionais. Segundo (Ramos, 2007) “o Diagrama de Classes possibilita desenhar uma base dados relacional recorrendo a conceitos com um nível de abstração mais elevado e, por essa razão, mais próximo do profissional não informático”.
Uma classe é a descrição de um conjunto de objetos que partilham os mesmos atributos, operações, relações e a mesma semântica. Uma instância é caraterizada por ser uma abstração, à qual um conjunto de operações pode ser aplicado.
Um objeto é uma instância de uma classe, herdando todos os atributos e métodos definidos na própria classe que possui uma representação de execução própria, a qual se pode designar genericamente por estado, bem como uma identificação única no contexto da sua execução. Na Figura 30, está representado o Diagrama de Classes do novo sistema desenvolvido.
3.2 - Mapeamento entre Diagrama de Classes e o Modelo Relacional
A transposição do Modelo de Classes para o Modelo Relacional tem como objetivo final a criação de uma base dados relacional. As regras da transposição asseguram que:
Não ocorre perda da informação;
Não existe informação redundante no Modelo Relacional. As regras de mapeamento são caraterizadas por (Ramos, 2007):
As classes e associações do tipo “muitos para muitos” dão origem a tabelas;
As tabelas não têm de ter a mesma designação das classes ou associações que lhes deram origem;
Todos os atributos de uma classe são atributos da tabela que i) implementa a associação ou ii) herda as chaves primárias das restantes tabelas;
As tabelas que implementam os argumentos da associação herdam a chave primária das outras tabelas como chave estrangeira;
As tabelas cujos registos são suscetíveis de serem relacionados com apenas um registo da outra tabela herdam como chave estrangeira a chave da tabela cuja correspondência é unitária.
3.3 - Modelo Relacional
O Modelo Relacional foi proposto em 1970 e começou a ser utilizado comercialmente no início dos anos 80. Segundo (Ramos, 2007), “o seu sucesso deveu-se essencialmente à sua simplicidade e consequente facilidade de utilização”. De acordo com (Carvalho et al., 2008), “no desenho de bases dados devemos concentrar-nos primeiro nas entidades ou objetos e nas suas caraterísticas e relações, antes de se decidir sobre a forma como eles devem ser implementados”.
Uma entidade é um conjunto de objetos, acontecimentos ou conceitos sobre o qual pretendemos guardar dados. Uma instância de uma entidade é um elemento desse conjunto. Um atributo de uma entidade é uma caraterística específica dessa entidade, podendo ser simples ou composto.
No presente trabalho, o SI é composto por treze entidades, que se passam a descrever:
A entidade Cliente, é composta pelos atributos Cod Cliente, Tipo Cliente, Nome Cliente, Contato, Observacoes e Email. Existindo a necessidade de identificar de forma única cada entidade, esta faz-se através da chave primária (Cod Cliente). O atributo Tipo Cliente permite- nos distinguir entre cliente interno ou cliente externo. O atributo Email, guarda o endereço de correio eletrónico do cliente possibilitando uma resposta eficaz.
A entidade Ficha Movimento Doc é composta pelos atributos Cod Movimento e Num Impresso (chave composta), Cod Impresso, Atualizacao, Revisao, Data Movimento, Data Aprovacao, Cod Cliente, Anexos Ativos, Anexos Obsoletos e Anexos Gestão. O atributo Cod Cliente é chave estrangeira.
A entidade Modelos de Impressos é composta pelos atributos Num Impresso, Cod Impresso, Denominacao e Cod Estrutura. O atributo Num Impresso é a chave primária e o atributo Cod Estrutura é a chave estrangeira. O campo Cod Estrutura permite associar um modelo de impresso a um setor dos SASUTAD.
A entidade Unidades é composta pelos atributos Cod Unidade, Denominacao, Cod Estrutura e Anexo. O atributo Cod Unidade é a chave primária e o atributo Cod Estrutura é a chave estrangeira. O campo Cod Estrutura permite associar uma unidade a um setor dos SASUTAD. O campo anexo permite guardar as plantas das unidades operacionais.
A entidade Estruturas é composta pelos atributos Cod Estrutura (chave primária), Denominacao e Observacao.
A entidade Categoria, é composta pelos atributos Cod Categoria (chave primária), Denominacao e Observacoes.
A entidade Registo de não Conformidade, é composta pelos atributos Cod NConf (chave primária), Cod Unidade (chave estrangeira), Ano, Data Nconf, Tecnico Manutencao, Resumo Nconf, Descricao Nconf, Responsavel Nconf, Correcao NConf, Observacoes, Doc Anexo, Entrou, Cod Cliente, Email, Formulario Report, Modelo Impresso, Analisada e Resposta. O atributo Cod Cliente é chave estrangeira.
A entidade Ação Preventiva, é composta pelos atributos Cod Acao Prev (chave primária), Cod Cliente e Cod Unidade (chaves estrangeiras), Data Acao Prev, Resumo Acao Prev, Motivo,
Responsavel Implementacao, Parecer Tecnico, Ano, Resposta, Email, Solucao, Solucao Acao Prev e Valor Acao Prev. O campo Cod Cliente está associado ao emissor do pedido.
A entidade Ação Corretiva, é composta pelos atributos Cod Acao Corretiva (chave primária), Ano, Causas NConf, Origem Materias-primas, Origem Meioambiente, Origem Infraestrutura, Origem Trabalhadores, Origem Equipamentos, Descricao Acao Corretiva, Data Registo, Interv Analise Causa1, Interv Analise Causa2, Interv Analise Causa3, Interv Analise Causa4, Responsavel Implem, Data Prevista Conclusao, Eficacia Implem, Eficaz, Analisar Situacao, Data Eficacia, Cod Nconf, Data Conclusao, Anexos, Entrou, Data Nova Analise,Cod Admin, Variavel Tempo, Estimativa Despesa, Valor Despesa, Carrega Acao Corretiva, Acao Corretiva Encerrada e Resposta Acao Corretiva. O campo Cod Acao Corretiva (chave estrangeira) permite associar uma ação corretiva a uma não conformidade, carregada anteriormente no sistema.
A entidade Ficha Manutenção Preventiva, é composta pelos atributos Cod Manutencao Prev e Tipo Manutencao Prev (chave composta), Cod Cliente e Cod Unidade (chave estrangeira), Data, Observacoes e Plano Intervencoes.
A entidade Detalhes de Manutenções Preventivas, é composta pelos atributos Cod Manutencao Prev, Tipo Manutencao Prev, Cod Equipamento (chave composta), Cod Empresa Man (chave estrangeira), Valor e Ficha Tecnica.
A entidade Empresa Manutencao é composta pelos atributos Cod Empresa Man (chave primária), Tipo Empresa Man, Nome e Observacoes.